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
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.
For now, only show dock separators when they are needed, not all the
time. We need a better solution eventually, but at least docks in the
image window doesn't look terrible any longer.
In preparation for making GimpDock inherit from a non-window, stop
casting GimpDocks to GimpDockWindows. Instead look up the toplevel
widget for a dock and get the dock window that way.
Michael Natterer