When removing the focus widget of a GimpToolWidgetGroup, use the
last child, rather than the first child, as the new focus widget.
This plays nicer with auto-raise, and is probably better anyway.
When a focused widget is added to a group, make it the new focus-
widget of the group, instead of unsetting its focus if another
widget already has focus.
When removing the focused widget from a group, set a different
widget as the group's focus widget (if one exists), instead of
unsetting the focus widget, so that nonempty groups always have a
focus widget.
In gimp_tool_widget_group_button_press(), explicitly call
gimp_tool_widget_group_hover() before forwarding the event to the
group's hover widget, so that the hover widget gets recalculated.
If a widget is added to the group as a result of a button-press
event, this guarantees that it gets considered as a target for the
same event.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
In GimpCanvasTransformPreview, add the necessary bits to the
preview graph so that, when transforming a layer, the layer's
opacity and mask are correctly applied to the preview. Note that
since we're still not rendering the preview as part of the image
graph, the output is not always accurate, but it should be good
enough in most cases.
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06f
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
All babl formats now have a space equivalent to a color profile,
determining the format's primaries and TRCs. This commit makes GIMP
aware of this.
libgimp:
- enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA
as deprecated aliases, add PERCEPTUAL values so we now have LINEAR,
NON_LINEAR and PERCPTUAL for each encoding, matching the babl
encoding variants RGB, R'G'B' and R~G~B~.
- gimp_color_transform_can_gegl_copy() now returns TRUE if both
profiles can return a babl space, increasing the amount of fast babl
color conversions significantly.
- TODO: no solution yet for getting libgimp drawable proxy buffers in
the right format with space.
plug-ins:
- follow the GimpPrecision change.
- TODO: everything else unchanged and partly broken or sub-optimal,
like setting a new image's color profile too late.
app:
- add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as
replacement for all "linear" booleans.
- change gimp-babl functions to take babl spaces and GimpTRCType
parameters and support all sorts of new perceptual ~ formats.
- a lot of places changed in the early days of goat invasion didn't
take advantage of gimp-babl utility functions and constructed
formats manually. They all needed revisiting and many now use much
simpler code calling gimp-babl API.
- change gimp_babl_format_get_color_profile() to really extract a
newly allocated color profile from the format, and add
gimp_babl_get_builtin_color_profile() which does the same as
gimp_babl_format_get_color_profile() did before. Visited all callers
to decide whether they are looking for the format's actual profile,
or for one of the builtin profiles, simplifying code that only needs
builtin profiles.
- drawables have a new get_space_api(), get_linear() is now get_trc().
- images now have a "layer space" and an API to get it,
gimp_image_get_layer_format() returns formats in that space.
- an image's layer space is created from the image's color profile,
change gimpimage-color-profile to deal with that correctly
- change many babl_format() calls to babl_format_with_space() and take
the space from passed formats or drawables
- add function gimp_layer_fix_format_space() which replaces the
layer's buffer with one that has the image's layer format, but
doesn't change pixel values
- use gimp_layer_fix_format_space() to make sure layers loaded from
XCF and created by plug-ins have the right space when added to the
image, because it's impossible to always assign the right space upon
layer creation
- "assign color profile" and "discard color profile" now require use
of gimp_layer_fix_format_space() too because the profile is now
embedded in all formats via the space. Add
gimp_image_assign_color_profile() which does all that and call it
instead of a simple gimp_image_set_color_profile(), also from the
PDB set-color-profile functions, which are essentially "assign" and
"discard" calls.
- generally, make sure a new image's color profile is set before
adding layers to it, gimp_image_set_color_profile() is more than
before considered know-what-you-are-doing API.
- take special precaution in all places that call
gimp_drawable_convert_type(), we now must pass a new_profile from
all callers that convert layers within the same image (such as
image_convert_type, image_convert_precision), because the layer's
new space can't be determined from the image's layer format during
the call.
- change all "linear" properties to "trc", in all config objects like
for levels and curves, in the histogram, in the widgets. This results
in some GUI that now has three choices instead of two.
TODO: we might want to reduce that back to two later.
- keep "linear" boolean properties around as compat if needed for file
pasring, but always convert the parsed parsed boolean to
GimpTRCType.
- TODO: the image's "enable color management" switch is currently
broken, will fix that in another commit.
In GimpToolCompass (and, as a consequence, in the measure tool),
update the measured angle when the shell is scaled, rotated, or
flipped, so that we always satisfy the compass's constrains, and
render correctly.
When using a GimpToolCompass in 3-point mode, add a small gap after
the angle arc to the line corresponding to the "second" non-origin
point, so that it's visually distinguishable from the line
corresponding to the "first" point. This has significance for the
measure tool, since it determines the direction of the rotation
when straightening the image (the first point is rotated toward the
second point.)
Add an "orientation" property to GimpToolCompass, which can be one
of "auto", "horizontal", or "vertical", and which controls the
orientation of the line against which the angle is measured, when
not in 3-point mode (previously, the line would always be
horizontal.) When "orientation" is "auto", the orientation is
automatically set to either horizontal or vertical, such that the
measured angle is <= 45 deg.
Keep the line horizontal, or vertical, in display-space, rather
than in image-space, so that the compass works correctly even when
the canvas is rotated and/or flipped.
Fix the compass's behavior when the image's horizontal and vertical
resolutions are different, both with and without dot-for-dot.
Add "pixel-angle" and "unit-angle" read-only properties, which
return the measured angle either with or without taking the image's
resolution into account, respectively. These properties will be
used by the measure tool in the next commit, instead of having it
implement its own angle calculation.
Fix gimp_constrain_line() and friends to properly constrain line
angles when the image's horizontal and vertical resolutions are
different, and dot-for-dot is disabled.
- remove gimp_widget_flush_expose()
- remove the "now" argument to gimp_display_shell_flush() and make it
only update widget states
- rename gimp_display_flush_whenever() to gimp_display_flush_update_region()
and call gimp_display_shell_flush() separately in the only case we
passed FALSE to flush_whenever()
- remove th flush_now interval logic from GimpDisplay, as soon as we
have exposed the canvas, we are in the loop for the next frame clock
tick anyway, so delaying a useless and removed process_updates serves
no purpose
- in gimptool-progress.c, create the invisible grab widget also for
non-cencelable cases, so we can always safely run the main loop
manually to make the progress updates visible
- in gimp-gegl-apply-operation.c, always run the main loop manually
to make the progress updates visible
- in gimpstatusbar.c, leave some FIXME comments as reminder that
we might need the same logic as in gimptool-progress.c
which means we can't setup scrollbars there. Move the code to a
GtkTickCallback which runs before the next frame after the
size-allocate.
Also put the center_image_on_size_allocate() code there because it has
to run after the canvas' tick callback, and the order of tick
callbacks can't be controlled.
As a side effect we now have a flag in GimpDisplayShell which
indicates that there will be a size allocate before the next frame, so
simply skip drawing the canvas completely. This fixes new images
jumping around when they are first shown.
In GimpCanvasTransformPreview, when the image mask is not empty,
make sure to align it with the drawable using a gegl:translate
node, before combining both at the gegl:opacity node. Otherwise,
the mask is applied at the wrong offset when the drawable's offset
is not (0, 0).
In GimpToolRectangle, call gimp_tool_rectangle_update_options()
when the "[xy][12]" properties change, so that the "x", "y",
"width", and "height" properties are updated accordingly.
In particular, we set these properties when committing an empty
rectangle select tool, to init the rectangle to the current
selection bounds, and this call is necessary so that the "x", "y",
"width", and "height" tool options are properly updated as well.
GimpToolWidgetGroup is a tool widget acting as a container for
child widgets, multiplexing widget events and demultiplexing tool
events. It can be used by tools to display multiple widgets
simultaneously.
The group keeps track of the current focus widget, and hover
widget. Certain events are only dispatched to/forwarded from these
widgets.
The hover widget is determined by performing a hit test for all the
children, starting from the last child. The first widget returning
GIMP_HIT_DIRECT, if any, is selected as the hover widget;
otherwise, if the current focus widget returns GIMP_HIT_INDIRECT,
it's selected; otherwise, if exactly one widget returns
GIMP_HIT_INDIRECT, it's selected; otherwise, there is no hover
widget.
The focus widget is set when clicking on a widget (or
programatically, using gimp_tool_widget_set_focus()).
Additionally, the group can raise the clicked widget to the top of
the stack (see gimp_tool_widget_group_set_auto_raise().)
... which takes the same arguments as GimpToolWidget::hover(), and
performs a hit-test, returning one of the following values:
- GIMP_HIT_DIRECT: The point corresponds to one of the widget's
elements directly.
- GIMP_HIT_INDIRECT: The point does not correspond to one of the
widget's elements directly, but the widget otherwise responds
to press events at this point.
- GIMP_HIT_NONE: The widget does not respond to press events at
this point.
Unlike hover(), hit() should not have any side effects.
... which should be called on a widget when the cursor leaves the
widget, i.e., when it stops receiving hover events.
Have the default implementation clear the tool status.
The next few commits are going to add support for using multiple
tool widgets simultaneously. As a first step, add a notion of a
focused tool widget, by adding gimp_tool_widget_{set,get}_focus(),
which tools/subclasses can use to control focus, and a
corresponding "focus-changed" signal, which tools/subclasses can
use to respond to focus changes.
When Control-Button2-Zooming, remember the start point, pass it to
gimp_display_shell_scale_drag() and force gimp_display_shell_scale()
to zoom around that point by passing GIMP_ZOOM_FOCUS_POINTER and
faking the point using gimp_display_shell_push_zoom_focus_pointer_pos().
Reset the canvas size request from gimp_display_shell_constructed() in
gimp_display_shell_canvas_size_allocate() so the image window can be
made smaller again. GTK+ 3.x always respects size requests.
Remove all clipping hacks for drawing the canvas background, turns out
they never worked and we were relying on the pattern set on the
window, gah!
Also remove deprecated attempts to get a backgroud color and simply
don't show a color box in the menus for "from theme" cases.
we were not using a single GtkStatusBar features, it was only in the
way. Remove broken size allocation logic and simply set a minimum
height of 3em in CSS. Also ellipsize the label, long labels had funny
effects since changing the overall GimpDisplayShell packing to pure
GtkGrid.
- Fix gimp_scroll_adjustment_values() for smooth scroll events
- Set GDK_SMOOTH_SCROLL_MASK on all widgets where we set GDK_SCROLL_MASK
- Add GIMP_ZOOM_SMOOTH to enum GimpZoomType
- Add "gdouble delta" to gimp_zoom_model_step()
- Change the meaning of the "scale" parameter to "scale or delta" in
all functions that take GimpZoomType and a scale factor.
In gimp_display_shell_canvas_tool_events(), use
gdk_window_set_event_compression(), instead of implementing our own
motion compression, which used to introduce all sorts of weird
effects when combined with extended input devices, that we had to
hackishly work around.
For tools that use GIMP_MOTION_MODE_EXACT, we call
gdk_window_set_event_compression() to disable motion compression
for the canvas window upon initializing the tool in response to a
GDK_BUTTON_PRESS event, and again to re-eanble compression upon the
corresponding GDK_BUTTON_RELEASE event.
This commit also merges
gimp_display_shell_canvas_tool_events_internal() back into
gimp_display_shell_canvas_tool_events(). The split was a detail
of our custom motion compression implementation.
In gimp_display_shell_draw_image(), enable the code that adjusts
the scale-factor used for rendering the image by the window scale
factor, so that we make full use of the screen resolution even on
HiDPI displays. This also fixes artifacts along render-chunk
borders.
and use it where we used to pass gimp_button_menu_position() to
gimp_ui_manager_up_popup(), remove gimp_button_menu_position() because
it's now unused.
- add new "device from event" apparatus that works on GTK+ 3.x
- fix the active device selection mechanism
- use the new device grabbing functions
- make sure we don't process events while we have a grab on
another device
- compensate for some really obscure (and likely broken) behavior
of XI2, it feels like we are the first real users...
... _even at low zoom levels_
Pass GIMP_ZOOM_FOCUS_POINTER to gimp_display_shell_scale() when
wheel-scrolling, and change the scaling code to really honor
GIMP_ZOOM_FOCUS_POINTER and not apply magic image centering.
This keep the same point centered under the mouse for wheel-scrolling
and the zoom tool (== when the zooming is really triggered at a
certain mouse position).
GimpDeviceInfo is the only way to store per-device settings like
color, brush etc. It used to be derived from GimpContext and therefore
limited to the context's properties, causing everything else (all
tool-individual options) to be lost on device change.
Derive it from GimpToolPreset instead, so it's capable of storing
arbitrary tool options.
Adapt things to the new class hierarchy and add a bunch of signal
handlers that make sure the active device's GimpDeviceInfo is updated
properly when the tool changes. Also change device switching
accordingly.
Change GimpDeviceStatus to only show the stuff that is relevant to
each device's tool.
And various small changes to make things work properly...
Commit b279c2d217 was breaking a specific use case, which I oversaw:
when space bar activates the move tool, you may want to release the
space bar while mouse button is pressed, and expect to still be able to
move the layer/selection/guide, but releasing space was stopping the
move immediately. The move tool must only be deactivated when both space
and button 1 are released, and the move itself must continue as long as
button 1 is pressed (when started while space was pressed).
As a nice side effect of this commit, panning and canvas rotation are
also improved since now they can be continued while releasing space
(respectively shift-space) if mouse button 1 was pressed, and up until
the mouse button is released. Pressing space again, then releasing the
mouse, back and forth, also work as expected (i.e. move tool stay
activated though the move stops; and panning or rotation continue).
Of course now we don't get anymore panning/rotation stuck while neither
space nor mouse buttons are pressed (which was the original bug). At
least one of these need to stay pressed for panning/rotation/move to
stay activated. And initial activation is obviously always through
(shift-)space only.
Invert zoom adjustment using the mouse or the keyboard when in
inverse mode. Take zoom factor into account when panning using the
keyboard. Fix motion cancelation.
GimpToolGyroscope is a tool widget providing canvas interaction for
3D rotation. The widget doesn't preset a UI, but rather
facilitates panning, rotation, and zoom, by dragging the canvas, or
using the keyboard.
Rotation is expressed using yaw/pitch/roll angles (performed in
this order). A zoom factor can be specified, which affects the
magnitude of the rotation per distance traveled. The widget can
operate in inverse mode, performing an inverse transformation.
Align rectangles added to the display paint area, in
gimp_display_paint_area(), to a coarse grid, to reduce the
complexity of ther overall area. This is similar to commit
49285463e6, however the alignment
happens in display space, instead of image space.
Last commit caused -xobjective-c to be passed during linking on
Mac, causing object files to be treated as source files. Add a
-xnone flag to AM_LDFLAGS, canceling the effect of -xobjective-c.
Additinally, add a -xobjective-c++ flag to AM_CXXFLAGS, so that we
can use Objective-C in C++ files on Mac, if we ever need to.
On Mac, pass -xobjective-c to the compiler through AM_CFLAGS, not
AM_CPPFLAGS, so that it's only used for C sources, and not C++
sources. In the latter case, it clashes with the -std=... flag,
spewing an error. Thanks, Partha :)
Statusbar progress updates that update the progress bar are
relatively expensive, slowing down operations that report progress
frequently. Only update the progress bar if a certain amount of
time has passed since the last update, to counter that.
Remove the connect_after() hack from GimpImageWindow again and instead
add gimp_display_shell_canvas_realize_after() and restore the configured
ruler visibility there. Should work for all cases now.
Add "ellipsize" property to GimpColorFrame and set it to
PANGO_ELLIPSIZE_END in the the pointer information dockable.
Better cut off long numbers than make them expand the dock.
gimp_image_window_constructed(): connect_after to the notebook's
"switch-page" signal so gimp_display_shell_appearance_update() is
called after gimp_display_shell_canvas_realize(). Just another hack
to fix the hack...
This keeps the same rectangle packing behaviour, so to behave exactly as
before for what concerns batching the updates, but should be lighter
when looping to find the first good rectangle to use.
In rtree_insert(), some conditions in the if tests are implied by
previous conditions. And therefore the 2 successive for loops are
actually identical.
In rtree_node_insert(), it is wrong/harmful to insert zero sized
rectangles in the tree because they can never be selected and just make
the list longer. So rtree_node_create() should just return NULL when w
or h are 0.
See bug 694917, comments 51 to 61.
As suggested by massimo in bug #694917, move unconditional creation/destruction
of a wrapper GeglBuffer object from top-level scope of the function to the
single conditional scope where it is used.
... scrolling in progress.
In particular, this could happen while panning with mouse middle click
and hitting space. This space should simply be ignored.
The bug was affecting actually both canvas rotation and panning when
done with space key. If the first mouse button was also clicked, then
released after the space key, we ended up in some stuck action. It could
only be unstuck by hitting/releasing space again.
I am actually unsure that this was not originally done on purpose,
especially since the code has these 2 status variables space_pressed and
space_release_pending, but really apart from looking at this code, the
behavior just looks very buggy and impracticable.
The new behavior is to just stop the canvas panning/rotation as soon as
space is released (which is also how it is documented in our manual, and
how everyone seems to use the feature). I only kept the variable
space_release_pending, which I use as was used space_pressed before.
Avoid redrawing GimpCanvasProgress items upon
GimpProgress::set_value() if a minimal amount of time hasn't passed
since the last call. This notably improves performance of
frequently-updated GimpCanvasProgress items.
Don't choke when calling gimp_tool_rectangle_set_constraint() while
there's no active image, or while the active image has no active
layer, which can happen when updating the default aspect ratio of
the crop tool. This would previously result in CRITICALs.
Additionally, use weak pointers for the crop tool's current_image
and current_layer members, to avoid potential dangling pointers.
While not currently necessary, this makes the code less dependent
on the exact order of events.
Since a few commits, I don't generate the traces anymore in errors.c but
delay this to gui-message.c and rely on the message severity to decide
whether or not generating traces.
Unfortunately none of the current severities are properly describing
this new type of messages. Even GIMP_MESSAGE_ERROR is used everywhere in
our code NOT for actual programming bug, but often for data errors
(which are not bugs but proper messages and should obviously not prompt
a debug trace).
which is just a #define to g_assert for now, but can now easily be
turned into something that does some nicer debugging using our new
stack trace infrastructure. This commit also reverts all constructed()
functions to use assert again.
This avoids warnings when the handle positions the handle-transform
tool result in a matrix that transforms the TransformGrid's handles
(which are all invisible) to coordinates that are outside of the
corresponding properties' range.
Fix indentation, typos, style. Use array parameters for the
control points, instead of using individual by-value parameters.
Use GArray* for the results, instead of GArray**. Verify
arguments.
Adapt the rest of the code to the changes.
Add a "clip" property to GimpCavnasTransformGuides. When set, use
gimp_transform_polygon() for transforming the guides and the
bounding box, so that they're properly clipped.
Add a corresponding "clip-guides" property to
GimpToolTransformGrid, and set it to TRUE in GimpToolHandleGrid, so
that the handle-transform tool's guides are clipped properly.
the angle arc and the small helper line were displayed on opposite
sides of the first point. Now they are on the same side, just like for
all other angles.
... gimp_transform_matrix_generic()
Replace the separate x/y coordinate arrays of GimpHandleGrid with
GimpVector2 arrays, and use gimp_transform_matrix_generic(),
instead of gimp_transform_matrix_handles(), when calculating the
matrix. When the resulting matrix is invalid, hide the guides.
... which can be used to control the guides' visibility.
Will be used by the next commit, to hide the guides in
GimpToolHandleGrid when the tranformation is invalid.
...if "Show rulers" is disabled
Add HACK to gimp_display_shell_canvas_realize() that makes sure the
rulers are always mapped once for each new GimpDisplayShell. This
seems to magically fix all the crashes.
Before you get too exceited -- no, this commit doesn't integrate
transform previews into the image graph :) We still use a
separate canvas-item overlay, just like before, but instead of
using an impromptu implementation to render the preview, we use
gegl:transform. We properly adjust the matrix passed to the op
according to the display scale, so that we still render only as
much as needed.
This is both notably faster than the current code, and, for
perspective transforms, more accurate.
This reverts commit 36258a671a.
This commit was making the rotated canvas rendering quite horrible to
the point that I think it would make the canvas rotation feature barely
usable. See bug 759287, comments 13 to 18.
I think we will need to find other ways to accelerate rendering.
Compromise on quality is possible, but I think that in this case, this
was more than just a compromise. It was more like completely abandonning
quality. We could even see the lines "spiking" while you were rotating!
Like your drawing was alive!
Improve the disabling/enabling of extended input events for the
canvas during enter/leave-notify events, in particular, so that
enter-notify events that are a result of pointer ungrabbing don't
erroneously reeanble extended input events.
Something about the unqueueing and requeueing of the entire event
queue during motion compression fries GTK's brain w.r.t. extended
input events. Instead, have gimp_display_shell_compress_motion()
return the first non-compressed event to the caller, making it
responsible for dispatching it after handling the motion event.
...outside area of Crop Tool -> Highlight option
Add "highlight-opacity" property and turn the controlling GUI into an
expanding toggle that reveals an opacity slider.
After commit 8029508fbe, we always
render the image in chunks that are at most
GIMP_DISPLAY_RENDER_BUF_WIDTH x GIMP_DISPLAY_RENDER_BUF_HEIGHT,
even when the window's scale factor is > 1.
Replace the "lock brush size to zoom" paint option with a "lock
brush to view" option, which links the entire brush transform to
the view transform, so that the brush remains invariant in display
space under scaling, rotation, and reflection.
When you move an endpoint in the Blend Tool, angle and distance
information are especially important, in case you want to draw a
gradient with specific values.
Currently Blend tool only shows the vector coordinates whose usefulness
is a bit of a question. Now it will also show distance (in current shell
unit) and angle!
Add an offset_angle parameter to gimp_constrain_line(), which
offsets the radial lines by a given angle.
Add gimpdisplayshell-utils.[ch], with two new functions:
- gimp_display_shell_get_constrained_line_offset_angle():
Returns the offset angle to be passed to
gimp_constrain_line(), in order to constrain line angles in
display space, according to the shell's rotation angle and
flip mode.
- gimp_display_shell_constrain_line(): A convenience function
which calls gimp_constrain_line() with the said offset angle.
Use the new functions in all instances where we constrain line
angles, so that angles are constrained in display space, rather
than image space.
The only exception is GimpEditSelectionTool, which keeps
constraining angles in image space, since it's not entirely obvious
that we want to constrain angles of dragged layers/selections in
display space.
Add gimp_display_shell_[un]transform_with_scale(), which are
similar to gimp_display_shell_[un]transform(), however, they
transform the bounding box to/from uniformly-scaled image space,
given the scale factor as a parameter. These functions are more
accurate than using gimp_display_shell_[un]transform() and applying
the scaling separately, in particular, when the scale matches the
(horizontal or vertical) display scale.
Use these functions in gimp_display_shell_draw_image(), to avoid an
off-by-one error when transforming screen-space chunks to image-
space chunks, which leads to the symptoms described in the bug.
Fix another potential off-by-one error affecting non-uniformly
scaled images, and window scale factors other than 1.
Use CAIRO_FILTER_FAST when painting the xfer surface to the
screen. This notably improves performance when the canvas is
rotated, at the cost of lower filtering quality.
Based on a patch by Massimo.
Move the entire image-space/screen-space transformation logic from
gimp_display_shell_render() to gimp_display_shell_draw_image(), so
that the former works entirely in image space, and do the chunking
and clipping in screen-space, making sure that image-space chunks
are never larger than
GIMP_DISPLAY_RENDER_BUF_WIDTH x GIMP_DISPLAY_RENDER_BUF_HEIGHT,
even when the window's scale factor is greater than 1.
Add a GIMP_BRICK_WALL environment variable, which, when set, shows
the screen-space chunk bounds.
...is a regression in common cases
Commit the free select tool on double click inside the polygon.
Done by implementing GimpCanvasItem::hit() in GimpCanvasPolygon, using
ugly code.
Update the dprod production of generated enum files to include
abbreviated value descriptions, as per the previous commits.
Add a comment for translators above the abbreviated descriptions,
specifying the full description they abbreviate.
Now add also flip information in the status bar so that one knows that
the canvas is flipped horizontally and/or vertically. Especially if you
often flip and rotate the canvas (or if you did it by mistake), at some
point, it may become confusing to remember whether this is the case. Now
it will be possible to check in a single glimpse at the status bar.
Similarly to what I previously did for the rotation information, hitting
the flip icons in status will allow to unflip easily without having to
go in menus or remember all shortcuts.
These information will be visible only when the canvas is flipped or
rotated.
In GimpCanvasTransformPreview, use the transform matrix to
determine if we're doing a perspective transform, rather than
relying on a separate property, so that we don't use the slow
perspective path unnecessarily.
Consequently, remove the does_perspective member of
GimpTransformTool, since it's no longer used.
Return FALSE from gimp_display_shell_has_filter() when there are
filters, but they're all disabled, to avoid unnecessary extra
color conversions during rendering.
When we have display filters, break the color profile transform in
two: first, convert from the image profile to sRGB, then apply the
filters, then convert from sRGB to the monitor profile.
When a display filter's configure() function returns NULL, use a
propgui for the filter, instead of not showing a widget at all, to
spare filters the need to manually construct a configuration gui.
When processing display filters, shift the filter buffer to the
top-left corner of the render area, and pass the actual render
area, instead of an area whose top-left coords are (0, 0), to the
display filter. This allows for position-dependent display
filters.
Change gimp_tool_set_active_modifier_state() to honor the new
GimpToolControlSetting. Explicitly set the mode to SEPARATE in
all tools that require modifier keys during a stroke.
And here comes the actual fix: change GimpTransformTool and
GimpToolTransformGrid to use SAME mode, and remove their
active_modifer_key() and hover_modifier() impls, so it makes no
difference whether a modifier is pressed before of after mouse button
press/release.
Allow propgui constructors to specify an (optional) callback function
when creating pickers, to be called when a color/coordinate is picked,
similarly to controller callbacks.
Implement picker callback support in GimpFilterTool. When the active
picker has an associated callback function, call it instead of the
class's color_picked() function.
Add lots of "#include <gegl.h>" to .c files that miss it, which is
now necessary, since this commit adds a Babl* parameter in
propgui-types.h.
Add parameters, controlling the behavior and appearance of sliders,
to GimpControllerSlider. The macro GIMP_CONTROLLER_SLIDER_DEFAULT
expands to a nonmodifiable lvalue of type GimpControllerSlider,
whose members are initialized with the most common default values.
Handle the new parameters in GimpToolLine. A slider using the new
"autohide" mode is only visible when selected, or when the cursor
is close enough to the line, between the slider's min and max
values, and no other handle is grabbed or hovered-over.
... which is emitted when a handle is single/double/tripple clicked.
The signal handler returns a boolean value. A return value of TRUE
stops further event processing, while a return value of FALSE allows
it.
The signal is emitted when a slider is dragged away from the line,
and will be removed when the button is released, and when the
slider is dragged back to the vicinity of the line, and won't be
removed. The last parameter of the signal is a boolean flag
differentiating between the two cases.
Note that a remove-slider signal may be emitted without a preceeding
prepare-to-remove-slider signal, however, is a prepare-to-remove-
slider signal is emitted with a TRUE last parameter, it must be
eventually followed by a remove-slider signal, or by another
prepare-to-remove-slider signal with a FALSE last parameter.
Add support for adding and removing sliders to/from a GimpToolLine,
using three new signals:
- can-add-slider: Takes a double argument in the range [0,1],
indicating a location along the line, and returns a boolean
value, indicating whether a slider can be added at that
location.
- add-slider: Takes a double argument in the range [0,1],
indicating a location along the line, for which can-add-slider
returned TRUE. In response, should add a new slider at that
location, and return its index, or a negative value if no
slider was added.
- remove-slider: Takes a slider index. In response, may remove
the slider.
On the UI side, when the cursor is close enough to the line, but
not within the hit area of an existing handle, GimpToolLine checks
if a slider can be added at the cursor position, using can-add-
slider. If a slider can be added, a dashed circle appears at the
cursor position along the line, indicating where a slider will be
added. The cursor is added by clicking, which emits an add-slider
signal; if the signal returns a slider index, the new slider is
selected, and can be subsequently dragged.
Removing a slider is done by either selecting the slider and
pressing backspace (or delete, although we don't actually forward
it to the tool atm,) or by "tearing" the slider: when dragging
the slider, if the cursor is far enough from the liner, a dashed
circle appears around the slider, and releasing the mouse removes
the slider.
En route to on-canvas gradient editing, add support for persistent
handle selection to GimpToolLine (a handle being either an endpoint
or a slider). Handles are selected through clicking, however,
unlike before, the selection persists after the mouse is released.
A new "selection" property specifies the currently-selected handle
(who knows, maybe in the future we'll add multi-selection), and a
new "selection-changed" signal is emitted when the selection changes.
The visual feedback has been changed to better suit the new behavior,
and the behaviors yet to be added: The selected handle is marked
using highlighting; the highlighting doesn't change while hovering
over other handles. Only the hit-test circle is used as hover
indication, however, we use a fixed-size circle, and only show the
circle for the currently hovered-over handle -- no more trippy
expanding circles :)
A few minor changes along the way:
- The selected handle is now the (first) one that's closest to the
cursor, instead of the first one to pass hit-testing.
- We don't move the selectd handle upon button-press, only upon
motion, so that handles can be selected without moving them.
- Show a MOVE cursor modifier when hovering over a handle.
In gimp_canvas_sample_point_get_extents(), use the drawn number's
actual size instead of some random constant that was good enough for
my own font size.
Updating the cursor information involves sampling the active image/
drawable, which can be expensive, especially if there are filters
active that also respond to cursor motion, e.g., while using the
warp tool.
Move the actual updating to an idle function. This dramatically
improves responsiveness in these situations.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
During constrained motion, round the slider value before clamping
it, so that the slider limits are always enforced. Additionally,
snap the slider to 1/12-ths of the line length, rather than
1/24-ths.
Make sure that sliders can never have negative-zero values, which
can result in a -inf base for spiral.
and update the grid as soon as a constraint is changed, not only on
the next motion. Change GimpTransformTool to forward the events to the
widget if it exists, but still handle them if it doesn't (yes this
code duplication is ugly, but the widget can hardly handle events if
it doesn't exist...).
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
Add supprt for placing sliders on a GimpToolLine -- handles that can
be dragged over the line. The sliders are accesible through a new
"sliders" property, and via the gimp_tool_line_{get,set}_sliders()
functions.
Add a slider-line controller, which works like a line controller,
but whose callback also supplies/takes an array of sliders.
Note that the data type for individual sliders is called
GimpControllerSlider (in particular, it's not line specific), so
that we may use it with other controller/tool-widget types in the
future.
- introduce new state "boolean is_first" which tracks if the currently
drawn rectangle is the first with this instance
- cancel the widget if there was no movement when creating the first
rectangle
- undo to the previous rectangle if the user created a zero-extent
rectangle
- also undo to the previous rectangle if a newly drawn rectangle is
canceled with button-3 release
because of bailing out early after emitting "response". Instead, don't
ref the object around this function, and move the "response" emission
to the end of the function.
- unset "rect_adjusting" before bailing out on button_release()
- update the integer rectangle when the double properties change
- don't try to show handles with a size of < 3
- remove unused members
- shorten some variable names
which is a replacement for GimpRectangleTool. It's a massive piece of
code and I'm not sure everyting works as it should, but it seems to do
crop stuff without any glitches.
and a default key_press() handler that emits CONFIRM, CANCEL and RESET
responses. Remove code with the same purpose from all subclasses.
Change tools feed key_press() to the widget and connect to its
"response" instead of implementing key_press() themselves. This will
only be better and less code after the tool side of this is done
generically.
Rename gimp_tool_widget_snap_offsets() to set_snap_offsets(),
and add gimp_tool_widget_get_snap_offsets().
Also rename gimp_tool_widget_status() to set_status(), and
add new function and signal set_status_coords().
Ell