.ani files require metadata fields to be an even length. If the data
length is odd, an extra 0x00 is added for padding.
This patch updates the export and import code to comply with this
requirement.
Now text layers are proper types, which means that the binding API will also be
nicer (e.g. `txt_layer.set_text('hello world')` in Python).
This commit also adds the param specs allowing to create plug-in procedures with
text layer parameters.
Finally it fixes the few calls in file-pdf-save (apparently the only plug-in
using specific text layer API right now) with explicit type conversion.
After re-reading #534, I realized I missed the discussion about unsupported
markup by the tool. Then I tested and confirmed what Ian Munsie initially said
in a comment: unsupported markups are properly rendered in the text layer, yet
are simply dropped when editing with the text tool.
This is actually the ideal behavior as it means that with the API, you can even
go further than what is currently possible with the GUI. So it gives nice powers
to people who can script GIMP. We still need some warning in the function
documentation to tell developers about this weakness in the tool GUI.
It seems I had forgotten some hardcoded color in there. I didn't notice it until
now, because it was not that bad in the few instances where it was shown (for
instance the comment field in export plug-ins), but I really realized there was
a problem with the Python console which was not too practical (white writing on
kinda light background).
This complements the existing text_layer_get_markup function and allows
scripts to create and modify complex text layers.
It adds the <markup> root tag if it was not supplied and will run the
markup through pango_parse_markup() to check for errors.
Reviewer's (Jehan) note: this is a mostly untouched patch contributed in #534,
except that code moved around. I also fixed the header set in the .pdb, a link
to pango markup docs and added the meson changes.
Fixes:
> /usr/bin/ld: ../libgimp/.libs/libgimpui-3.0.so: undefined reference to `gimp_check_custom_color2'
I am actually unsure this fix is fine. It doesn't look like it should
work. And worse, I can't reproduce the fix by reverting it after.
The only other person who reported it was akk, with exactly the same
symptoms.
I noticed some buttons had a bluish border, showing the system theme leaking
over our default theme. So I'm just overriding this with a grayscale color.
These 2 new rules are especially useful in dialogs so that you know what happens
when you hit "Enter". The "default" action (.suggested-action in GTK CSS) is the
action we set to be the active one by default. E.g. if you open a dialog and hit
Enter immediately, without touching any widget focus, this is what will be
activated.
The GTK CSS .default action on the other hand seems to simply be the button with
focus right now, which can be changed through Tab or other ways. If both types
of styles are visible, the .default one is the actually activated action (not
.suggested-action), which is why I make its style a bit stronger (solid rather
than dotted and a bit more opaque).
Also I discover the shade() function to reuse a color and adding it
transparency!
Checked buttons had a background using the @selected-color. This was because of
a too broad rule on `.text-button:checked`. Basically it looks like the broad
rules are not good because they sometimes override more accurate rules for
specific widgets.
I also make a few more rules a bit more accurate. Also I extend some CSS rules
for check and radio buttons.
Adds an option to export as CMYK (mutually exclusive with the existing
Duotone export option). Header information (mode and number of channels)
are set, and the data itself is converted via Babl.
Layer channels are also hardcoded to 4, since GIMP currently doesn't
support CMYK channels.
We had some concept of slightly more extreme theme colors (i.e. darker in dark
themes) to color differently in some widget-in-widget cases.
For instance, we use this in the treeview list to separate it better from nearby
interface. But this extreme dark background may have been a bit "too dark", as
reported by Jacob. The goal is for this list to stand out, but maybe it was
standing out too much. Hopefully it's better now.
As a side change, I also add some borders to the top icon header (with "eye" and
"lock" icons) just above the list. I think it better explain the separation.
Just use an inverted logic for the selected text (i.e. white on black in light
mode, or black on white in dark mode). This is the usual logic for rendering
selected text anyway (except that we don't use non-grayscale colors, e.g. blue
background is common in system themes).
As diagnosed in #8649, using a guint32 for windows identifier may have been
right long ago (was it?), but is definitely not anymore. I can see that a XID is
an unsigned long nowadays (usually 64-bit on 64-bit Linux).
As far as I can see, on Windows, it would be a void* behind (which also
corresponds to the error message in #8649 description):
> typedef void *PVOID;
> typedef PVOID HANDLE;
> typedef HANDLE HWND;
Cf. https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
I *think* that pointers would be 64-bit on Windows 64-bit, though I'm unsure
(after all, this is an OS with 32-bit long int on 64-bit arch!).
Anyway, it's just better to move to 64-bit window identifiers.
Since Clang 15.0.0:
> The -Wint-conversion warning diagnostic for implicit int <-> pointer
> conversions now defaults to an error in all C language modes. It may be
> downgraded to a warning with -Wno-error=int-conversion, or disabled entirely
> with -Wno-int-conversion.
This kinda reverts commit 6aebd30de1 ("app: remove
icon sizing preferences"), except that the code base is different enough since
this old commit was mainly for GIMP 2.10.x.
In any case, after initially thinking that GTK+3 handling for high density
display would be enough, we finally decide that adding back a Preferences-wide
setting for overriding the theme-set icon size is a good idea (additionally to
GTK+3 automatic support).
The base idea for removing the feature was that GTK+3 has high density display
support, through the "scale factor". Typically a high density display will
normally be set as using a ×2 scale factor so all icons will be double size.
Unfortunately it turns out it's not enough.
For instance, on very small screen estate, even with a scale factor of 1, if the
theme sets 24px toolbox icons, it may still take too much space.
Oppositely on huge screens, even with ×2 factor scale detected by the OS, the
icons may still feel too small (this is possibly what happens with #7023).
Furthermore there is also a matter of taste. Some people like small icons even
when they have the space. Others may want bigger icons, easy to click on.
Finally you can like a theme for its color scheme for instance, but it may not
have the icon size you want. Right now, we'd need to duplicate every theme in
small or bigger size. Instead of doing so, let's just have this global setting
overriding the theme rules.
Comparison with the 2.10 implementation:
- We still provide 4 sizes: small, medium, large and huge.
- We don't have the "Guess ideal size" setting anymore. Instead this is now a
mix of the GTK+3 scale factor logic and the theme-set or custom size. I.e.
that on a high density display with ×2 scale factor, we could have toolbox
icons up to 96 pixels (48×2)!
- We now try to have less custom code in widgets as we append the CSS rules to
the theme (similar to what we were already doing for dark theme or icon
variants). What happens in widget code is mostly to connect to changes in
themes and redraw the widgets which need to be.
- The custom size will now affect: toolbox icons, the FG/BG editor widget (in
both the toolbox and the color dockable), dockable tab icons, the main
dockable buttons, eye and lock header icons in item tree views, eye and lock
cell icons in the item lists.
There are still a bunch of areas where it is not taken into account, such as
plug-ins, and various dialogs, but even in custom-made interface in dockables.
Ultimately it might be interesting to have a way to sync more buttons and
widgets to a global size settings.
Lastly, I fixed a bunch of existing bugs where we were updating icon sizes with
gtk_image_set_from_icon_name() using the const icon name taken from
gtk_image_get_icon_name(). As this was reusing the same string pointer, we were
ending with freeing the icon name.
This was massively breaking GtkScale rendering. Or at least the marks (and mark
texts) added by gtk_scale_add_mark() were simply invisible.
I tried to figure why, staring at the GTK inspector and testing various CSS
rules to fix it without removing this line, but just couldn't make sense of it.
In the end, I'll just remove this line. It looks like in CSS (or just GTK CSS?),
it might be better to set rules on accurate widgets rather than too broad rules. 🤷
This is the needed improvements I was talking about in commit 00fbcbea0b. Right
now, when changing the icon size, the FG/BG color widget was not immediately
resizing. It needed a restart of GIMP.
Now it will properly react to "style-updated" signal, but also to "theme"
property of GimpGuiConfig.
The reset of the color icon pixbufs is also needed when GimpFgBgEditor size is
re-allocated.
When changing the theme, the style-updated signal is *usually* run, but not
always. For instance, moving from a theme with big icons to one with smaller
icons (or the other way around) sometimes work, and sometimes doesn't. I'm not
sure if it's to be considered a bug in GTK or if this signal depends on other
things. Anyway we have our own "theme" signal on the GimpGuiConfig and we know
exactly that we need to make sure that the icons are properly redrawn in such a
case. So let's just connect to this signal.
So what we read on the topic is to use (as base color) the gray which is
perceptually half-way between black and white. Unfortunately it can mean
different colors. For instance if using the sRGB TRC, the #808080 color is
sometimes cited.
Instead I went with the color LCH (50, 0, 0), i.e. with half perceptual
lightness in "CIE LCH(ab) float" babl space, i.e. #777777 in sRGB. It
corresponds to the 18.42% gray which is often refered to, so it seemed a fine
choice.
This replaces proposal in !683 because the contributor is not responding
anymore, and also it uses the common theme base CSS files used by all other
official themes.
Write both ICC and NCLX boxes for RGB AVIF to make sure that
all browsers render the AVIF images in same manner.
Use heif_init/heif_deinit in libheif 1.13.0+
Luca Bacci