In tool-group GimpToolButton tooltips, in addition to showing the
description of the currently-active tool, list the other tools in
the group as well, to improve discoverability.
Add a new GimpAccelLabel widget, which shows an accelerator label
for a given GimpAction. Unlike GtkAccelLabel, GimpAccelLabel
doesn't show a user-provided label in addition to that.
Note that the size request of GtkAccelLabel doesn't include the
accelerator part, which is desirable in some contexts.
GimpAccelLabel doesn't suffer from that.
Wherever we store arbitrary-format colors in an opaque buffer, use
double for the buffer, instead of char, so that it has a strict-
enough alignment to handle all our used pixel formats.
Color picking on a single layer still works as it used to. On multiple
layer, it will now pick on the composited color, similarly to sample
merged if only selected layers were made visible.
The PDB/libgimp function gimp_image_pick_color() is also updated to work
on multiple drawables too, giving the same ability to plug-ins (the only
call to this function in core plug-ins have been updated).
Similarly to shift-click on visibility or link toggles, shift-click on
expanders allow to expand/collapse all layer groups at a given level,
but the one initially clicked.
- Don't trigger selection when toggling visibility/links.
- Fix some weird selection jump when clicking while editing a layer
title.
- Return FALSE in GDK_BUTTON_RELEASE so that viewable larger preview
popup gets closed on mouse release.
These actions raise a GimpViewableDialog. For this to work, I made this
widget work with a list of GimpViewable, not a single viewable anymore
(so maybe the widget class name should change?).
When this list contains only a single GimpViewable, it will display
exactly like before, with a viewable preview. With several viewables,
the preview won't show.
This allows to add masks to all selected layers at once, with the same
basic options for all masks, as set in the dialog.
Both with the various action layers-lock-alpha, layers-opacity-* and
layers-mode-*, as well as through the layer tree view GUI (alpha lock
icon, opacity slider and layer mode combo box).
… multi-selected items.
The idea is that with multi-selection now enabled, you may always lose
track and forget you have several items/layers selected. This is
especially true when you have a lot of layers (say you selected one at
the top of the list, another at the bottom; without scrolling, you may
only see one of them). And this can become bad when doing some
destructive action which is allowed on several layers at once (say
deleting several layers while you thought you were deleting only one!).
I got the idea from Thunderbird GUI which also displays the number of
selected conversations in the email list. Same as in Thunderbird, I also
wanted to theme the label similarly to a selected item in the item list
below. This was hard because there is no way to reference the parent
theme colors from within GIMP one. Instead I made so that the label is
always shown as a fully selected text (which is a bit ugly semantically,
but I could not find better). Why I wanted this styling is to give *a
bit* of focus to this info so that it is not too invisible. Otherwise
purpose is defeated. Yet this label is still more subtle than
Thunderbird one (don't want to take all attention toward it). Hopefully
this got the right in-between style.
This got broken by some actions now performed on GDK_BUTTON_RELEASE,
i.e. after GDK_2BUTTON_PRESS. Let's shortcut these actions on specific
case when we edit a cell.
After much thought, tests and discussions with Aryeom, we decided adding
back an active item concept additionally to the selected items ones is a
bad idea as it makes only usage unecessarily complex.
We will just have selected layers. Some kind of operations will work
when more than one item (layers, channels, vectors) are selected while
others will require exacty one item.
In particular, let's replace instances of gimp_image_(s|g)et_active_*()
by corresponding gimp_image_(s|g)et_selected_*(). Also replace single
item in various undo classes by GList of items.
Also "active-*-changed" GimpImage signals are no more, fully replaced by
"selected-*s-changed".
This is still work-in-progress.
This was already implemented for the new button which had its own drag'n
drop handler, and now also for other buttons (in particular the delete
button which is multi-item aware).
In the middle of multi-item insertion, you don't want to run
gimp_container_view_select_items() as was being done in
gimp_item_tree_view_insert_item_after(). As it turns out, this is the
only implementation for this virtual function, and it doesn't need to be
run on the specific inserted viewable, just make it a call to run when
all insertions are done.
For single drawable drag, we still display the name of this only layer.
Also apply some basic markups, showing the drawable count as italic
subscript in parentheses to differentiate it from a drawable name.
I was changing selection only on button release because we don't know if
the initial button press is not going to actually become a drag'n drop
operation. Nevertheless it had a counter-intuitive effect when
multi-selecting some layers then trying to drag another (non-selected)
layer.
To fix this, I actually change the selection on *press* event but only
if the pressed item is currently non-selected.
Though it's not finished yet, I am changing "active layer" into
"selected layers" logics. Probably the "active layer" concept will be
back eventually (i.e. even in a multi-selection a specific layer could
be said "active", highlighted in the list a bit differently, hence one
could edit this specific layer only). But for simplicity, for now, it's
better to first get rid of it, otherwise it's just messy.
This whole drag'n drop code is quite overwhelming, I'm pretty sure this
commit introduced various bugs, and there are already several areas of
improvements I noticed. But at some point, I need to split at a not-too
broken code state or I'll just make things worse.
I wanted to enable it in the end, but it makes my work tree messy. Just
commit this now. Multi-selection basically works but there are still a
lot of broken features which are to be taken care of one by one.
Only enabled for layer tree so far.
Basically the single click selection must happen on mouse button
release, not initial press, otherwise it would cancel your multiple
selection when you were actually about to drag the items.
As for contextual menu, it should trigger a selection only when the
clicked item is not in the current multiple selection.
Properly pass the multi-selection information through the container
classes. Previous implementation was incomplete (most code paths with
multiple item selected were just ignored) and data was passed through
the "select-item" signal with the GimpViewable to NULL and the data to a
list of items (instead of being a GtkTreeIter otherwise). Having a
pointer data which changes meaning in the same function/class is not the
best idea. So instead "select-items" will have 2 list as parameters: a
list of items and a list of GtkTreePath to be used similarly and with
less ambiguity.
gegl:focus-blur blurs the image around a focal point. It can be
used to create fake depth-of-field effects.
Add a prop-gui constructor which uses a FOCUS controller to control
the focus geometry.
There is no non-hackish way of fixing this without adding a new
"use-opacity-paint-mode" property to GimpToolPreset and a new toggle
in GimpToolPresetEditor. Restoring opacity and paint mode can now be
controlled explicitly, and defaults to TRUE.
If we don't do this, the clipboard owner doesn't get unreffed (also the
GtkClipboardClearFunc is not called either, but we don't set any so this
was not a big problem).
The main consequence was that copying was setting the Gimp object as an
owner, which kept a reference and prevent its finalize() method to run,
hence was leaking data (and in particular some GEGL buffers for
clipboard operations, which was how the issue became more visible upon
exit).
The GIR parser is giving warnings because both e.g. a signal, a
corresponding vfunc and a method emitting it are named
"channel_changed", which can and will give issues in some bindings.
The easiest option is to follow the general convention of starting the
signal emitters with `emit_`, which also makes clear the intention of
the method.
When building (at least on 32-bit), fixes this warning:
> app/widgets/gimpdashboard.c:3840:58: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Unsigned long long is specified in the C99 standard to be at least
64-bit. So it's normal that the compiler complains, as a cast from
unsigned long long to a pointer has chances to go very wrong.
Yet gimp_backtrace_get_frame_address() actually returns a guintptr which
is type-compatible with gpointer so let's not give the compiler false
information and just use this type. Then cast it to unsigned long long
just for printing to dashboard log.
In GTK+3 GIMP, without a "width-chars" even short layer names (a few
letters) were always ellipsized to nothingness with the "ellipsize"
property.
So add a reasonable prefered width char (which will be at most 10
characters, less if the layer name is smaller).
Also drop "xpad" property as this is now deprecated.
Apparently, the "drag-begin" signal of dockbook tabs can be raised
multiple times when a drag begins (this seems to happen randomly,
and rarely -- possibly a GTK bug). In
gimp_paned_box_drag_callback(), which gets called in response, make
sure not to leak the corresponding idle source in this case, which
can lead to a segfault if the widget is destroyed before the idle
is run.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
In GimpSpinScale, apply the slider gamma to the input [min,max]
range, rather than the output [0,1] range, using an odd gamma
curve, in particular, so that we handle negative values correctly.
In GimpFgBgEditor, we currently use gtk_render_frame() in master,
and gtk_paint_shadow() in gimp-2-10, to draw a border around the
color FG/BG color areas. However, the former is relatively
subtle, especially with dark themes, and the latter is a NOP with
the pixmap engine, which is what our built-in themes use.
Instead, draw the border ourselves as a pair of black and white
rectangles, similarly to Photoshop.
Move the entire color-frame drawing functionality to a separate
function, to avoid code duplication between the FG and BG frames.
