It was infinitely-looping because of a mis-usage of the % matching rule.
On the rule or dependency side, I must use $(@D) instead of % to match
the directory part of the target (I could also have used $* to get only
the matching part of the stem).
Commit 8bb1421 broke the build by changing build order. Line back
tools/ after libgimpbase/ and move also icons/ after tools/ (for the
vectorial icons).
- gimp-gradient-shapeburst-angular (straight path).
- gimp-gradient-spiral-clockwise (stroke-width).
- gimp-gradient-spiral-anticlockwise (stroke-width).
- gimp-gradient-square.
- gimp-info (1-point paths).
- gimp-path-stroke (stroke-width).
- gimp-path (stroke-width).
- gimp-prefs-icon-theme (1-point paths).
- gimp-prefs-playground
- gimp-prefs-toolbox
- gimp-selection-to-path (stroke-width).
- gimp-toilet-paper
- gimp-tool-desaturate (useless path).
- gimp-tool-fuzzy-select
- gimp-tool-n-point-deformation
- gimp-tool-preset
- gimp-tools
- gimp-tool-zoom (straight path).
- gimp-wilber
- gimp-wilber-eek
- gimp-wilber-outline
Note that even with these tweaks, icon extraction is still not perfect
because of a limitation of librsvg which does not return accurate
position/dimensions. As a result, extracted icons may have off-by-1
shift. So the extraction is still marked as experimental until this
librsvg bug is fixed:
https://bugzilla.gnome.org/show_bug.cgi?id=762039
This icon was broken:
- gimp-selection-none (was disformed).
This will extract vectorial symbolic icons out of the SVG source, and
generate vectorial symbolic inverted icons too.
Vectorial color icons are not extracted yet.
I also make sure that the tools/ subdir is processed by make before
icons/ because a few build tools will be needed to extract the icons.
Yet I mark the feature as experimental because librsvg seems to be
broken on many edge cases and several icons end up wrong. I'll keep
the option experimental until I figure the right way to extract the
icons.
replace with old gimp design.
The design prefered by inkscape is not clear enough to distinct
between horizontal and vertical.
Even in inkscape itself the directions change with the icon themes.
Scalable sources will follow later (after jehan has finished his tests).
gimp-flip-horizontal
gimp-flip-vertical
Updates to copyright, some button contrast for TDSOG, TDLSOG. Added comment
for button focus area. Fixed selected text for TLSOG themes. Redid screenshots
to match changes. Fixed menu style name. Updated copyright year. Fixed menu
items for Ubuntu unity. Fixed prelight and fg for widget text. Updated to
v0.1.6.
gimp-flip-horizontal (sync with color and inkscape)
gimp-flip-vertical (sync with color and inkscape)
gimp-tools (no cockwheel and wrench)
gimp-tool-preset (no toolbox, cockwheel and wrench)
gimp-prefs-toolbox (no cockwheel and wrench)
gimp-prefs-folder-tool-presets (no wrench and hammer, only pencils)
gimp-prefs-folders-tools (no hammer, just putty-knife and varnish)
gimp-prefs-tool-options (no cockwheel)
gimp-prefs-folders-tool-plug-ins (no cockwheel)
swapped (for better consistency with gimp-tool-scale):
gimp-scale
gimp-resize
changed
gimp-reshow-filter (shutters are in a semantic field with filters, cockwheels not)
new in color-scalable
gimp-sample-point
and remove lots of labels from calls to gimp_prop_foo_new(). Also
had to manually remove some unwanted labels that are now added
automatically, fixes bug #761880.
I am still not sure whether custom guides should follow snapping rules.
Yet I could easily imagine you could want some normal guides with
snapping and in the same time symmetry without snapping to axis of
symmetry. So for the time being, let's disable snapping to custom guides
all the time and see if logic could be improved later.
This is not ideal since the scale widget is crazy huge, thus
impractical, but the solution used on properties of other symmetries
(updating min/max of the class property) is wrong since it applies to
the whole class.
For the time being, it avoid setting obviously bad values until we
figure out the ideal automatic UI construction.
