To be used by the blend tool gradient editor to edit the gradient
endpoint/stop/midpoint properties corresponding to the selected
handle.
The GUI is currently empty; the following commits add its contents.
When a midpoint is double-clicked, convert it into a gradient stop
(i.e., split the corresponding segment at the midpoint,) by
responding to the line's handle-clicked signal.
Add a tentative_gradient member to GimpBlendTool, which, when set,
is displayed instead of the current gradient.
Use this to show a version of the gradient with the currently
selected stop deleted, upon receiving a prepare-to-remove-slider
signal, i.e., when the slider is about to be removed.
Add a boolean "modify active gradient" option to the blend tool.
when checked, the active gradient is modified in-place while edited.
When unchecked, the active gradient is copied to the internal
"custom" gradient upon editing, and the custom gradient becomes
subsequently active.
Show a hint when the option is checked, but the active gradient is
non-writable, and can't be edited directly.
This commit adds the new gimpblendtool-editor.[hc] files, which are
where the gradient-editing related functionality of the blend tool
is going to go.
Add a boolean "instant mode" option to the blend tool, togglable
using shift. When checked, commit the gradient immediately when
the mouse is released.
When not in instant mode, don't commit the gradient when clicking
outside the line, since this will become easy to do accidentally
once we add on-canvas gradient editing.
While I am at it, let's spread the improvement to options_box which was
also a weak pointer with g_object_add_weak_pointer(). Let's make it
rather a GWeakRef for the same reason as I did options_gui.
Other than multi-threading (which here is not the problem), using
GWeakRef has the other advantage that it makes the type of pointer
obvious, hence avoiding the kind of errors as fixed in commit 12df796.
One can't just change the pointer value directly, and has to use
g_weak_ref_set(), so such problem won't happen again.
Repalce the two separate size entries, used for the position and
size properties of GimpRectangleOptions, with a single size entry
with two fields, so that they accept ratio expressions. Note that
this doesn't change the UI.
... the matrix is not actually used
Don't abort transform-tool commits when the transformation matrix
is the identity, for transform tools that don't calculate a
transformation matrix to begin with (i.e., the flip tool),
otherwise they do nothing.
...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().
Paint tools in straight line mode (shift click) will now display the
angle in status bar. Angle 0 is considered as the horizontal line from
left to right, and angle is measured counterclockwise from there, which
is the most common convention.
Add "gboolean with_filters" to gimp_drawable_calculate_histogram(),
which is passed as FALSE in almost all places, except the histogram
dockable where we want to see both the drawable's unmodified histogram
*and* the histogram after filters are applied.
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);
Change the text selection to draw an outline around each selected
glyph. It looks just as ugly as before but at least keeps the text
readable regardless of its color.
if did revert to the previous selection and thus break stuff like
enbaling quick mask or inverting the selection, because I merged the
undo magic it does into gimp_rectangle_select_tool_halt(), whereas
before it was done by the former gimp_rectangle_tool_cancel(), so only
on explicit cancel not HALT from whatever source.
Do the same in the new code and move the undo magic from halt() to
rectangle_response(CANCEL), which is exactly the same distinction as
with the old GimpRectangleTool code.
Don't unconditionally call COMMIT in rectangle_response(), because
that now implicitly HALTs the tool. Instead, check if we got here
because of a click, and call our commit() directly.
GimpOperationTool's aux inputs were not properly ported to the new way
filter tools work (complete destruction and re-creation of the tool
dialog).
Split creating the operation GUI and adding it to the dialog into
separate functions, and call them at the right places.
Call HALT generically in gimp_tool_control() after calling COMMIT, and
remove all hacks in tools that call both COMMIT and HALT or call
halt() from commit().
Some tools interact with their subclasses (e.g. filter tool and
operation tool), and it's essential that COMMIT runs through the
entire class hierarchy before HALT.
Probably breaks something, please test.
Need to keep around the operation's name and its description, so
everything can be re-created when an image is clicked.
Instead, completely shut down GimpOperationTool when GimpGeglTool is
halted, so the next click will bring up a dialog with only the
operation selection combo.
which allow to override stuff from GimpToolInfo for dynamic tools like
GimpFilterTool and friends. When NULL, the getters are falling back to
GimpToolInfo strings.
...and "export_dialog_title"
It's ridiculous to keep this code around for strings that are only
marginally different (and not better) than the strings we can generate
from other strings we have anyway.
to ::can_undo() and ::can_redo(). They still return description
strings and the new naming is slightly off :) but get_undo_desc() will
be needed for something else soon, and half of the time the functions
are indeed used to check whether there are undo/redo staps at all.
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.
Use the new gimp_filter_tool_get_drawable_area() instead of always
using gimp_item_mask_intersect() which is only right when the
operation is applied to the "selection" region. Also call
gimp_operation_tool_sync_op() when the region is changed in the UI.
Pass a "GimpCreateControllerFunc" to all gimppropgui-*.[ch]
constructors which takes a callback (to update the config object when
the on-canvas GUI) and a controller type that determines the
callback's signature, and returns another callback (to update the
on-canvas GUI when the config object changes).
In GimpOperationTool, pass such a GimpCreateControllerFunc that
handles creating and adding on-canvas controller via the new
gimpfiltertool-widgets.[ch]. So far, a simple line like in the
blend tool is supported.
Add a custom GUI for gegl:spiral, and have its origin, radius and
angle controlled by such a line.
which return's the used drawable's offsets and a GeglRectangle
where the filter is applied according to GimpFilterOptions::region
(either the selection or the whole drawable).
and call it from GimpFilterTool's "notify" callback. Remove signal
connections from all subblasses and instead implement ::config_notify().
The config object belongs to GimpFilterTool, and only GimpFilterTool
should know when it's created and can be connected to.
so things from the tool's previous use get destroyed, including their
(maybe dangling) signal connections. Also shut down more stuff in
halt(), including destroying not just hiding the GUI.
because widgets are bound to one GimpDisplayShell. Also, chain up
unconditionally in gimp_color_tool_draw(), we always want to draw the
widget even while picking colors.
The widget is fed events by GimpFilterTool, the actual interaction
with the filters operation and config will be done by subclasses.
The order of precedence when there are multiple possible canvas
interactions is: moving the split preview guide, color picking,
widget.
We can't rely on g_object_unref() in halt() for breaking all property
GBindings between the tool options and GimpToolRectangle, because we
might be in the middle of a signal emission which also refs and keeps
the rectangle alive until the last callback returns. So we had
dangling rectangles interacting with tool options.
Remember all bindings in a list, and break them explicitly when we
shut down the rectangle in halt().
Also, forgot to unset the display's highlight in the rectangle
selection tool.
The tool manager still keeps an active tool which it unrefs on
destruction, triggering a final HALT on the tool, which may want to
lookup tool options to reset something. Happened with the new
widget-ported rectangle select tool.
We were leaking all tool widgets set with gimp_draw_tool_set_widget(),
and those having signal connections to e.g. the display shell were
doing things when they were supposed to be gone. Fixes make check.
- factor out widget creation to new start() function
- and tool shutdown to new halt() function
- connect to "response" and remove key_press()
- remove oper_update(), it was doing the same as the draw tool impl
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.
Simply use g_object_bind_property() to connect the grid properties of
GimpTransformOoptions and GimpToolTransformGrid and remove all other
grid property setting code.
This option behaves similarly to the other transform tool, however
it's limited to "adjust" and "clip" only. Now that the flip tool
can reflect across guides, this option is meaningful.
Since commit bc4589968c, GimpFilterTool
assumes that color picking is only ever enabled through color picker
toggles, created using gimp_filter_tool_add_color_picker(). However,
the curves tool enables color picking using the color tool functions
directly. CRITICALS ensued.
Use the new gimp_filter_tool_enable_color_picking() function, added
in the previous commit, and handle picking through the filter tool
interface, instead of the color tool interface. This fixes the
issue.
Subclasses of GimpFilterTool should use these functions to control
picking, instead of using gimp_color_tool_{enable,disable}()
directly. This makes sure that the tool's picking state is
consistent, and allows the caller to control the pick identifier,
and use abyss picking (not currently needed by any subclass, but
maybe in the future, who knows.)
Return only the config object's GType and do the g_object_new() in the
caller (one caller only needs the type, there is no need to create a
dummy object just to get to its type).
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).
... to the warp tool
The interpolation and abyss policy options control the sampler type
and abyss policy of the map-relative node. The high quality preview
option determines whether to use the same sampler for map-relative
during preview as the one used during commit, or whether to use a
fast nearest-neighbor sampler.
A bit too much? Maybe :)
... and to disable/control the rate of the periodic stroke.
The warp tool is now fast enough to enable stroking directly in
the motion handler, which gives better-quality response to motion
than stroking periodically. It's not quite fast enough to enable
exact motion, though :/
Allow individually enabling/disabling stroking during motion and
periodically, and allow controlling the rate of the periodical
stroke.
When using the MOVE behavior, don't append the current cursor
position to the stroke path in the timeout proc if the cursor
hasn't moved since last time. It has no effect, except for
requiring an unnecessary update.
When undoing a warp stroke, don't disconnect the current warp node
from its predecessor; rather, keep the graph as-is, and only
reconnect the render_node to the previous node. This avoids
invalidating the undone node, so that redoing it (which, likewise,
only involves reconnecting the render_node) doesn't require
reprocessing, making it much faster.
The spacing parameter controls the stroke spacing of the warp op.
It's similar, but not identical, to the brush spacing parameter of
the paint tools. It provides a tradeoff between speed and quality.
Change the UI range of the hardness parameter from [0, 1] to [0, 100],
to match the other parameters.
When transform tools are applied on a path, set their bounding box as follow:
- if a selection exists, use the selection bounds
- else if the path has a valid bounding box, use it
- else use the image canvas bounds
Also disable transform tools on an empty path (path without strokes) since
there is no data to transform.
With bigger and denser default images, the older 18px font default is
very small (~ 4pt font at 300PPI).
I decided to settle for a 15pt font, i.e. 62 px at 300 PPI, which seems
like quite an acceptable relative size for our FullHD defaults.
It is bigger than a default font size for —say— a text processor, but
GIMP is not really designed to process large walls of small text anyway.
Rather shorter texts at bigger sizes (i.e. designs, etc.). So this seems
like quite an ok default.
Note that as any defaults, this only goes as far and won't be what most
people need most of the time anyway. But at least we should get rid of
this ridiculous 18px default.
... tool when font unit is not pixel.
The default size is 18px. If for instance one is on a 300 PPI image, and
set the unit to mm, hitting "Reset to default values" sets to 213 px
(which corresponds to 18mm at 300PPI). I'm not 100% sure of the source
of the problem, but resetting the font size before the unit fixes it and
properly sets back to 18px. Let's go the lazy way and just do this.
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.
Determines if the tool can pick at a given coordinate, without
actually picking. The default implementation uses
gimp_image_coords_in_active_pickable(); GimpFilterTool overrides
this function, to return TRUE whenever the active picker has
pick_abyss == TRUE.
Use this function when updating the cursor, and when determining
whether to draw the sample-average region indicator.
Add a boolean 'pick_abyss' parameter to GimpCreatePickerFunc. When
this parameter is TRUE, the picker should pick outside the bounds
of the drawable. Use FALSE for color pickers, and TRUE for position
pickers.
Change wording in Advanced Color Options drop-down menu to not imply
that GIMP isn't color-managed.
Slightly changed wording from Elle's original patch (mitch).
Also set the combo box' "ellipsize" property to END because it's too
wide. As mentioned before, this doesn't work for whatever reason,
hints are appreciated :)
when a click is detected by gimp_tool_check_click_distance(), only do
a motion() back to the button_press() coordinates if there has been a
motion at all since button_press(). This should not change any tool's
behavior, it's only an optimization to keep tools from doing useless
work.
If the transformed item is a layer, and we are transforming the entire
layer (if there is now selection), hide the original layer during the
interactive transform. Based on a 2.8 patch from saulgoode.
We don't support subpixel source sampling, so there's no use in
pretending that we do. Demoting everything to int as soon as
possible helps guarantee that these values are at least rounded
properly and in fewer places.
Make sure we always round coordinates down, and not toward zero.
Keep using floats only in the signatures of the relevant PDB
functions.
Copy TransInfo arrays around using memcpy(), use memcmp() to
compare them, add a function to allocate one. Clean up some
logic in gimp_transform_tool_check_active_item().
and a GimpSettingsBox. This brings savable settings to all ops, also
the automatic ones in the GEGL tool. It also makes the code cleaner
and more general.
GimpFilterTool::get_settings_ui() is no longer needed, replace
it by a simple utility function in gimpfiltertool-settings.c.
Also, use the GimpFilterOptions functions added earlier, and some
random cleanup.
and add them as return values to GimpFilterToool::get_operation(), so
the tools is configured entirely per-instance now.
This makes get_operations()'s signature more evil, but helps making
GimpOperationTool less conplicated and convoluted.
Filters settings used to be serialized and deserialized only
when a filter tool's GUI was shown, too late for the code that
re-runs/re-shows filters with previous values.
Move the entire loading/saving code to gimp-operation-config.c, even
adding/removing the dummy separator item between timestamped automatic
history and manually saved settings. Load the settings automatically
when a settings container is requested, but still trigger saving from
the few places the container is changed in the GUI; could also
automate that later.
This commit also moves all settings of filters that have their own
tools from gimpdir/tool-options/ to gimpdir/filters/. Add compat code
to try the old filename if the new doesn't exist, so files are
migrated automatically.
WIP, but this step already fixes the bug.
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.
Remove all stock items added since 2.8, restore accidentially removed
ones, and rename the newly added GIMP_STOCK_* defines to GIMP_ICON_*.
(will move to having GIMP_ICON_* defines instead of magic hardcoded
strings for all icons).
which got renamed from create_map() in this commit too. "Completely"
means including insane options like color_managed and gamma_hack, they
are confusing enough so they should at least work correctly.
Replace the 'with-behind' and 'with-replace' properties with a
single 'context' property, and use it to select the included
layer modes, according to their context mask.
Add a dummy GIMP_LAYER_MODE_SEPARATOR value to the GimpLayerMode
enum, and use it to explicitly mark the menu separators in the
layer-mode group arrays; add separators to the layer-mode menu
accordingly.
Update the rest of the code to use 'context' instead of 'with-behind'
and 'with-replace'. In particular, in the layers and layer options
dialogs, select the right context based on whether or not the
selected layer is a group.
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.
Fix cage transform to refuse to work on locked, invisible and group
layers. Add GimpTool::initialize() implementation so the generic
"drawable has changed" mechanism triggers the right response.
Largely based on a patch by Ell, with the enum type renamed and
various small changes. Adds another axis of configurability to the
existing layer mode madness, and is WIP too.
I know this looks absolutely horrible, please spare me comments about
that. This commit has the purpose to let everybody experiment with the
new modes, and suggest improvements of the GimpLayerModeBox widget; we
need *some* way of controlling the new layer mode madness.
- set the filter_tool->drawable before showing the tool gui.
- set the sensitivity functions for channel combobox of threshold,
levels and curves tools dialogs only once during dialog creations.
- use the filter_tool->drawable inside the sensitivity functions
... in status bar.
Follow-up of commits f836892 and d1c3c3d. With high resolutions, the
distance displayed in the status bar when shift-clicking in a paint tool
may lack digit precision and show the same value (in non-pixel unit) for
several consecutive pixels. Compute a more accurate precision than what
gimp_unit_get_digits() can provide in such cases.
When working with high resolution, you may have cases where measured
length won't be displayed with enough digits; i.e. several pixels length
would show up as 0. For instance at 4000 PPI, up to 7 pixels show up as
0 mm, then at 0.1 mm from the 8th pixel (actually reaching over 0.05 mm,
approximating as 0.1), then 0.2 at 24 pixels (actually: 0.152), and so
on. At such a resolution, 3 digits are needed for 'mm' instead of the
1 digit returned by gimp_unit_get_digits() so that we display reliable
lengths.
Therefore we need to compute ideal digit precision. Configured digits
for a given unit will now be used as a minimum value, but actually used
digits may be higher.
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.
The "accumulated" (color value) adjective does not look like the best
word in both descriptions. Respectively, the first is an averaged
value whereas the second would be a "merged" or "composited" value.
If native speakers have comments or better propositions, they are
welcome to speak up.
...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.
Move the entire drawing control logic to gimp_color_tool_oper_update()
which gets invoked on hovering, and don't mess with it in
button_press() and button_release(). Tested to work with the color
picker, paint and filter tools.
Change GimpHistogram to take a "gboolean linear" parameter and always
honor that parameter, so both kinds of histograms can now be created
for all drawables.
Add a horrible "Linear" toggle to the histogram dockable which always
defaults to the active layer's actual pixel format, but can be
switched at any time. This UI is ugly and needs to change.
On the PDB, default to gamma-corrected if the plug-in is unaware of
higher precision, and to the drawable's native pixel format otherwise.
Other places using histograms (e.g. levels, curves) are unchanged.
Set gimp_tool_control_set_preserve() to TRUE and set an appropriate
dirty_mask, just like all tools which have a permanent on-canvas state
outside of a simple press-drag-release.
Redundant accelerators were:
- <Primary><Shift>y on dialogs-mypaint-brushes and edit-strong-redo.
Since the <Primary>z vs <Primary>y has quite a strong history for
undo/redo actions, and dialogs-mypaint-brushes is quite new, let's
unmap the latest.
- <shift>l on tools-seamless-clone and tools-unified-transform.
Since the Seamless clone tool is still in the playground and we
don't even know if it will make it out quite soon, let's give
priority to the Unified Transform tool.
Don't rely on the exact modifier being pressed or released. Instead,
check if only the right modifier is pressed after *each* modifier
change, and switch to color picking if it is; disable color picking
otherwise. This greatly reduces the risk of missing the user's wish to
pick colors because of other modifiers being pressed and released in
whatever order.
Probably fixes bug #734743.
Add color management to GimpDrawableFilter and GimpFilterTool, GEGL
ops applied to drawables can be applied in color managed space
now. Sadly, this is very slow, so disabled by default.
I'm sure the profile guessing based on the operation's format doesn't
always work, but this general bug counts as fixed now.
so the threshold can now be based on the GimpHistogramChannel enum.
Add a channel menu to the threshold dialog and a channel argument to
the PDB procedure (which is new in 2.10).
If I hadn't forgotten what the "RGB" channel is supposed to do I would
have implemented the RGB mode in GimpOperationThreshold correctly.
Right now I'm just guessing. Anyone?
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.
This fixes restoring of brush properties (size, spacing angle etc.)
from presets, which was utterly broken before. The fix consists of
two parts:
- In tool_manager_preset_changed(), always copy the brush properties
again after setting the preview on the tool options, in order to
override brush properites that get copied from a linked brush when
that brush gets set on the tool options.
But no amount of copying stuff again and again would help without:
- In gimp_context_set_by_type(), don't use g_object_set() to set the
object (brush, pattern etc.). Instead, build a GValue and call
gimp_context_set_property(). This may seem odd, but avoids a
g_object_freeze_notify()/thaw_notify() around the g_object_set(),
which was causing "notify" to be emitted at the very end, after
everything this context change has triggered. GimpContext is an
essential core object and there is an expectation of a reasonable
order of signal emissions and callbacks being called. The "notify"
at the end was keeping any callbacks of the context's "foo-changed"
signals to override anything an earlier callback had done, if a
"notify" callback was overriding that overriding again.
This was probably the reason for a lot of odd behavior observed over
the years. In fact, I have been searching for this for at least 5
years.
...are not submitted to respective Tool Options sliders
Treat brush angle and aspect ratio like all other paint options values
that can be linked to brush defaults and take their default values
from the brush. They were special casing their defaults to constants,
and GimpBrushGenerated was adding the passed dynamic radius and aspect
values to its own. This was totally incomprehensible.
Now GimpBrushGenerated's transform_size() and transform_mask()
implementations just translate between these APIs value ranges and the
brush's own value range and only use the passed values (not the
brush's native values), which makes the editor <-> tool options
interaction and the painted brush shape predictable.
Also connect the active brush's property notifications to the paint
options properties, so the paint options follow a brush edit live if
the respective "linked" toggles are checked.
And some cleanup.
Add a GimpFillType argument to GimpItem::resize() and fill type
widgets to the canvas and layer resize dialogs. Fill the new parts of
the drawable according to fill type in gimp_drawable_resize(). Make
sure places that need the old behavior get GIMP_FILL_TRANSPARENT
passed by hardcoding it in the GimpItem::resize() implemetations of
channel, mask, selection etc.
...when moving guides
Show relative coordinates when moving guides and sample points, the
cursor display in the statusbar already shows absolute coordinates.
and move the actual stroking code to select-commands.c,
vectors-commands.c and gimpvectorstool.c. Remember the active drawable
so the stroke always happens on the drawable the dialog was invoked
with.
...when threshold > 0
Add an "Antialias" toggle to the bucket fill options and set it on the
GimpFillOptions. In gimp_drawable_bucket_fill(), pass it to
gimp_pickable_contiguous_region_by_seed() instead of always defaulting
to TRUE.
The position of the toggle and its huge tooltip may need some
adjustment.
... 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/
...selection on the canvas
if the editor dialog is active do not copy to the
clipboard the text selected, copy it instead when
selected with keys <Shift>-left/right.
Pass a GeglRectangle to all gimp_prop_gui_*() functions, and set
the soft limits to the rectangle's extents if the GParamSpec
metadata's "unit" is "pixel-coordinate" or "pixel-distance".
In GimpSymmetryEditor, pass the image extents, in GimpOperationTool
pass the drawable extents.
Whereas some IME would just cancel any preediting on IM context reset,
others would commit their preedit (for instance Ibus-Hangul).
Unfortunately it is not necessarily immediate, even after
gtk_im_context_reset() and gtk_im_context_focus_out(), so when switching
text layer, any preedit text is committed on the new layer.
Let's recreate the IM context on abort to make sure we don't share any
input between text layers.
The IM should be the one taking care of it by sending the proper
signals, and I would assume this should be done when we run:
gtk_im_context_focus_out ().
But it doesn't and leaves a dangling styled preedit text on leaving
a text layer, either because the IME is not properly implemented (not
reacting to the context leaving the focused widget), or GTK+2 is bugged,
or maybe we just don't understand exactly how this all works. Anyway
let's explicitly clean preedit text, not waiting for preedit-end or
commit signals on IM abort.
With left gravity, the mark is moved back 1 character to the left of the
cursor, whereas with right gravity, it is right after newly-inserted
text. This resulted sometimes into non-deleted preedit characters.
I don't understand all the subtleties since the problem only occurred
for the first character of a text layer, at least in my tests.
Anyway now it should be good.
Japanese IME emits the preedit-commit before preedit-end (Hangul or
Unicode don't, but we could assume other IMEs may be doing the same).
As a consequence, the undo step was not pushed, thus breaking undo
history and consistency.
The solution is to simulate preediting end then restart when a commit
happens during preediting.
Since commit b593462, gimp_text_tool_apply() is a semi-public function
(only to be used from gimptexttool-editor.c). Therefore move it to the
"public functions" section.
Commit cd147a4 reintroduced the crash. The culprit was the idle function
gimp_text_tool_apply_idle() which may not have been processed when
gimp_text_tool_move_cursor() is called, resulting in inconsistencies
between the text in the text tool's pango layout and its buffer.
Force any pending text commits to be applied before moving the cursor.
In the text tool editor code, connect to GtkIMContext::preedit-start
and introduce a boolean text_tool->preedit_active which indicates that
a preedit is going on.
Remove the new preedit-removal code from gimp_text_tool_reset_im_context()
because it was not reflecting the IM's internal state and made things
worse. Instead, added gimp_text_tool_abort_im_context() which really
gets rid of any ongoing preedit by force.
In the main text tool code, check for preedit_active and if TRUE,
apply any edits directly widhout pushing undo steps. Factored out
gimp_text_tool_apply_list() for that purpose in order not do
duplicate a lot of code.
On undo and on button_press, force-abort any ongoing preedit. This is
the right thing to do on undo, but not really on button_press, but I
don't see another way to keep states consistent.
The new gimp_text_tool_im_delete_preedit() also makes sure that
text_tool->preedit_string is non-NULL when modifying the buffer,
so it can be used as indication whether or not a preedit is
going on (in order to skip undo stuff while preediting).
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
In particular, I don't want the preedit foreground colors to be
displayed in the text style editor UI. They are only temporary hints
and should not be taken into account as user-chosen style.
When gtk_im_context_get_preedit_string(), we have to inspect the
returned Pango attributes, so that the preedit string can be displayed
in the expected fashion (i.e. as in other programs).
Some input methods in particular would even break the preedit strings
in several chunks of text displayed differently (for instance Japanese),
depending on the cursor position within the preedit string.
First of all, derive GimpFilterOptions from GimpColorOptions, not the
other way around, which was a sick way of magically showing the right
options for various tools. That approach has failed and needed
additional hacks to do the right thing. Simply have the right class
hierarchy and call the right tool options GUI constructors and done.
Remove gimp_histogram_options_gui(), we don't need histogram scale
controls in tool options when we already have them next to the
histograms in the tool dialogs.
Also remove gimp_histogram_options_connect_view() and use a simple
g_object_bind_property() instead.
Reduces members and all sorts of duplication and is a much better
abstraction of what it does. Also make it a lot smarter and
self-updating, chop up the apply() function and move its parts where
they belong. Also, it's now aware of selection changes and does the
right thing.
Don't abort GimpImageMapTool on selection changes, it now nicely
handles that.
see commit below, they are not needed any longer. Also call
gimp_image_map_tool_preview() from gimp_image_map_tool_create_map()
and remove more other calls to preview().
- call it in gimp_image_map_tool_get_operation() so
gimp_operation_tool_set_operation() doesn't need to call it
- gimp_image_map_tool_settings_import() doesn't need to call it because
importing settings changes the config object anyway
Instead, emit "notify" in the config object, which is a hack,
but a temporary one. If should be the right code tho, if only
Gegl pads would be normal properties...
... and improve input method UI. IM should not use some floating overlay
frame to display the preedit text. Instead it is now directly inserted
into the text tool box, as selected text. It permits redimensionning of
the text box while typing, and push the rest of the text when inserting
in the middle (instead of superimposing an overlay box over the current
text box, making everything unreadable).
Input methods still have a few more issues, but this fixes the main UI
weirdness as well as the crash with Hangul IM.
Change things so the guide is preferred over any color picking
interaction of the parent GimpColorTool. Needs a minor change in the
GimpCurvesTool subclass too.
...for the preview?
Change to allow for split previews in all 4 directions. Remove the
direction controls from the filter dialog, and instead implement
shift- and control-clicking on the split guide to switch
original/filtered sides, or orientation.
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).
Add generic tool actions for spacing, hardness and force, and the
GimpToolControl infrasctructure to redirect them to tool-specific
actions. Add tool-specific actions for GimpBrushTool, GimpMybrushTool
and GimpWarpTool as redirect targets. Also fix some existing tool
action callbacks to use the right increase/decrease steps.
and remove lots of labels from calls to gimp_prop_foo_new(). Also
had to manually remove some unwanted labels that are now added
automatically, fixes bug #761880.
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.
which essentially means some cleanup and no more regressions:
- add state POINT_BOTH for moving the entire line
- use the move cursor for moving the entire line
- reorder some functions
- set the tool to handle click events
- make clicks and no-motion releases behave properly
- #if 0 the code for "shapeburst handles", they don't work yet
- return to gimp:shapeburst until we have figured progress for GEGL ops
- indentation, stuff...
Commit the old tool before even creating the new tool. Old and new
tool might be the same and share tool options, and we don't want
the new tool's initialization to mess up the old tool's state.
Fixes changing from one GEGL operation to another without explicitly
confirming the first operation. The bug only killed the cached filter
result, but that's bad enough.
