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().
which is the code that calculates handle size based on pointer
proximity. Use the new function in GimpToolHandleGrid and
GimpToolLine, and clean up some stuff in GimpToolLine.
Simply use g_object_bind_property() to connect the grid properties of
GimpTransformOoptions and GimpToolTransformGrid and remove all other
grid property setting code.
so widgets can return which handle was clicked. The values boolean
semantics stay the same so if(retval) gives the same result. This is
useful for the upcoming transform tool widgets.
When compressing tool motion events, only compress motion events
at the front of the event queue, targeted at the same widget as,
and having similar characteristics to, the initial motion event;
stop compressing upon the first mismatched event.
Previously, all pending motion events targeted at the canvas were
compressed, stopping only at a button-release event targeted at the
canvas. As a result, when adding a guide by dragging from a ruler,
there could be a situation where a pending button-release event
targeted at the ruler would be followed by motion events targeted at
the canvas, with a cleared state mask. These motion events would
get compressed to the initial motion event targeted at the ruler,
resulting in a motion event with a cleared state mask being processed
before the said button-release event. This, in turn, would cause the
guide tool's cursor_update function to be called, while the tool is
still active, emitting a CRITICAL. Sheesh.
The moral of the story is: let's play it safe.
which encapsulates a bunch of GimpCanvasItems plus their interaction,
using GimpTool-like virtual functions like button_press(),
button_release() motion() etc. Also has GimpDrawTool-like API to
manage the canvas items of its subclasses.
Call gimp_canvas_group_remove_item() and don't just unref them, so
their state gets restored and signals get disconnected. They may not
be owned by the group, or have other external references.
Simply increase its change_count in dispose(). There is really no
reason to build expensive update regions and emitting signals when we
are about to go away.
Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
Limit the number of lines drawn in the transform tool canvas grid to
one line every 5 image pixels. This should probably be done in display
pixels, didn't change that yet.
We check them into git, so this makes it easier to keep them in
sync when using a separate build directory.
Case in point -- this commit also syncs a few enum files that went
out-of-sync with their headers.
gimp_unit_get_digits() won't return relevant information when using
higher resolution. gimp_unit_get_scaled_digits() will provide the right
amount of details relatively to the actual print resolution of the
active image.
and use them for the new image in "Paste as new image". We were using
the resolution and unit of the image the paste command was invoked
from, which is entirely random and useless.
The abbreviated commit hash we show in the shell and the about
dialog is currently just the last 7 characters of 'git describe',
based on the assumption that abbreviated hashes are always 7-digits
long. When the hash is longer than that, we're just showing a
nonsense commit.
This was never a good idea, since users can override this, and
since disambiguation can result in longer hashes, but since git
2.11, the default abbreviated hash length is determined based on
the size of the repository, which currently results in 10 digits
for us.
Let's just do it right.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
In DEs which use a global menu, such as Unity, updating the menu
can be expensive. This particularly affects canvas scaling and
rotation, for which updating the menu synchronously causes notable
lag.
.. due to gdk_pixbuf_scale() with themes using the pixbuf engine
Make GimpDisplayShell a subclass of GtkEventBox, so that it gets its
own window, isolating its events from those of its ancestors.
In particular, the "expose" event handler of GtkNotebook, which the
shell is a child of in SWM, is particularly slow with themes that
use the pixbuf engine. If the notebook and the shell use the same
window, this can cause notable, and somtimes severe, lag when the
rulers or scrollbars are updated frequently, such as when rapidly
moving the cursor.
In particular, this enables grids whose points of intersection
are at the middle of the image's pixels, which is useful for
undistorted painting with odd-sized brushes using tools other than
the pencil.
This commit also changes the grid visibility behavior, so that the
the visibiltiy of horizontal and vertical grid lines (depending on
the zoom level) is independent.
Nobody has them anymore, and they are deprecated in GTK+ 3.x. This
also fixes all conflicting mnemonics except those I missed, but we can
fix them now.
The print size displayed in image property and title format should use
gimp_unit_get_scaled_digits() instead of gimp_unit_get_digits() and
adding 1, which is quite random or magic number-y.
We can't just switch to a GimpOperationTool by using the normal
gimp_context_set_tool() or gimp_context_tool_changed() because it
needs additional initialization like setting an operation at all.
In gimp_gegl_procedure_execute_async(), g_object_set_data() the used
procedure on the newly created tool.
In gimp_display_shell_initialize_tool(), when we re-create the active
tool because of a drawable change, check for the procedure and invoke
it again, instead of simply creating an empty operation tool by
calling gimp_context_tool_changed().
Compute the ideal decimal precision for cursor position and length
status so that you get the best precision on physical units depending
on the current resolution, yet avoiding over-precision (which can be
misleading). The unit's "digits" value is now used as a minimum
precision only.
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
...regardless of image color precision
Split enum value GIMP_COLOR_FRAME_MODE_RGB into RGB_PERCENT and RGB_U8,
which display the current % values, and values in a range of 0..255.
Add GimpMenuFactory can always be found in a GimpDialogManager, use
gimp_dialog_factory_get_menu_factory() where we have a dialog factory
instead of accessing "global_menu_factory" or redundantly passing a
menu factory around where we already pass around a dialog factory.
Convert GimpRGB to CMYK using a color transform to the configured CMYK
profile instead of the naive gimp_rgb_to_cmyk().
Add gimp_color_frame_set_color_config() and call it on all color
frames in the GUI (color picker tool, cursor info, sample point view).
Keep a GimpColorTransform around that does the conversion.
Also color manages the frame's color area now (visible in the sample
point view), which was forgotten earlier. Addresses bug #467930.
Fix the check that keeps events on overlay widgets from entering the
tool event mechanism, they have no business there.
gimp_overlay_child_realize(): set the embedding widget's event mask on
all overlay children, so their windows will be used as event window,
so their events become distinguishable from events on the parent (the
canvas).
gimp_display_shell_canvas_tool_events(): fix the check for events on
overlays, and skip them for real this time.
Add a SELECT_SOFTPROOF_PROFILE mode to the color profile dialog and
use it to select a profile from a newly added "Soft-Proofing Profile..."
menu item in view -> color management.
In a blocking operation we don't give the main loop time to lay out
the statusbar correctly after showing the progress bar. Force a size
on the progress bar using gtk_widget_size_allocate(). This sucks.
the edge of a dock in multi-window-mode
when the pointer is grabbed do not process a
motion-notify-event having the wrong 'device' member.
This avoids a harmful device change.
Use the newly added clipboard for entire images to copy/paste layers
(we only create single-layer clipboard images, and use only the first
layer of any recieved image, the layers can be arbitrarily complex
though):
- change gimp_edit_copy,cut,paste() to return/take a GimpObject
that can be a GimpImage or GimpBuffer
- cut/copy the whole layer if there is no selection
- always paste layers as new layers, not floating selections
- always paste news layers on top of the active layer, where
we would attach a floating selection
- add enum GimpPasteType { FLOATING, FLOATING_INTO, NEW_LAYER }
- add GimpPasteType parameter to gimp_edit_paste() and handle all
three cases there because there is now a lot of common code
involved
- change all callers accordingly, use only legacy buffer pasting
from the PDB for now
... standard icon names and GTK+ icon names as second choice.
We should only use GIMP specific icon names as last resort, when there
is no standard or GTK+ names dedicated to the function.
This is made possible thanks to commit 3cc77b0.
s/gimp-document-recent/document-open-recent/
s/gimp-indent/format-indent-more/
s/gimp-next/go-next/
s/gimp-previous/go-previous/
s/gimp-save/document-save/
s/gimp-save-as/document-save-as/
s/gimp-revert/document-revert/
s/gimp-open/document-open/
s/gimp-document-recent/document-open-recent/
s/gimp-quit/window-close/ ou s/gimp-quit/application-exit/
s/gimp-warning/dialog-warning/
s/gimp-edit-clear/edit-clear/
s/gimp-justify-.*/gtk-justify-.*/
s/gimp-font/gtk-select-font/
s/gimp-color-palette/gtk-select-color/
s/gimp-cancel/gtk-cancel/
Place the rulers' origin at the top-left corner of the canvas
(screen space) bounding box, and set their scale to the image-
space scale along the screen-space horizontal/vertical directions
(in other words, measuring a distance using the rulers should
give the same results as the measure tool; note that rotation
comes into play here only when the horizontal and vertical
image or screen resolutions are different, since otherwise the
scale is direction invariant.)
Make scrollbar step match ruler step under the new behavior.
... not screen space
Flip and rotate the canvas around the center of the viewport,
instead of the center of the image. Scroll the display as
necessary to keep the center of the viewport fixed during
these operations. This applies to both the corresponding
menu items, and rotation using Shift+Space.
Likewise, flip the canvas across the designated axis in
screen space, instead of image space. Rotate the display as
necessary, such that the reflection appears to happen in
screen space, regardless of the current rotation angle of the
canvas.
Need to connect_after() to the shell's GimpColorConfig "notify" so the
profile transform cache in gimp_widget_get_color_transform() is
already invalidated when we call gimp_color_managed_profile_changed()
in the shell's notify callback.
This is a hack. Actually the shell should create its transform only on
demand, and a config change should simply get rid of the previous
transform, just as all other widgets are doing it.
... and image_resolution != screen_resolution.
Partially revert commit 26ea7a3530.
Also, reset shell->dot_for_dot in gimp_display_shell_fill(), so that new
images that use the first display don't inherit the dot-for-dot state of the
previous image that used the same display.
Now the max parameter from Windows is taken into account and takes
precedence over the saved session state if set.
This can be applied either through the "run" property of a shortcut,
or by command line: `start /max gimp-2.9.exe`.
There is a start for min handling as well but I can clearly see the
window being minimized and immediately re-raised. There must be a call
later which deiconifies the window. This will have to be fixed.
which encapsulates a cmsHTRANSFORM and does all the pixel format
conversion magic. It has API to create transforms and proofing
transforms, and to convert pixels arrays and GeglBuffers.
Before, each place which has a transform had to keep around the
transform and its input and output Babl formats, and had to implement
lots of stuff itself. Now all that lives in GimpColorTransform,
removing lots of logic from many places, and pretty much removing lcms
from the public API entirely.
This removes including <lcms2.h>, LCMS_LIBS and LCMS_CFLAGS from
almost all directories and potentially allows to replace lcms by
something else.
Replace the 3-state "off", "display" and "softproof" radio items by
two toggles "enable" and "softproof". Also add separate controls for
display and softproof options.
They are unreliable because every type checking cast discards them,
they are useless anyway, visual clutter, added inconsistently, and
generally suck. Wanted to do this a long time ago, it was a bad idea
in the first place.
Add rendering intent, black point compensation and gammut warning menu
items to View -> Color Management. They set the respective values of
the active color management mode, so both "color managed display" and
"print simulation" are almost completely configurable per-display
now. Setting the simulation profile is still missing.
Add a View -> Color Management submenu that allows to change
the color management mode per-display.
Internally, keep a GimpColorConfig object around per-display that
is synchronized with the global config except for the properties
that have a per-display GUI (currently the mode).
Also provide an "As in Preferences" menu item to follow the global
settings again.
Use the shell's color config for color managing the display and
various auxiliary widgets attached to it, like the notebook tab widget
and navigation popup.
The config is currently just a reference to the global prefs config,
so no behavior changed.
Keep GimpStatusbar progress messages at the front of the list.
Previously, gimp_statusbar_push() and friends would push progress
messages behind temporary messages, and would push normal messages,
added after a progress had started, in front of progress messages.
This resulted in the progress bar text not being updated if a
temporary message was active at the time the progress started, or
if a normal message was pushed after the progress started.
This commit fixes this by always keeping progress messages at the
front of the message list.
Disable "new-style" fullscreen mode on OS X, we need support in
GTK+ in order for this to work properly. The currently available
fullscreen option in View > Fullscreen works fine and we plan to
migrate to the "new-style" fullscreen support in the future.
...in "alt-pressed" mode
Menu activation doesn't cause a focus-out becaus menu keyboard
grabbing is implemented with a simple gtk_grab_add() (the menu popup
never gets the focus). Therefore, the canvas never gets a focus-out
event and the pressed modifiers are stuck.
Fixed by connecting to "grab-notify" on the canvas, and artificially
releasing all modifiers when the canvas is shadowed by a grab.
Add two new tools, GimpGuideTool and GimpSamplePointTool. They are
one-trick-ponies and can only create new or move existing guides and
sample points. They can't be selected from the toolbox, only
temporarily pushed as active tools on top of any active tool using
their public start() APIs.
Use that API to enable them when the rulers are clicked, and replace
the entire guide and sample point moving code in GimpMoveTool and
GimpColorTool by simple calls to that API.
This might look like overkill but can easily be used for other
features like moving guides from within the paint tools (mirror
painting) or gegl filters (preview curtain).
Pass the display scroll offset down to gimp_cairo_stipple_pattern_create()
and set it as offset on the created cairo pattern, so stipple patterns
look the same no matter how the display is scrolled.
This reverts commit 6878b49491.
I didn't take into consideration that different themes could apply
various fonts, font sizes or label-scale for the widget. So the font
description needs to be reinitialized at every theme change.
You can now set any paint tool to mirror painting relatively
horizontal/vertical axis or a central point (any combination of these 3
symmetries).
This has been implemented as a new multi-stroke core, where every stroke
is actually handled as a multi-stroke (default of size 1).
This is also the first usage of custom guides for symmetry guiding.
Current version has to be activated in the playground.
With gimp_guide_custom_new(), you can create a custom guide with a different
style on canvas (other pattern/color/width). A custom guide won't be saved
and could be used, for instance, for specific GEGL op guiding.
In gimp_display_shell_expose_region(), invalidate each rect rather
than rebuilding the cairo_region_t as GdkRegion and then invalidating
the entire GdkRegion. Improves performance for tools that invalidate
complex regions.
Use a GQueue instead of a GList in GimpCanvasGroup, so adding items
takes constant time instead of O(n). Also, removing items was
traversing the list twice. This should generally speed up tools with
lots of canvas items.
Also, add a private pointer to the instance struct instead of using a
GET_PRIVATE() macro.
Add "title" and "help_id" parameters and members/properties to
GimpToolDialog, GimpToolGui, GimpOperationTool. Also make the order of
parameters more consistent.
Call the suspend()/resume() from the previous commit around
gimp_display_shell_appearance_update() so the cancas is not
repositioned for each individual widget configuration.
Implement a mechanism to suspend/resume GimpImageWindow's "keep canvas
pos" logic which is used to keep the image in place across widget
changed such as show/hide rulers.
gimp_display_shell_fill(): call suspend()/resume() around
gimp_display_shell_appearance_update(), and center the image after
calculating the initial scale factor, so the image jumping at least
starts at the approximately right position.
because this should happen generically in the zoom model's "zoomed"
callback, and is done explicitly in a few special cases. The removed
calls should all be redundant.
...several different zooms tiled together
In gimp_display_shell_scale() don't shortcut things in the case where
we resize the window, but call gimp_display_shell_scale_resize() like
all other scaling functions do in the end.
Call gimp_display_shell_scrolled() before gimp_overlay_box_scroll()
so the rotate transform is updated before the actual scrolling.
The explicit call to gimp_display_shell_rotate_update_transform() got
lost during the last commits, but this solution is cleaner and less
redundant anyway.
by changing it to always deal with the center of the viewport instead of
its upper-left corner.
Fix gimp_display_shell_scroll_center_image_coordinate() to use the
proper transform functions like in the last commit.
gimp_display_shell_scale_to(): calculate the point that should not
move with GimpDisplayShell's untransform/transform functions before
and after scaling, then scroll to the right point. Just using the
scale functions doesn't work any longer when a rotation is
active. Other functions are affected too, but this most important
issue can be fixed by fixing just this function.
Since commit 867b1f7e the window did always pop if it was set to
visible once, even if closed and "Use info window" disabled.
Fix this by adapting the show logic to the fact that we now keep the
widget alive across images/displays.
...in initially active tab
gimp_tool_gui_update_shell(): implement the "overlay" case and hide the
gui on the previous shell, then show it on the new one.
to not return a reference that has to be dropped. Also allow NULL to
be returned if the managed cannot have a profile. If it can have one,
get_color_profile() still always returns a profile (either the
assigned one, or a generated built-in one).
gimp_image_constructed(): connect to "notify" on GimpColorConfig
and call gimp_color_managed_profile_changed() on the image.
Remove the "notify" handler on GimpColorConfig from
gimpdisplayshell-handlers.c because it already connects to the
image's "profile-changed" signal.
Additionally, implement GimpColorManaged::profile_changed() in
GimpImage and invalidate the image and all layer previews. One step
closer to color managing image and layer previews.
...when a color profile is active
This commit doesn't fix anything, but it prepares the code to do the
right thing:
It passes the actual raw image pixels through the entire color picking
mechanism to the widgets which display colors, particularly
GimpColorFrame.
This is needed for GimpColorFrame's "Pixel" mode (as opposed to its
RGB, HSV etc. modes) which is supposed to show the raw pixel values
from the image.
Before this commit, it was recreating the raw pixel values from the
GimpRGB value it knows, which will become impossible when we correctly
pick color managed GimpRGB values soon.
it used to be a typedef to gpointer and actually was a cmsHPROFILE.
Change its API to be more "standard", remove the public close()
function. The object caches both the cmsHPROFILE and the data/length
ICC blob, so conversions between the two become obsolete (simply call
get_lcms_profile() or get_icc_profile()).
Adapt everything to the new API, but port it in a naive way for now,
the code doesn't take advantage of the new possibilities yet (like
refcounting).
...but they aren't clipped
gimp_display_shell_profile_can_convert_to_u8(): allow the shortcut of
converting directly to 8-bit for display only for GIMP_COMPONENT_TYPE_U8.
This might be an lcms bug, the code can be enabled again for U16 and
U32 if it's indeed an lcms bug and it gets fixed.
but they aren't clipped
Add gimp_display_shell_profile_can_convert_to_u8() which returns
whether the lcms transform can safely write directly into an u8 buffer
without destroying out-of-gammut pixel values, which we assume is the
case for all integer formats. If the function returns FALSE, always
convert via the R'G'B'A float filter_buffer.
Also connect to the image's "precision-changed" signal and update the
profile transform when it's emitted.
- disable auto-adding of the lcms display filter module
- change profile convert dest formats to be always R'G'B'A, a display
profile transform outputs something that can be displayed directly,
so no additional gamma transform must happen when the pixels are
copied to a cairo-ARGB32 buffer
- add a medium forest of if() branches to gimpdisplayshell-filter.c
which cover all combinations of profile and display filter
transforms
- all of this is still very broken when changing an image to linear,
because the configured RGB profile from prefs will do horrible
nonsense (things work fine though with a per-image profile that is
for linear data)
Move some functions from libgimpwidgets/gimpwidgets.[ch]
and from app/widgets/gimpwidgets-utils.[ch]. Newly add
gimp_widget_get_color_profile() which is extracted from
modules/display-filter-lcms.c.
...bring focus back to GIMP image window
When showing docks in multi-window-mode, try to set the keyboard focus
back to the active display because it might have been stolen by a dock.
- change start() and set_text() to use "format" and "..." instead of
"message", allowing to format progress messages in place
- s/cancelable/cancellable/
- move "cancellable" to be the second argument of start()
Set the active display's viewport as priority rectangle on the image.
Update the rectangle in the default implementations of
GimpDisplayShell::scaled(), ::scrolled() and ::rotated(), which isn't
entirely correct yet but much better than before, and the only "bad"
thing that can happen with a bogus priority rectangle is that the
image is updated as out-of-viewport as before, just differently.
This may or may not remove some logic that avoids drawing tiny update
regions, and may or may not improve things or make them worse. Will
add code that actually tile-aligns update areas later.
...(crop, rectangle, etc) in large image zoomed-to-fit
Introduce a hash of the last 16 used icons in GimpStatusbar, it was
loading icons at a very high frequency. Found by Massimo.
Always round grid spacings and offsets to integer precision when
using them for snapping and grid drawing. While we might *want* to
have subpixel precision grids, all the UI is pretending it to be
on pixel boundaries. Make that pretense an fact.
In gimp_image_window_new(), place the window on the right
monitor manually if we are not in single-window-mode.
In gimp_image_window_switch_page(), make sure we don't use an
unrealized new window's monitor for updating the session info, because
the monitor of an unrealized window is always where the pointer is.
Change gimp_get_display_name() to also return the screen, and its
implementation in the GUI to return the initial monitor during
startup. Retrieve that information in app.c using a weird callback
construct and pass the monitor to file_open_from_command_line().
Half-related, add screen and monitor parameters to GimpDisplayShell
and use these initial values for calculating the canvas's initial
extents.
The image windows still don't position themselves correctly though
because we have no mechanism for that whatsoever just yet, but we now
at least pass the needed monitor information to the right objects.
Add a "monitor" parameter and return something reasonable, instead
of a useless resolution average of all the screen's monitors. Also
require a screen to be passed now.
There is now a preference option that determines whether windows
should be opened on the same monitor as before. It should be disabled
when the machine gets monitors plugged/unplugged dynamically ("laptop")
and enabled when there is a static multi-monitor setup ("wokstation").
This is merely the current simplistic policy on top of the newly added
underlying infrastructure:
- pass integer monitor numbers around in all places where we already
pass around a GdkScreen. Pass the "current" monitor to these changed
APIs, where "current" is either the monitor where the action-triggering
widget is, or if that is unavailable the monitor where the mouse is.
- add gimp_widget_get_monitor() in order to easily get to the monitor,
just like gtk_widget_get_screen().
- add screen and monitor parameters in some places that were missed
before.
- in sessionrc, save all window positions relative to the window's
monitor, and save the monitor separately, if it's not the screen's
primary monitor.
- when restoring window positions, use the stored monitor when the new
prefs options says so (use the screen's primary monitor if there is
no stored monitor), otherwise use current monitor that is now passed
around.
Jehan