Vector Tools: Implement new GUI design for vector tools
Open, NormalPublic

Description

Please use these requirements as a reference.

The list of GUIs:

  1. Tool Options docker for:
    1. Shape selection tool
    2. Path editing tool (editing mode of the shape selection tool)
      • rectangle
      • circle/ellipse
      • polyline (path)/polygon
      • line
    3. Filter tool
    4. Gradient tool
    5. Pattern tool
  2. Alignment popup and/or docker

If possible, put the designs into Pholio so everybody could discuss it :)

jospin added a subscriber: jospin.Oct 4 2016, 1:43 PM

pholio added. You can give feedback on the vector tools UI through the Pholio area here... https://phabricator.kde.org/M76

dkazakov renamed this task from Create GUI design for new vector tools to Vector Tools: Implement new GUI design for vector tools.Jan 9 2017, 9:38 AM
woltherav assigned this task to dkazakov.

Dmitry declared this testable yesterday, so lets add the bugs here. :)

Okey, first bug :3

Alright, I think this is self-explanatory.

  • In the Select Shapes tool, the opacity slider starts relatively uninitialised: It doesn't prepend opacity, nor is it set to the shape opacity.
  • when you have a semi-opaque shape and it has markers rendered, the fill of the markers is more transparent than their stroke. (this also counts if the stroke has a semi-opaque color)
  • Are Global Coordinates and Uniform Scaling implemented? If so, can we have a tooltip explain what they do? Toggling them is inobvious.
  • Pattern fill should probably be disabled until it's finished.
  • Changing the foreground color changes the stroke, but changing the backgroud color does not change the fill...
  • When drawing a path with the path tool with 'fill->foreground and stroke->none', the stroke is still rendered as filled with the foreground color, aswell as set to the curret brushsize, but the fill color widget isn't shown.
  • Similarly, the polygon, straight line, polyline, circle and rectangle tools have the stroke always set despite the configuration, and the stroke never takes the current brush size.
  • Is there any reason why the stroke width is snapping to certain values? Is it set to render svg px?
  • The stroke fill in the freehandpath/pencil tool doesn't do anything. Linestyle does work.
  • When attempting to change the markers, I got a sigkill, god knows why:
 Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb)

I'm gonna restart and look at what else I find...

Deevad added a subscriber: Deevad.Feb 19 2017, 12:20 PM
woltherav added a comment.EditedFeb 19 2017, 1:13 PM

svg quality bugs

  • when you make a circle shape and save, that shape isn't loaded as a circle shape.
  • The SVG inside that kra above loads like this in Inkscape 0.91:
    • Note the duplicate gradient entries. Maybe Krita should check which gradients are in use before saving them into the kra?
    • The resolution issue is because the paths themselves are still stored in Mystery Resolution X (probably also the cause of the stroke width being weird), instead of the document resolution.
  • Firefox refuse to load the above svg, because there's no such thing as a Krita namespace:
XML Parsing Error: prefix not bound to a namespace
Location: file:///home/krita/.local/share/krita/content.svg
Line Number 63, Column 1250:
  • Chromium
    Chromium renders the wrong gradient on the circles because there's conflicting gradientIDs in the SVG.
  • The marker gradient, when assigned via the stroke should probably not be set via def in the marker def, nothing seems to even pick up the correct gradient.
  • it seems there are two empty group entries in the file that were not made by me.
  • please make the formatting of the svg work proper. Everything besides the defintions isn't spaced out proper.

SVG loading issues.

This one crashes Krita:

Thread 1 (Thread 0x7ffff7f088c0 (LWP 1290)):
---Type <return> to continue, or q <return> to quit---
#0  0x00007ffff5798367 in ?? ()
   from /home/krita/Qt/5.6/gcc_64/lib/libQt5Core.so.5
#1  0x00007ffff55e59b3 in QRegularExpression::match(QString const&, int, QRegularExpression::MatchType, QFlags<QRegularExpression::MatchOption>) const ()
   from /home/krita/Qt/5.6/gcc_64/lib/libQt5Core.so.5
#2  0x00007fffa3be8220 in ImageShape::loadSvg (this=0x1b4dbc60, element=..., 
    context=...)
    at /home/krita/kde/src/krita/plugins/flake/imageshape/ImageShape.cpp:154
#3  0x00007ffff1feb0f7 in SvgParser::createShapeFromElement (
    this=this@entry=0x7fffffffb5e0, element=..., context=...)
    at /home/krita/kde/src/krita/libs/flake/svg/SvgParser.cpp:1488
#4  0x00007ffff1ff4451 in SvgParser::createObjectDirect (
    this=this@entry=0x7fffffffb5e0, b=...)
    at /home/krita/kde/src/krita/libs/flake/svg/SvgParser.cpp:1422
#5  0x00007ffff1ff2560 in SvgParser::parseSingleElement (
    this=this@entry=0x7fffffffb5e0, b=...)
continues add infinitum

Mismatches (probalby related to defs:






(mostly concerned with the stroke style of the big arrows here...

I'm gonna try and find some more complicated svgs.
Strangely enough, the main file of these renders pretty well, despite having text-shapes...

woltherav added a comment.EditedFeb 19 2017, 2:00 PM

Alright, this is the most complicated SVG I have:


I think it mismatches because of the way I use clipping paths...

EDIT: interestingly, the clipping paths on the groups DO work, but you need to get to a group that has a clipping mask, and wiggle it around. That forced the image to update properly.

When opening a Svg - resize to image size jumbles up the image.
to reproduce,

  • Get an svg which ahs elements beyond its canvas boundaries
    • Drag and drop the same svg in krita
  • Now go to Image > Trim to image size

result - you'll get an image with contents jumbled up or most of the content shifted to top left side of the canvas

Reposting the bug that I mentioned elsewhere

regarding the node handles I feel the actual node and the bezier handles shouldn't be similar, there should be some difference, the nodes should be either bigger size or of different color than the bezier handles, because when you select multiple nodes it becomes confusing to differentiate which is node and which is its handle. for example see the screenshot below

All the nodes and handles are shown same. This happens when the nodes are in corner mode.

scottpetrovic added a comment.EditedFeb 19 2017, 5:11 PM

When editing vector nodes directly on a line, it has some sporadic behavior... see video

it seems to happen more extreme the closer you are to an anchor point.

Wolthera mentioned this, but the pattern tool option has nothing in it. If we aren't going to have time to get it working, it should probably be hidden.

a couple minor UI points (that maybe I can look into)

  1. The icons while editing vector shapes might need some improvements. They don't do a very good job explaining the action they perform. For example the "Insert Point" has a + symbol in it, but it is very small. That should be much bigger. Many of the others have a similar issue of communicating the action of what they are doing (breaking, joining, converting, etc)
  1. For the stroke and fill tool options...the fill type picker has a ton of empty space that isn't being collapsed. even if there is no fill or stroke, the tool options still have the scrollbars.

not sure if we are still putting comments in this ticket...

I made a square in inkscape. then copied it to Krita. When it was pasted, the square shape looks good, but it has been converted to a paint layer and loses its vector points. I was thinking the format would still be vector when bringing it over to Krita. Copying from Krita to inkscape seems to preserve the vector properties.

scottpetrovic added a comment.EditedMar 31 2017, 3:48 PM

It sounds like this copy/paste issue is maybe specific to my build or windows OS. Not sure if the official builds will have this problem. It sounds like it is working alright on Dmitry's boxes that he is developing it on.

Followup: Just tested on my Ubuntu build and the copying/pasting works great. It may be specific to my windows build. or just windows in general.