Can we has object-outliner? Karbon has it. (Inkscape doesn't, much to the sadness of many)

Basically, a layer-entry for every vector object, with the vector layer as the root. The reason I am interested in this is because it's waaaay more easy usability-wise, for example if you need to find all text-shapes, or are trying to order one shape underneath the other, or are trying to access a hidden shape.

SVG can handle most of our shape needs, I am mostly worried about our Text needs and finding a rendering library for that...

I would like to add some of the requirements(Wish) for vectors

• Ability to combine, subtract, divide( break the overlapping as well and other parts into seperate object) intersect.
• Ability to arrange and align ( this option is present currently)
• Ability to add a selected shape to preset and save it in bundle, this way we can share borders, shapes like speech bubbles, and other design elements .
• Ability to organise wth tags and load vector shape presets
• Ability to quickly select a shape ( a variation or extension of 'R' click) currently 'R' click selects the vector layer and extension to 'R' click by adding a modifier key to quickly selecting particular vector shape may be good.
• Create brushes tips from selected vector shape.
• A vector brush ( with pressure sensitivity, I wish only for basic parameters - size, scatter , rotation etc) to ink artwork in vector brush strokes, that way scaling lines would be no problem. Related bug report - https://bugs.kde.org/show_bug.cgi?id=265814
• Ability to export and import a vector shape to and from .EPS or svg
• Ability to animate the vector shapes with simple tweening of rotation position, transforms, and possibly shape tween (example circle to square)

I just documented what we publicly stated to people in the kickstarter about what we are going to do with these vector improvements. I think as long as we address each point to a certain degree, I think we should be ok. It is pretty vague, so I think whatever we do people are going to be impressed.

Vector

• Use SVG 2 as a base
• improve the range of effects, operators and gradients available
• Make the UX easy to use and work with
• (an assumption that most existing functionality won’t be removed)

Ok, on the sprint we decided that...

1. We will support SVG 1.2 tiny. For the fact it has a RelaxNG schema that we can use to generate parsers/writer classes with. (This is a good thing)
2. We will extend this Schema with SVG filters and SVG 2.0 text support.
3. We will not implement SVG 2.0 Z-Index for the sanity of poor dmitry who would have to rewrite our rendering engine for the gazllionth time. In fact, all SVG 2.0 features will have to go through some review.

Other:

1. We will need to investigate what is up with ICCcolor tag, as that's something inkscape does save, but I have no idea to what state it is in for SVG 2.0. (It's in SVG 1.1 and 1.2... but I am not sure how it should be implemented)
2. We will have to investigate the maturity of the text-tags.

Due to the maturity of the SVG 2.0 spec, we will primarily focus on the vector editing tools themselves before we look at parsing/writing, so that we have a better grasp of the difference between Krita and the SVG spec, as well as what we will need.

We looked over all the tools. Dmitry has made a gazillion notes on each tool. Not sure when he's going to transcribe them to phab.

Vector System Requirements [MOVED]

The actual requirements have been moved to Phriction:

https://phabricator.kde.org/w/krita/vector_tool_requirements/

For the record: I disagree with the decision to use SVG++, for the following reasons:

• It's a big mess of templates that the author is proud that it cannot be compiled with some compilers

• It's going to be really hard to fit in with the way the flake system works (notably the load/save methods), and we really cannot afford to drop that whole-sale and redo from start.

• It only handles parsing svg, not saving.

• It's meant to render svg as it parses, not to create an editable data model.

In fact, I am tempted to propose that I write the svg loading/saving code so you can focus on the user interface, just to make sure we avoid depending on and probably forking this library.

In T1005#57671, @rempt wrote:

• It's a big mess of templates that the author is proud that it cannot be compiled with some compilers

Well, it compiles fine here. I know you don't like boost personally, but it shouldn't force us to invent the bicycle every time :) SVG++ has quite a lot of features, like SVG schema checking and error reporting that we will hardly ever be able to implement.

• It's going to be really hard to fit in with the way the flake system works (notably the load/save methods), and we really cannot afford to drop that whole-sale and redo from start.

I haven't spent time on investigations into the code yet. A brief look into KoShape::loadOdf* shows that not much will change. Just these methods will be called not from our own loading code, but from SVG++. And they will accept not raw XML, but already parsed attributes, including inherited values, like "color", "opacity" and etc.

• It's meant to render svg as it parses, not to create an editable data model.

Let's wait until I have time on the code stuff. It might happen that yes, we don't need it. Just at the moment I don't think we can live without it and not go insane.

In fact, I am tempted to propose that I write the svg loading/saving code so you can focus on the user interface, just to make sure we avoid depending on and probably forking this library.

I cannot agree on splitting this task.

Perhaps, the best course of action is to agree to spent a limited amount of time on integrating svg++, if it cannot be done within a limited amount of time, it is not worth doing.

Dmitry, do be mindful that we're having a huge problem to attract people who build Krita, especially on widnows, as we constantly need to switch compilers to even get VC working. It might very well be that you can build this, but you aren't the one maki g the final builds, so it might not be easy to understand the fear boud has for difficult libraries. Maybe, just as much as boud should respect your understanding of the undo system, you could show him some mercy? :p

Anyway, we do really need to set a time limit on this. There's far more work to do than parsing svg.

Yes, I'm fine with a time-boxed experimental phase.

But: before we add another dependency we need to make sure that it's a viable one. I know we succesfully pushed libraries that weren't available in distributions before (lcms, vc, eigen), but those had authors that were friendly, helpful and interested in doing their bit to make their library work with Krita.

In particular, I think that a new dependency:

• be appropriately licensed
• should have been in active development for some time
• be developed by more than one person
• be in active use by at least two other projects.
• show active response to bug reports
• be shown to build on all three our main platforms (and have a sane build system).

There also needs to be, or be written, a cross-platform find****.cmake module.

And, ideally, the API shouldn't be eye-wateringly crap :-)

I'll try again to build svgpp with mingw later tonight, my first attempt failed because its CMakeLists.txt doesn't enable C++11, even though it's needed, the second because apparently it doesn't build with Boost 1.55, even though it doesn't do a version check. I'll also try to build it on OSX.

On Windows, with MingW:

With Boost 1.55:

C:\dev\svgpp\src\demo\render\svgpp_render.cpp:1062:94:   required from here
C:/dev/i/include/boost-1_55/boost/spirit/home/support/context.hpp:110:32: error: no matching function for call to 'as_list(boost::fusion::result_of::transform<const boost::fusion::vector<boost::phoeni
x::actor<boost::phoenix::reference<const svgpp::factory::length::unitless<> > >, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fu
sion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_>, boost::spirit::detail::expand_arg<boost::spirit::context<boost::fusion::cons<double&, boost::fusion::nil_>, boost::fusio
n::vector0<> > >, boost::fusion::void_>::type)'
               , fusion::as_list(
                                ^
In file included from C:/dev/i/include/boost-1_55/boost/fusion/include/as_list.hpp:10:0,
                 from C:/dev/i/include/boost-1_55/boost/proto/fusion.hpp:25,
                 from C:/dev/i/include/boost-1_55/boost/proto/core.hpp:21,
                 from C:/dev/i/include/boost-1_55/boost/proto/proto.hpp:12,
                 from C:/dev/i/include/boost-1_55/boost/spirit/home/support/meta_compiler.hpp:19,
                 from C:/dev/i/include/boost-1_55/boost/spirit/home/qi/meta_compiler.hpp:14,
                 from C:/dev/i/include/boost-1_55/boost/spirit/home/qi/action/action.hpp:14,
                 from C:/dev/i/include/boost-1_55/boost/spirit/home/qi/action.hpp:14,
                 from C:/dev/i/include/boost-1_55/boost/spirit/home/qi.hpp:14,
                 from C:/dev/i/include/boost-1_55/boost/spirit/include/qi.hpp:16,
                 from C:/dev/svgpp/include/svgpp/parser/detail/common.hpp:10,
                 from C:/dev/svgpp/include/svgpp/parser/grammar/angle.hpp:11,
                 from C:/dev/svgpp/include/svgpp/parser/angle.hpp:14,
                 from C:/dev/svgpp/include/svgpp/parser/value_parser.hpp:10,
                 from C:/dev/svgpp/include/svgpp/attribute_dispatcher.hpp:19,
                 from C:/dev/svgpp/include/svgpp/document_traversal.hpp:11,
                 from C:\dev\svgpp\src\demo\render\svgpp_render.cpp:6:
C:/dev/i/include/boost-1_55/boost/fusion/container/list/convert.hpp:43:5: note: candidate: template<class Sequence> typename boost::fusion::result_of::as_list<Sequence>::type boost::fusion::as_list(Se
quence&)
     as_list(Sequence& seq)
     ^
C:/dev/i/include/boost-1_55/boost/fusion/container/list/convert.hpp:43:5: note:   template argument deduction/substitution failed:
C:/dev/i/include/boost-1_55/boost/fusion/container/list/convert.hpp:50:5: note: candidate: template<class Sequence> typename boost::fusion::result_of::as_list<const Sequence>::type boost::fusion::as_l
ist(const Sequence&)
     as_list(Sequence const& seq)
     ^
C:/dev/i/include/boost-1_55/boost/fusion/container/list/convert.hpp:50:5: note:   substitution of deduced template arguments resulted in errors seen above
demo\render\CMakeFiles\svgpp_agg_render.dir\build.make:162: recipe for target 'demo/render/CMakeFiles/svgpp_agg_render.dir/svgpp_render.cpp.obj' failed
mingw32-make[2]: *** [demo/render/CMakeFiles/svgpp_agg_render.dir/svgpp_render.cpp.obj] Error 1
CMakeFiles\Makefile2:88: recipe for target 'demo/render/CMakeFiles/svgpp_agg_render.dir/all' failed
mingw32-make[1]: *** [demo/render/CMakeFiles/svgpp_agg_render.dir/all] Error 2
Makefile:82: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
 
c:\dev\svgpp\src>

With Boost 1.61:

c:\dev\svgpp\src>mingw32-make
Scanning dependencies of target svgpp_agg_render
[ 1%] Building CXX object demo/render/CMakeFiles/svgpp_agg_render.dir/C_/dev/svgpp/third_party/agg/src/agg_curves.cpp.obj
[ 1%] Building CXX object demo/render/CMakeFiles/svgpp_agg_render.dir/C_/dev/svgpp/third_party/agg/src/agg_trans_affine.cpp.obj
[ 2%] Building CXX object demo/render/CMakeFiles/svgpp_agg_render.dir/C_/dev/svgpp/third_party/agg/src/agg_vcgen_dash.cpp.obj
[ 2%] Building CXX object demo/render/CMakeFiles/svgpp_agg_render.dir/C_/dev/svgpp/third_party/agg/src/agg_vcgen_stroke.cpp.obj
[ 2%] Building CXX object demo/render/CMakeFiles/svgpp_agg_render.dir/svgpp_render.cpp.obj
In file included from C:\dev\svgpp\src\demo\render\common.hpp:33:0,

from C:\dev\svgpp\src\demo\render\svgpp_render.cpp:4:

C:\dev\svgpp\src\demo\render\parser_rapidxml_ns.hpp:24:8: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]

std::auto_ptr<Impl> impl_;
     ^

In file included from C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/memory:81:0,

from C:\dev\svgpp\src\demo\render\parser_rapidxml_ns.hpp:6,
from C:\dev\svgpp\src\demo\render\common.hpp:33,
from C:\dev\svgpp\src\demo\render\svgpp_render.cpp:4:

C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/bits/unique_ptr.h:49:28: note: declared here

template<typename> class auto_ptr;
                         ^

In file included from C:/dev/i/include/boost/iostreams/detail/is_dereferenceable.hpp:12:0,

from C:/dev/i/include/boost/iostreams/detail/resolve.hpp:26,
from C:/dev/i/include/boost/iostreams/detail/push.hpp:24,
from C:/dev/i/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
from C:/dev/i/include/boost/iostreams/stream_buffer.hpp:22,
from C:/dev/i/include/boost/iostreams/stream.hpp:21,
from C:/dev/i/include/boost/spirit/home/qi/stream/detail/iterator_source.hpp:14,
from C:/dev/i/include/boost/spirit/home/qi/stream/stream.hpp:16,
from C:/dev/i/include/boost/spirit/home/qi/stream.hpp:15,
from C:/dev/i/include/boost/spirit/home/qi.hpp:30,
from C:/dev/i/include/boost/spirit/include/qi.hpp:16,
from C:/dev/svgpp/include/svgpp/parser/detail/common.hpp:10,
from C:/dev/svgpp/include/svgpp/parser/grammar/angle.hpp:11,
from C:/dev/svgpp/include/svgpp/parser/angle.hpp:14,
from C:/dev/svgpp/include/svgpp/parser/value_parser.hpp:10,
from C:/dev/svgpp/include/svgpp/attribute_dispatcher.hpp:19,
from C:/dev/svgpp/include/svgpp/document_traversal.hpp:11,
from C:\dev\svgpp\src\demo\render\svgpp_render.cpp:6:

C:/dev/i/include/boost/type_traits/detail/bool_trait_def.hpp:18:79: note: #pragma message: NOTE: Use of this header (bool_trait_def.hpp) is deprecated

1. pragma message("NOTE: Use of this header (bool_trait_def.hpp) is deprecated") ^

In file included from C:/dev/i/include/boost/type_traits/detail/bool_trait_def.hpp:21:0,

from C:/dev/i/include/boost/iostreams/detail/is_dereferenceable.hpp:12,
from C:/dev/i/include/boost/iostreams/detail/resolve.hpp:26,
from C:/dev/i/include/boost/iostreams/detail/push.hpp:24,
from C:/dev/i/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
from C:/dev/i/include/boost/iostreams/stream_buffer.hpp:22,
from C:/dev/i/include/boost/iostreams/stream.hpp:21,
from C:/dev/i/include/boost/spirit/home/qi/stream/detail/iterator_source.hpp:14,
from C:/dev/i/include/boost/spirit/home/qi/stream/stream.hpp:16,
from C:/dev/i/include/boost/spirit/home/qi/stream.hpp:15,
from C:/dev/i/include/boost/spirit/home/qi.hpp:30,
from C:/dev/i/include/boost/spirit/include/qi.hpp:16,
from C:/dev/svgpp/include/svgpp/parser/detail/common.hpp:10,
from C:/dev/svgpp/include/svgpp/parser/grammar/angle.hpp:11,
from C:/dev/svgpp/include/svgpp/parser/angle.hpp:14,
from C:/dev/svgpp/include/svgpp/parser/value_parser.hpp:10,
from C:/dev/svgpp/include/svgpp/attribute_dispatcher.hpp:19,
from C:/dev/svgpp/include/svgpp/document_traversal.hpp:11,
from C:\dev\svgpp\src\demo\render\svgpp_render.cpp:6:

C:/dev/i/include/boost/type_traits/detail/template_arity_spec.hpp:13:84: note: #pragma message: NOTE: Use of this header (template_arity_spec.hpp) is deprecated

1. pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated") ^

In file included from C:/dev/i/include/boost/iostreams/detail/is_dereferenceable.hpp:13:0,

from C:/dev/i/include/boost/iostreams/detail/resolve.hpp:26,
from C:/dev/i/include/boost/iostreams/detail/push.hpp:24,
from C:/dev/i/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
from C:/dev/i/include/boost/iostreams/stream_buffer.hpp:22,
from C:/dev/i/include/boost/iostreams/stream.hpp:21,
from C:/dev/i/include/boost/spirit/home/qi/stream/detail/iterator_source.hpp:14,
from C:/dev/i/include/boost/spirit/home/qi/stream/stream.hpp:16,
from C:/dev/i/include/boost/spirit/home/qi/stream.hpp:15,
from C:/dev/i/include/boost/spirit/home/qi.hpp:30,
from C:/dev/i/include/boost/spirit/include/qi.hpp:16,
from C:/dev/svgpp/include/svgpp/parser/detail/common.hpp:10,
from C:/dev/svgpp/include/svgpp/parser/grammar/angle.hpp:11,
from C:/dev/svgpp/include/svgpp/parser/angle.hpp:14,
from C:/dev/svgpp/include/svgpp/parser/value_parser.hpp:10,
from C:/dev/svgpp/include/svgpp/attribute_dispatcher.hpp:19,
from C:/dev/svgpp/include/svgpp/document_traversal.hpp:11,
from C:\dev\svgpp\src\demo\render\svgpp_render.cpp:6:

C:/dev/i/include/boost/type_traits/detail/template_arity_spec.hpp:13:84: note: #pragma message: NOTE: Use of this header (template_arity_spec.hpp) is deprecated

1. pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated") ^

C:\dev\svgpp\src\demo\render\svgpp_render.cpp:620:8: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]

std::auto_ptr<ImageBuffer> own_buffer_;
     ^

In file included from C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/memory:81:0,

from C:\dev\svgpp\src\demo\render\parser_rapidxml_ns.hpp:6,
from C:\dev\svgpp\src\demo\render\common.hpp:33,
from C:\dev\svgpp\src\demo\render\svgpp_render.cpp:4:

C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/bits/unique_ptr.h:49:28: note: declared here

template<typename> class auto_ptr;
                         ^

C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/as.exe: CMakeFiles\svgpp_agg_render.dir\svgpp_render.cpp.obj: too many sections (53345)
C:\Users\krita\AppData\Local\Temp\ccVgfpyF.s: Assembler messages:
C:\Users\krita\AppData\Local\Temp\ccVgfpyF.s: Fatal error: can't write CMakeFiles\svgpp_agg_render.dir\svgpp_render.cpp.obj: File too big
C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/as.exe: CMakeFiles\svgpp_agg_render.dir\svgpp_render.cpp.obj: too many sections (53345)
C:\Users\krita\AppData\Local\Temp\ccVgfpyF.s: Fatal error: can't close CMakeFiles\svgpp_agg_render.dir\svgpp_render.cpp.obj: File too big
demo\render\CMakeFiles\svgpp_agg_render.dir\build.make:162: recipe for target 'demo/render/CMakeFiles/svgpp_agg_render.dir/svgpp_render.cpp.obj' failed
mingw32-make[2]: * [demo/render/CMakeFiles/svgpp_agg_render.dir/svgpp_render.cpp.obj] Error 1
CMakeFiles\Makefile2:88: recipe for target 'demo/render/CMakeFiles/svgpp_agg_render.dir/all' failed
mingw32-make[1]: * [demo/render/CMakeFiles/svgpp_agg_render.dir/all] Error 2
Makefile:82: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

This is with svgpp's CMakeLists.txt patched to force c++11.

OSX builds (with g'mic-like speed), but it does give a load of warnings like:

[ 18%] Building CXX object samples/CMakeFiles/Sample01h.dir/sample01h.cpp.o
In file included from /Users/boud/src/svgpp/src/samples/sample01h.cpp:8:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/svgpp.hpp:1:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/document_traversal.hpp:11:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/attribute_dispatcher.hpp:19:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/value_parser.hpp:10:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/angle.hpp:14:
/Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/grammar/angle.hpp:48:33: warning: multiple unsequenced modifications to '_val' [-Wunsequenced]
                          [_val = phx::bind(&angle_grammar::call_make_angle<tag::angle_units::grad>, _a)]
                                ^
In file included from /Users/boud/src/svgpp/src/samples/sample01h.cpp:8:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/svgpp.hpp:1:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/document_traversal.hpp:11:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/attribute_dispatcher.hpp:19:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/value_parser.hpp:11:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/animation.hpp:13:
/Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/grammar/clock_value.hpp:103:39: warning: multiple unsequenced modifications to '_val' [-Wunsequenced]
            >>  (   lit('h')    [_val = phx::bind(&clock_value_grammar::create_hours, _a)]
                                      ^
In file included from /Users/boud/src/svgpp/src/samples/sample01h.cpp:8:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/svgpp.hpp:1:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/document_traversal.hpp:11:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/attribute_dispatcher.hpp:19:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/value_parser.hpp:12:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/color.hpp:15:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/external_function/parse_color_impl.hpp:12:
/Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/grammar/color.hpp:79:29: warning: multiple unsequenced modifications to '_val' [-Wunsequenced]
            >> ( hex3 [_val = phx::bind(&color_grammar::six_hex_digits, _a, _1)]
                            ^
In file included from /Users/boud/src/svgpp/src/samples/sample01h.cpp:8:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/svgpp.hpp:1:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/document_traversal.hpp:11:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/attribute_dispatcher.hpp:19:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/value_parser.hpp:14:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/length.hpp:18:
In file included from /Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/external_function/parse_length_impl.hpp:14:
/Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/grammar/length.hpp:106:29: warning: multiple unsequenced modifications to '_val' [-Wunsequenced]
                      [_val = phx::bind(&detail::length_units_symbols::create_length<LengthFactory, Number>, _r1, _a, _1)]
                            ^
/Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/grammar/length.hpp:151:31: warning: multiple unsequenced modifications to '_val' [-Wunsequenced]
                        [_val = phx::bind(&detail::length_units_symbols::create_length<LengthFactory, Number>, _r1, _a, _1)]
                              ^
/Users/boud/src/svgpp/src/samples/../../include/svgpp/parser/grammar/length.hpp:189:31: warning: multiple unsequenced modifications to '_val' [-Wunsequenced]
                        [_val = phx::bind(&detail::length_units_symbols::create_length<LengthFactory, Number>, _r1, _a, _1)]

Let's first discuss the GUI requirements! Does anybody have anything to add about GUI?

This area does seem very GUI/UIX heavy. I am assuming we are keeping all of the existing path editing operations...

Anchor Point conversions
to Corner Point
to Smooth Point
to Symmetric Point

Line conversions
Segment to Line
Segment to Curve
Make Line point
Make curve point

Combine operations
Break at Point
Break at Segment
Join with Segment
Merge Points

You can get to these when creating a vector object with multiple points (eg. multi-line tool). These options are in the tool options.

For the gradient, pattern, and filter tools -- Those seem like part of the fill or object options for a vector shape, not a separate tool. You can't just select the tool on the toolbox and start using it on the canvas. You NEED to have a vector object selected first for the tools to work.

I think because of this, it would be better to incorporate those options in the object properties docker. We call a tool "Shape Manipulation Tool", but it would probably be easier to understand for people if we end up calling it the "Selection Tool".

I don't know how many times I have seen people use the "Shape Manipulation Tool" and try to use it like the Move tool. One design idea would be to combine the move tool and the new "Selection Tool". If you are on a paint layer, the selection tool would move the layer content and do everything that that the move tool does.

If you are on a vector object, it will also move vector objects, but will also give you a bunch of options for editing and modifying the vector object.

We can get some more feedback, but I can start coming up with some wireframe ideas for all of this vector stuff.

@dkazakov, it seems that vector booleans were not something discussed at the sprint. Karbon has the code though, and it's extremely useful for vector editing. Maybe we should have it in scott's suggested selection tool? As that would be the one that can select multiple shapes?

With this design, I am thinking it will follow in close relation with the text tools since those are also vector. With the current text tool design direction, there is a new Object Properties Docker where all of the object editing can be done.

If you have one object selected, it will show the properties for the one vector object. If you have multiple vector objects selected, we need to figure out if we want to do bulk changes to both objects, or have other options that deal with multiple objects like boolean paths like @woltherav pointed out.

In T1005#57867, @woltherav wrote:

@dkazakov, it seems that vector booleans were not something discussed at the sprint. Karbon has the code though, and it's extremely useful for vector editing. Maybe we should have it in scott's suggested selection tool? As that would be the one that can select multiple shapes?

+1 for Booleans are important aspect in my opinion for example they are useful in creating various balloons

Is part of this work including the word bubble support, or is that going to be another ticket. I remember discussing that a fair amount at the sprint.

In T1005#57866, @scottpetrovic wrote:

Anchor Point conversions
...
Line conversions
...
Combine operations
Break at Point
Break at Segment
Join with Segment
Merge Points

The semantic of these actions fit quite nicely into the Tool Options of the "Path editing tool", which is basically an editing mode of the selection tool, see Selection Tool, chapter 1

> You can get to these when creating a vector object with multiple points (eg. multi-line tool). These options are in the tool options.

Are they in the Path/Polygon Tool or in Path Editing tool? They can be shared if needed.

For the gradient, pattern, and filter tools -- Those seem like part of the fill or object options for a vector shape, not a separate tool.

For gradient and pattern they are both: options and a tool. In the tool options you select the gradient preset and in the tool you drag the handles of the gradient to place it precisely over the shape. Of course, this can be somehow combined with the "editing mode" of the selection tool. Either always show these gradient handles when in editing mode (might be disturbing) or show them when some switch is active. Do you think it is sane to move editing of the gradient and pattern into the general editing tool?

You can't just select the tool on the toolbox and start using it on the canvas. You NEED to have a vector object selected first for the tools to work.

This is the first requirement of every tool: you can select shapes with it. But if we move the editing into a single tool, then yes, the extra tools can go.

I think because of this, it would be better to incorporate those options in the object properties docker. We call a tool "Shape Manipulation Tool", but it would probably be easier to understand for people if we end up calling it the "Selection Tool".

Speaking truly I don't really like the idea of introducing a separate docker for that (and for the text as well). At the moment we, basically, have two modes of the Selection tool: selection and editing. The two modes have two different Tool Options. In the basic mode you can modify basic properties like Fill, Stroke, Geometry and stuff. And in editing mode you modify shape-specific properties, like "Convert to curves", "Break at point", "Merge points" and etc. It fits quite nicely into the GUI design. The only reason for a separate docker I can guess is the size: it might be too big in comparison to the options of the usual brush tool so it might not fit into the usual position. But we can solve it somehow, like auto-detach...

I don't know how many times I have seen people use the "Shape Manipulation Tool" and try to use it like the Move tool. One design idea would be to combine the move tool and the new "Selection Tool". If you are on a paint layer, the selection tool would move the layer content and do everything that that the move tool does.
If you are on a vector object, it will also move vector objects, but will also give you a bunch of options for editing and modifying the vector object.

Yes, it would be a very good idea. But I would postpone it until after the Shapes refactoring. Better add it into Krita: Abyss

In T1005#57867, @woltherav wrote:

@dkazakov, it seems that vector booleans were not something discussed at the sprint. Karbon has the code though, and it's extremely useful for vector editing. Maybe we should have it in scott's suggested selection tool? As that would be the one that can select multiple shapes?

I added 'Undecided Questions' section into the requirements. We didn't talk about them and we need them, so it should be discussed. The code for combining path shapes is not that complicated, but it needs a good GUI. And we also need requirements for it. I'll add questions to the Questions section.

In T1005#57948, @scottpetrovic wrote:

With this design, I am thinking it will follow in close relation with the text tools since those are also vector. With the current text tool design direction, there is a new Object Properties Docker where all of the object editing can be done.
If you have one object selected, it will show the properties for the one vector object. If you have multiple vector objects selected, we need to figure out if we want to do bulk changes to both objects, or have other options that deal with multiple objects like boolean paths like @woltherav pointed out.

As I said I'm not yet convinced that one more docker is a good idea. I guess we should discuss it either on IRC or hangouts.

What you listed above fits nicely into the "Editing mode". The only possible trouble is the size.

For me, the main goal is not exactly where things go, but have the tools make sense and be as efficient and compact as possible. I am not really tied to any of the ideas I have shown so far.

@dkazakov - If I give you an inkscape file, could you move stuff around with how you are thinking? You seem to have some concerns about my designs, which tells me you probably have alternatives that we can use that might be easier. I can give you my vector tool file and text tool file. This might help with communicating what you are thinking. The problem I have with disregarding the text tool design right now is that is the only base design we have currently (which the vector stuff will be similar). Disregarding the text design direction means we will be back to nothing. We need a base design direction to iterate over and update.

Writing is ok, but seeing the wireframes can help facilitate discussion much better.

Vector Tools Design SVG file (can load this into Inkscape)

Text Tools Design SVG file (can load this into Inkscape)

I talked with Dmitry over IRC and finally have some mockups for this. The direction is changing a bit, but not too drastically Make any comments about the GUI here...

https://phabricator.kde.org/M76

I have moved the requirements from the comment to a Phriction document:

https://phabricator.kde.org/w/krita/vector_tool_requirements/

Note https://bugs.kde.org/show_bug.cgi?id=365712

Report about the works left for the vector tools

Mandatory part

1. Finish Gradiet Edit mode of the Vector Selection tool [1 day]
   • paint decorations in DefaultTool class, not in the strategies
   • activate only when Fill: Gradient tab is active
   • implement handles intersection avoidance by using smaller grabbing radius for the gradient handles
2. Stroke Fill [2-3 days]
   • adapt the fill widgets to be able to set stroke() instread of backround()
   • save/load gradients in strokes in SVG (we cannot do it atm)
   • save old gradient/fill when switching to another fill type, therefore accidental switching would not cancel all the configuration work
   • compress setStroke() and setBackground() commands
   • changing thickness of multiple shapes should not reset the color
3. Stroke Style [3.5-5.5 days]
   • save/load markers to SVG [2-3 days]
   • load angular dimensions from SVG
   • load marker templates from external files [0.25 day]
   • load dash templates from QInputWidget by entering a sequence of numbers [0.25 day]
   • test save/load line thickness (seems to be broken)
   • Polish GUI for markers, dashes and joins according to wireframes [1-2 days]
   • BUG: Round Join is not round in one corner of the rectangle
   • Auto fill markers with the shape's stroke color/gradient
4. Editing tool [6 days]
   • allow selection of objects
   • port handles painting code to KoHandlesPainterHelper [1 day]
   • embed object properties in the tool's docker [2 days]
   • Polish GUI according to wireframes [2 days]
   • Fix random bugs: 365712, (need more to the list!) [1 day]
5. Integrate selection and edit tools together [1 day]
   • switch to and from with Enter and Esc
   • double-clicking
   • rename the tools
   • remove gradient and patterns tools

6. Fix copy-paste

• Duplicate Layer is broken (uses ODF)
• Copy/Paste is broken (uses ODF)

Total: [13.5 - 16.5 days]

Probably, will be postponed till later

1. Boolean operations for shapes [1 day]
2. Predefined transformations for shapes (we need at least "reset transform" action) [0.25 day]
   1. Rotate CW/CCW 90deg
   2. Rotate 180deg
   3. Mirror H/V
   4. Reset all transformation
3. Snap to original point when doing operations with shapes: [0.5 day]
   • ShapeMoveStrategy
   • ShapeResizeStrategy
   • ShapeShearStrategy
   • ShapeRotateStrategy
   • KoPathSegmentChangeStrategy
   • KoPathPointMoveStrategy
   • KoPathControlPointMoveStrategy
   • KoParameterChangeStrategy
4. Enter group mode [min 3 days]. A special mode that allows the user to work with objects within a group without ungrouping it. Also needed for editing the patterns.
5. Patterns editing [min 3 days]
   1. Implement a selection docker tab for modifying the main properties of the pattern, like reference point and repeat strategy.
   2. Implement on-canvas editing of the reference point of the pattern (no pattern transformations, they are hardly supported by any software!)
   3. Implement a context menu action for adding shapes as a pattern to other shapes.
   4. Use Enter Group mode for editing the pattern content
6. Filters [min 5 days]
   1. Implement Saving, Loading and rendering of SVG filters
   2. Implement a Selection Tool tab for editing the filters attached to the current shape (just pure loading from xml files without real editing)
7. Different "pinning" modes for the gradients and patterns: 1) [implemented] pin control points; 2) pin entire gradient (the gradient transforms with the shape); 3) don't pin (gradient is pinned to the image and not changed when the shape is transformed).
8. 'Inherit' option for Fill and Stroke properties [2 day]
9. Styles [min 5 day]
10. "Global Mode" checkbox should affect the mouse-based shape transformations (not it affects geometry box only) [0.5 day]

Regarding the SVG filters, I made a lowdown over here: T3577

Checked every filter primitive against the spec and stuff.

It might be an idea to move the maybe later stuff as separate tasks into the abyss with some notes of the things it touches while all that information is still fresh in our brains. that way a specific task might be picked up more easily in the future.

@dkazakov - your breakdown of tasks is pretty good I think. In terms of the "Probably, will be postponed till later", I think the boolean operations are probably the most important aspect of that part. I would bump that to #1 for the probably list if time permits.

For the polish GUI work...
I would lower the priority of all GUI polish work. We might have to do other GUI tweaks as people start using it more. I am not sure exactly what 'polish' means with that work, so maybe it is something I won't be able to do. I can certainly try to help with some of the GUI polish as the functionality starts taking shape.

I think he means things like the color button being duplicated in the stroke widget. That type of stuff is small, but it's also numerous and needs some time planned in for it, otherwise it'd be forgotten :)

One doubt I had is - Are we going to provide the menu items for the vector layer operations. currently when you select an object you get certain commands such as bring to front, group & ungroup etc. these commands have shortcuts and are in right click context menu, but is this enough ? there may be more operations in future like make cliping mask, add pattern, boolean operations, align and arrange etc. how are we going to provide these other than showing those in tool options and right click menu?

Loading https://www.dropbox.com/s/ppww79ojv29urtg/hylti_p01_0006.kra?dl=0 gives weird results; see the folio image. Left is 3.x, right is master.

Moving a rectangle around leaves indelible artefacts, probably the bounding box is wrong?

Creating a rectangle without an outline gives a black outline top and left; the rectangle itself seems pinkish, even though the selected background color is white.

Here's the vector-patterns file. It's a work in progress, so indeed, only the first 14 patterns are visible here.