Image m2-d0f86ab189cbe900ec389ca6d7464713.tif from the imagetestsuite
is a fuzzed image with an invalid very high number for the channel count.
This causes GIMP to become unresponsive for a very long time. Possibly
trying to allocate memory for all channels or another cause related to
the high number of channels.
Let's go for a more "reasonable" limit of 99 channels like we also do
for Photoshop images and show a message when we find an image with more
channels.
When loading a TIFF image using a script/plug-in in non interactive mode,
we did not initialize the list of pages, causing a crash when trying to
access it.
So, always initialize this list when non interactive.
Due to a change in the format string in libtiff, warnings about unknown
fields were not filtered out anymore.
Adjust our filtering of warning messages so we catch this again since
end-users don't need to worry about this and we don't need the
possible extra issues.
This is purely fixing by meson rebuilds and some regexp fixes. I didn't
touch any semantic.
Basically the "&" XML entity should not have made their way to the
po files. I fixed our script in the previous commit, and now I just
rebuild the po files and clean the entity programmatically so that our
Windows installers for GIMP 2.99.12 release have valid text.
Here is what I did:
(1) I regenerated the pot and po files:
$ meson compile gimp30-windows-installer-pot
$ meson compile gimp30-windows-installer-update-po
(2) I opened all the po files in vim and regexp through them.
Get back the proper Report-Msgid-Bugs-To:
:bufdo! %s$"Report-Msgid-Bugs-To: \\n"$"Report-Msgid-Bugs-To: https://gitlab.gnome.org/GNOME/gimp/issues\\n"$ge|update
No translations were fuzzy in any po files before this change. I remove
all the fuzzy flags, but only if the msgid contains an ampersand, hence
leaving appropriate fuzzy strings in (the ones where the source string
changed since the last translation):
:bufdo! %s/#, fuzzy\n\([^&]*\)&/\1\&/ge|update
Then I replaced & in msgstr (msgid was fixed through the automatic
regeneration thanks to previous commit, but not the translations) with:
:bufdo! %s/&/\&/ge|update
(3) Finally I did a manual `git diff` review to verify all is good.
In particular, I had to fix a bunch of "E&xit". The string is probably
too short so gettext heuristic failed to consider it likely the same as
"E&xit".
… Windows installer localization.
There are kind of 2 separate bugs here:
- Direct i18n.gettext() to the proper data directory where to find the
ITS file. Otherwise `meson compile gimp30-windows-installer-pot` and
`meson compile gimp30-windows-installer-update-po` complained about
not knowing XML and falling back to C, which is obviously a problem:
> /usr/bin/xgettext: warning: file 'build/windows/installer/lang/setup.isl.xml.in' extension 'xml' is unknown; will try C
- Set gt:escapeRule to "no" in the ITS file, otherwise the XML entity is
kept as-is in the po file (i.e. "&" stays "&" inside the po
files), but it's considered as raw text when merged back to XML, i.e.
that the '&' is properly converted to a XML entity, so we end up with
a double escape "&".
Now the po file will have a '&' which will still be converted to XML
entity at merge time. This is actually most likely better than asking
translators to handle XML entities themselves (with the possibility to
make typos and break the XML entity).
See https://savannah.gnu.org/bugs/?58643
- The mailing list URL is now a general discussion URL.
- Gather all discussion channels in a single section.
- Remove some outdated sentence about a web form for plug-ins (no idea
what this is, but clearly we don't have this anymore).
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.
This linear gradient really doesn't render any feeling of "background"
IMO. I only initially implemented it this way because the underlying
theme seemed to use such gradient effect on headerbar for background
dialogs, so I wanted to test this.
Anyway simply using the "disabled" color seem to work well. After all,
the semantic is similar too (if it's in the background, a dialog can be
considered inactive in some way). In any case, the meaning definitely
comes across now.
Don't use it only on menus. For instance, there were disabled checkboxes
(and their label) in plug-ins which were not showing different at all,
and it's confusing. Now both menu items, and other type of settings will
show similar "disabled" style.
Creates two new parasites to save the black point compensation status
and rendering intent simulation settings in GimpImage.
The parasites are saved and loaded as part of the image in the
.xcf file.
Something which is regularly asked is to use smaller icons. We used to
have a "Small" theme in 2.8, which got away in 2.10 with icon sizing (cf
issue #6121).
This is a revival of such a theme (except I call it "Compact" because it
feels more appropriate than "Small"). The theme is basically the same as
"Default" (through an include), just tweaking some size related CSS
rules.
Until now we were sizing the FG/BG area with hardcoded size ((40, 38)
which I'm not sure where it came from!). Now this allocation size will
depend on the toolbox icon size (I made so that the FG/BG area is more
or less the same size as former hardcoded values with large toolbar
icons).
I had to tweak a bit the size of the default FG/BG icons and the swap
icons, which were also hardcoded. They now also depend on the allocation
size, hence the icons size.
Note that this code still has a limitation: it won't resize when you
switch from a theme with one size to another size of icons. A restart
will be necessary. This is something we should improve.
… variant.
Now with my recent code, instead of creating 2 different themes, I make
it a single theme containing both a Light and Dark variant.
I move all semantic logic into common.css which will be included by both
variants after they set up their color definitions.
For choosing the basic gray to use for the dark variant, I first looked
up what is usually recommended. Most articles on the web about dark
themes would cite some "Material design" project (apparently originated
from Google) which makes guidelines for Android/iOS/Flutter and web
applications. Their guidelines recommend #121212 ("Dark Grey") as
background color. I tried, it's **really** dark. Maybe I'm just not used
to it, but it feels like it might be OK for small phone "apps" which
people might want to watch in the dark, but possibly not for a full
grown desktop software. I don't really know, I might be wrong and some
people might want to edit their pictures with such dark GUI.
Anyway for now, I settled for a base background #303030, which is
already quite dark, darker than Adwaita dark or than our 2.10 dark
variant, but at least doesn't feel like a black hole.
Instead of hardcoding the colors in CSS rules, make variables of them,
with meaningful semantic names. It will help with making consistent
design where a color means something and is reused in several places
(e.g. a color for "hovering" or "selecting").
I add some variants but not too much (e.g. treeviews had even lighter
background, with an inversion of logic, where selected items are on
darker background instead of lighter).
Colors in this theme are mostly the same before and after this commit,
except for a few parts where I felt that having more variants was
detrimental for consistency and maintenance.
As part of the changed colors:
- check and radio buttons' background just reuse the lighter background
color (as used e.g. in treeviews and entries).
- menus also use this lighter background color with the color inversion
(same as treeviews) for hovered items.
This commit also brings some improvements to disabled cases:
- Stylize also disabled tree view items (e.g. disabled actions in action
search were styled the same way as runnable actions).
- Stylize the same way disabled buttons drawn directly or with an image
widget.
The last use for this change is that it will help to create a dark
variant for the same theme using nearly the same code, hence get
consistent styling.
This way, what will happen is that:
- We can have a single "Default" theme which will have both the light
and dark versions.
- With our Default theme, when "Use dark theme variant if available" is
unchecked, we just follow the system-wide dark settings. (though I'm
unsure we actually do with current code; we do load our theme over the
system theme, which may be dark, but I don't think we'd load a dark
theme variant then)
- If the option is checked, we will load the specific dark variant,
bypassing system settings specifically for GIMP.
Technically for theme designers, all it takes to have a dark variant is
to add a gimp-dark.css next to gimp.css. `gimp-dark.css` is loaded
instead of `gimp.css` when the settings is checked.
Note: there is apparently a new freedesktop portal for setting the
prefered variant (and now it's apparently either light, dark or
default), which is now implemented by GNOME, KDE and Elementary at
least. It would be nice if we could grab this settings and use it if
available. The below link has code sample showing how to do it with
DBus:
https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference
- Indent all rules in Light theme with the same number of spaces for
style consistency.
- When GIMP was set in "Prefer dark variant", spin buttons and other
entries had too dark borders. Fix this.
- Fix the spinbutton entry's border radius which was at 0, but since the
buttons of the spin button are themselves rounded, it looks weird only
on the top and bottom left corners. So apply a 3px radius. I did this
in the System theme.
Makes the following changes:
*Toolbox Wilber is now visible
*Large black border removed from ScrolledWindow
*"Duplicate text" effect removed from labels
*Toolbox tabs are now stationary when changing selection
*"Add Tabs" menu background color changed to match Light theme
*Unnecessary border around Check Updates box removed
Optionally includes the previously saved
Duotone color space data on PSD export.
New load dialogue alerts user if duotone data was imported.
New export dialogue appears if the image is still grayscale and
the parasite exists.
If selected, the mode is set to PSD_DUOTONE in the header and
the original duotone data is written in the color space section.
These are issues which appeared to me only when GIMP was set to use the
dark theme variant. In such a case, I guess we see quite well CSS rules
coming from parent themes, such as the globally set system theme.
* Remove any background image (which may come from the system theme?) on
buttons.
* The headerbar was dark and when in the background, it had a dark
linear gradient (probably coming from my system theme). So make sure
the background color is right as a general rule, and add back a
(small) light gradient to indicate the background state.
* GtkListBox had a dark background. We don't have a lot of usage for
this widget yet, but a few (for instance in icon theme settings, or in
the modifiers editor).
* The GtkSwitch buttons were dark on dark. Set a light background. Also
when the switch is ON, I add a bit of color, not too strong, but
enough to indicate the checked status, because I find this widget
design not so obvious. Since I don't think we use switch buttons
anywhere else but in Preferences, this is probably not a big problem
as it should not affect color perception when working on the canvas.
Add the info about max dimension of WebP with WEBP_MAX_DIMENSION macro.
There is also a test about (picture->width / 4 > INT_MAX / 4), resp.
height, but this should anyway never happen as the C spec says the
smaller range for int is [-32767, 32767], which is an order bigger than
the current WEBP_MAX_DIMENSION (16383).
So we are probably fine assuming all VP8_ENC_ERROR_BAD_DIMENSION errors
will happen because of WEBP_MAX_DIMENSION.
Actually our X11 implementation is right, and the implementation from
the Freedesktop portal is "as far as it can do", i.e. that we get the
returned RGB value, which is unfortunately in display space. And it
doesn't return any space information together (we don't even know which
display the color comes from, in multi-display setups).
Therefore let's check if we are running GIMP on X11 and if so, let's
call this implementation first.
See this report on xdg-desktop-portal to get proper space info:
https://github.com/flatpak/xdg-desktop-portal/issues/862
We should set these explicitly, otherwise it will usually default to the
first of the enum, which is perceptual (which is usually not a proper
choice).
Relative colorimetric is usually the recommended default.
Jacob Boerema