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.
When running gimp-console-2.99.exe --dump-gimprc-system we get two
warnings:
(gimp-console-2.99.exe:23000): Gimp-Config-WARNING **: 16:08:29.604:
FIXME: Can't tell anything about a gint64.
Let's fix this by adding G_TYPE_INT64 as a known integer value.
Fix the search for previous folders, which was broken as it was
specifically expecting 1-digit numbers so far.
The differences of the GIMP 3 config import are:
- update sizes and positions in the sessionrc according to the scale
factor, because GTK2 doesn't have scale support. It means that, e.g.
with a 2× display, all sizes and positions in GIMP 2.x must be divided
by 2 (otherwise the first thing many people will get when testing GIMP
3 for the first time is an off-screen window).
Of course, I even wondered if it would not be nice to just drop the
sessionrc altogether and start with a nice blank slate, but then you
also lose the opened dock and their organization and some settings
(such as whether you chose single or multi window mode, etc.).
- scripts/ and plug-ins/ are not imported. Probably makes no sense so
far as they would end up broken (but maybe it's not true for all
script-fu scripts?).
Another sensible default change proposed by Aryeom. Until now, all tools
which could make use of dynamics started with "Dynamics Off". This makes
it very hard for beginners to start using GIMP with a tablet directly
without actually knowing the technical settings of the software.
This is even more anticlimactic in GIMP 3 as tablet are supposed to work
from scratch (and they do), but without a proper dynamics, you can't see
it. And same as it used to in GIMP 2.x, at first launch, it looks like
your tablet is not recognized.
We hesitated between "Pressure Size" and "Pressure Opacity". Both are
sensible choices and would directly show your tablet works. Also they
rely entirely on tablet-specific input (pressure), unlike e.g. speed or
direction, which is much better for the purpose of showing the tablet
works and is properly supported.
A -quick done- first step towards the addition of a smart selection tool.
Require the gegl:paint-select workshop operation.
Still LOT of work to do (wip):
- fluctuations removal (GEGL side)
- multilevels pyramid approach + banded graphcut for instant result on large
image (GEGL ? GIMP ?)
- Gaussian Mixtures for color models (GEGL side)
- drawable offsets (GIMP side)
- undo / redo (GIMP side)
- scribbles edition mode (GIMP side)
- dedicated icons
- ...
Some people had been complaining that they couldn't find some actions in
some case, which was only because they were in states where the actions
were non-sensitive. So it was "normal" (i.e. not a bug), yet I can see
how it can be disturbing especially when we don't realize that an action
is meant to be inactive in some given case.
Of course the option to show all actions already existed in the
Preferences. But as most options in Preferences, this is hardly
discoverable and many people only use default settings. Moreover showing
hidden action made the action search cluttered with non-sensitive
actions in the middle of sensitive ones.
This change gets rid of the "Show unavailable actions" settings and
always show all matching actions. In order not to clutter the list with
useless results, I simply updated the display logics to always show
non-sensitive action after sensitive ones. Note that even non-sensitive
actions will still be ordered in a better-match-on-top logics, yet they
will be after sensitive actions. So the top results will be the best
matches among sensitive actions (action in history), followed by various
levels of matches (actions with matching labels, tooltips, different
order matches, etc.); then they will be followed by best matches among
non-sensitive actions, followed by the same levels of matches as
sensitive ones.
This way, we still keep a very relevant result and there is no need to
have a settings for this.
Orientation is now handled by core code, just next to profile conversion
handling.
One of the first consequence is that we don't need to have a non-GUI
version gimp_image_metadata_load_finish_batch() in libgimp, next to a
GUI version of the gimp_image_metadata_load_finish() function in
libgimpui. This makes for simpler API.
Also a plug-in which wishes to get access to the rotation dialog
provided by GIMP without loading ligimpui/GTK+ (for whatever reason)
will still have the feature.
The main advantage is that the "Don't ask me again" feature is now
handled by a settings in `Preferences > Image Import & Export` as the
"Metadata rotation policy". Until now it was saved as a global parasite,
which made it virtually non-editable once you checked it once (no easy
way to edit parasites except by scripts). So say you refused the
rotation once while checking "Don't ask again", and GIMP will forever
discard the rotation metadata without giving you a sane way to change
your mind. Of course, I could have passed the settings to plug-ins
through the PDB, but I find it a lot better to simply handle such
settings core-side.
The dialog code is basically the same as an app/dialogs/ as it was in
libgimp, with the minor improvement that it now takes the scale ratio
into account (basically the maximum thumbnail size will be bigger on
higher density displays).
Only downside of the move to the core is that this rotation dialog is
raised only when you open an image from the core, not as a PDB call. So
a plug-in which makes say a "file-jpeg-load" PDB call, even in
INTERACTIVE run mode, won't have rotation processed. Note that this was
already the same for embedded color profile conversion. This can be
wanted or not. Anyway some additional libgimp calls might be of interest
to explicitly call the core dialogs.
Multi selection actually only really matter when "Merge within active
groups only" option is checked, in which case we are able to merge
layers within several layer groups simultaneously, and end up with
multi-selected merged layers.
Also not sure why both layers-merge-layers and image-merge-layers exist,
as they are exactly the same (exact same callback called when
activated).
Meson has a very useful tool for combining a set of linked libraries and
compiler arguments (like an internal pkg-config):
`declare_dependency()`. Use this command to ensure that we can easily
reuse libapp* over multiple libraries, executables and tests.
That way, if we also add a new dependency later on in one of the libapp
libraries, this won't need to be added multiple times.
The idea is to be able to advertize a new revision of the same version
of GIMP. For instance, this would apply when we release a
`gimp-2-10-14-setup-3.exe` Windows installer (then we are at revision
3, provided we started at revision 0).
The revision number is obviously only relevant to a given platform and
version. Also the concept of build ID allows to differentiate various
builds for a same platform, in particular to not look at revisions of
third-party builds. The build ID can be any string. Maybe we could just
use reverse DNS build id (such as "org.gimp.GIMP_official") to identify
the official GIMP build. So in the end, we only compare revisions for an
identical (version, platform, build-id) tuple.
Add a new "Snap brush outline to stroke" toggle to the "Image
Windows" preferences page. When enabled, the brush outline in
paint tools snaps to the individual dabs while painting, instead of
following the cursor precisely (this is the existing behavior).
When disabled, the brush outline follows the cursor while painting
in the same way it does while not painting.
Disable the option by default. This seems to be what most other
programs are doing, and it does give paitning a smoother feel.
Add a new Gimp::tool_item_ui_list, which is a GimpTreeProxy over
Gimp::tool_item_list. This allows us to use either a hierarchical
or a flat tool list in the UI, by setting the "flat" property of
the new list.
Use Gimp::tool_item_ui_list in GimpToolPalette, so that the toolbox
layout is affected by this choice.
Add a "Use tool groups" toggle to the toolbox preferences, and bind
it to the "flat" property of Gimp::tool_item_ui_list.
GIMP will now process the remote gimp_versions json file to look if one
is using the last version of GIMP. This initial code doesn't act up yet
on this information. This will come in further commits.
Here are the characteristics:
- Since this requires internet access, a new checkbox is available in
the Preferences dialog, allowing to disable version checks. Note that
it is enabled by default as it is an important security feature, but
it has to be deactivatable.
- The remote access is done as an async operation because we don't want
it to block the startup in any way (for whatever reason). Also it
doesn't output errors if it fails to not be a bother (you don't
technically need internet access for an image program).
- We don't check at every startup. At each successful check, we save a
timestamp to prevent too frequent useless checks (I set it the timer
to a week or more for now).
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
export it to libgimp via GPConfig and add new API gimp_export_comment().
Bump the protocol version and improve variable names in both GPConfig
and libgimp/gimp.c.
Add a new "Swap compression" option to the preferences, allowing
explicit control over the tile-swap compression algorithm.
Previously, control over swap compression was only possible through
GEGL command-line options/environment variables. Since the GEGL
API to list all available compression algorithms is still private
for now, we currently only list the three predefined compression
levels -- "best performance" (the default), "balanced", and "best
compression" -- and a "none" option, to disable compression
altogether. Selecting a custom compression algorithm is possible
by entering its name manually.
Add an option to keep the normal canvas padding in "show all" mode,
instead of extending the checkerboard pattern indefinitely. This
is useful when wanting to show the image content beyond the canvas,
while still keeping the focus on the canvas; further commits will
extend this mode to behave in more view-related cases as if "show
all" wasn't enabled.
Add a new 'View -> Padding Color -> Keep Padding in "Show All"
Mode" toggle, which controls this behavior, with a corresponding
default-value option in the preferences, under "Image Windows ->
Appearance".
Add a "show canvas boundary" display option, and a corresponding
"View" menu item and default-apperance preferences option. When
enabled (the default), the canvas boundary is shown as an orange/
black dashed line in "show all" mode.
Add a "show all" mode to GimpDisplayShell, controlled through a
corresponding "View -> Show All" menu item. When enabled, the
entire image content is displayed, instead of cropping the image
to the canvas size. More generally, the display behaves as if the
canvas were infinite. The following commits improve the overall
behavior in this mode.
Add a prefernces option to control the default "show all" state.
GimpConfigWriter contains several constructors with the convention
`gimp_config_writer_new_* ()`. This will lead to problems however with
languages like Vala, where it cannot disambiguate the following:
```
// calls config_writer_new_string()
Gimp.ConfigWriter w = new ConfigWriter.string("xxx");
// calls config_writer_string()
w.string("xxx")
```
Using `from_` in constructors is general practice in GObject-bsed
libraries because of this.
This also fixes an error when trying to use vapigen on the GIMP .GIR
file.
