2014-03-11 16:31 GMT+01:00 Tomasz Boczkowski <penginsbacon@...400...>:

Thank you for your comments. I have to change my design a bit.

...

4. What is the purpose of the "transform" button? The pattern

transform is specified on the object, not on the pattern, and is already editable on the canvas. This looks like a mistake.

I tried to fix the bug #210442 in my solution. The transform button can be replaced by scale/rotation entries.

I think the transform should be editable in the Fill & Stroke dialog only. It should not appear in the Swatches/Paints dialog since the transform is an attribute of the object, not of the pattern.

...

How would this "new object" be represented at the XML level?

I thought about representing them as svg:g elements with inkscape:type = "patternEdit" attribute. It is similar to the way layers are represented.

...

5. I think it would be more sensible to embed the pattern preview and

chooser into the existing fill and stroke dialog.

...

The proposal looks sensible. If you don't have too much experience with the Inkscape codebase, I think you could limit the proposal to providing the pattern preview in the fill and stroke dialog

I don't have much experience with Inkscape codebase yet. I can resign from implementing pattern edition tool. I have created a new mockup illustrating modified Fill and Stroke dialog [1]. Solution 1 consists in embedding the pattern browser inside combo-box popup. Gtk+ seems to be flexible enough to allow such changes [2]. The main advantage of this solution is providing the pattern browser with more screen space to display pattern icons.

Selection from a combo box is not very nice when you have lots of items, for instance selecting markers is a pain. I like solution #2 better.

I would implement the browser widget in a way that allows future handling different paint servers: solid colors/hatches/gradient. Implementing "paints" or new "swatches" dialog around it seems feasible. This somehow extends the named color swatches blueprint [3]. I can make it an optional goal.

What do you think about this?

This slightly reduced project looks very sensible to me. With some guidance I think you have pretty good chances of being accepted and succeeding.

...

and converting a few things to C++ along the way.

I see there is some C-like code left in sp-pattern.h/.cpp. What else could I focus on in my project?

There are several classes used in the fill and stroke dialog which you could convert to C++ or improve, for example SPColorSelector and its derived classes. They are C++ classes, but they are hidden as members inside GObjects, which is confusing to novices and leads to verbose code. You could convert them to proper C++ classes that derive from the relevant gtkmm widgets.

Regards Tomasz

[1] https://www.dropbox.com/s/kvgjvtowpm55m5h/new_patterns_ui_2.svg [2] http://tirania.org/pictures/hwidgets/gtk-combo-tree.jpg, http://tirania.org/blog/archive/2008/Jun-01.html [3] https://blueprints.launchpad.net/inkscape/+spec/named-color-swatches

PS

Your message was sent directly to me, omitting the mailing list.

Oops, my bad.

Regards, Krzysztof