Let's force having the bash-completion dependency when we want to enable
the feature. Then clearly shows the feature state in the final setup
summary.
Otherwise the risk is that GIMP may not use the correct path on a given
system and a packager who wants this script to be installed may miss
that it is installed in the wrong directory.
(cherry picked from commit 88b4f29ce7)
This is a useful debugging function for developers. It is enough to hide
the menu by default on stable releases, I don't think we also need to
hide the CLI option. Developers don't know all these options by heart,
so we need to make them reasonably discoverable!
In particular make it also work with the `gimp-console` and with all
symlink names.
Also rename the bash completion file using the full application version
so that it will be possible to install several such completion files
side by side.
This fixes:
> […]/gimp/etc/meson.build:31:39: ERROR: dependency.get_variable got unknown keyword arguments "define_variable"
This MR was years-old. Maybe this option got renamed since that time.
We forgot to edit the default unitrc when removing these fields in
commit 2a00a9e60a. It's OK since our code can still read these fields
for backward compatibility anyway, but better clean up the file.
What it was doing was casting the input buffer to another TRC, basically
pretending the data was what it was not. In particular, it was casting
linear input buffers to non-linear and all other TRCs to linear.
As was noted in #1958, this was in fact a useful trick, yet it's still a
trick. Basically when it's needed, it's either:
1. because the operation implementation does not work in the technically
correct space. Then the operation code should be fixed;
2. or because several work TRC are valid, then an option should be
proposed by the operation;
3. or for artistic reasons, which people are free to implement as
plug-ins or third-party filters, but it should not be a core GIMP
feature.
Therefore for most cases where it felt needed, the real solution will be
to improve the operations' implementations.
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.
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.
Also get rid of various old references to menurc and don't install it anymore to
etc/ (neither the new shortcutsrc as it doesn't look like it brings much value
to do so).
Existing default was requesting a window of size 1024×768 at position
(200,100). While it may seem a reasonable default on nowadays displays,
it was not on some intermediate size displays which are considered HiPPI
anyway.
Taking my personal example, my screen is 2560×1440, which is considered
HiPPI by GNOME 3 with a scale ratio of ×2. As a consequence, setting a
size of 1024×768 was actually creating a window of 2048×1536, which is
already higher than the screen. Worse, gtk_window_resize() resize the
window without taking into consideration the title bar, which in my case
added 74 pixels, so GIMP window started at 1610 pixels of height, much
bigger than my screen size, hence unusable (and for some reason, with
the title bar out of the screen so without knowing Super+click shortcut
to move or Super+Up to maximize, people would have a hard time to resize
or close GIMP).
This issue only happens at the first launch of GIMP, when no user
sessionrc exists yet. Once you resize yourself the main window, then
restart GIMP, it is fine (as next times, it will use the user's
sessionrc). Yet it is already a bad first impression.
For temporary workaround, let's use a smaller 800×600 defaults (which
will actually span on 1600×1200 pixels + decoration size on scale ratio
×2).
Still I don't like using arbitrary numbers for window size default.
As we see here, it can end up into all sort of weird result. Even more
with all the scale ratio business which didn't exist back in GTK+2.
Instead, the defaults should have no size, and our code should just
resize to whatever makes the most sense on the current display, which I
believe should likely be maximized. Unfortunately I have a hard time
with gtk_window_maximize() which doesn't seem to do anything at all
(does GNOME ignore _NET_WM_STATE_MAXIMIZE_* hints when requested by
applications maybe?). So until we find the right system, let's go with
this lower window size defaults at least.
Add a default toolrc file, installed in the sysconf dir, with a
more minimalistic tool layout using groups, inspired by Photoshop
(not identical, though, don't kill me! :)
It must not be a boolean but a `feature` option, with `auto` by default.
`auto` value mean enabled for macOS and Win32, and disabled for other
cases. This default logics disappeared in the meson build.
Also the mypaint-brushes package is a mandatory dependency, which must
always be checked. Absence is fatale.
Finally properly set the MYPAINT_BRUSHES_DIR macro depending on the
proper relocatable case.
Some gimprc properties' default values depend on the machine where
"make dist" in run. We had an ugly hack in place to force
(num-processors 1) in the installed system gimprc and its manpage, but
were still leaking "tile-cache-size" and "mypaint-brush-path".
The files are generated by the hidden options --dump-gimprc-system
and --dump-gimprc-manpage which exist only for this purpose.
In gimpconfig-dump.c, special case the three properties in
dump_gimprc_system() and dump_gimprc_manpage() to output constant
default values for "num-processors" and "tile-cache-size" and
output @mypaint_brushes_dir@ in "mypaint-brush-path" which can
be replaced at configure time.
Also introduce etc/gimprc.in so @mypaint_brushes_dir@ can actually be
substituted for the installed system gimprc.
Since we have many themes now, this new name better indicates that it
is meant to follow your desktop theme settings.
Also it will likely not remain the default theme.
