...to accept GeglColor paramaters instead
of GimpRGB. This function is used to draw
the layer/channel color tags.
Note that a temporary GimpRGB was left
to use with gimp_rgb_composite ().
It will be replaced once that function is
also converted to use GeglColor.
On Windows, the title bar can be set to light or dark mode via DwmSetWindowAttribute ().
This adds code to update the main title bar and dialogue title bars based on the current theme.
The main title bar uses "prefer-dark-theme", while the dialogue title bars
uses the color of the widget background to assume the correct color.
Brush, font, gradient, palette and pattern choices are currently chosen through
a dialog created by the core, which then returns the user choice to the calling
plug-in. This has the unfortunate consequence of having a pile of likely at
least 3 windows (main GIMP window by core process, plug-in window by plug-in
process, then the choice popup by the core process) shared in 2 processes, which
often end up under each other and that's messy. Even more as the choice popup is
kinda expected to be like a sub-part of the plug-in dialog.
So anyway, now the plug-in can send its window handle to the core so that the
resource choice dialog ends up always above the plug-in dialog.
Of course, it will always work only on platforms where we have working
inter-process transient support.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
There were some mixups between a few representations of menus:
* "_Some Menu" and "Some Menu" should both map to an existing submenu "Some
Menu" (in the GimpMenuModel, the stored path doesn't contain mnemonic).
* The menu item on the other hand should contain the mnemonic and not lose it.
* Not only this, but "Some _Menu" should still map to the same menu, even if it
was already created with a different mnemonic. It means that the first
registered menmonic "wins", as we don't want duplicate submenus with same
title (even if they have different mnemonics).
So this new code is better handling the canonical menu path (no mnemonic, no
section name, no double slashes, no trailing slashes, etc.) vs. the
canonical-with-mnemonic menu path to avoid weird duplicates.
Some additional bugs are fixed where we were creating weird empty submenus
containing the same items as the parent menu as well, or when a submenu title
was a perfect prefix of another submenu title at the same level.
This will replace the "placeholder" concept where I was using an invisible item
with a label and no action, making it invisible. Instead let's just name
(internally) our sections. This has the following advantages:
* Conceptually more correct: basically we just want to place items among the
same category of actions.
* Easier to search for plug-in developers who'll want to place their plug-in
procedures in menus, because it uses an actually searchable attribute
("section-name").
This is used by the core by allowing a special syntax in menu paths: if finished
by "/[Section]" then the item will be place in the specific section named
"Section". In case one actually wanted to create a submenu called "[Section]",
they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a
normal submenu (not a section name) titled "[Section]".
All other usage of square brackets will not be processed in a particular way.
E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be
a submenu and so on.
Finally this system is currently limited to the position of the item itself,
i.e. must be placed as last element in the path. In particular, you currently
cannot use it to position a new submenu inside a section. E.g. say that I want
to create a submenu "From Platforms" under the "Open" section of the File/ menu.
This is currently impossible. With this syntax, we can create new items directly
in the "Open" section, or create a "From Platforms" submenu in the end of the
File/ menu, containing our new procedures.
This could be a good improvement to come.
As a further optimization (even though the big slowness situation is
mostly resolved anyway by a previous commit), let's not rebuild whole
submenus when only a few items were added or removed.
1. First make so that the action "visible" property is only notified
when the visibility actually changes. This way, we can trust that the
visibility of the item and of the related action are properly synced.
2. Now when an action which is part of a model changes its visibility,
we trigger the proper "items-changed" only for the added or removed
item. This replaces the old procedure of removing then adding
everything (i.e. a full reset).
3. Add some utilities in gimpwidgets-utils (out of gimpmenushell.c).
This cleans up some code and also fixes some bugs which were
reimplementing (badly) some code I already implemented (right) in a
static function.
4. Fix adding new actions in sub-sub… menus. Previous code was only
showing the direct parent, not up to the root menu (this could happen
for plug-in procedure items in particular).
Also getting rid of gimp_action_get_proxies() API which is now unneeded, I
think. Furthermore GimpMenu does not have to connect to label changes. Making
the items proxies of a GimpAction is enough to have them updated.
Depending on the OS, the display name may contain characters which are not valid
for action names. In particular, on X11, the display name could be ":0.0" and
therefore we get actions named "app.dock-move-to-screen-:0.0" or
"app.view-move-to-screen-:0.0". The ':' is invalid, which will make calling
gtk_application_get_accels_for_action() (or more simply our new function
gimp_action_get_accels()) fail.
See docs of g_action_parse_detailed_name().
The new utils function gimp_make_valid_action_name() will help us get rid of
invalid characters for actions whose name was generated from strings we don't
totally control.
Furthermore gdk_screen_make_display_name() is now deprecated API, and more
generally gdk_display_get_n_screens() is deprecated too and now always returns 1
since GTK+ 3.10 (i.e. now each display only contains a single screen). Instead
we just use gdk_display_get_default_screen() for every GdkDisplay. So this
commit doubles as GTK/GDK deprecation cleanup.
… blinking it.
This will be necessary to demo new features available only in some
situations. E.g. a new option in line art detection mode of bucket fill
would require said mode to be enabled.
First I strip now every pieces of text. What it allows it to span the
script elements for instance on several lines, indent them and all that.
The second thing is that since all the dockable start with "gimp-", we
may as well allow use shorter names (both are allowed). Same for tool
(which we special-case), all the tool buttons ID start with "tools-"
since we reused the action names. So let's just allow the shorter
versions.
Finally I create a new gimp_blink_toolbox() which is a specialized
gimp_blink_dockable() for the toolbox in particular. I also move there
the whole code about selecting the right tool.
… a given order, not at the same time.
This will be used for the release item notifications to show people
where new or changed features are, but in an ordered blink scenario. For
instance: select a tool first, then blink some tool icon, open the tool
options and finally blink the specific new/changed option. I am hoping
it would help awareness of changes (just words on a web news may make
some features a bit foreign when not used to look in details in advanced
options).
... which takes a pair of GtkAdjustments, and binds the value of
the first to the lower-limit of the second, and the value of the
second to the upper-limit of the first.
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
gimp_widget_flush_expose() has been removed since commit 3089a20167.
I now reimplemented it by simply checking if event sources are waiting
to be processed.
This was heavily needed as the statusbar was not showing any progress
(at least on highly demanding process, such as saving or loading files),
and therefore we were stuck with a seamingly frozen GUI.
Despite the name, this does not apply to a widget in particular anymore,
but to the whole program events.
We currently construct the tool-options GUI for all the tools at
startup, which takes a significant amount of time. Instead,
only register the GUI construction function with the tool-options
object, using the new gimp_tools_set_tool_options_gui_func()
function, and use the registered function to construct the GUI when
actually needed.
It was using deprecated functions regarding how icons used to work, such
as gtk_icon_set_get_sizes() or gtk_style_context_lookup_icon_set().
The last uses of this function disappeared in last commit.
- remove gimp_widget_flush_expose()
- remove the "now" argument to gimp_display_shell_flush() and make it
only update widget states
- rename gimp_display_flush_whenever() to gimp_display_flush_update_region()
and call gimp_display_shell_flush() separately in the only case we
passed FALSE to flush_whenever()
- remove th flush_now interval logic from GimpDisplay, as soon as we
have exposed the canvas, we are in the loop for the next frame clock
tick anyway, so delaying a useless and removed process_updates serves
no purpose
- in gimptool-progress.c, create the invisible grab widget also for
non-cencelable cases, so we can always safely run the main loop
manually to make the progress updates visible
- in gimp-gegl-apply-operation.c, always run the main loop manually
to make the progress updates visible
- in gimpstatusbar.c, leave some FIXME comments as reminder that
we might need the same logic as in gimptool-progress.c
and use it where we used to pass gimp_button_menu_position() to
gimp_ui_manager_up_popup(), remove gimp_button_menu_position() because
it's now unused.
Add "color-profile-path" to GimpDialogConfig to remember the last-used
path in any profile chooser dialog.
Whenever a GimpColorProfileChooserDialog is created, call a new
gimpwidgets-utils helper function that connects to the dialog's "show"
and "response" signals and makes sure "color-profile-path" is set on
the dialog if it doesn't have a current folder already, and sets the
property back to the config object when a profile was actually chosen
from disk.
Add gimp_item_get_merged_color_tag(), which returns the color tag
of the nearest ancestor (including the current item) that has a
color tag other than NONE. Use this function in GimpItemTreeView,
instead of gimp_item_get_color_tag(), to set the cell color of
items, so that item's with a NONE color tag inherit the color of
their parent. Add a boolean "inherited" parameter to
gimp_get_color_tag_color(), which indicates if the color tag is the
item's actual color tag, or an inherited color tag, and modify the
returned color accordingly, so that inherited colors are less
saturated/lighter than non-inherited ones.
gimp_dockable_blink() is used to attract the user's attention to a
specific dockable. Generalize this to arbitrary widgets, by
replacing gimp_dockable_blink[_cancel]() with
gimp_widget_blink[_cancel](), in gimpwidgets-utils.c.
Add property "color-tag" of type enum GimpColorTag to GimpItem so all
layers, channels and paths can be tagged with a color.
For interoperability, use the color list from Krita which is a
superset of Photoshop's colors.
Features a "Color Tag" submenu in the layers, channels and paths
menus, a row of color radio buttons in the properties dialogs,
undo and PDB API.
As a side effect, some common code is now factores out into
items-actions.[ch] and items-commands.[ch] which adds visible, linked
and lock actions for layers and channels.
Add code to GimpOverlayChild which can render arbitrary children of
the widget fully opaque, ignoring the configured opacity.
Add gimp_widget_get,set_fully_opaque() which gets/sets a per-widget
boolean flag to trigger that code.
Set the color picker's and the text tool style widget's color areas to
fully opaque.
gimp_suggest_modifiers(): change "shift_format" and "control_format"
parameters to "extend_selection_format" and "toggle_behavior_format",
which fixes the longstanding problem that the function did the right
thing only by accident.
tools: use gimp_get_extend_selection_mask() instead of GDK_SHIFT_MASK
which is not 100% semantically correct in all cases, but at least a
step in the right direction to make the tool modifiers easier to
improve.
Move some functions from libgimpwidgets/gimpwidgets.[ch]
and from app/widgets/gimpwidgets-utils.[ch]. Newly add
gimp_widget_get_color_profile() which is extracted from
modules/display-filter-lcms.c.
Add a "monitor" parameter and return something reasonable, instead
of a useless resolution average of all the screen's monitors. Also
require a screen to be passed now.
There is now a preference option that determines whether windows
should be opened on the same monitor as before. It should be disabled
when the machine gets monitors plugged/unplugged dynamically ("laptop")
and enabled when there is a static multi-monitor setup ("wokstation").
This is merely the current simplistic policy on top of the newly added
underlying infrastructure:
- pass integer monitor numbers around in all places where we already
pass around a GdkScreen. Pass the "current" monitor to these changed
APIs, where "current" is either the monitor where the action-triggering
widget is, or if that is unavailable the monitor where the mouse is.
- add gimp_widget_get_monitor() in order to easily get to the monitor,
just like gtk_widget_get_screen().
- add screen and monitor parameters in some places that were missed
before.
- in sessionrc, save all window positions relative to the window's
monitor, and save the monitor separately, if it's not the screen's
primary monitor.
- when restoring window positions, use the stored monitor when the new
prefs options says so (use the screen's primary monitor if there is
no stored monitor), otherwise use current monitor that is now passed
around.
Add new utility function gimp_get_all_modifiers_mask() which returns
all modifiers used for "useful" things on the current platform, like
in the commit below.
