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.
Sometimes even within symbolic icons, parts of the design must keep
fixed colors, when they are semantic. For instance this is the case for
the color-picker-(black|gray|white) icons or the gimp-default-colors.
The trick used by GTK+ to recolor is by supplying an additional CSS
style to icons which overrides inline CSS thanks to "! important"
keyword. Our own trick to circumvent this trick is to set "!important"
in inline CSS when one wishes not to have it overrided by the general
colors.
Right now I am doing the edit by hand with vim because Inkscape doesn't
seem to validate this keyword if I add it manually in its XML editor. So
what I did is add the "color-important" label on such object, and I will
later modify my SVG export tool to add !important on such object "fill"
values at export time.
The current recolorization code only recolors paths and rectangles. In
particular it leaves circles and ellipses as-is.
I opened the merge request gtk!214 for this issue. But in the meantime,
it is quite easy to change circles and ellipses into path with "object
to path" in Inkscape.
A second problem is that it only recolors fills, not strokes, as
previously stated. So I need to remove strokes from icons, or transform
them to paths.
For anyone wishing to help me fix icons, here is the trick: apparently
GTK+ would fill the paths with CSS colors, not stroke them. So when we
have icon drawing based on path-stroking, they don't end up as expected.
In Inkscape, just run "Stroke to Path" to transform a stroke design in a
fill design.
I am fixing "gimp-tool-cage", "document-revert", "gimp-image-reload",
"gimp-reset" and "view-refresh". More to follow as we discover them, I
guess.
Treat the gimp-core-pixbufs and gimp-icon-pixbufs resources like we
changed the cursor resources before, and clean out a lot of cruft from
icons/ (there is no need to generate stuff in all icon themes when we
include only one fallback icon from one theme).
With the symbolic-awareness of GTK+, vector icons are recolored (using
fg, success, warning and error colors). Unfortunately it was also
recoloring some rectangles with neither fill nor stroke, which were
using only to get appropriate icon size (these icons were therefore
displayed as just a square).
I made a quick pass in our icons to "fix" these. I expect I may have
missed some icons, or at the opposite, I may have broken other icons by
removing rectangles which should not have been removed. If you find any
such icon, please fix.
Also some icons do not look quite right just now. We will have to create
new guidelines on how to make symbolic icons and fix/redesign some, I
guess.
"gimp-detach" does not just use "gtk-convert" anymore and has its own
design. As for "gimp-attach", this is not used anywhere (yet), but it
could be soon as reverse action of gimp-detach. For instance, this icon
can be used for bug 791859 when we implement re-attaching overlay
dialogs.
These are simple on purpose since the smaller size they are displayed at
is 12 px (in overlay dialogs) so it needs to be simple shapes.
Note by Jehan: gimpicons.h and Makefile.am not updated yet. Waiting for
the color icons first.
The dashboard dockable shows the current GEGL cache and swap sizes,
and their recent history. It has options to control the update
rate and history duration of the data, and an option to warn (by
raising/blinking the dialog) when the swap size approaches its
limit.
It's not finished yet, but I have already added all the individual
Freedesktop and GTK+ icons. The goal will be to have all the Symbolic
icons in this one file so that in the future we can just extract
individual SVG files from object IDs.
This was the original plan but librsvg was just too buggy and would not
extract the proper viewbox for some icons. Fortunately it seems that the
bug reports I made are finally starting to be taken into account so I am
hoping for a usable librsvg soon and starts the work which should have
been done from the start.
These icons are requested by the System theme, which outputs warnings at
loading, so they are needed even when using vector icons otherwise.
Not sure why these are hardcoded. Maybe we should rather edit these out
from the gtkrc instead. But this will do for the time being.
This reverts commit 2226fb1dc8.
It doesn't make much difference right now, will work the same on
native builds and be broken on cross-builds.
I need to fix how invert-svg is built (broken on commit 84439a8),
so that it is a build executable again. Work in progress.
But since it makes no difference right now, let's just revert this
one already.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
The 24 and 48 versions are slightly different, with the arrow on the
smaller version being bigger.
Preferences icon are also stored in all kind of size, like 16 and 22.
It may become necessary to make an alternative version for these smaller
sizes.
In 24x24, there was barely 1 pixel between the 2 links of the chain, and
not even inside a perfect pixel (so with interpolation, that's barely
recognizable).
I don't know if it's a very good-looking change but for now, that will
do. Designers are welcome to contribute improvements!
Symbolic icons were already taken care of in commit 3ff408f.
Freedesktop's "Thumbnail Managing Standard" defines 2 standard sizes
for thumbnails: 128x128 and 256x256 (section 5.3. Thumbnail Size).
Since the "folder" icon is used in-place of thumbnail when selecting a
folder in the GTK+ file dialog, it should also provide these default
sizes.
Commit 82737bf got rid of the only pieces of code where these icons were
used. Since they were never available in any version release of GIMP,
let's delete them from libgimpwidgets API as well.
Observed initialization time for OpenCL observed on modern systems has been up
to 1 second - OpenCL speed ups will not outweigh initialization costs for these
small icons.
Jehan