GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-03-15T16:00:00Zhttps://gitlab.gnome.org/GNOME/epiphany/-/issues/2296Enhancement: Please change or remove specific tab navigation/arrangement keyb...2024-03-15T16:00:00ZCaden MitchellEnhancement: Please change or remove specific tab navigation/arrangement keyboard shortcuts* Epiphany version: 45.2
There are keyboard shortcuts that aren't displayed in the keyboard shortcuts menu. These are the shortcuts for jumping to the first tab (<kbd>Ctrl</kbd>+<kbd>Home</kbd>) and jumping to the last tab (<kbd>Ctrl</k...* Epiphany version: 45.2
There are keyboard shortcuts that aren't displayed in the keyboard shortcuts menu. These are the shortcuts for jumping to the first tab (<kbd>Ctrl</kbd>+<kbd>Home</kbd>) and jumping to the last tab (<kbd>Ctrl</kbd>+<kbd>End</kbd>). This is actually relly, really frustrating for people doing text editing. <kbd>Ctrl</kbd>+<kbd>Home</kbd> is the universal shortcut to place the text cursor at the very beginning of the document, and <kbd>Ctrl</kbd>+<kbd>End</kbd> is the universal shortcut to place the cursor at the end.
Furthermore, <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>Home</kbd> moves the current tab to the very beginning of the tab list, and <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>End</kbd> moves it to the very end.
Firstly, I don't know why this is not documented in the keyboard shortcuts. Secondly, this makes it annoying to jump to the top and bottom of a text box such as that of GitHub, iCloud Notes, even Google Docs. Secondly, it makes it hard to select all text from the cursor position to the beginning or end of the document. As a workaround, you need to press <kbd>Shift</kbd>+<kbd>Home</kbd>/<kbd>End</kbd>, and then spam the up/down arrow to select all that text, or use the mouse pointer.
This behavior is unexpected, and also non-standard, as other browsers like Firefox, Safari and Chrome do not interfere with these shortcuts. While I appreciate the existence of this quick keyboard shortcut functionality, it seriously interferes with everyday use. A possible solution is to rework shortcuts a little bit. <kbd>Alt</kbd>+<kbd>1</kbd>-<kbd>0</kbd> on the keyboard will quickly jump to the corresponding tab. Why not use <kbd>Alt</kbd>+<kbd>Home</kbd> and <kbd>Alt</kbd>+<kbd>End</kbd> instead of <kbd>Ctrl</kbd>, making it more consistent with the aforementioned shortcuts.
Since <kbd>Alt</kbd>+<kbd>Home</kbd> is already used to go to the homepage, why not change that to <kbd>Ctrl</kbd>+<kbd>Alt</kbd>+<kbd>Home</kbd>, making it harder to accidentally press, requiring a more deliberate input. Alternatively, we remove it altogether. Even Firefox lacks these four shortcuts.https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2949Online accounts list has a messy, slightly confusing order2024-03-15T11:34:17ZAllan DayOnline accounts list has a messy, slightly confusing orderWhat the online accounts list looks like in main:
![image](/uploads/aa87722ac1e5abffba2bed42f2e1fec5/image.png)
It's a bit messy:
* There are two styles of account: some with symbolics and descriptions, and some with colour logos and...What the online accounts list looks like in main:
![image](/uploads/aa87722ac1e5abffba2bed42f2e1fec5/image.png)
It's a bit messy:
* There are two styles of account: some with symbolics and descriptions, and some with colour logos and no descriptions. These aren't grouped together, which produces an unharmonious appearance.
* The Microsoft accounts would be easier to read if the main branded Microsoft account came first - it would act as a header for the Microsoft section, and make it easier to make sense of the other Microsoft accounts.https://gitlab.gnome.org/GNOME/epiphany/-/issues/2037Make "Send Link by Email…" feature more discoverable (in main hamburger menu,...2024-03-15T01:06:21ZJeff FortinMake "Send Link by Email…" feature more discoverable (in main hamburger menu, and on hyperlinks)Spiritual successor to issue #1125 and https://gitlab.gnome.org/GNOME/epiphany/-/issues/97#note_738240
I totally accidentally (re)discovered today that Epiphany actually _has_ this "Send Link by Email…" feature now:
![image](/uploads/4...Spiritual successor to issue #1125 and https://gitlab.gnome.org/GNOME/epiphany/-/issues/97#note_738240
I totally accidentally (re)discovered today that Epiphany actually _has_ this "Send Link by Email…" feature now:
![image](/uploads/4bfd1491aa5bca77e3c825e038860ef0/image.png)
However, there are a few problems with the way it's implemented and named:
1. Ironically, it _only_ works when you click something that is _not_ a hyperlink, by clicking on an empty area of a page.
2. It is not present in the main hamburger menubutton. It should be there, as it would be more discoverable than right-clicking.
3. It would need to be available when right-clicking hyperlinks, too (and to populate the contents based on the hyperlink instead of the page, in that case)
In case no. 3 this action item's label should remain the same as it is now ("Send Link by Email…"), but in cases no. 1 and 2, it should be labelled more accurately, "Send Link to this Page by Email…" or "Email a Link to this Page…" or "Email this Page…".GNOME 46Leon MarzLeon Marzhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3366Preferences search only finds values, not section titles2024-03-14T18:49:58ZKeywan TonekaboniPreferences search only finds values, not section titlesHi, I tried the Search for preferences, but I can only search for specific settings like "simple"/"detailed" not for "Date and Time Format".
# Affected Version
- Version: 46.0
- Distribution: Gnome OS Nightly
- Also happens with deve...Hi, I tried the Search for preferences, but I can only search for specific settings like "simple"/"detailed" not for "Date and Time Format".
# Affected Version
- Version: 46.0
- Distribution: Gnome OS Nightly
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Open Preferences
2. Search for "Date" or "Format"
# Expected Behavior
A result for "Date and Format"
# Actual Behavior
I must search for "Simple" or "Detailed", but I don't know this, when I start the search. I want to search for "Performance" or "Grid View" or "Menu".https://gitlab.gnome.org/GNOME/gimp/-/issues/7746Suggestions to improve the painting tool : brush and settings2024-03-14T03:57:01ZFabrice SalvaireSuggestions to improve the painting tool : brush and settingsWhen I am doing extensive image editing, I am continuously changing opacity / brush size and sometimes other parameters. And switching between tool clone, heal, dodge/burn, smudge etc.
An important way to improve the experience, is to s...When I am doing extensive image editing, I am continuously changing opacity / brush size and sometimes other parameters. And switching between tool clone, heal, dodge/burn, smudge etc.
An important way to improve the experience, is to set up shortcuts/tablet express keys.
But I think the brush setting dock is confusing with a lot of widgets. I frequently use doge instead of burn and reciprocally because I forgot to check the corresponding checkbox.
Also, we cannot set up a set of brush settings. It is slow to switch from 10% to 90% opacity.https://gitlab.gnome.org/GNOME/gimp/-/issues/100442.99 ScriptFu: enhance: run-time choice of language version2024-03-13T15:53:29ZLloyd Konnekerkonnekerl@gmail.com2.99 ScriptFu: enhance: run-time choice of language version#8404 and #9608 propose changes to the ScriptFu language re returned scheme object from PDB calls.
Those simplify the language, making it more Scheme-like, removing ugly warts from the original design.
This enhancement proposes that the...#8404 and #9608 propose changes to the ScriptFu language re returned scheme object from PDB calls.
Those simplify the language, making it more Scheme-like, removing ugly warts from the original design.
This enhancement proposes that the changes be a script run-time choice
instead of an API-breaking change at build time of Gimp 3.
## Details
A new function:
```
(script-fu-v3)
```
early in a script would make subsequent calls to the PDB return what is proposed in #8404 and #9608,
i.e. #t or #f for boolean PDB functions, and a single value for PDB functions returning a single value
(instead of wrapping them in a list.)
## Discussion
### Good
Backward compatibility: existing scripts would work as is but new scripts could be shorter:
without (= (gimp- ...) 1) and (car (gimp- ..)) baggage.
### Bad
This slightly affects performance. Each call to the PDB would execute a few more instructions, branching on a global flag
while marshalling return values.
Most scripts do not iterate over calls to the PDB. The performance hit might be significant when a script does.
### Other
#8457 proposes to eliminate TRUE and FALSE (C-isms) as symbols from the language.
We wouldn't do that, but new scripts would not need them.
### Pragmatics
Needed changes are few and compact, mainly in the code that marshals return values from the PDB (recently refactored.)
Changes are only in the ScriptFu wrapper of TinyScheme, not in TinyScheme.
### Other
There might be a precedent in other Lisp dialects which we should model.
The new function is not quite a macro or cond-expand.
Suggestions are welcome.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/6016GIMP 3.0 modernised Wilber logo2024-03-13T13:30:28ZC RogersGIMP 3.0 modernised Wilber logo# Locked issue
This issue was locked to prevent the contributors from twitter-like hating and to stay on topic. See: https://gitlab.gnome.org/GNOME/gimp/-/issues/6016#note_2049405
# Description of the feature
This is a logo update/red...# Locked issue
This issue was locked to prevent the contributors from twitter-like hating and to stay on topic. See: https://gitlab.gnome.org/GNOME/gimp/-/issues/6016#note_2049405
# Description of the feature
This is a logo update/redesign suggestion/gift/whatever. :)
Some time ago I made a new logo for GIMP, and had mentioned it and reposted on IRC with positive response. I updated them taking some feedback from the #GIMP IRC channel. Here are the results
![gimp_3.0_logo_samples](/uploads/60de1a91aba89ebb28fe069dc25f03c5/gimp_3.0_logo_samples.png)
# Use cases
This logo has the advantage of being easily monotone for engraving, CNC, screen printing, etc. And with added eyebrow slightly more human with a friendly and positive look.
Here's how it looks on some tees (unisex) and polo in monotone:
![GIMP_shirts](/uploads/81b2167b9302e4d0843cb90e5dd88e0a/GIMP_shirts.png)
And here's the flat-shaded version:
![GIMP_shirts_2](/uploads/f44cd6e9e7d79f0d9d4ba9611a98e639/GIMP_shirts_2.png)
Comments welcome. My intent is to make something folks in the project like. :)
I'm happy to provide all image files once the artwork is done and there's consensus.
Enjoy!3.0 RC1AryeomAryeomhttps://gitlab.gnome.org/GNOME/gedit/-/issues/412Shorten length of tab titles when many tabs are open2024-03-12T19:02:23ZHatsune MikuShorten length of tab titles when many tabs are openIt helps to see many documents at once and switch easily without having to move and find
Current text editor(gedit) only shows 5 tabs max on average screen
![image](/uploads/5d48c865386534c71757f456968de497/image.png)
![image](/upload...It helps to see many documents at once and switch easily without having to move and find
Current text editor(gedit) only shows 5 tabs max on average screen
![image](/uploads/5d48c865386534c71757f456968de497/image.png)
![image](/uploads/b650c8470515524410de76b14bc673a5/image.png)
![image](/uploads/36698b4c0b73496ba755cfa087743cea/image.png)https://gitlab.gnome.org/GNOME/gimp/-/issues/7658Support more metadata namespaces (e.g. pmi, MiCamera, pur, apple-fi, illustra...2024-03-10T18:35:02ZJehanSupport more metadata namespaces (e.g. pmi, MiCamera, pur, apple-fi, illustrator, OPMedia… XMP prefix) available since GExiv2 0.12.2 requirement### Environment/Versions
- GIMP version: master
- Operating System: all
### Description of the bug
Followup of #5863 for the support of various metadata namespace which currently output warning messages in stderr.
These are user-prov...### Environment/Versions
- GIMP version: master
- Operating System: all
### Description of the bug
Followup of #5863 for the support of various metadata namespace which currently output warning messages in stderr.
These are user-provided data, so we don't generate debug now anymore (cf. #5863), but eventually we still want to support these.
### Reproduction
Reproduction steps:
1. Open https://www.zooplus.fr/magazine/wp-content/uploads/2019/11/chaton-errant-1024x683.jpeg
Result: this displays in stderr:
> gimp_metadata_deserialize_text: No namespace info available for XMP prefix `pmi'
> gimp_metadata_deserialize_text: No namespace info available for XMP prefix `pur'
And I suppose these metadata are dropped (are they?).
Expected result: whatever these metadata means, we should ideally either support them properly or explicitly ignore them (e.g. if we decide they don't make sense when being imported/export into/from GIMP).2.99.16Jacob BoeremaJacob Boeremahttps://gitlab.gnome.org/GNOME/gvfs/-/issues/530Admin:// very slow2024-03-10T15:20:44ZsimplelinuxuserAdmin:// very slowCopying files/directories using admin:// is very slow (10MB tops) vs normal sudo -E nautilus (~300MB)Copying files/directories using admin:// is very slow (10MB tops) vs normal sudo -E nautilus (~300MB)https://gitlab.gnome.org/GNOME/gimp/-/issues/9006Font popover stays behind the ruler/tab bar sometimes2024-03-10T00:29:17ZGhost UserFont popover stays behind the ruler/tab bar sometimes## Description
In certain zoom sizes and scroll positions, the font popover stays behind the ruler/tab bar:
![Screenshot_from_2022-12-31_21-10-37](/uploads/c87d35e88442743de85de9431a5932e9/Screenshot_from_2022-12-31_21-10-37.png)
And ...## Description
In certain zoom sizes and scroll positions, the font popover stays behind the ruler/tab bar:
![Screenshot_from_2022-12-31_21-10-37](/uploads/c87d35e88442743de85de9431a5932e9/Screenshot_from_2022-12-31_21-10-37.png)
And in some cases, the font popover is completely inaccessible, making the user to adjust the zoom to reach the controls.
This is reproducible in 1366x768, 50% of zoom, 1920x1080 image size.
## More info
* GIMP 2.10.32 (Flathub)
* Fedora 37 Workstation
* GNOME 43.2https://gitlab.gnome.org/GNOME/gimp/-/issues/6811text toolbox near tall document top is too high2024-03-10T00:28:57ZNick Levinsontext toolbox near tall document top is too high### Environment/Versions
- GIMP version: 2.10.24
- Package: Unknown. I don't remember if it came with Fedora 32 or 33 or if I installed it separately using Fedora's Gnome's Software app. Therefore, I don't know if Flatpak was involved.
...### Environment/Versions
- GIMP version: 2.10.24
- Package: Unknown. I don't remember if it came with Fedora 32 or 33 or if I installed it separately using Fedora's Gnome's Software app. Therefore, I don't know if Flatpak was involved.
- Operating System: Fedora 34 Linux.
### Description of the bug
The text toolbox is partly or completely hidden behind the top ruler.
### Reproduction
Is the bug reproducible? Always.
Reproduction steps:
1. Create a new image and set the height to be more than your monitor's height. (I use a laptop's built-in monitor.)
2. If the new image's top is not abutting or behind the top ruler, leaving a gap between the ruler and the document, vertically scroll so it is.
3. Select the text tool, such as by typing T.
4. Click in the image or document, near the top.
Expected result: The text toolbox should appear in full regardless of where the click is located.
Actual result: The text toolbox is partly or completely hidden behind the top ruler.
### Additional information:
The toolbox should be context-sensitively positioned.
I keep Fedora evergreen.
A kludge served me: I clicked further down, saw the whole toolbox, typed there, and cut and pasted the text further up. If that's impracticable because the image is small or visually busy, I suppose the user could create a new document, create the text there, and cut and paste it into the desired document, but then the user can't write the text in context for better design control.
No backtrace, crash, or warninghttps://gitlab.gnome.org/GNOME/gimp/-/issues/4498UI doesn't warn user of unsupported fonts2024-03-09T23:44:30ZKalvinUI doesn't warn user of unsupported fontsGIMP version: 2.10.14
Operating System: Fedora 31
Package: standard-issue from Fedora base repository
# Description of the bug
Typically, when you select a text layer with the text tool, the tool assumes the options (font face, size,...GIMP version: 2.10.14
Operating System: Fedora 31
Package: standard-issue from Fedora base repository
# Description of the bug
Typically, when you select a text layer with the text tool, the tool assumes the options (font face, size, etc.) of the existing text in the layer. However, if the layer uses a missing font:
1. the text tool mutates the problematic text layer immediately upon focus,
1. undoing the step leaves visible mutations (though the xcf will appear unchanged), and
1. the undo history menu behaves erratically.
# Reproduction
This bug is always reproducible on my system against the "Noto Sans Heavy Condensed" (henceforth NSHC) font.
Reproduction steps:
1. Start with a prepared xcf with a text layer using NSHC.
1. On a system that does not support NSHC (so in my case, a system without the `google-noto-sans-fonts` package installed), open said xcf in GIMP.
1. Engage the text tool and either click on the text layer directly or select "edit text on canvas" from the layer menu. This is where the weird behavior manifests:
* The text tool selects the Source Sans PS font, mutating a period and the number 5 in my text layer (looks kinda like Unicode mojibake?). GIMP thinks I've edited the xcf despite my not having typed anything.
* Hitting `Ctrl-Z` to undo will stop GIMP from thinking the file has been mutated (asterisk disappears from window title). But visually, the text layer appears to be rendered using some fallback font that doesn't look like NSHC to me.
* The Undo History menu stops working. If I click on "Base image," GIMP forcibly snaps the revision back to the version with the text layer mutation.
This bug goes away when I install `google-noto-sans-fonts` and is reproducible when I remove the same.
As a final note, nothing relevant appeared on stdout when I ran tried the reproduction steps running `gimp --verbose`.
This report is written in hopes of an enhancement to propagate some kind of warning to the user if an xcf uses unsupported or missing fonts. Thanks for reading.https://gitlab.gnome.org/GNOME/gimp/-/issues/10806Save gradient as CSS: Remove outdated vendor-prefixed CSS extensions2024-03-09T22:15:16ZAndre KlapperSave gradient as CSS: Remove outdated vendor-prefixed CSS extensionsSee https://caniuse.com/border-radius and https://caniuse.com/css-gradients
Last browser versions which still supported these custom vendor prefixes were released in 2012; their global usage is less than 0.1%.See https://caniuse.com/border-radius and https://caniuse.com/css-gradients
Last browser versions which still supported these custom vendor prefixes were released in 2012; their global usage is less than 0.1%.3.0 RC1https://gitlab.gnome.org/GNOME/gimp/-/issues/9883Some Popup Menus from dock dialogs are messy2024-03-09T18:14:09ZBruno LopesSome Popup Menus from dock dialogs are messy### Environment/Versions
- GIMP version: 2.99.17
- Package: custom build
- Operating System: Windows 11
### Description of the bug
The default/generic popup menu of dockable dialogs extends from "Move to Screen" to "Add Tab". However,...### Environment/Versions
- GIMP version: 2.99.17
- Package: custom build
- Operating System: Windows 11
### Description of the bug
The default/generic popup menu of dockable dialogs extends from "Move to Screen" to "Add Tab". However, **there is no section line** over Add Tab, what causes some confusion. This problem isn't so serious depending on the dialogue. See:
![Captura_de_Tela__176_](/uploads/5bd06ec5433f59a8219bfbd047ad82d3/Captura_de_Tela__176_.png)
Some dockable dialogs, however, have confusing menus because they have much more entries, resulting in an exceptionally tall and very messy list of entries.
![Captura_de_Tela__175_](/uploads/c76e4bfec0289be13ef1d4b2772f0ebc/Captura_de_Tela__175_.png)
This affects:
1. Colormap
2. Brush
3. MyPaint Brushes
4. Patterns
5. Gradient
6. Palettes
7. Font
8. Buffers
9. Image
10. Document History
11. Image Templates
12. Error Console
### Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Open some dock dialog
2. Click on left arrow to open popup menu
Expected result: generic menu is separate from specific menu
Actual result: generic menu is optically mixed with the specific menu3.0 RC1https://gitlab.gnome.org/GNOME/nautilus/-/issues/1731Use a timer-based search activation algorithm to prevent Nautilus spamming it...2024-03-09T16:05:55ZJeff FortinUse a timer-based search activation algorithm to prevent Nautilus spamming its search engines (improve live filtering search-as-you-type performance)Similar to what I'm recommending in gedit at https://gitlab.gnome.org/GNOME/gedit/-/issues/398 and elsewhere...
Unless I am mistaken (based on my observations of the floating statusbar, and some very light peeking at Nautilus' files in ...Similar to what I'm recommending in gedit at https://gitlab.gnome.org/GNOME/gedit/-/issues/398 and elsewhere...
Unless I am mistaken (based on my observations of the floating statusbar, and some very light peeking at Nautilus' files in gitlab), it seems that everytime I type a character, Nautilus _immediately_ triggers a search query (to tracker or whatever search engine is available to it) without any delay to see if I will type more characters... and that's terrible for performance. It does too much work, at the wrong time (see @federico's timeless [performance optimization presentations/principles](https://people.gnome.org/~federico/#performance-articles)).
I suspect Nautilus could get _much_ better performance by using a timer-based search approach with just a tiny amount of delay, with logarithmic back off (ex: the first 2-3 characters have a longer timer than the 10th or 15th, for example), to avoid spamming your search engines. This is what I did in Pitivi years ago and it made a huge impact on performance, and I will ensure this sort of optimization is done in GTG as well. See https://github.com/getting-things-gnome/gtg/issues/281 as I go into a more detail over there regarding the ideas of how this can work. It has now been implemented in GTG, and I've seen it make a _huge_ difference in performance over there too.
Please consider this potential performance optimization for Nautilus as well :)GNOME 43Jeff FortinJeff Fortinhttps://gitlab.gnome.org/GNOME/gimp/-/issues/4944Font search filter without function2024-03-09T13:09:53ZJohannes HofmannFont search filter without functionGIMP version: 2.10.18
Operating System: [Windows]
# Description of the bug
When entering any letter into the filter field, the font list gets empty not showing any font related to the search string.
[Gimp_Filter-Bug](/uploads/4deb6ec7...GIMP version: 2.10.18
Operating System: [Windows]
# Description of the bug
When entering any letter into the filter field, the font list gets empty not showing any font related to the search string.
[Gimp_Filter-Bug](/uploads/4deb6ec74968bc36e0ce78eaafdc9953/Gimp_Filter-Bug.png)
# Reproduction
Is the bug reproducible? [Always]
Reproduction steps:
Just enter characters into the filter field
Expected result: Show all fonts that contain the search string
Actual result: Empty listhttps://gitlab.gnome.org/GNOME/gimp/-/issues/400Text entry tool should get out of the way2024-03-09T12:42:46ZBugzillaText entry tool should get out of the way## Submitted by Vanessa Dannenberg
**[Link to original bug (#675409)](https://bugzilla.gnome.org/show_bug.cgi?id=675409)**
## Description
The new text-entry-on-canvas feature has one major misfeature - there's no way to move the ove...## Submitted by Vanessa Dannenberg
**[Link to original bug (#675409)](https://bugzilla.gnome.org/show_bug.cgi?id=675409)**
## Description
The new text-entry-on-canvas feature has one major misfeature - there's no way to move the overlay off of my image window. Depending on the size of the image and the zoom level, this overlay can obscure the *entire* image, pretty much wrecking the usefulness of this new feature, especially if you're adding text near the bottom edge of the image (if I can't see the text on the canvas while I'm adding it, what's the point?)
I should be able to choose the "use editor" option and have *all* of the content of this overlay moved into that dialog. No overlay should be present in that mode.
Version: 2.8.0
### See also
* [Bug 791859](https://bugzilla.gnome.org/show_bug.cgi?id=791859)2.99.16https://gitlab.gnome.org/GNOME/gimp/-/issues/7107Panel font too small. Option to set the font size?2024-03-09T11:46:11ZUnknown UserPanel font too small. Option to set the font size?**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 10, 4K monitor with 200% DPI.
### Description of the feature
The only reason I am waiting for Gimp 3.0 is better high-DPI support and bett...**Operating System:** <!--[Windows? macOS? Linux? All?] (write it after the > symbol) --> Windows 10, 4K monitor with 200% DPI.
### Description of the feature
The only reason I am waiting for Gimp 3.0 is better high-DPI support and better GUI, because the only reason I rarely use Gimp is the bad GUI. You know, Blender 2.8 became a lot more popular with just the GUI improvement.
Anyway, I have tested 2.99.6, and whilst it looks better than 2.9X, but the font size and the icon size on the left panel seem too small. See, the font is smaller than that of other parts like the context menu. The mode icons are too small to click comfortably.
I guess that maybe there are people who want them to be small, but why not make the sizes adjustable by the user's preference?
![image](/uploads/bfa210b9759549bd5d61d349378b1b3f/image.png)
### Use cases
Less eyesore.https://gitlab.gnome.org/GNOME/gimp/-/issues/5034show warning if font is missing2024-03-09T11:35:08Zmussolshow warning if font is missingIt would be nice to show a warning with information about missing fonts if you open a file that contains references to a font that is not installed in the system.
Right now it just switches to another font leading to unexpected behavior...It would be nice to show a warning with information about missing fonts if you open a file that contains references to a font that is not installed in the system.
Right now it just switches to another font leading to unexpected behavior and confusion.
When moving xcf files between computers it's easy to forget which fonts were installed on each computer, specially when you work with lot of fonts.
Warning could include font info and layers using it so you can decide if you need it or not.
Maybe if you use a lot of layers warning should appear when you make an affected layer visible, not on loading the file.