Improvements of GimpPickableButton:
- Update the selected pickable live as you choose it in the popup. This allows
for instance to get live preview of GEGL operations while staying within the
pickable popup.
- Store the initially selected pickable (before popping up) so that when one
cancels (either with Esc key or by clicking outside the popup, but not on the
parent button), the button comes back to the previous pickable.
- Properly destroy the popup when the parent widget is finalized to avoid
annoying cases where the popup might still be alive.
Additionally I split the GimpPickablePopup with a GimpPickableChooser containing
most of the GUI, which will make it usable as plug-in pickable chooser as well!
This is a better fix for the previously reverted commit, avoiding
"floating-selection-changed" and "select-items" to recursively calling
each other.
The other fix on context update is similar and was also triggering
crashes because of recursive signal calling after the previous revert.
This got broken in commit 28f6b1b268 because you want to always throw
the signal. Yet the context must only be updated with a grid view in the
GimpContainerEditor. Now it should work correctly (hopefully!).
The whole hack for types managed by context is not needed anymore. It
works fine with generic code. Also because of this hack, there was a bug
when clicking on some button raising a container popup (such as the
"Dynamics" button in tool options) would reset the context to default
value (e.g. reset to "Basic Dynamics") on the first click, without
raising the popup. Only the second click would raise a popup.
… GimpContainerComboBox and add a warning when the implementation is
missing.
Basically the default get_selected() implementation only works for
context properties, not for more generic usage of GimpContainerView. The
new warning will be a lot more informative and will help any future
cases where we might experience this bug.
This prevents repeatitively running the same signals when it is useless.
In particular, I encountered a case of infinite loops between
"floating-selection-changed" and "select-items" ending up infinitely
calling each other (then crashing GIMP).
Now that we have implementations for select_items everywhere and that
all the code is only wired to call or handle select_items, the single
item variant select_item is of no use anymore. Let's make a big cleanup.
… and use gimp_container_view_select_items() when the context changes.
Even though some types of containers still expect only a single
selected content, we should slowly move to multiple item code. The
reason is to avoid 2 code paths which makes the code more complicated
and bug-prone. When all child classes of GimpContainerView will have a
valid select_items() implementation, we can work on getting rid of the
select_item() in favor of the multi-item one.
Rather than trying to fix up our own heuristics using a
`GtkMenuPositionFunc`, use whatever GTK provides to position given a
specific rectangle, which also has the benefit of nicely integrating
with GDK backends such as Wayland. Another advantage is that we can use
GdkGravity to center the popup.
Since GTK 3, GtkWidget also gained a "popup-menu" signal, which we
can/should use instead of rolling our own context signals.
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.
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.
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.
which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to
... while the container is frozen
In GimpContainerView, do nothing in response to a
gimp_container_view_{select,activate,context}_item() call while the
view's container is frozen. While the container is frozen the view
is empty, and these functions can segfault.
The bug is very hard to reproduce, probably because it requires specific
timing conditions but this looks like this commit would prevent it.
Apparently the signal handler gimp_container_view_name_changed() may
have been run while the container view (set as user data) was most
likely already finalized, hence leaving an invalid dangling pointer.
Let's just make sure we disconnect this handler (and another) when we
finalize the container view and its private data.
Add an "expanded-changed" signal to GimpViewable, which should be
emitted by subclasses when the viewable's expanded state changes.
Emit this signal when the expanded state of group layers changes.
Respond to this signal in GimpContainerView, by calling a new
expand_item() virtual function. Implement expand_item() in
GimpContainerTreeView, expanding or collapsing the item as
necessary.
Don't special case on view_iface->model_is_tree and always run
gimp_container_view_remove_foreach(), also on the view's toplevel
container. Run gimp_container_view_clear_items() anyway on the
toplevel as an optimization, but with a big comment. This makes all
views (on list *and* tree models) behave the same way, and makes
view_iface->model_is_tree practically obsolete, will remove it later.
When removing the container of a GimpContainerView,
gimp_container_view_remove_container() must be the last call. It was
causing a `GIMP_IS_CONTAINER (container)' failure in subsequent
gimp_container_get_children_type().
For good practice, unsetting a container works now the exact reversed
order as the setting of a container.
Wrong order of destruction functions were causing critical warnings on
g_signal_handlers_disconnect_by_func() calls.
Also g_object_ref/unref() the container because the tree handler might
hold the last ref to the container, once it's disconnected the container
could be gone.
Implemented infrastructure for multiple selection support.
GimpContainerTreeView actually provides such functionality.
All other GimpContainerViews should work as before.
In the drop callbacks, don't check if the GimpContainerView's container
contains the dropped item, it might be in a sub-container. Instead,
simply checking if the GimpContainerView knows the item is sufficient
(and also much simpler than a recursive container serach).
The new function is called after the item is inserted. This is a much
smaller change than turning all vfuncs into signals just to be able
connect_after to one of them.
* app/widgets/gimpcontainerview.h: add "gboolean model_is_tree"
to GimpContainerViewInterface.
* app/widgets/gimpcontainerview.c: default to FALSE and enable the
commented-out optimization in remove_container() for list-only
container views.
* app/widgets/gimpcontainerview.[ch]: add and remove container trees
recursively. Change virtual function ::add_item() to pass the
insert_data of the parent viewable.
* app/widgets/gimpcontainercombobox.c
* app/widgets/gimpcontainerentry.c
* app/widgets/gimpcontainergridview.c: changed accordingly.
* app/widgets/gimpcontainertreeview.c
* app/widgets/gimpitemtreeview.c
* app/widgets/gimplayertreeview.c: dito, but actually use the passed
parent_insert_data to insert the item at the right place in the
GtkTreeView.
Factor out large portions of identical code into new utility functions
gimp_container_view_connect_context() and
gimp_container_view_disconnect_context().
Keep around the handler IDs for the "name-changed" signals of the
container's children in a hash table that maps containers to handler
IDs and move adding/removing of the handler to
add_container()/remove_container(). This way the name-changed code is
prepared for handling multiple containers.
In preparation of having a tree of containers, added
gimp_container_view_add_container(),
gimp_container_view_remove_container() and
gimp_container_view_remove_foreach()
which do all the job of inserting/removing items and
connecting/disconnecting the "add", "remove" and "reorder" signals.
Also refactored things so when the toplevel container freezes/thaws,
it simply gets removed from the view instead of ignoring its signals.
gimp_container_view_real_set_container()
gimp_container_view_freeze()
gimp_container_view_thaw(): use the new add_container() and
remove_container() APIs and fix the code for the unlikely case
that a frozen container gets added/removed.
GHashTable has g_hash_table_remove_all() since GLib 2.12, so there is
no need any longer to clear the hash table by destroyung it. Instead,
keep the hash around during the view's entire lifetime and remove all
re-creation code and all checks for its existence.
