I've tested lightly this removal. I don't think this code was really
needed or logical anyway, though maybe I am missing something because I
barely discover the existence of this "Image Selection" feature of dock
windows!
As Cheesequake noted in !1673, there may be cases where one would want
to run gimp_help_connect() while also setting a tooltip. So they also
run gimp_help_set_help_data(), even though the latter is implied by the
former. Worse, it makes the order matter too much because if you call
gimp_help_connect() after gimp_help_set_help_data(), the tooltip would
be removed.
Now the reason is that gimp_help_connect() was clearly made to be run on
windows whereas gimp_help_set_help_data() was for other widgets, which
usually don't need to react to F1. Yet the previous commit does add
F1-connect for the lock buttons, which kind of makes sense. So why not
just add this tooltip argument.
As a side fix, I am removing a bunch of gimp_help_connect() on each
button in the layers effect popover. Just run it once on the top
container.
Needs backport to 2.10
gimp_dock_windows_constructed creates a GimpDockColumns, a child widget,
and keeps a private reference to it at dock_window->p->dock_columns.
Then it connects the signal dock_columns.doc_removed to two callbacks:
gimp_dock_window_dock_removed() and gimp_dock_window_update_title().
gimp_dock_window_dock_removed() callback is called first and can
destroy the GimpDockWindow widget and its child widget GimpDockColumns.
Then gimp_dock_window_update_title is called
and tries to call dock_window->p->dock_columns.get_docks()
but it is already destroyed.
The fix is to nullify the internal pointer to dock_columns when destroyed,
and encapsulate access to dock_columns.get_docks so that it
returns a valid but empty list when dock_columns has already been destroyed.
Alternatively, you might be able to fix it by rearranging the order
of connections to dock-removed signal, but then the title would be wrong.
Another alternative might be to rethink the whole destruction sequence.
Pre-GIMP-3.0 code logics would re-allocate several GimpMenuFactory or
GimpUIManager for no good reason. While it was still working with old GtkAction
code, with our new GAction-based code, we were ending up overriding an action
with a new version of the same action, while keeping reference to old actions.
This made for discrepancies of the enabled or visible state of actions.
The new code keeps singleton of some objects and references to already
registered GimpUIManager or GimpActionGroups objects and make sure no actions
with the same name are created twice.
GimpDisplay contains only the ID logic and the "gimp" and "config"
pointers, and lives in the core.
GimpDisplayImpl is a subclass and contains all the actual display
stuff. The subclass is only an implementation detail and doesn't
appear in any API.
Remove all hacks which pass displays as gpointer, GObject or
GimpObject through the core, or even lookup its type by name,
just use GimpDisplay.
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
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
... 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);
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.
...one image onto another
gimp_dock_window_display_changed(): make sure the "auto-follow-active"
logic works both ways: when the active image or display is changed in
a dockable, update the global context. Fixes multi-window mode.
gimp_context_real_set_display(): make sure a context's display and
image are always in a consistent state and never have a display that
is not display->image: when display is the same as context->display,
check that the context's image matches display->image, so that after a
gimp_context_set_display(), the context is consistent in all
cases. Fixes single-window mode.
Add GimpDockContainer::get_dock_side() and write that info in the
sessionrc file. In single-window mode, a dock can be either on the
left or right side of the image window. In a dock window however, the
side concept doesn't apply ('side' has nothing to do with what column
a dock is in in a GimpDockColumns)
Make GimpDockContainer::get_docks() return a new list and not just a
pointer to a list so that GimpImageWindow can implement it (who needs
to merge its two GimpDockColumns lists).
Make GimpDockWindow implement the GimpDockContainer interface. The
plan is to make GimpImageWindow also implement the GimpDockContainer
interface when we start to session manage docks in single-window mode.
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 a helper function gimp_dock_window_should_add_to_recent() which
properly handles the toolbox with regards to what dock windows that
should be added to the list of recently closed docks.
Since the order of docks in a dock window is arbitrary, it can never
be correct to only care about the first dock. Remove
gimp_dock_window_get_dock() and correct that code that made use of
it. (The function itself was introduced when there could only be one
dock per dock window.)
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.
Get rid of 'global_toolbox_factory' and manage everything dock-related
with 'global_dock_factory'. The whole of 'global_toolbox_factory' was
a big special-case and getting rid of it makes it easier to extend the
session management with e.g. single-window mode dock functionality.
To get rid of 'global_toolbox_factory' we, roughly, have to
* Replace 'global_toolbox_factory' with 'global_dock_factory'
everywhere. We can also get rid of lots of code that did special
things for the "toolbox" factory.
* Make the use or interaction with the toolbox explicit in some
places. For example, a function gimp_dock_window_has_toolbox() has
been introduced.
* Make GimpSessionInfoDock have an 'identifier' parameter so we can
differentiate between the "gimp-dock" and "gimp-toolbox" dock
types.
