On Wed, 2010-10-13 at 12:10 +0200, Andy Fitzsimon wrote:
I had a thought after some observation and while it wouldn't look good on our already crowded toolbox, it should be fairly easy to implement a crop tool. In practice its just applying parent group to all things then a clippath and finally a resize page to contents command which we already have the code for...
If you presented a crop tool to me, I would expect that after cropping, all the stuff outside the crop area is gone. So more like a boolean operation.
Why would Resize Page be part of it? You might want to confine elements to a rectangle that doesn't fill the page. In some cases, you might not care one bit that shapes extend outwards of the page; you use the page as clipping area, but stay flexible.
Currently, if a user clips something, he knows it is clipped, as that's explicit. He wouldn't with a cropping too, necessarily.
My thinking is that right now creating clippaths is a weird concept for new-to-vector users, but almost everyone gets the idea of cropping
Lots of things might seem weird if you're new to vector graphics. Initial hurdles become so insignificant further down the road, where getting stuff done in the most efficient way is what counts.
With clipping we have a flexible tool that allows all kinds of shapes, not just rectangles. Results are reversible/tweakable. It's an explicit operation with no abstraction.
In comparison, what you propose seems to me like a one-trick pony that wraps existing functionality and leads to a situation where the user either has to find out that a cropped area is clipped, thus it can be released, or where you have to wrap that, too, with an "uncrop".