This is a followup of previous commit. As well diagnosed by Anders, this
value relies on "gegl:gaussian-blur" operation's argument's range.
Also adding a comment to make it easier for future developers seeing
this value.
Though these are not as user-facing as other strings, the action names
still are somewhat user-facing. Let's rename them consistently with the
GUI and the API.
This commit also handles user config migration so that custom shortcuts
are not lost.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes#10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
This is meant to obsolete GeglParamColor with at least an additional argument
has_alpha which we need in GIMP. It allows to advertize when a parameter wants
an opaque color, which in particular means we know when displaying a GUI to pick
colors with alpha or not.
There are no plug-ins which uses GimpRGB for procedure argument, nor is there
any base PDB procedure. We don't pass this type anymore through from/to
core/plug-ins. So let's clean the whole code out as a next step to get rid of
GimpRGB from our codebase!
Allows users to quickly configure themes and other
"controversial" options when first installed.
Also allows the welcome dialogue to appear on start,
depending on user preference.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
The merged icon theme is simply named "Default" and contains a color and
symbolic variant for all icons. While in 2.10, it made sense to have both icon
themes because a theme had no concept of a "symbolic" variant back then, icon
themes in 3.0 have this concept and we support this in GIMP through the "Use
symbolic icons if available" option in Preferences.
Until now, it was confusing to have both themes + this option, even more as you
could use the Color icons with the "Use symbolic icons" option, which meant that
if some icons were missing, you could end up with a mix of color and symbolic
icons (and oppositely using the Symbolic theme with the option unchecked).
The new state is much simpler and less confusing. Just 1 icon theme with both
color and symbolic variants (the latter being used by default).
Note that the identical meson.build in each size subfolder is still mandatory
because of the inability of meson (still!) to generate files with
custom_target() in a subfolder as output.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
Also added option in Edit->Preferences->"Tool Options"->"Paint Options
Shared Between Tools" that decides weather the options should be shared
between different tools.
Original patch by @ellestone.
The current tooltip is somewhat confusing for two reasons: It doesn't
mention the word "ICC", leaving room for doubt as to what a "color
profile" might be. And as @TheTooleMan suggested, it's easier to read
and understand if the action (opening a file . . .) is in front of the
modifier (. . . with an embedded ICC profile) instead of vice versa.
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
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.
This patch does the following things:
- An option "Merge menu and title bar" (this is hopefully more understandable
than calling it "Client-side decoration" or again "header bar") is added in
Preferences > Image Windows. This option triggers the restart warning.
Moreover when checked a small warning message will tell that in some cases, it
may not work (there are feedbacks of people having 2 title bars when using GTK
applications using CSD).
- For the reason evoked above (sometimes 2 title bars) and also because the CSD
concept seem really to divide people a lot (some love this as much as others
hate this), this new option "custom-title-bar" on GimpGuiConfig is FALSE by
default.
- When the option is checked, the image windows will use a GTK header bar
containing the menu, the window title (image name and information) as well as
the usual minimize/maximize/close buttons per your OS conventions.
- Since the header bar is set to be hidden when maximizing, if you checked "Show
menubar" for the "Default Appearance in Fullscreen Mode" in Preferences >
Image Windows > Appearance, the menu will be moved to its "old style"
position, i.e. above the canvas. This makes the menu possibly visible (if
relevant option is checked) even in fullscreen mode.
- I tweaked the Default theme to show the header bar with minimal height,
because I find GTK default theme's headerbar height unreasonably high
(especially if the point of the header bar is to save screen space). I am
unsure if this was the right move though, because maybe the default theme
should not do such choices (maybe this should go in the Compact theme?).
We had this feature "can-change-accels" where people could change their shortcut
directly by browsing the menu. It was on the property "gtk-can-change-accels" in
GtkSettings. Unfortunately this got deprecated in GTK+ 3.10 (more accurately in
dev version 3.9.8, according to GTK's NEWS file), and is therefore ignored since
then. In other words, whether we check the box or not in our Preferences, it
doesn't do a difference.
If we want to get the feature back some day, we'll have to reimplement it with
custom code. In the meantime, there is no need to leave this visible in
Preferences.
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.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
This object's goal will be to manage customized modifiers per input
device button, which is why I add it to GimpDisplayConfig. It is in its
own new config file (`modifiersrc` in config dir) because it requires
GDK types access (well I could have done without, but it would have been
less semantic, hence not as good of an API). Anyway it is only useful
when running GIMP as GUI.
The GUI widget and the usage code to make this actually useful will come
in upcoming commits.
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
Since localization is fully handled plug-in side now (see #8124), we
need to make sure the query functions are run again for all plug-ins
when the UI language changes (otherwise we might end up with
localizations from the previously used languages).
We were already reloading plug-ins when explicitly changing the lang in
the Preferences, but this new implementation is much better as it's
generic. In particular, it will also handle the case when the system
language changes (or when you play with locale environment variables).
Reviewer (Jehan) note: cherry picked from MR !274. Still deciding
whether this will be pushed to gimp-2-10 branch too.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
app/display/gimpdisplayshell-draw.c
app/plug-in/gimppluginmanager-call.c
libgimp/gimp.c
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
libgimpwidgets/gimppreviewarea.h
libgimpwidgets/gimpscrolledpreview.c
This was missing ever since commit 505a78e715 but we weren't seeing this
by using meson. I opened the report #8145 for us to handle this
regression of the build system.
Adds the new configuration option "drag-zoom-speed" to adjust the rate
at which mouse movement can zoom the canvas, ranging from 25% to 300%
of the base rate and applying to both drag-to-zoom modes.
This option can be found in the preferences dialog as:
Image Windows -> Zoom & Resize Behavior -> Drag-to-zoom speed
Adds a new configuration option "drag-zoom-mode" to choose whether to
zoom by distance of movement (newly added) or by duration of movement
(previous behavior) when zooming via dragging the mouse, defaulting to
distance.
This option can be found in the preferences dialog as:
Image Windows -> Zoom & Resize Behavior -> Drag-to-zoom behavior
We take a step back from the original MR which was proposing the "single
dot" cursor as a new "Pointer mode" option. I was really unsure this was
the best solution, especially reading again the whole original report.
It means that now nearly all of the original patch has been rewritten
another way, but let's leave the contributor commit as a start point to
get to where we are, and as acknowledgement of the contribution.
The reporter was annoyed by the crosshair when none were requested and
probably mostly for painting tools only (at least examples were about
brush or pencil, etc.) while showing outline. It looks to me like the
real issue was maybe when we were showing the big crosshair when using
the 4-arc fallback outline, for instance when using a dynamics changing
size. If so, this main issue is already fixed by my commit 64dc26064b.
No need of a new option for this, especially if the option can be as
confusing as a barely visible dot-cursor (I can already imagine the bug
reports of people tweaking random preferences and unhappy because the
pointer became invisible, while they don't know how they did it).
Instead I would say that when people specifically uncheck both "Show
brush outline" and "Show pointer" options, showing a huge crosshair
feels quite counter-productive. This is where I think that our small
unobtrusive cursor (probably a better name than "Single dot" by the way,
as it's not a single dot anymore) might be of use, the ultimate case
when someone really want a cursor as inconspicuous as possible, while
still having a visible feedback of the pointer position (even with
display-tablets, parallax issues make such a visual feedback important
to target where one paints).
So let's try this first and see how it goes.
… in previous commit.
Also fix some coding style bugs.
Finally change s/"Single Dot"/"Single dot"/ to have the same label
syntax (only capitalize the first letter of the label) as other labels.
Cf. #7034 and !466.
Thinking again, this is simply the version of the config files, mapping
to the application version. Even though it's not really a user-visible
string (except in config files themselves), I find this a much more
elegant name than the ugly "last-run-version" (which is not even true
anymore once startup passed; it's only the last-run version info at very
beginning of the startup process).
This will be used by the update check to verify you are running a new
version since last time. In the future, it might even allow to handle
some types of config migrations if ever we update some things in-between
micro releases. Until now, we could only detect minor updates through
the config folder name (and even this was limited as the config folder
can be specified, in which case we would not even know what version the
files were for).
Maybe we could start also warning in cases of downgrading too, which can
break some configuration files (though there is not much we can do about
it other than warn as there is no time machine!).
Last point: if the new config value "last-run-version" doesn't exist, it
simply means the config folder was run for a GIMP before this point in
time/commit. So we just show the welcome dialog.
This was added in commit 88f97aedef and only expected to last until
fontconfig had a fix **and** it got into a released version.
This is now done.
I could verify in the git repo that fontconfig's commit 55eb1ef is
included since their tagged release 2.13.95 which is now on MSYS2
(2.13.96 there even), so we will use it for our next release.
Thanks to frogonia (long time no see! \O) for following up on this!
See also fontconfig report:
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/144
The 3 available formats are: simple text search, regular expressions and
glob patterns (cf. previous commit). I did a small step back from
previous commit by getting "is-pattern" property back in GimpItemList
instead of having this case as a value of GimpSelectMethod. The reason
is that it would render a useless value in the Preferences combo box.
Text search is the default.
… gimprc's manpage as a consequence.
When running `gimp-console-2.99 --dump-gimprc-manpage` to output a man,
a line was:
> .TH GIMPRC 5 "Version @GIMP_VERSION@" "GIMP Manual Pages"
This is clearly the autotools substitution syntax, which is not being
used here (this is not a .in file processed by the build system), maybe
from some older build logics.
Saving a thumbnail is closely related to the other metadata preferences,
but so far this was the only one that didn't have a preference for a
default user value.
This commit adds a preference in the metadata section where a user can
select whether thumbnail saving is enabled by default or not.
On Windows the --dump-gimprc, --dump-gimprc-system and --dump-gimprc-manpage
command line parameters do not produce any console output.
Apparently we need to request the handle for stdout instead of directly
using1 for stdout.
After this commit there still is a problem when redirecting output to a
file. It seems that the buffer where stdout is stored is not flushed or
the file pointer is reset to 0 every time causing overwrites instead of
appending to the file.
