... tools' brush options.
After discussions, it turned out that many people disliked that the spin
scale for brush size (and some other options) get you fractional values.
How often do you actually need to get a 4.32 pixel-size brush? And even
how meaningful is it? On the other hand, you usually want a 4 or a 5
pixel size brush and it's nearly impossible to get (exactly) by dragging
the scale widget.
It is so annoying that some even resort to edit the value with keyboard!
So I am adding an optional "constrain" feature to GimpSpinScale. It will
still be possible to get fractional values when constraining is on, for
instance with keyboard edit (the arrow incrementation also will keep any
fractional part). So the interaction for such scales is simply reversed
so that you get integers easily, and fractional parts with a bit more
effort.
It is not turned on by default (some feature actually need precision and
we don't want to break the sliders for these) and for the time being, I
only applied it to all the brush settings in paint tools. Now that it
exist, we may want to apply this to more scales in various parts of
GIMP.
... on macOS.
The debugger running on macOS is usually lldb and (from the reports we
get) it looks like lldb displays the tid as hexadecimal on macOS
(whereas lldb displays decimal tid on Linux! I know, it's confusing, yet
consistent with crash report experience!). So let's just do the same,
making it easy to quickly copy-search in order to look up the crashing
thread (without having to convert from decimal to hexa).
This is a bit of an approximation as I imagine we could have gdb on
macOS or whatever edge case. Let's say it's good for the common case and
still not an error otherwise (just a base conversion away).
When initializing a pygimp plug-in derived from gimpplugin.plugin,
only pass the plug-in's init() and quit() functions to gimp.main()
if the plug-in actually implements them, instead of passing the
default NOP versions. This avoids plug-ins that don't implement
init() from being registered as having an init function, causing
them to be run at each startup.
In gimp:gradient, when using adaptive supersampling, render the
gradient tile-by-tile, using an iterator, instead of row-by-row.
This significantly improves performance, while also avoiding the
assumption that gimp_adaptive_supersample_area() works row-by-row.
Additionally, when not using supersampling, use a single GRand
instance, since the separation to distinct seed and per-tile
instances, which was a threading optimization (commit
7f39e41254), is no longer needed.
... from menus.
The script-fu version is still available through pdb (for scripts) and
even in the action search. But in menus, only the new Python version
will be shown. Also update the description and name of the old version
to make clear it is deprecated in favor of the new plug-in.
Finally rename the new version to simply "plug-in-spyrogimp" (dropping
the "-plus" part as we should consider it as a replacement rather than
as another plug-in, which the "plus" would imply). Anyway the old one
was called "script-fu-spyrogimp", so there is no name clash.
While at it, do some trailing whitespace cleaning in the new plug-in.
(cherry picked from commit 8729f9a662)
Comment by reviewer (Jehan):
This was submitted through gimp-developer mailing list, by the same
author as the original Spyrogimp in script-fu, but this time in Python.
It does more than the original plug-in, with some automatic preview (by
drawing directly on a temporary layer, not as a GEGL preview), and using
the current tool options (current brush, etc.). The new API is similar
yet different. The much evolved possibilities makes that I don't think
it is worth trying to map 1-1 the new API to the old one, so I just let
the old plug-in next to the new one, with a different name.
Note finally that the author also contributed a new Spyrograph operation
to GEGL, yet with the comment: "The GEGL spyrograph operation is very
basic, and untested from gimp. I intend to keep developing it, since I
thought that on-canvas interaction would be very user-friendly. However,
I am not sure I will be able to get it work in a way that makes the
on-canvas interaction interactive enough.
Even if I do, it will not do what the Python plugin can do. It will be
much more basic."
So let's just integrate this evolved version of Spyrogimp for now. :-)
See: https://mail.gnome.org/archives/gimp-developer-list/2018-September/msg00008.html
(cherry picked from commit 529583430d)
Before each release, we prepare now a <release> tag. Unfortunately some
details are not always well known for sure in advance, in particular the
date of release (plans are made to be broken!), and also the release
news URL (since the date is in the URL). So I usually leave them as TODO
and until now, I never forgot to update them just before release. But
there is always the risk of forgetting.
Now the test for the appdata files will also look for remaining "TODO"
in the file if and only if the micro version is even (which means it's a
release). So we won't ever forget to update the file as long as we run
`make check` on the last commit (which we always do obviously).
It got disabled in commit 0492157dd2 because of a bug in appstream-util,
which has been fixed for monthes now. Let's just reenable it and assume
anyone who wants to run a `make check` on GIMP uses a recent
distribution with up-to-date system tools.
Add a "markers" page to the performance-log viewer, which lists
the event markers contained in the log, and allows navigating
between them.
Update docs accordingly.
When a fill zone was a bit too segmented, you'd want to just stroke
across it. But it was leaving some pieces uncolored, even though the
pointer dragged through it! The exact motion mode allows more events.
Note: I don't set it in the similar color filling (where it could have
been useful too) mostly because it is harder to remove events then (even
if a point was already filled, it could still serve as a seed for more
filling if threshold > 0), thus implied too much processing. Anyway in
all my tests, it was more a problem for line art filling anyway.
In GimpToolRectangle, fix the type of the cornder_radius field, so
that non-integer radii are properly displayed.
In GimpRectangleSelectOptions and GimpToolRectangle, increase the
maximal corner radius.
We were doing it all the wrong way, fixing one combo box object at a
time. So this commit basically reverses commits 68a33ab5bd, 6dfca83c2a
and a9a979b2d0 and instead runs the same code in the class code. This
way, all objects based on these base classes will have the fix from
scratch.
These improved various other drop-down lists (I found some of them, and
probably not all) as I fixed all GIMP custom widgets based on
GtkComboBox.
Note that it has to be run after filling the list apparently (I had the
problem especially with GimpIntComboBox if running in the _init() code,
then the list widget showed wrong).
The main window height was always bigger than my screen height on
startup, overriding my previous session's window size.
I could retrace the memorized size being changed when adding the display
shell with gimp_image_window_add_shell() in gimp_display_new(), just
before showing the window. Unfortunately this happens after we applied
the session position/size (in gimp_image_window_session_update() at end
of image window construction). I'm not sure why adding the shell
increases the size of the window, especially since the window can be
manually sized at the expected dimension without any graphical glitch.
Maybe we could investigate this, but simply forcing any session managed
window to behave as expected upon showing is not a bad move anyway and
in this specific case, it works fine.
When clearing a channel, do nothing if the channel is already
empty; otherwise, align the cleared rectangle to the channel
buffer's tile grid, so that all affected tiles are dropped, rather
than zeroed. Furthermore, only update the affected region of the
channel.
In commit c71b4916af, I forgot to disconnect signals on the bucket fill
options at finalization, leading the software to crash on an
non-existing tool.
After discussion with Sébastien Fourey and David Tschumperlé, it was
decided that a better fix for the edge case raised in #2785 was to add a
keypoint anyway, even if the point and none of its neigbours have a
positive smoothed curvature, yet they have a positive raw curvature. In
such case, we use the local maximum raw curvature instead of the local
maximum smoothed curvature.
In the perofmance-log viewer, add header-bar buttons to clear and
invert the selection, and allow inverting the selection by ctrl-
right-clicking on the sample-selection area.
Update the docs.
Piotr Drąg