Replaces "Solid Colors" option in Fill Path with Foreground/Background
Colors options. This allows users to fill with either, rather than
having to switch the foreground color each time.
GIMP_CONTEXT_PROP_MASK_BACKGROUND was added to the fill and stroke
contexts to allow the background color to be recognized.
In places where Solid Color was used as a default, Foreground Color is
now used instead.
This patch does the following things:
- An option "Merge menu and title bar" (this is hopefully more understandable
than calling it "Client-side decoration" or again "header bar") is added in
Preferences > Image Windows. This option triggers the restart warning.
Moreover when checked a small warning message will tell that in some cases, it
may not work (there are feedbacks of people having 2 title bars when using GTK
applications using CSD).
- For the reason evoked above (sometimes 2 title bars) and also because the CSD
concept seem really to divide people a lot (some love this as much as others
hate this), this new option "custom-title-bar" on GimpGuiConfig is FALSE by
default.
- When the option is checked, the image windows will use a GTK header bar
containing the menu, the window title (image name and information) as well as
the usual minimize/maximize/close buttons per your OS conventions.
- Since the header bar is set to be hidden when maximizing, if you checked "Show
menubar" for the "Default Appearance in Fullscreen Mode" in Preferences >
Image Windows > Appearance, the menu will be moved to its "old style"
position, i.e. above the canvas. This makes the menu possibly visible (if
relevant option is checked) even in fullscreen mode.
- I tweaked the Default theme to show the header bar with minimal height,
because I find GTK default theme's headerbar height unreasonably high
(especially if the point of the header bar is to save screen space). I am
unsure if this was the right move though, because maybe the default theme
should not do such choices (maybe this should go in the Compact theme?).
I don't see a reason why the quick mask menu was sharing the same
manager as the image menu (the main top menu and on-canvas). This was
why it was receiving all notifications to create menu items on <Image>,
as registered by plug-ins.
Giving it its dedicated manager makes sure this doesn't happen.
Use g_idle_add() instead of g_timeout_add(300ms), which makes
it respond instantly, while still keeping the actual zoom
call out of the slider callback.
Fixes#9500
By doing `gimp_display_shell_pointer_grab()`, we actually prevent events
from a tablet coming through. There doesn't seem to be a reason to use
it and it's not regressing in functionality either, so let's just remove
it.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8016
Note that it will only work for a model attached to a GimpMenu. In particular,
it won't work for the menu bar set to a GtkApplication with gtk_application_set_menubar().
In other words, it won't work on macOS where we let the OS handle the menu.
Use this for the "View > Zoom" and "View > Flip & Rotate" submenus which used to
display the zoom level and rotation angle. This regression is now fixed.
Since we now generate actions for GEGL ops, we might as well generate menu items
for these too.
What I did:
- Move the "GEGL Operation…" tool (generic dialog with a drop-down list of all
non-ignored GEGL ops) to Tools menu.
- Create a "GEGL Operations" submenu in Filters > Generic.
- Move "GEGL Graph" to the top of this new submenu.
- Generate a new menu item for each generated action tied to a GEGL plug-in,
alphabetically sorted.
Though the GEGL Operation tool is still useful as a generic dialog, let's
generate also per-operation (the ones not ignored and not already special-cased
in the rest of the GUI) tools and actions.
These "tools" are mostly hidden (e.g. not selectable in toolbox where it would
be a bit useless as they would show with the generic GEGL icon or none), but
they can be searched with the action search, shortcuts can be assigned and they
can be added to menus.
In particular on macOS, we want to show some default common actions (see
comments in !837) but gtk_application_prefers_app_menu() docs says that it will
always return FALSE on this OS. So we ignore this call on macOS.
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.
Testing the 2 code paths is otherwise extremely annoying. Let's just add an
environment variable allowing us to run one or the other implementation if the
variable is set.
Since GAction don't have labels or visibility, it is up to every application to
fill the GMenuModel with such infos. In my previous implementation, I was simply
handling these in GimpMenuShell subclasses (GimpMenu, GimpToolbar and
GimpMenuBar) since we need them for tooltip support (unavailable from GMenu).
Nevertheless there are cases where we want to use GTK API directly with a
GMenuModel, in particular with gtk_application_set_menubar(). This is necessary
to handle the macOS specific code path, where we don't want our usual menu bar.
This OS has its own display of a software menu bar, directly in the desktop GUI.
See !558 for some screenshots of this.
So this commit moves around some code away from GimpMenuShell subclasses into
the new GimpMenuModel class. Now we use this new class instead of simpler GMenu
objects. It handles syncing with GimpAction-s, auto-updating labels, visibility
and sensitivity, as well as adding custom items (plug-in actions, recently
opened files, opened images, etc.).
My last commit message was slightly wrong. I had one last special case to
handle: the ability to only create sub-GimpMenuShell (i.e. at a specific path
other than the root).
We are using this ability in particular for tool options submenus.
I only translated the undo menu into GtkBuilder's .ui format for now.
The only missing part is that the icon is now shown.
Note that in various parts, I don't rely anymore on a bogus menu action (i.e.
"undo-popup" action in this case) which does nothing but has an associated label
and icon. I simply add the label and icon as submenu attribute directly in the
.ui file, which is translatable and whose strings should be parsed by gettext.
Eventually I'll just get rid of all the various "*-popup" or "*-menu" bogus
actions.
This demonstrates a first version of our replacing menu, using GAction and
GMenuModel. I had to make our own subclass of GtkMenu to process the model (from
a .ui XML file) for the following reasons:
* gtk_menu_new_from_model() doesn't support tooltips, which is a feature we use
quite extensively in GIMP: with all our filters, being able to give a longer
description is often useful; moreover we use tooltips to give hints about why
a menu item is deactivated as well.
Unfortunately it looks like GTK doesn't consider this lack as a problem and
don't plan on adding tooltip support.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/785
* I won't to avoid copying action's label and icons in the .ui file. This only
duplicates strings and would be a source of issues each time we change
action's strings (we'd have to do it in 2 places, which someone will
inevitably forget).
Now it still has various issues:
* The syncing between actions and menu items need to be cleaned up. It's still
in early demo code.
* It uses directly some Gtk*Action code because GimpRadioAction and
GimpToggleAction are not directly related right now (only through their
parents).
* gtk_application_set_menubar() might still be necessary on macOS as I think
it's what enables the native menu system on this OS. It means that we'll have
to edit the menu model to add back the labels (as this function does not
extract these from the linked action since GAction has no label or icon
concept).
* Icons are not taken into account right now.
* I'll have to verify if GimpAction with proxy work (but my guess is that right
now, it won't).
* Action's active state is not synced with menu item active state right now.
* Various actions are inserted live, such as opened images, opened views,
recently opened images, and so on. This needs to be implemented back.
* Plug-ins need to be able to create their own menu item into this new menu.
* For all these various reasons, I'm keeping the old menu around, for the sake
of comparison, until the time the new one becomes feature-full.
Part of this commit is inspired by !558 and obsoletes this MR.
gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory
(shell->profile_data). Unfortunately while converting prevision in
gimp_image_convert_precision(), we change the "precision" property (hence the
source format) first, hence end up trying to write data in a too small buffer.
This crash was hard to find as it was not showing up on my machine (though it
did produce rendering artifacts!), unless I built both GIMP and babl with
`b_sanitize=address`.
Note that an alternate fix was to make sure that the profile_data buffer is big
enough (by calling gimp_display_shell_profile_update() before rendering), but
anyway the image is in an inconsistent state while conversion is in progress:
whereas the `src_format` is the new one, the `src_profile` is still the old one
(and cannot be changed before we finish converting).
Moreover the render happen regularly on progress signals, once after each
converted drawable. So each of these rendering step happens in an inconsistent
state, with the wrong profile set, some of the drawables converted and others
not yet.
We could still render properly if each drawable's buffer used space-aware format
(thus allowing different drawables to use different profiles/spaces), but it
feels over-engineering the problem. It might be much better to ignore rendering
steps while converting the image precision. Moreover it would obviously make a
faster conversion.
See discussions in #9136 for this crash, which didn't have dedicated report
AFAIK.
(cherry picked from commit de25be9210)
Note: on the `master` branch, even with sanitized code, I don't get the crash.
Yet this change seems relevant enough that I'm adding it.
When the clipboard contains raw image data or single layers, it's the same as
the normal "Paste" (and "Paste In Place" respectively). These actions are useful
if you want to copy a bunch of layers and paste them "merged" into a single
layers (since now the copy-paste of multiple layers will create multiple
layers).
It is somehow similar to the "Copy Visible" action except that it works on
selected layers only and work at paste time, making the action more versatile.
When dropping a buffer, we just consider it like common data pasting, hence we
leave the GIMP_PASTE_TYPE_NEW_LAYER_OR_FLOATING algorithm decide what type of
paste it will be.
Reviewer's message (Jehan): This was a work-in-progress by Niels, which
we only keep in this state because Lukas worked over it. I have rebased
and fix-amended many broken part of this commit, because various things
had been changed in these areas of code since this commit was initially
written.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
If we released first the modifiers, then the pointer button during
scrolling, we could end up blocked on scrolling. This makes sure the
button release is the finale scroll unlock, allowing modifiers to be
only used for starting the scroll.
It also fixes activating custom actions, by storing the action
description from the initial modifiers at press time, not release time.
The GimpColorProfileComboBox widget requires the profile chooser dialog
to be explicitly constructed. It doesn't create it by itself.
I guess I hadn't tested clicking this "Select color profile from disk…"
combo item during review. I only selected visible profiles in the list!
This adds a Soft-Proofing pop-over menu when right-clicking the toggle
in GimpStatusBar. It lets users toggle proofing, using BPC and showing
out-of-gamut colors. It also lets users change the profile and
rendering intent.
Opacity and brush size are among the 2 most common tool options which
people might want to often change, though we should likely later add all
other common types of tool settings angle, aspect ratio, spacing, etc.
I am also unsure using the enum action is the right call because what it
does is just taking into account the distance from initial click to
compute an opacity. Instead it might be more interesting to increase or
decrease slowly or rapidly by going right or left from the initial
click. We'll see. But it's a first step.
The mouse controller had many limitations:
* It was not per-device.
* It was a long hard-coded list of events, which made its evolution
annoying and scrolling the list boring.
* It was starting at button 8, while the first buttons were supposed to
be hardcoded interactions. And it stopped at button 12, while some
device might have more buttons nowadays. See !386.
* The "Grab event" does not seem to work in many cases, according to
feedbacks.
The new GimpModifiersEditor will now handle any button (except the first
button, which is reserved for tools), you can even override or change
default canvas actions (panning, rotation, etc.). It should not be
limited with a max button number either (though I haven't tested with a
device really having a lot of buttons since I don't have any such device
but I did emulate huge button numbers on my stylus with xsetwacom and it
did work well; hopefully I'll get feedbacks). And now it can even run
custom actions.
So basically it should deprecate the mouse controller as the modifiers
editor can do everything the controller could, and more (unless I missed
anything).
Custom actions are basically any action (currently GtkAction) which can
be assigned a shortcut. Now they can also be assigned to an input device
button (with modifier or not).
* The relative brush size change was not implemented anyway. Maybe later.
* Also changing the defaults to GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE
which I think might be the most understandable size variant.
* Finally re-label "Rotate" to "Rotate View" as per Aryeom's feedback
because just "Rotate" is indeed confusing as it could mean several
different actions in GIMP.
Actually I am renaming GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE into
GIMP_MODIFIER_ACTION_BRUSH_RADIUS_PIXEL_SIZE, which allows to set the
brush size on-canvas, starting from center to border.
The new GIMP_MODIFIER_ACTION_BRUSH_PIXEL_SIZE now sets the brush size
from one border to another.
Space: panning
Ctrl-space: zooming
Shift-space: rotating
Ctrl-shift-space: constrained rotating
Note that these are still hardcoded, unlike the actions through
modifiers + pointer buttons.
