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
- ...
I took the icon directly from Adwaita repository as of today's version:
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/Adwaita/scalable/status/software-update-available-symbolic.svg
By being installed on our local GIMP-only hicolor, this gets picked up
after any custom theme software-update-available version. I didn't
install it inside the Symbolic or Color theme because anyway Adwaita
seems only to provide a single vector version. There is a color version,
yet as PNG icons and installed in the legacy/ section. I don't think it
makes sense to use an icon considered as legacy by its author and
without vector version. So I just install the symbolic version and all
themes can fallback to it (be them symbolic icon themes or not).
This icon comes from the Adwaita repository and is therefore licensed
under the terms of either the GNU LGPL v3 or Creative Commons
Attribution-Share Alike 3.0 United States License. See:
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/COPYING
It seems to be an old file move error I did 2 years ago (commit
1e5cf10585). I wonder how I only realize this now. Anyway let's remove
this lonely file.
So it turns out there are still a few bugs in librsvg position/size
computation. One of them is described in my comments:
https://gitlab.gnome.org/GNOME/librsvg/-/issues/250#note_900325
To work around them, I had to increase stroke width of a SVG <circle> to
be over 0.5px.
See commit 1e5cf10585.
I am reorganizing again a bit the global file with all icons to
experiment a bit again with icon extraction using librsvg (let's see how
the library evolve since last time I tried, a few years ago!).
These icons are not available in any of our themes (Symbolic or Color).
Also they don't seem to be available in many icon themes either actually
and I'm not sure GIMP properly fallbacks to system icon theme when an
icon is missing in the selected theme anyway (I think to remember this
used to work, but it doesn't look like it works anymore).
Anyway I just copied the 2 symbolic switch on|off icons available in the
GTK+ repository at gtk/icons/scalable/status/. These are supposed to be
used by GtkSwitch but somehow they aren't. So for the time being, let's
bundle them directly with GIMP (until we figure something better out).
I put them in hicolor because this is the generic/default theme which is
always used as last resort and is common to any theme. It means any
specific theme will be able to override these icons, but if missing,
hicolor will be able to provide a fallback.
Add a new 3D Transform tool, based on GimpToolTransform3DGrid,
added in the previous commit. The tool UI provides a notbook with
three tabs, corresponding to the three GimpToolTransform3DGrid
modes:
Camera - allows setting the primary vanishing point, as well as
the camera's focal length, expressed either directly, or as the
camera's angle of view, relative to the whole image or the
transformed item. By default, the vanishing point is aligned
with the item's center, and the angle of view is fixed relative
to the item; this essentially means that each item is transformed
using a local perspective, independent of its position and size
relative to the image. A global perspective can be achieved by
using a common vanishing point and focal length (or an image-
relative angle of view).
Move - allows moving the item using X, Y, and Z offsets.
Rotate - allows rotating the item using X, Y, and Z Euler angles.
The order of rotation of the different axes can be controlled by
a set of numbered buttons next to the sliders, and the rotation's
pivot can be controlled using a pivot selector.
GimpPivotSelector is a 3x3 grid of toggle buttons, used for
selecting a natural pivot position (e.g., for a transform) relative
to an item: its center, its corners, and the midpoints of its
edges.
This is a quick and dirty fix to just deal with this specific issue, but
looking at meson rules for icons, it looks like I will need to do a
proper and very detailed review of this part of the build system.
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
Allow setting the type of GimpCurve control-points to either SMOOTH
or CORNER. Smooth points produce a smooth curve, while corner
points produce a sharp curve (previously, all points were smooth).
In GimpCureView, display corner points using a diamond shape,
instead of a circle.
In the Curves tool, allow changing the curve's point types.
Add an option to record a performance log through the dashboard.
The log contains a series of samples of the dashboard variables, as
well as the full program backtrace, when available. As such, it
essentially acts as a built-in profiler, which allows us to
correlate program execution with the information available through
the dashboard. It is meant to be used for creating logs to
accompany perofrmance-related bug reports, as well as for profiling
GIMP during development.
The sample frequency defaults to 10 samples per second, but can be
overridden using the GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY
environment variable. Backtraces are included by default when
available, but can be suppressed using the
GIMP_PERFORMANCE_LOG_NO_BACKTRACE environment variable.
Logs are created through the new "record" button at the bottom of
the dashboard dialog. When pressed, a file dialog is opened to
select the log file, and, once confirmed, data is being recorded to
the selected file. Recording is stopped by pressing the "record"
button again (we use a highlight to indicate that recording is
active.)
While recording, the "reset" button is replaced with an "add marker"
button, which can be used to add event markers to the log. These
can be used to mark events of interest, such as "started painting"
and "stopped painting", which then appear in the log as part of the
sample stream. Markers are numbered sequentually, and the number
of the next (to-be-added) marker appears on the button. Shift-
clicking the button adds an empty (description-less) marker, which
is only identified by its number; this can be used when markers
need to be added quickly.
The log is an XML file, containing some extra information (such as
the output of "$ gimp -v", and symbol information) in addition to
the samples. The data in the file is delta-encoded to reduce the
file size, meaning that samples (as well as some other elements)
only specify the changes since the previous sample. This adds a
necessary decoding step before data can be processed; the next
commit adds a tool that does that.
There are currently no tools to actually analyze the data -- that's
still TBD -- but at least we can start gathering it.
That's the problem of having alternative build options! My previous
commits were made when testing the build with PNG icons.
Anyway I am planning to soon merge the 2 options.
We don't need to commit PNG symbolic icons as `gtk-encode-symbolic-svg`
is perfectly able to generate them from the SVG.
Moreover its man says that it makes "specially prepared png files",
whatever that means. So I don't think we should just rename our
self-exported PNG files as '*-symbolic.symbolic.png'. It is better to
generate them with this tool.
Note that I am now splitting icon-list.mk into 2 files. This is only a
temporary stepback, as I am actually going to merge the 2 icon themes
into one very soon, and hopefully we should be able to generate the list
to ensure we don't miss an icon.
Anyway the icon lists had already diverged earlier, even though it was
only all still in a single file.
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06f
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
I know that the idea of black toilet paper is traumatizing nomis! ;-)
So here it is, using the CSS "!important" trick to override GTK+ CSS
recoloring code.
In order for the icon to be always visible, even on light background, I
am adding a path around the toilet paper shape (which this time will
be properly recolored by GTK+ with the foreground color, hence making
the icon clearly visible).
It should now be possible to fully export our symbolic icons from a
single central file.
My long-standing bug of librsvg#250 is still opened and unfixed, but it
turns out most issues I encountered are anyway also problems when
recoloring symbolic icons in GTK+ (like using strokes instead of
fills!). So let's just bypass all problems at once by accounting for
these issues in the design.
I tried to fix all the icons I could see which had issues regarding all
recoloring matters (using fill not stroke, change circle/ellipses to
paths, etc.) when looking at a blank canvas.
I'm sure I still miss a lot but that will do for now.
Jehan
