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.
The "Settings:" label should never be aligned with a label in the UI
below, because that suggests that are related. Also consistently
rename all GimpImageMapTool parameters and variables to "im_tool".
seems I didn't consistently group things in indented GimpFrame widgets
last time I cleaned up here. Should be better now. Also change the
"Auto" button to "Auto Input Levels" to make things clearer.
Add new string members to GimpImageMapTool and use them instead of the
resp. fields of GimpToolInfo. Change ::get_operation() to return the
operation name and a lot of strings for the UI, and create both the
GeglNode and the config object in GimpOperationTool. Lots of various
cleanups in GimpImageMapTool subclasses. This is an intermediate state
on the way of making the whole filter applying mechanism more generic
and less depending on subclasses.
Add "title" and "help_id" parameters and members/properties to
GimpToolDialog, GimpToolGui, GimpOperationTool. Also make the order of
parameters more consistent.
When checked, diagonally neighboring pixels are considered connected
when calculating the affected area.
This commit also adds a corresponding diagonal_neighbors parameter to
gimp_drawable_bucket_fill(), and modifies the callers, other than the
bucket fill tool, to pass FALSE for this parameter, to retain the
current behavior.
...gimp_pickable_contiguous_region_by_seed(), in preperation
for adding a similar option to the relevant tools.
When this parameter is TRUE, all eight neighbors of each pixel
are considered when calculating the resulting region, instead
of just the four orthogonal ones.
This commit also modifies all callers to pass FALSE for this
parameter, to retain the current behavior.
Remove the code that links size, spacing etc. to brush defaults from
the GimpPaintOptions class impl and add it to gimppaintoptions-gui.c
as a callback instead.
It's not a core thing and that magic with side effects should only be
applied to the GimpPaintOptions behind the tool options GUI.
- GimpContext API and property
- a GimpDataFactory
- List and grid views with GimpDataFactoryView
- actions and a context menu
None of this is connected to the actual tool yet, or depends on
libmypaint in any way.
...selection on image in another tab
Fixed for rectangle select, ellipse select and crop, they now all
confirm the previous display's tool interaction instead of aborting it
when the tool is used on another display.
...selection on image in another tab
Make the free select tool behave when switching between displays.
Also clean up the code a bit and reduce utility function
fragmentation.
The Curves tool is to be considered "enabled" as soon as it is selected,
not when it is initialized (usually at the first click on the image).
One of the main consequence of not being "enabled" was that the tool
cursor was wrong at selection.
Add code to GimpOverlayChild which can render arbitrary children of
the widget fully opaque, ignoring the configured opacity.
Add gimp_widget_get,set_fully_opaque() which gets/sets a per-widget
boolean flag to trigger that code.
Set the color picker's and the text tool style widget's color areas to
fully opaque.
gimp_suggest_modifiers(): change "shift_format" and "control_format"
parameters to "extend_selection_format" and "toggle_behavior_format",
which fixes the longstanding problem that the function did the right
thing only by accident.
tools: use gimp_get_extend_selection_mask() instead of GDK_SHIFT_MASK
which is not 100% semantically correct in all cases, but at least a
step in the right direction to make the tool modifiers easier to
improve.
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
We intend reuse the dialog across displays, so don't destroy the
dialog in GIMP_TOOL_CONTROL_HALT, only hide it. This way the dialog
keeps its detached state.
...in the Levels dialog explain the difference between them
Improve the tooltips of the pick buttons to say
"Pick FOO point for {all channels|the selected channel}"
...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.
...certain sets of linked layers
Fix the move tool (GimpEditSelectionTool) using the same principle
as the other "linked item" features, just a bit more complicated...
Never translate the active item and its linked items separately,
always translate the entire list at once.
The linked logic was distributed across the entire file. Changed the
code to prepare lists of items that are translated live (layers and
vectors), and items that are translated at the end (channels, masks
and the selection). In the motion and button release functions, simply
use the prepared lists without any further duplicated checking.
Also clean up the stuff a bit, there is more cleanup needed but first
the fix...
...certain sets of linked layers
Fix for translating layers from the PDB, and with the cursor keys
for gimpeditselectiontool. Moving layers with the mouse is still broken.
The approach is exactly the same as in 25a696c7.
...certain sets of linked layers
Fix this bug for flip, rotate and general transforms (not for move yet):
gimp_item_linked_flip,rotate,transform(): always transform the passed
item too (do not filter it out of the list of items), so these functions
do the entire job of transforming a linked group now. Transforming the
active item separately didn't work (and is not implementable) if both
a layer and its parent layer group were linked.
flip tool, transform tool, layer->transform callbacks: don't call
gimp_item_foo() *and* (if the item is linked) gimp_item_linked_foo().
Instead call gimp_item_linked_foo() if the item is linked, and
gimp_item_foo() otherwise.
This commit also kills the mis-feature of transforming the selected
pixels of the active layer, and then the linked items completely. We
now either only transform the selected area *or* the linked group.
...when opened by the "Edit these settings as Curves" button on the
Levels dialog
The code to configure the entire GUI correctly was not even called
when initially creating the curves dialog (the color bars probably
looked right just because of default values of their own).
Factor out gimp_curves_tool_update_channel() which properly updates
the GUI. Call it after the dialog has been created, and when the
active channel changes.
Keep the config values around even if compiled without MyPaint brush
support, so we remember the values between sessions of differently
compiled GIMP versions.
Reorganize tool modes to be { ADD_TRANSFORM, MOVE, REMOVE }, where
ADD_TRANSFORM is the default and allows to add handles *and* transform
the image in one click-drag. MOVE moves handles without transforming
(shift) and REMOVE removes handles (control). Also improve cursors to
accurately show the result of a click.
