This commit removes the empty-dock-pane message, and instead
highlights all empty dockable drop-target areas once a drag
operation begins.
Add new gimp_dockbook_{add,remove}_callback() global functions,
which can be used to register a callback function to be called when
a dockable drag operation begins and ends.
Register such a callback in GimpPanedBox, and use it to highlight
all drop areas the widget handles. Furthermore, when the widget is
contained in a GtkPaned, make sure that it has a minimal size for
the duration of the drag operation, so that the drop area is
visible even if the widget is normally hidden.
In GimpToolEditor, update the visibiltiy-toggle state in response
to the corresponding tool-item's "notify" signal, rather than its
"shown-changed" signal, since the latter is not emitted when the
item's visibility changes while it's not shown.
Add a new Gimp::tool_item_ui_list, which is a GimpTreeProxy over
Gimp::tool_item_list. This allows us to use either a hierarchical
or a flat tool list in the UI, by setting the "flat" property of
the new list.
Use Gimp::tool_item_ui_list in GimpToolPalette, so that the toolbox
layout is affected by this choice.
Add a "Use tool groups" toggle to the toolbox preferences, and bind
it to the "flat" property of Gimp::tool_item_ui_list.
Add a new read-only GimpToolItem::shown property, and a
corresponding GimpToolItem::shown-changed signal, which determines
if a tool item is visible throughtout the hierarchy, i.e., if it
and all its ancestors are visible. This replaces
gimp_tool_item_is_visible().
Use the new property and signal in GimpToolPalette and
GimpToolEditor, to simplify the code, and in preparation for a flat
toolbox view.
When the active tool of the tool group associated with the
currently-selected tool changes, we select the new active tool;
this is currently handled in GimpToolButton. Move this logic to
GimpToolManager, which already handles the other half of the
problem: updating the group's active tool when one of its tools is
selected.
In GimpToolPalette, allow for a single-column layout, which is more
practical now that we have tool groups. Note that other widgets in
the toolbox pane might still prevent a single-column layout, in
particular, the empty-dock label.
Add a new GimpToolButton class, used for tool-buttons in the
toolbox, instead of implementing them directly in GimpToolPalette.
Each GimpToolButton is associated with a GimpToolItem, which can be
either an individual tool or a group.
When a tool button is associated with a group, it displays the
group's active tool, with an arrow at the corner. Clicking the
button selects the active tool, while clicking-and-holding, or
right-clicking, shows a menu of all the tools in the group.
Alternatively, the active tool can be changed using the scroll
wheel.
Add tool-group support to GimpToolEditor, used to organize tools in
the Preferences dialog, including creating, rearranging, and
deleting groups. Also, major cleanup.
In the default implementation of
GimpContainerTreeView::drop_viewable(), handle the case where the
source and/or destination viewables are not direct descendants of
the tree-view's container, but rather of one of its subcontainers.
... if not using unique names
Add a new GimpContainer::get_unique_names() virtual function, and a
corresponding gimp_container_get_unique_names() function, which
determines if the container uses unique names for its objects.
Override get_unique_names() in GimpList, to return the corresponding
property.
In gimp_container_deserialize(), don't merge new objects with
existing objects sharing the same name if the container doesn't use
unique names.
Add GimpToolItem as a common base class for toolbox items.
Derive GimpToolInfo from GimpToolItem, representing an individual
tool. The next commits add support for tool groups, represented by
an alternative subclass of GimpToolItem.
Most of the tool-info properties remain in GimpToolInfo, however,
GimpToolItem takes care of tool-item visibility.
Add a new GimpToolTransform3DGrid tool widget, subclassed from
GimpToolTransformGrid, which can be used to perform 3D
transformations.
The widget can be in one of three modes:
CAMERA - allows adjusting the primary vanishing point by moving a
handle.
MOVE - allows moving the object through dragging.
ROTATE - allows rotating the object through dragging.
By default, controlling the transformation through dragging applies
to the X and Y axes. Holding Shift (or setting the "constrain-
axis" property) restricts the motion to only one of the axes.
For the MOVE and ROTATE mode, holding Ctrl (or setting the "z-axis"
property) allows controlling the Z axis instead.
For the same modes, holding Alt (or setting the "local-frame"
property), applies the adjustments in the object's local frame of
reference, instead of the display's global frame of reference.
GimpPivotSelector is a 3x3 grid of toggle buttons, used for
selecting a natural pivot position (e.g., for a transform) relative
to an item: its center, its corners, and the midpoints of its
edges.
Which is a linear transform of xyY that is more perceptually
uniform, and so well-suited for eventually adding chromaticity
diagrams to GIMP color tools. ACES documentation uses this color
space instead of xyY for showing chromaticity diagrams. Moving
forward I expect other venues also will start using Yu'v' as
the advantages over xyY chromaticity diagrams are fairly obvious.
Adds a number of modifier keys to the layer dockable's new "Merge Down"
button to access further functions, and adds among them a new action to
merge visible layers using the dialog's last values, akin to those
accompanying the New Layer and Add Layer Mask dialogs.
Modifier keys are bound as follows:
Shift -> Merge layer group
Ctrl -> Merge visible layers
Ctrl + Shift -> Merge visible layers from last used values
The Merge Down button is kept sensitive even when the current layer
can't be merged down to allow access to these functions
As they are both mutually exclusive and serve an almost identical
purpose, the "Merge down" and "Anchor Layer" are given mutually
exclusive visibility in menus, and the anchor button is replaced
with a merge down button in the Layers dockable whenever there is
no active floating selection
gtk_widget_get_window() may return NULL. I had the case when opening
some menus in bottom of tool options (like the "Save|Restore Tool
Preset" menus). We must check this before doing anything with it.
Previously we were only passing this information on the debug dialog
when debugging warnings and criticals. Now it will also have the
information for crashes, hence recommending people to update their GIMP
instead of reporting bugs on old versions.
Instead of making the focus on bug reporting, the debug dialog will now
make the focus on updating the application if it is found that one is
not using the last version.
Debug data (backtraces and co.) will still be available and copiable,
but under an expander, and bug report button won't be displayed (i.e.
data will still be available upon request but we don't push anymore
people to submit it directly if they are using old versions of GIMP).
Of course, if you are using the last version (or version check was not
possible), the dialog still stays the same.
...MyPaint brushes dialog
In gimp_tag_entry_assign_tags(), don't add/remove tags while iterating
tag_entry->selected_items, because that might change the list. Instead,
make a temporary deep copy of the list and iterate the copy. Spotted
by Massimo.
The GimpDial widget can now be snapped to the nearest fifteen degree
interval by holding the shift key while adjusting. When adjusting both
an alpha and beta value, both will be snapped according to the alpha,
preserving the angle between them
In gimp_histogram_view_update_bins(), don't update the view's
range if there's no histogram or the histogram is empty, to avoid
discarding the existing range. Additionally, improve the range
readjustment when the number of bins changes.
Add an n_components parameter to gimp_histogram_clear_values(),
which allows to set the new component count when clearing the
histogram. This is useful to seed the histogram with the correct
number of channels, for display purposes, before starting an async
histogram calculation. We use this in GimpHistogramEditor, to
avoid resetting the view's channel back to "Value" each time the
active drawable changes.
In GimpHistogram, get rid of the "n-channels" property and
corresponding gimp_histogram_n_channels() function. The former
returned the actual number of channels, but this wasn't too useful,
as channel values may not be sequential; the latter returned the
number of components. Instead, add an "n-components" property and
a corresponding gimp_histogram_n_components() function, both of
which return the number of components. Furthermore, add a
gimp_histogram_has_channel() function, which determines if the
histogram has a given channel; this allows for simple testing for
channel availability, which was done wrong in various places.
Adjust the GimpHistogram code for the changes, and clean it up,
fixing a few bugs.
Adjust users of GimpHisotgram for the changes. In particular,
in GimpHisotgramView, fix the channel-availability test when
setting the view's histogram (which happens whenever the active
drawable's preview is frozen), to avoid erroneously swithcing the
view's channel back to "Value" when a non-RGB channel is selected.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Similar to commit 9b328167ab. Apparently the same function is duplicated
into app/.
Also add some comments to detail a bit more where this Win32 different
comes from (i.e. bug 359538 on Bugzilla, commit eac61e1e12).
Moreover I tested the same steps as comment 4 in bug 359538 on master
code. The same hanging issue still exists with GTK+ 3.24.1 (in a Windows
VM at least). I have not investigated further, just wanted to check if
this ifndef could not simply be removed by now. Apparently not.
and remove a gazillion gtk_widget_show() all over the place, some
places need a gtk_widget_hide() now, and I'm pretty sure I broke at
least one thing in all those files...
to match gimp_int_combo_box_new(), and add gimp_int_store_new_valist().
Move the va_list of (name, value) parsing code to
gimp_int_store_new_valist() and use it from
gimp_int_combo_box_new_valist().
This makes the entire GimpIntStore/GimpIntComboBox stuff useable much
more generically for the price of an incompatible change of a public
function that is used exactly once outside of libgimpwidgets.
Add a new "Swap compression" option to the preferences, allowing
explicit control over the tile-swap compression algorithm.
Previously, control over swap compression was only possible through
GEGL command-line options/environment variables. Since the GEGL
API to list all available compression algorithms is still private
for now, we currently only list the three predefined compression
levels -- "best performance" (the default), "balanced", and "best
compression" -- and a "none" option, to disable compression
altogether. Selecting a custom compression algorithm is possible
by entering its name manually.
This function returns a HINSTANCE (which is technically a pointer if I
understand correctly) for backward compatibility reason. But this is
actually meant to be used as an int only according to the docs.
Yet casting to gint outputs "cast from pointer to integer of different
size" warnings.
We should use intptr_t instead for such cases, since it is a type made
explicitly to hold a pointer as int, hence should always be right on any
platform.
https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutea
In GimpBufferSourceBox, dup the selected buffer (and flush the
pickable to make sure it's fully rendered) instead of using it
directly in the source node. This avoids chunking artifacts when
the buffer's content depends on the filter output, such as when
using the affected layer, or a dependent projection, as input.
