Remap font names to unique generated names
so that pango sees them.
keep the font name for display and the internal
name for everything else.
* Fonts are still broken When exporting to pdf
* Not sure if xcf files would be usable on other systems
maybe use hash of psname internally instead
* Not sure if plug-ins using text layer work correctly
(do they use internal font name or the actual name?)
Inline completion is case sensitive, this makes it
broken, because fonts desplayed in the pop should be
quried in a case-insensitive manner.
This fixes#2832.
See gtk issue #275.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
Use the dedicated function rather than comparing strings.
Because of this, menu items for the "windows-display-*" actions were not
destroyed, neither were the relevant images because the proxy menu item was
keeping a reference to the image (for the small in-menu preview in Windows
menu).
"Windows" and "Help" should always be last. New top-level menus (created by
plug-ins, scripts or GEGL ops) will be appended in the order of creation between
"Filters" and "Windows" menus.
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.
Though I didn't encounter this bug in my commit 54b22c717a, 2 unit tests are now
failing with:
> Bail out! Gimp-Widgets-FATAL-CRITICAL: gimp_ui_manager_update: assertion 'GIMP_IS_UI_MANAGER (manager)' failed
I am assuming this is a consequence of this code I just changed.
This GTK widget code could be reach from a thread calling gimp_image_flush().
Yet all GUI-related code must happen in the main thread (also even though
actions are not GTK code anymore, they can trigger GUI updates).
No issue happened from this so far (that we know of), but a trace by SBDaule for
their growing layer project showed that we'd reach this code if calling
gimp_image_flush() from the paint thread.
This results in an infinite loop and there is no change done, so no reason to
flush anything. Mitch had a fix for this (probably the same, per the IRC
discussion), but I really wanted to just release GIMP 2.99.16. So Mitch, if you
read this, sorry for not waiting for you to push this one!
Resolves issue with #8461.
This provides a conditional value for the fill options to only show
a color and pattern, rather than fore/background colors.
Currently only used for the text editor.
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.
With more recent logic, not all actions are inside the application's action map.
We need to look up actions in our GimpUIManager.
This fixes failing to find the actions with the "text-editor." prefix (in the
text tool editor's toolbar).
The RGB histogram shows three histograms overlaid on each other.
This multiples the pixel and count attributes by 3. To correct this,
the result of gimp_histogram_get_count () is divided by 3 for the
pixel and count displays.
Additionally to the F1 shortcut, a secondary icon is now shown in the
action search entry. It works exactly the same as F1, i.e. that by
default, it shows the action search manual page (when nothing is
selected), or the manual page for the specific action currently selected
otherwise.
The default F1 result (if no action is selected) is to show the generic
help page for the action search. If an action is selected, it will show
the specific help for this action.
This reverts commit 3a35974e3a.
This is not the right fix for the issue (which was happening on the
Quick Mask menu specifically) because root menu models are set with a
NULL path. So forbidding root menu models to handle new subpath means
preventing plug-ins to register new top-level menus.
The correct fix for the issue on the quick mask menu will happen in a
coming commit.
See issue #9586.
...trying to get the index. Resolve#9568.
The color picker tool calls this twice if you're in Add to Palette mode,
and the editor's color may not be set the first time it's run.
This adds a check to ensure the color is set before trying to retrieve
it from the palette to prevent a CRITICAL.
The layer resize to selection and crop to content menu commands were
using the same help ids. This made it difficult to have them both listed
separately in the index of the manual.
Since we use separate help ids everywhere else for menu commands, let's
give each its own help id here too.
Though this doesn't make a problem in normal use (AFAICS), we have crash
in a unit test in CI because the action_factory object was apparently
invalid when calling gimp_action_factory_delete_group().
Resolves#9560.
The Simulation Intent and BPC widgets in the Preference Dialogue needed
to be connected to their properties with `gimp_prop_*` when created to
show the saved default image values.
This way we handle all kinds of proxies (particularly buttons).
Also add a small hack that prevents extended multiline tooltips of
GimpButton from being overwritten by gimp_action_update_proxy_tooltip().
According to the ::drag-drop GTK documentation: "The call to gtk_drag_finish()
can be done either directly or in a “drag-data-received” handler which gets
triggered by calling gtk_drag_get_data()"
The GimpToolbox's vbox handling DnD chooses however to do both, the drag-drop
handler is calling gtk_drag_get_data() and invariably calling gtk_drag_finish()
to hint that the DnD operation is ending. While this worked in practice in X11,
This is a harder either/or in Wayland resulting in the transfer being cancelled.
In order to behave better wrt the documentation, and make DnD into the toolbox
work on both X11 and Wayland, avoid the first gtk_drag_finish() if the data is
being requested, and only bail out if no offered target matches what the widget
can handle. The handling done indirectly through gimp_toolbox_dnd_init() and
gimp_dnd_*_dest_add() will take care of finalizing the DnD data transfers
successfully.
Closes: https://gitlab.gnome.org/GNOME/gimp/-/issues/7373
In GimpLayerTreeView, set the action states using GimpActionGroup
instead of using gimp->app directly to look up the actions ( after
trying to get the Gimp from a NULL GimpContext).
Fixes#9433
The height of the boxes was never determined by the preview but by the
label+entry, causing vertical padding around the preview. Now the
preview fills the area in more cases, at the cost of a few less
horizontal pixels for the entry.
gimp_toggle_action_real_toggle(): set "active" before emitting
"change-state" so we don't infinitely try to set the state in case of
a recursion.
gimp_toggle_action_toggle(): add notify("active") because it wasn't
done anywhere.
Fixes#9392
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
