This fixes the following warnings:
```
[2153/2321] Compiling C object app/widgets/libappwidgets.a.p/gimppanedbox.c.o
../app/widgets/gimppanedbox.c: In function ‘gimp_paned_box_dispose’:
../app/widgets/gimppanedbox.c:171:17: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Wsign-compare]
171 | for (i = 0; i < G_N_ELEMENTS (paned_box->p->dnd_highlights); i++)
| ^
../app/widgets/gimppanedbox.c: In function ‘gimp_paned_box_drop_indicator_draw’:
../app/widgets/gimppanedbox.c:370:17: warning: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Wsign-compare]
370 | for (i = 0; i < G_N_ELEMENTS (paned_box->p->dnd_highlights); i++)
| ^
```
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.
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.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
and use GtkNotebook's implementation instead. This is mostly moving
dockable adding and removing code to GtkNotebook::page_added() and
::page_removed() and removing lots of code.
Fix the return values of drag_motion() and drag_drop() callbacks.
Commit 7b85cf4de8 started mixing up
the two unrelated concepts
- the widgets has handled the event
- a drop here would do something / did something successfully
into one boolean value being both the function's return value and
a success indicator for the DND operation.
Untangle the concepts again by returning FALSE when
gimp_paned_box_will_handle_drag() returns TRUE (indicating that the
docking DND mechanism will kick in), and always returning TRUE
otherwise; and by using the state "drop was / would be successful"
only for calling gdk_drag_status() and gtk_drag_finish().
This way we make sure that:
- drag_leave() is called reliably again (because we return TRUE if no
other widget will handle the event)
- drag data is freed reliably again (because we always call
gtk_drag_finish())
Reduce the minimum width of the "You can drop foo here" label to one
pixel, so it can be hidden as completely as possible while keeping the
label visible.
Ensure a minimum size of the drop area and make sure it stays visible
at the bottom of a minimized toolbox. This wastes a few pixels at the
bottom of a toolbox that contains no dockables.
Reduce the requested width of the "You can drop foo here" label to 16
pixels, which makes is look a bit crappy, but at least the toolbox
becomes shrinkable to < 3 columns. Whoever keeps this empty space
around without using it shall henceforth be punished by having to see
that distorted and misplaced label.
Instead, either destroy the child instead of removing it, or remove
*and* destroy it in cases where the remove() api on the "parent"
doesn't match GTK+'s parent/child relation (like with all our dock
widgets). We can't rely on remove() to implicitly detstroy, because
there might be arbitrary other code holding references, such as
accessibility modules and whatnot. Most likely fixes unclear crashes
in accessibility code and other crashes we blamed GTK+ for.
Instead of including dialogs/dialogs.h everywhere, introduce
gimp_dialog_factory_get_singleton(). The dialog factory singleton is
still initialized by dialogs.c though.
Right now the assumption is that we never will have another dialog
factory instance around. There were so many problems before when we
had four of them, so let's just keep one of them around.
Make drag-and-drop rearrangement of dockables happen directly in the
existing widget hierarchy so we don't have to use special, ugly
widgets (read GimpDockSeparator:s) for that.
More specifically, make edges of dockables and dockbooks have the same
semantics as the GimpDockSeparators had. We put a highlight colored
GdkWindow on top of the widget in question to highlight these special
drop areas. This GdkWindow is not taken into consideration in the GTK+
drag-and-drop code, so it does not interupt the DND interaction.
To achive this, there is a problem we must solve: Drag events in GTK+
are propagated inwards and out, but we sometimes want ancenstor
widgets to take care of drop events. We solve this by introducing the
concept of "drag handlers". A drag handler is asked if it will handle
a given drag event, and if it will, a client will let the drag event
be propagated upwards in the widget hierarchy. Right now, the
GimpPanedBox is the only "drag handler". The code could be generalized
more but it doesn't feel worth it at this point.
The size of the special drop area is 5px, the same size as the default
GtkPaned handles. This is because the plan is to later use these
handles as drop areas too.
Other changes of interest are:
* We need to take care of "drag-motion", "drag-drop" and widget
highlightning ourselves. We can not use the GtkDestDefaults
conveniences with gtk_drag_dest_set() any longer since we need more
control.
* Make the drop callback pass the insert index directly instead of a
GimpDockSeparator
* Add some GIMP_LOG() debug output for DND
* Disable the GimpDockSeparator code in GimpToolbox
Add a new class GimpPanedBox that wraps the arrangement of widgets
into GtkPaned hierarchies. It takes over the separator management from
GimpDock and the GtkPaned management from
gimpwidgets-utils.[ch]. GimpPanedBox can be both vertically and
horizontally oriented.
Change GimpDock to use this widget and make some other minor
adaptations.
