Clip path and mask UI patch - need guidance
Knutux has made excellent progress with the clipPath/Mask UI patch (nice couple options in prefs to make it more robust too). However, there are two issues left that are related, but we couldn't figure out the best solution.
Note that this is in comparison to both Xara & Illustrator as reference.
1) In Inkscape, currently you can not edit a clippath on canvas (presumably because it's located in defs). I wouldn't imagine this wouldn't be too painful to change, but the aspect of residing in defs brings up the other major difference/problem.
2) In Xara or Illustrator when you clip objects, they're "grouped" together (clipped objects and the clipping path/mask). It doesn't seem like this is easily achieved because of the structure of SVG and defs preceding regular items in the doc.
The more complicated of the two issues would be number 2. We kicked around a couple ideas, but neither seemed like the optimal solution so I figure I would ask for advice here.
The ideas were having the clipping object in defs be a clone of a "normal" object on canvas. That original object can then be grouped and the clone/clippath would follow a move of the original, and it would theoretically also take care of the editing aspect too.
And the other potential solution we thought of was having the clipPath (or mask) in defs just have a link to an object on canvas. Again, that object could then be grouped and would take care of the editing aspect too.
To me, neither method seems clean and each would potentially introduce it's own set of issues.
Bulia or Mental, do you have any suggestions?
-Josh
I think you should be able to create something like:
<g clip-path="#clipPath123"> <clipPath id="clipPath123"> ... the clipping object(s) ... </clipPath> ... the clipped objects ... </g>
There's no law that things like gradients and clipPaths have to go in <defs>, it's just a convention.
Since clipPath elements aren't part of the rendering tree in the SVG rendering model, there shouldn't be any actual circularity here (though I can't promise that Inkscape's renderer handles them entirely correctly in that regard).
Anyway, try playing with that in Inkscape and Batik to see how it works for you.
-mental
On 3/17/06, Joshua A. Andler <joshua@...533...> wrote:
- In Inkscape, currently you can not edit a clippath on canvas
(presumably because it's located in defs). I wouldn't imagine this wouldn't be too painful to change, but the aspect of residing in defs brings up the other major difference/problem.
OK, suppose you have a clipped object and you want to edit the clippath. What's wrong with this: you unclip ("release") it so that the clippath becomes a regular path, edit it, and then clip back? I always thought that's the way you do it in AI (but I may be wrong on this, as I never used clipping much anywhere).
- In Xara or Illustrator when you clip objects, they're "grouped"
together (clipped objects and the clipping path/mask). It doesn't seem like this is easily achieved because of the structure of SVG and defs preceding regular items in the doc.
What do you mean by "grouping"? Why would you, as a user, care about document structure at all? What you need is the correct behavior, not structure. Most importantly, the clippath must be transformed together with the clipped object. This is already true for some kinds of objects (eg ellipses) and I know how to make it true for all objects. And this is doable regardless of whether the clippath is in defs or not.
So, unless I'm missing something, I don't see any need for moving clippaths out of defs as Mental suggested.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 3/17/06, Joshua A. Andler <joshua@...533...> wrote:
- In Inkscape, currently you can not edit a clippath on canvas
(presumably because it's located in defs). I wouldn't imagine this wouldn't be too painful to change, but the aspect of residing in defs brings up the other major difference/problem.
OK, suppose you have a clipped object and you want to edit the clippath. What's wrong with this: you unclip ("release") it so that the clippath becomes a regular path, edit it, and then clip back? I always thought that's the way you do it in AI (but I may be wrong on this, as I never used clipping much anywhere).
In AI, if you clip an object and use the (black) selection tool, it moves the entire "group". If you use the (white) direct selection tool, you can manipulate the clippath (or clipped objects) while the clip is still applied.
In Xara, if you clip an object and use the selector tool, it will move the entire "group". If you ctrl+click using the selector tool, you can manipulate the clippath (or clipped objects) while the clip is still applied.
From what I recall of Freehand, which I haven't used in a few years, you could also live edit clipped objects and the clipping paths but by normal selection the acted as "groups".
With good UI, if I need to make 20 tweaks to a clippath (or it could be 2 tweaks to 10 clippaths), I shouldn't have to visit the menus 40 times to do it. A ctrl+click like Xara saves the menu trips and is faster, more user-friendly, and I never have to leave the canvas.
For note, I do use clippaths quite a bit in my work.
- In Xara or Illustrator when you clip objects, they're "grouped"
together (clipped objects and the clipping path/mask). It doesn't seem like this is easily achieved because of the structure of SVG and defs preceding regular items in the doc.
What do you mean by "grouping"? Why would you, as a user, care about document structure at all? What you need is the correct behavior, not structure. Most importantly, the clippath must be transformed together with the clipped object. This is already true for some kinds of objects (eg ellipses) and I know how to make it true for all objects. And this is doable regardless of whether the clippath is in defs or not.
The way that I'm talking about grouping is the behavior, not necesarilly a document structured group (but I would imagine it is, but just a special type). You're right, what I do need is the correct behavior. From the way it seems, if anyone that uses masks or clippaths in other vector software comes to Inkscape, they'll be confused by lack of ease with editing. Please try to clip some objects and manipulate them in both Xara & AI with my instructions above, and the "grouping" I talk about will probably make more sense to you then.
So, unless I'm missing something, I don't see any need for moving clippaths out of defs as Mental suggested.
I would personally prefer not moving them out of defs as well, but if it's the best solution, then it is what it is. And even though we both prefer to keep clippaths and masks in defs, I feel the need to repeat your own question and following statement back to you. "Why would you, as a user, care about document structure at all? What you need is the correct behavior, not structure." And it seems like to get the correct behavior, we may have to not use the "best practice" of having it in defs and modify our structure... unless you have any other suggestions.
-Josh
On 3/17/06, Joshua A. Andler <joshua@...533...> wrote:
In AI, if you clip an object and use the (black) selection tool, it moves the entire "group". If you use the (white) direct selection tool, you can manipulate the clippath (or clipped objects) while the clip is still applied.
In Xara, if you clip an object and use the selector tool, it will move the entire "group". If you ctrl+click using the selector tool, you can manipulate the clippath (or clipped objects) while the clip is still applied.
OK, so these apps allow you to edit clippath without unclipping. That's good, and eventually we'll need to do this as well. However my point is that:
- even without it, clipping is quite usable if you have reliable clip and unclip commands;
- implementing editing clippath without unclipping would not be made any easier or more difficult by placing it in defs or not. Even when not in defs, clippath is still a special invisible object, and you still need special code to enable editing it as a regular path. It'll take work no matter which way you go.
The way that I'm talking about grouping is the behavior, not necesarilly a document structured group (but I would imagine it is, but just a special type). You're right, what I do need is the correct behavior. From the way it seems, if anyone that uses masks or clippaths in other vector software comes to Inkscape, they'll be confused by lack of ease with editing. Please try to clip some objects and manipulate them in both Xara & AI with my instructions above, and the "grouping" I talk about will probably make more sense to you then.
Please be more specific. I have already explained the situation with transforming clipped objects, and with editing clippath without unclipping (both are doable but need work). What else do you need to get the desired "grouped" behavior?
I would personally prefer not moving them out of defs as well, but if it's the best solution, then it is what it is. And even though we both prefer to keep clippaths and masks in defs, I feel the need to repeat your own question and following statement back to you. "Why would you, as a user, care about document structure at all? What you need is the correct behavior, not structure."
Because I am not a user, so I care about structure. I think that keeping them in defs would be much easier overall, because we have a lot of legacy code that assumes that everything is in defs.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Fri, 17 Mar 2006 18:44:42 -0400, "bulia byak" <buliabyak@...400...> wrote:
Most importantly, the clippath must be transformed together with the clipped object. This is already true for some kinds of objects (eg ellipses) and I know how to make it true for all objects. And this is doable regardless of whether the clippath is in defs or not.
If the clipPath and the clipped objects share a parent group, then you get "compensation" for free. Unlike gradients, I don't see a strong case for re-using clipPaths either (another usual motivation for putting things in <defs>).
Keeping the clipPath with the clipped objects seems to be the simplest approach...
-mental
On 3/17/06, MenTaLguY <mental@...3...> wrote:
If the clipPath and the clipped objects share a parent group, then you get "compensation" for free.
Not entirely for free, and in any case no more free than when they are elsewhere. Here's the scoop: The spec says that any transform= on clipped object affects the clippath as well, and we implement this. Therefore, for objects that always get transform= such as groups or ellipses, you get transforming the clippath truly for free, and this does not depend on where is the clippath - in defs or in group. It works the same both ways. However for objects that completely or partially embed the transformation, we will need to either (a) disable that and write transform= if there's a clippath or mask, or (b) add transform= to the clippath/mask corresponding to the embedded portion of the transform. Both approaches are relatively easy to do. Your approach (always putting clippend object(s) in group with clippath there too) is just another way of doing the (a) - you just disable embedding transforms into the object by virtue of its always being the group. However for that you have to pay the price of an unavoidable extra level of <g> and the dangers associated with resources-not-in-defs which our legacy code is known to mishandle often.
Unlike gradients, I don't see a strong case for re-using clipPaths either (another usual motivation for putting things in <defs>).
Sure, I don't want them to be shared either. It's not about sharing or not sharing.
Keeping the clipPath with the clipped objects seems to be the simplest approach...
I don't think so, see above. Besides, if you rely on your clippaths always inside groups and thus do not implement (a) or (b) above, you will damage your ability to gracefully handle non-Inkscape SVGs.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
# from Joshua A. Andler # on Friday 17 March 2006 01:29 pm:
And the other potential solution we thought of was having the clipPath (or mask) in defs just have a link to an object on canvas.
This thread seems to be mostly about clipping, but I would like to visit an issue about masks.
The XAR transparency object is totally separate from the fill. Rather than the RGBA, the fill only describes color (albeit in CMYK, RGB, etc) and the transparency object can describe flat or gradient (linear, elliptical, radial, etc) transparency. This allows you to have e.g. a vertical linear transparency over a horizontal linear gradient.
The only way that I have found to express this in SVG is with a mask, but ideally I would like to be able to link the mask entities to the entities on the canvas. I have found that I can accomplish this by referencing (use) them both to an entity in the defs section, but that disables editing in inkscape's canvas. All other forms seem to lead to circular linkage. Suggestions?
http://scratchcomputing.com/tmp/mask_linked.svg
Maybe some mode of editing entities in the defs section? Possibly in a separate canvas or just as ghosted (dotted?) shapes on the main canvas?
--Eric
On 3/19/06, Eric Wilhelm <scratchcomputing@...400...> wrote:
This thread seems to be mostly about clipping, but I would like to visit an issue about masks.
Everything said here applies both to clips and masks. Both are implemented internally already, and both are now on the verge of getting some simple UI.
Maybe some mode of editing entities in the defs section? Possibly in a separate canvas or just as ghosted (dotted?) shapes on the main canvas?
As I proposed, at this first stage we will have clippaths/masks in defs and not editable except by temporarily unclipping/unmasking, editing, and then clipping/masking back. Later we'll look into making them editable while in defs, possibly by making them partially visible by "ghosting" or something similar.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
# from bulia byak # on Sunday 19 March 2006 10:42 am:
Everything said here applies both to clips and masks.
except that there is no need to link to the entities which are being clipped...
Maybe some mode of editing entities in the defs section? Possibly in a separate canvas or just as ghosted (dotted?) shapes on the main canvas?
As I proposed, at this first stage we will have clippaths/masks in defs and not editable except by temporarily unclipping/unmasking, editing, and then clipping/masking back.
If I understand this correctly, the plan is to (conceptually or actually) move them out of defs for a bit and onto the canvas proper?
How would that work with an entity and mask which are both "use"ing a path from the defs section? How would a user select one as the mask for the other when they are identical?
This is at least somewhat distinct from clipping in that a mask which is defined by a shape which is identical to thing which it masks is difficult to deal with when it is unmasked. Of course, I am only talking about a very specific (mis?)use of masks here. There might be a better approach to getting around the lack of transparency/fill separation in SVG, but I haven't seen it. If I do use a mask to represent this, I would like to know what is the best way to make it editable.
--Eric
On 3/19/06, Eric Wilhelm <scratchcomputing@...400...> wrote:
# from bulia byak # on Sunday 19 March 2006 10:42 am:
Everything said here applies both to clips and masks.
except that there is no need to link to the entities which are being clipped...
No, there's no difference at all except that one uses <clipPath> and the other <mask>. Other than that, they will behave the same. (But rendered differently of course.)
If I understand this correctly, the plan is to (conceptually or actually) move them out of defs for a bit and onto the canvas proper?
Not at this stage, as I explained many times here. You can move them back out of defs if you unclip or unmask, thus removing the clip or mask. Then you can clip/mask the same objects with the same but edited clippath/mask again.
How would that work with an entity and mask which are both "use"ing a path from the defs section?
No, it's the other way round. It was proposed that a clippath/mask in defs are clones of an object on canvas. But I'm not in favor of that.
This is at least somewhat distinct from clipping in that a mask which is defined by a shape which is identical to thing which it masks is difficult to deal with when it is unmasked.
I'm not sure I understand this. Anyway, this is so far a very abstract discussion - what if you just wait until we commit the patch we have, and then we can resume this discission on a more concrete material?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
After the patch with clipping masks/paths was applied, I'm figuring out how to solve an issue with tranforms on masks. The problem is: *If any object to which a mask is applied is transformed already, mask is placed on wrong place *If masked object is moved, unmasking places mask object in wrong place
First solution that comes in mind - for first issue take a transformation of masked item, invert it and apply to a mask item (the ones which is moved to defs), for second issue - take transform of masked item and apply it to masked item which is moved back from defs.
But that does not solve same issue for multiple items which are masked/unmasked. So, quickest solution I see - if mask is beeing applied to multiple items, make an ordinary group and apply mask to it. That still does not solve an issue with unmasking multiple items whick mask was set manually or externally - for those we can just say, that unmask transform is calculated by the last item which mask is removed.
So, if there are no objections, I will implement that behavior.
Andrius
On Mon, 20 Mar 2006 14:45:53 +0200, "Andrius Ramanauskas" <knutux@...400...> wrote:
First solution that comes in mind - for first issue take a transformation of masked item, invert it and apply to a mask item (the ones which is moved to defs),
You may want to work with bulia to ensure that you don't duplicate code -- he's already written quite a bit of "compensation" code for other object types (e.g. gradients), so there may be some things there you can reuse or refactor into reusable form for this too.
-mental
On 3/20/06, Andrius Ramanauskas <knutux@...400...> wrote:
After the patch with clipping masks/paths was applied, I'm figuring out how to solve an issue with tranforms on masks. The problem is: *If any object to which a mask is applied is transformed already, mask is placed on wrong place *If masked object is moved, unmasking places mask object in wrong place
First solution that comes in mind - for first issue take a transformation of masked item, invert it and apply to a mask item (the ones which is moved to defs)
Yes, this might work. Please test it and commit if it works.
, for second issue - take transform of masked item and apply it to masked item which is moved back from defs.
Yes, this is what I had proposed for that problem.
But that does not solve same issue for multiple items which are masked/unmasked. So, quickest solution I see - if mask is beeing applied to multiple items, make an ordinary group and apply mask to it.
I think there's a better solution. If a user wants a group masked, he can always group it himself before clipping. Instead, I propose this: when you mask several objects by one common mask, just create a separate mask for each object being masked, i.e. copy the clippath/mask as many times to the defs as necessary. This will prevent sharing the clippath/mask among objects, which will likely have many issues. If you really need several objects with one shared mask, group them yourself.
Correspondingly, when you unmask/unclip, right now it checks whether the same mask is used by other objects, and if it's not, it's moved from defs to the canvas. Instead, I think it should _always_ create a copy of the clippath/mask object for _each_ unmasked object, and then delete those masks in defs that are not used anymore. So, if you unmask several masked objects, you get the corresponding number of mask objects - which may or may not coincide, depending on whether the objects have aquired different transforms since being clipped/masked.
I think this will resolve it in the most logical and flexible way. What do others think?
Here are a couple more things to do:
- When ungrouping a clipped/masked group, copy the clippath/mask once for each ungrouped object and apply, so that the objects remain clipped as they were before
- When converting anything to path, carry over the clippath/mask attributes
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 3/20/06, Andrius Ramanauskas <knutux@...400...> wrote:
But that does not solve same issue for multiple items which are masked/unmasked. So, quickest solution I see - if mask is beeing applied to multiple items, make an ordinary group and apply mask to it.
I think there's a better solution. If a user wants a group masked, he can always group it himself before clipping. Instead, I propose this: when you mask several objects by one common mask, just create a separate mask for each object being masked, i.e. copy the clippath/mask as many times to the defs as necessary. This will prevent sharing the clippath/mask among objects, which will likely have many issues. If you really need several objects with one shared mask, group them yourself.
Before I really begin, let me comment that masks and clippaths are things that I use in a significant portion of my work. Let me also say sorry before-hand if I misinterpret things and kinda go off on a tangent about it.
I think that reusing masks and clippaths is smarter than the duplicating that you speak of. I'll go into that further below...
One thing has become apparent though, you seem to be against the "auto-grouping" that other apps do. Why is that? It just doesn't make sense to me for you to have such a strong opinion considering you said you don't even use the feature that often. You obviously didn't use it enough to know that either Xara or AI could edit both clipped objects and their clipping paths while the clip is still applied. I can tell you that I now use clipPaths in 90% of my illustration work and roughly 50% of my design work (100% if you want to include our monogram that is clipped and used on all marketing materials). Honestly, the auto-group that the other programs do makes sense, especially with illustration. From my perspective, when you are clipping multiple objects it's generally because you want the result to be a new "entity".
I'll use my common illustration example to try and explain. If I am drawing a leg, and I have a bunch of objects on top of it that are layered for highlights and shading, when I clip or mask all of these, it's because I want the whole thing to be treated as one object (with restricted view). When I clip it... that's now the leg. If I move said leg, all highlights and shadows need to transform with the leg. It's not too far out there to ask considering AI, Xara, Freehand & Flash do it (and I bet Corel Draw and other programs do as well).
I am starting to think that we're going to need a separate page in Inkscape's Preferences for all of the Clipping & Masking options because the way you want to use them is probably not the way most other people will. Most people coming from other software will expect the auto-grouping and probably other things which we haven't thought of or run across.
Correspondingly, when you unmask/unclip, right now it checks whether the same mask is used by other objects, and if it's not, it's moved from defs to the canvas. Instead, I think it should _always_ create a copy of the clippath/mask object for _each_ unmasked object, and then delete those masks in defs that are not used anymore. So, if you unmask several masked objects, you get the corresponding number of mask objects - which may or may not coincide, depending on whether the objects have aquired different transforms since being clipped/masked.
If I'm understanding correctly, this is a bad solution. I do complex work, often with thousands of objects. I'm planning on going back to re-do effects on Gaze and a number of other pics down the line and I have some pretty wild ideas about how I want to do it. One of them involves masking sections of hair... there are THOUSANDS of strands of hair. This will murder my file to have thousands of masks in defs, inkscape will crawl handling said file, and then what if I want to re-mask a section? Have hundreds to thousands of masks show up on canvas on an unmask? This just sounds like it will be a usability nightmare. And no... pre-grouping sections shouldn't be necessary to avoid it as it isn't with other programs.
Additionally, Andrius had talked about having a dialog that will allow you to apply existing clippaths and masks to other objects, groups, or layers... this will then be impossible. I for one look forward to being able to mask or clip an entire layer easily... or another group, or object or whatever. I also look forward to having the ability to add or remove items to/from clipping and masking objects via the dialog as well (adding additional paths or masks to make compound paths/masks for example).
I think this will resolve it in the most logical and flexible way. What do others think?
I don't have an alternative solution, but it doesn't seem like the most logical or flexible way. It seems like it will be painful performance and filesize wise if people have complex documents.
Here are a couple more things to do:
- When ungrouping a clipped/masked group, copy the clippath/mask once
for each ungrouped object and apply, so that the objects remain clipped as they were before
Am I wrong in thinking that this will exponentially increase filesize and as a result hurt Inkscape performance with really complex documents?
- When converting anything to path, carry over the clippath/mask attributes
This makes sense.
Again, sorry if I am mistaken or misunderstand things.
-Josh
On 3/20/06, Joshua A. Andler <joshua@...533...> wrote:
One thing has become apparent though, you seem to be against the "auto-grouping" that other apps do. Why is that?
I'm against auto-anything if it does not really do anything which I can't do myself just as easily.
It's simple: there are 2 possible configurations:
(a) 10 objects grouped, group clipped
(b) 10 objects independent, each clipped separately
You seem to propose that applying clipping to several objects should automatically give (a). But note that I can still go from (a) to (b) simply by ungrouping. So if I need (b) I will have to undo something that was done automatically for me. In other words, both your and mine ways allow both (a) and (b), but in my approach, to get extra functionality (grouping), you need to do an extra step (group before clipping), whereas in your approach, to get more simple functionality (no group), you have to do the extra step of ungrouping. That's why I'm saying that my approach is more logical. However I do not insist on it, and if several people will assert that they use (a) much more often than (b), I will not object to autogrouping. It's not really a big issue.
I'll use my common illustration example to try and explain. If I am drawing a leg, and I have a bunch of objects on top of it that are layered for highlights and shading, when I clip or mask all of these, it's because I want the whole thing to be treated as one object (with restricted view). When I clip it... that's now the leg. If I move said leg, all highlights and shadows need to transform with the leg.
I really don't see why you had no need to treat these objects as a whole _before_ clipping and thus didn't group them _yourself_. This is what I would have done first thing, right at the start, and then would add new highlights and edit them while being _inside_ that group. Then when I need to move them all as a whole, or to clip them all, I would ascend to the parent layer and do this on the group as a whole. Compared to your scenario, this would save me a lot of trouble in not having to painstakingly select all those scattered highlights each time I need to treat them as a leg.
If I'm understanding correctly, this is a bad solution. I do complex work, often with thousands of objects. I'm planning on going back to re-do effects on Gaze and a number of other pics down the line and I have some pretty wild ideas about how I want to do it. One of them involves masking sections of hair... there are THOUSANDS of strands of hair. This will murder my file to have thousands of masks in defs,
Of course not. If all your hair needs to be precisely trimmed by the same shape, I am NOT proposing that you should clip or unclip each strand separately. OF COURSE you should group them all and clip the group. And unless you manually ungroup the clipped group, you will always have one clipping path applied to the single object (group).
However I can very well imagine that I may want to introduce some untidiness into the hair: first trim it but then move the clipped strands around, so that some of them stick out farther than others. Again, it's no big issue: with your autogrouping, I will just have to ungroup the group, and then I have the separate clipped strands that I can move around. But it just seems so much more logical to me that when I clip separate objects, I get separate clipped objects. When I clip a group, I get a clipped group. What's wrong with that?!
As for performance of 1000 strands having 1000 separate clippaths: first, as I just explained, I don't force this on you in any way (unless you want to have untidy hair, in which case it's unavoidable); and second, please don't panic until you have really tested it. My intuition says that a performance hit will be quite small.
Additionally, Andrius had talked about having a dialog that will allow you to apply existing clippaths and masks to other objects, groups, or layers... this will then be impossible.
I'm against actually sharing clippaths/masks among different objects, for architectural reasons. If you want 2 or more objects to use the same clippath, again, just group them and clip the group, or put them all in the clipped layer.
I for one look forward to being able to mask or clip an entire layer easily...
No problem with that either way.
I also look forward to having the ability to add or remove items to/from clipping and masking objects via the dialog as well (adding additional paths or masks to make compound paths/masks for example).
Why dialog? Just unclip temporarily, add to your clippath, and clip back. However, no problem adding a special command for the same, for example Object > Clip > Add to clipping path.
- When ungrouping a clipped/masked group, copy the clippath/mask once
for each ungrouped object and apply, so that the objects remain clipped as they were before
Am I wrong in thinking that this will exponentially increase filesize and as a result hurt Inkscape performance with really complex documents?
If by "exponentially" you mean what this word _really_ means, then of course no. It will increase size and probably somewhat affect the performance, but not by much. I don't think the change in performance will be even measurable in 1000 objects using 1 mask vs. 1000 objects using 1000 masks. On the other hand, sharing one mask among several non-grouped objects is sure to have a lot of hidden issues and extra code to guard against surprises.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
On 3/20/06, Joshua A. Andler <joshua@...533...> wrote:
One thing has become apparent though, you seem to be against the "auto-grouping" that other apps do. Why is that?
I'm against auto-anything if it does not really do anything which I can't do myself just as easily.
Fair enough.
I definitely understand what you're saying, and can agree that grouping is not too painful. What I needed to communicate in the last email was with the mentioned grouping... clipping "groups" are not quite like regular groups, they have special editing properties. Let me save a whole lot of correspondence by asking a question. Will it be possible to move objects around inside (and out) of the clipped area while clipping is applied? I believe there was a bug that was recently fixed for transforming the clippath with the clipped object. That bug allowed me to do what I speak of and that's really the most important thing that I'd personally need.
For the record, I noticed that I can moved nodes around and do the shape tool adjustments within the clipping area. So if we have a method other than selecting all nodes of an object, that's what I'm looking for.
If by "exponentially" you mean what this word _really_ means, then of course no. It will increase size and probably somewhat affect the performance, but not by much. I don't think the change in performance will be even measurable in 1000 objects using 1 mask vs. 1000 objects using 1000 masks. On the other hand, sharing one mask among several non-grouped objects is sure to have a lot of hidden issues and extra code to guard against surprises.
I trust you, if you really think that the performance difference wouldn't even be measurable then my fears are laid to rest
-Josh.
On 3/20/06, Joshua A. Andler <joshua@...533...> wrote:
I definitely understand what you're saying, and can agree that grouping is not too painful. What I needed to communicate in the last email was with the mentioned grouping... clipping "groups" are not quite like regular groups, they have special editing properties. Let me save a whole lot of correspondence by asking a question. Will it be possible to move objects around inside (and out) of the clipped area while clipping is applied?
Of course. If you've clipped a group, you can move objects inside the group, delete them or add new ones as you would do in any group. The clipping remains fixed as you do so. Only if you transform the group object itself as a whole, its clippath is transformed with it. I think this is quite logical.
It's only if you've applied clipping directly to an object, not a group, then moving that object without moving the clippath with it becomes impossible. But you can node-edit it (if it's a path) and thus even "move" it as a whole by moving all its nodes, without affecting the clippath. Or you can just unclip it, group it with something and clip the group.
Finally, if you _really_ need it, I can add yet another (5th) "transform with object" button to the Selector bar - for clippaths (and a 6th for masks). Like the corresponding buttons for gradients or patterns, these would allow you to transform the clipped/masked object either together or independently of its clippath/mask. It's not difficult to do, and I even like the idea somewhat for its consistency.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mon, 2006-03-20 at 21:47 -0400, bulia byak wrote:
Finally, if you _really_ need it, I can add yet another (5th) "transform with object" button to the Selector bar - for clippaths (and a 6th for masks). Like the corresponding buttons for gradients or patterns, these would allow you to transform the clipped/masked object either together or independently of its clippath/mask. It's not difficult to do, and I even like the idea somewhat for its consistency.
My feeling is that we should do that, but only have one button for both clippaths and masks.
-mental
By the way,
On 3/20/06, Joshua A. Andler <joshua@...533...> wrote:
What I needed to communicate in the last email was with the mentioned grouping... clipping "groups" are not quite like regular groups, they have special editing properties.
...and that is what I would absolutely hate to do. "Special kinds of anything" are evil and ugly and really unforgivable. Everything must be as simple and consistent as possible. A group is always a group, and a non-group is not allowed to pretend it's vaguely "group-like" without actually being a group.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (5)
-
Andrius Ramanauskas -
bulia byak -
Eric Wilhelm -
Joshua A. Andler -
MenTaLguY