* 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.
... 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.
Add CSS names using gtk_widget_class_set_css_name(), remove styling in
code and instead do it properly in CSS, so far in the System theme.
All horribly incomplete but a start.
Add GimpMenuFactory can always be found in a GimpDialogManager, use
gimp_dialog_factory_get_menu_factory() where we have a dialog factory
instead of accessing "global_menu_factory" or redundantly passing a
menu factory around where we already pass around a dialog factory.
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, inherit from GtkBox directly and set the orientation in
init(). Replace more gtk_container_add() by gtk_box_pack_start() in
the reparented classes.
In order to get accurate measurements of widgets that will be put in a
GimpDock, add gimp_dock_temp_add() and gimp_dock_temp_remove(). That
way we can add a widget temporarliy, measure it with the
GimpDock::font-scale property applied, then remove it when we're
done. We can't apply style properties on widget detached from a
GdkScreen hierarchy :(
Refactor stuff a bit so that the dock window description can be both
short and long. The short version only have the active dockables, and
the long version have all the dockables in the description string. We
use the short version for the window title and the long version for
the Recently Closed Docks menu items.
Add "dialog-factory", "ui-manager" properties to GimpDockColumns and
let GimpDock look for these before trying to look for a dock window
which does not exist in single-window mode.
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.
In order to make a GimpDock get hold of a GimpContext both in
single-window mode and in multi-window mode, don't make it look for a
GimpContext in a GimpDockWindow, put the context in GimpDockColumns
instead. GimpDockColumns exists both in s-w-m and m-w-m, contrary to
GimpDockWindow. Still use the GimpDockWindow as a backup though.
Don't crash when detaching dockables from the image window. This
scenario only occurs in single-window mode. We solve it by using
global variables and checking for NULL for src_dock_window; there is
no dock window when detaching from the image window.
The use of global variables is meant to be temporary.
Move the Image Selection Menu from GimpMenuDock to
GimpDockWindow. That is, if a dock window contains many docks then
they will share the same Image Selection Menu.
To do this we need to move around quite a bit of code. Move the
"context", "dialog-factory" and "ui-manager" properties from GimpDock
to GimpToolbox, GimpMenuDock doesn't need it any longer. Turn the
GimpDock getters for these properties into wrappers that go to the
GimpDockWindow properties. In some places, most notably GimpToolbox
construction, we use the GimpToolbox values of these properties, but
most of the time it works fine to just use the GimpDockWindow
properties. GimpDock::setup() and set/get_aux_info() have also been
moved to GimpDockWindow since the only aux info for docks was for the
image selection menu.
Also, we don't bother porting gimp_menu_dock_destroy() to
GimpDockWindow, but we leave the code around. If this is a problem, it
will show.
To make the smaller font in docks also apply in single-window mode,
move the GimpDockWindow::font-scale style property to GimpDock. We use
the GimpDockWindow approach, so now each GimpDock has a name of the
form "gimp-internal-dock-<id>". We add "internal" to avoid clashing
with the GimpDockWindow legacy id "gimp-dock-<id>".
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.
Allow to set the dropped callback after dock separator construction.
We need this in order to move the dock separators into a common widget
for which the callback to use is not known at construction time.
Move the GtkPaned management code into gimp_widgets_add_paned_widget()
and gimp_widgets_remove_paned_widget() in gimpwidgets-utils.[ch] so we
can share this code for GimpDockColumns later.
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.
Make GimpDock be a GtkVBox instead of a GimpDockWindow. This means we
can now put a GimpDock anywhere, including inside an image window.
In order to do this we need to:
* Separate dock and dock window creation in the dialog factory and
add a couple of new dock window constructors
* Change gimp_dialog_factory_dock_new() to not only create a dock,
but also create a dock window and then combine those two
* Change the dock constructor to take a GimpUIManager since they
depend on that during their construction. We get the ui manager
from the dock window, but we can't create the dock *inside* the
dock window, we have to add the dock later. So we create the dock
window first and then pass its ui manager to the dock constructors
* Make some other minor adaptions, mostly with
gimp_dock_window_from_dock() and gimp_dock_window_get_dock()
Niels De Graef