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.
Step one: get rid of all those deprecation warnings that make
it hard to see any other warnings:
- add a lot of dummy API to GimpAction, GimpActionGroup, GimpUIManager
etc. which simply forwards to the deprecated GTK functions, they
will all go away again later
- rename GimpAction to GimpActionImpl
- add interface GimpAction that is implemented by all action classes,
creates a common interface and allows to remove some duplicated
logic from GimpToggleAction and GimpRadioAction, and at the same
time adds more features
(cherry picked from commit 86e07c16b5)
Merged to gimp-2-10 to keep the diff to master as small as possible
Simplify GimpDockbook's signal connect/disconnect to
GimpGuiConfig::size-changed a lot, most likely to a point where some
connection doesn't get leaked, so this bug is probably fixed.
On macOS, the "drag-end" signal does not seem to be emitted in some
cases, which leaves dockables in an unsensitive state. Rather than
trying to fix GTK+2 which is half-maintained nowadays anyway, let's drop
the unsensitivity. As a comment notes, this was anyway only a visual
cue. Dragging dockables in GIMP 2.10 already shows a lot of other visual
cues, so this is redundant.
In case of drop failure, we also had to cleanup the icon widget and
detach the dockable. This can be handled by the "drag-failed" (which
hopefully work better on macOS).
As an additional improvement, I raise the newly created dockable window,
since this is the most likely behavior when you just detached a dock
(and I realize it usually appeared behind other GIMP windows, at least
on GNOME).
Note: this is a gimp-2-10 only fix as master relies on GtkNotebook DnD
code which (hopefully, as I haven't tested) doesn't have this issue. The
detached window behind other windows issue doesn't exist on master, at
the very least.
... 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.
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
Current code only guess resolution for a single monitor. Ideally
the widget sizes could be different depending on the window where a
given widget is on. But that's a start.
Argh! Always triple-check commits before pushing!
Commit e30c92c had completely wrong big values, which I was using
to make tab border update really visible while testing.
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.
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())
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.
using the proper API, so all stuff is properly disconnected and the
list items managing them are freed to. Also make removing robust
against dockbook->dock being NULL.
We don't need to call gimp_dockbook_refresh_tab_layout_lut() in
added() and removed() because we call
gimp_dockbook_update_auto_tab_style() in add() and remove().
Remove the dockable drag handle and move the menu button it hosts up
to the GimpDockbook, with the gtk_notebook_set_action_widget() API.
This frees up quite a lot of screen estate which can be used for the
content of dockables instead.
Add support for a new type of Tab Style called 'Automatic'. This tab
style makes the GimpDockbook use the biggest actual tab style it can
for its auto tab style dockables, based on its widget allocation.
The tab style candidates for auto tab style are "Status + Blurb",
"Status + Text" and "Status". A docked widget can also say that it
wants to use "Icon" instead of "Status" for its auto tab style. The
'Tool Options' dockable does this. This is to be as backwards
compatible with the old tab style setup, we make 'automatic' the
default everywhere.
We have quite a bit of dependency to internal layout code in
GtkNotebook, but the current code should be pixel perfect and rather
complete.
Also add a basic regression test.
The function gimp_dockable_get_tab_widget() and
gimp_dockable_get_drag_widget are not getters, they create new
widgets. Furthermore, gimp_dockable_get_tab_widget() doesn't use the
instance tab style but takes a tab style paramter. Rename the
functions to gimp_dockable_new_tab_widget_for_style() and
gimp_dockable_new_drag_widget() to reflect this.
When moving dockables from a dock window to an image window, they need
to start listening to the user context. So update the dockables with
the new context when we switch window mode.
When quitting GIMP while in single-window mode and the widget
hierarchies are cleaned up, prevent a tab widget from being
constructed so we don't get any annoying warnings due to failing to
look up a context.
Use g_signal_connect_object() instead of g_signal_connect() so that
the dockable is referenced and not destroyed before
_drag_end(). Prevents a crash, but DnD in single-window mode does not
work properly yet.
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
