Thoughts about Patterns
Hi everybody,
Working on the Edit Menu part of the Manual (done but in french only, english version on CVS before end of July), i've made different tests on clone and patterns. These are great functionnalities.
One may find pattern samples in the joined file. May be it could be incorporated as a library (the same way markers did). I leave it to our great developers.
But, if alloweded, some things appeared to be difficult for me : - first of all : when creating many patterns, it is hard to remember the creation order, so that i've been 'confused' in the fillsettings dialog. Because there is no preview of the pattern in the dropdown menu, one may wish to name the pattern without using XML editor (some don't like coding!! or don't understand SVG at all) : may be the best could be to make a dialog appear to enter a name just after using the Edit/tile command. - second : The original object is set to rect filled with the pattern. It is OK, but often, i don't need it anymore in the drawing. It could be hidden. - third : (and it is not due to pattern filling i think but) but when a pattern is not used anymore, it is automatically cleared from defs. But should I always really want to remove it ? The autoClean functionnality is very good, but we may find rules about its use.
I will now be working on a Symbol (clone) Library. I'll see from Sodipodi, I guess they've done may things this way since few months.
Thanks a lot. Cedric
- first of all : when creating many patterns, it is hard to remember the
creation order, so that i've been 'confused' in the fillsettings dialog. Because there is no preview of the pattern in the dropdown menu, one may wish to name the pattern without using XML editor (some don't like coding!! or don't understand SVG at all) : may be the best could be to make a dialog appear to enter a name just after using the Edit/tile command.
Sure, the patterns menu needs previews, similar to those in marker menus. Sometime we'll switch both from menus to table-like scrollable widgets with previews.
- second : The original object is set to rect filled with the pattern.
It is OK, but often, i don't need it anymore in the drawing. It could be hidden.
Just hit Del :)
- third : (and it is not due to pattern filling i think but) but when a
pattern is not used anymore, it is automatically cleared from defs. But should I always really want to remove it ? The autoClean functionnality is very good, but we may find rules about its use.
User-created patterns are not deleted automatically anymore (this was fixed shortly before 0.39).
On Mon, 2004-07-19 at 03:27, bulia byak wrote:
User-created patterns are not deleted automatically anymore (this was fixed shortly before 0.39).
Having thought about this a while, I think the rules for orphan collection should be:
inkscape:collect="always" - reap the object as soon as it is orphaned; this should only be used for objects that the user never sees directly (e.g. chained gradients which do not show up in the gradient list)
inkscape:collect="manual" - reap the object if it is orphaned and the user explicitly invokes "discard unused" command (bulia can probably think of a better name); this should get used for inkscape-created objects which do not appear directly on the canvas
inkscape:collect="with-parent" - the default if unspecified; the object is only reaped if its parent gets reaped -- if the user wants to get rid of it, they can delete it using the XML editor, or the "delete" action in whatever specialized dialogs the object appears in
Sound sensible, bulia?
-mental
inkscape:collect="always" - reap the object as soon as it is orphaned; this should only be used for objects that the user never sees directly (e.g. chained gradients which do not show up in the gradient list)
Yes, same as now
inkscape:collect="manual" - reap the object if it is orphaned and the user explicitly invokes "discard unused" command (bulia can probably think of a better name); this should get used for inkscape-created objects which do not appear directly on the canvas
inkscape:collect="with-parent" - the default if unspecified; the object is only reaped if its parent gets reaped -- if the user wants to get rid of it, they can delete it using the XML editor, or the "delete" action in whatever specialized dialogs the object appears in
Why do we need these? We can simply designate a list of element types which belong to "manual" (e.g. marker, gradient etc), otherwise consider them "with-parent". This way no extra attributes will be necessary.
participants (3)
-
bulia byak -
cedric -
MenTaLguY