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+
Something I wanted to implement for a long time and today I finally took
the time after I had one more annoying case where I had to merge all
groups for exporting then undo for saving!
Now this won't be needed anymore as the plug-in will allow to export
only as pages any first-level layers (groups included, so you could
gather your page compositions in root layer groups). For me, it's the
only way I use this when making/editing PDFs with GIMP, but maybe some
people would still want GIMP to crawl into groups and subgroups and
export layers individually. That's why I make it an option, defaulting
at TRUE.
Note that I didn't port "file-pdf-save-multi" at this point, though I
did move to using GimpProcedureConfig instead of GimpValueArray
everywhere.
In any case, that's a lot of code removal and simplification already,
though some part of this plug-in is still a bit ugly.
We also get proper config storing between sessions now.
As for metadata, it unfortunately doesn't look like Exiv2 has PDF
support, so I didn't add metadata settings.
… gimp_procedure_config_save_metadata().
If you use gimp_procedure_config_save_metadata() or
gimp_procedure_config_end_export(), you don't really control the flags
and let the GimpProcedure API make somes choices for you, based on
various assumptions. One of them is that the procedure has specific
properties (named "save-*", either created manually or with the various
gimp_save_procedure_set_support_*() functions). So if you don't have
them, we should assume this format doesn't handle a given metadata
format and deactivate it.
For plug-ins with a different/specific logic, they are expected not to
use these helper functions. They would likely call lower level functions
such as gimp_image_metadata_save_finish() or the newer
gimp_image_metadata_save_filter(), where you control the metadata flags.
The dl*() functions are in libc directly. This probably applies to all
*BSD too. And from what I read, it should even apply to macOS, even
though a libdl is present there (is it bogus?).
So let's make the libdl check proper by only make it mandatory on Linux
(on Windows it was already unchecked too).
Fix the Linux Input test to correctly only depend on whether or not the
header is present. Having X11 target is not enough (e.g. it breaks the
build for NetBSD and probably on all BSDs).
This file was just moved as content/core/specifications/locks.md in the
pat/bootstrap branch of the gimp-web-devel repository.
This branch will soon be merged and become our new website. Removing the
now duplicate in our source repo.
- Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated
HTML, and not an absolute path taken from build dir (otherwise this
would break, for installed docs, but also for the tarball and the
developer website!).
- Also use either gimp-logo.png or gimp-devel-logo.png depending on
whether we are on a stable or unstable branch.
- Install these in images/ inside the GIMP docs folder, which
corresponds to the relative path given to GIMP_LOGO_PATH.
- The installed root dir will be $datadir/doc/gimp-2.99/, e.g.
/usr/share/doc/gimp-2.99/
- Inside this folder, the library references will be in libgimp-3.0/ and
libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that
the root dir uses the application version (2.99) whereas the library
folder use the API versions. These are different in development phase.
- Archive the gi-docgen installed files, not taken from the build dir,
to avoid packaging temp files, such as the .toml files. Note that
`g-ir-docs` files are still taken from the build dir, as we don't
install them yet.
- Finally package all this in a directory before archiving in a tar.xz,
named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside
gimp-api-docs-2.99.13.tar.xz).
Gotam Gorabh