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