Implementaion of Division Command
What's the reasoning behind Inkscape's implementation of Division as opposed to having two overlapping shapes resulting in three pieces, including the exclusion area of the top (stacking order) shape in addition to the exclusion area of the bottom object and intersection?
I illustrated the question at http://www.angelfire.com/mi/kevincharles/inkscape/division.html
Thanks, -Kevin
On 8/3/05, Kevin Wixson <kevin@...738...> wrote:
I illustrated the question at http://www.angelfire.com/mi/kevincharles/inkscape/division.html
Because you cut the bottom object BY the top. The top one is expendable, it's the cutting tool which is discarded in the operation. Seems quite logical to me.
What you propose might be useful too, but (1) I don't see a persuasive use case and (2) if implemented it would not be called "divisiion" anyway.
bulia byak wrote:
On 8/3/05, Kevin Wixson <kevin@...738...> wrote:
I illustrated the question at http://www.angelfire.com/mi/kevincharles/inkscape/division.html
What you propose might be useful too, but (1) I don't see a persuasive use case and
Strictly speaking, can't the same effect as Division can be achieved with two copies of the two objects and performing Difference on one set and Intersection on and the other? So, Division's purpose is already one of convenience and productivity without any other real obvious reason. Why not just expand that idea to include the leftover area of the top shape as well, thus making it possible to simply select and deleted the unwanted bits? Isn't that also productive, or even more so? Otherwise, the method of making two copies and preforming Exclusion on one and Intersection on the other set is necessary, which is not as productive as just deleting the unwanted section to achieve the same result as the current Division command.
I use this kind of feature all the time in other programs, and where what I need is just the two of the three bits, I erase what I don't need. Much easier, I think, since I also don't have to worry about what the stacking order is.
But if you need a compelling use case, consider making a stained glass image effect, where you're cutting things apart so you can give them different fills, and you certainly don't want to be losing bits of the shapes in the process.
(2) if implemented it would not be called "divisiion" anyway.
I don't see why not, since it's still dividing two shapes into component parts, the bottom cutout, the intersection, and top cutout. It's still dividing the image. But you can call it something else that makes more sense if you think it's really necessary.
-Kevin
On 8/4/05, Kevin Wixson <kevin@...738...> wrote:
Strictly speaking, can't the same effect as Division can be achieved with two copies of the two objects and performing Difference on one set and Intersection on and the other?
Right, just the same as your proposed command can be achieved by several duplications and divisions.
of convenience and productivity without any other real obvious reason. Why not just expand that idea to include the leftover area of the top shape as well, thus making it possible to simply select and deleted the unwanted bits? Isn't that also productive, or even more so? Otherwise, the method of making two copies and preforming Exclusion on one and Intersection on the other set is necessary, which is not as productive as just deleting the unwanted section to achieve the same result as the current Division command.
No, the "use case" should be something like that: I have such and such practical situation, and I want to achieve this and this practical result. I can give such use cases for the regular division we have but not for your proposed "extended division". Can you?
I use this kind of feature all the time in other programs, and where what I need is just the two of the three bits, I erase what I don't need. Much easier, I think, since I also don't have to worry about what the stacking order is.
It's subjective. You don't have to worry about z-order, but I don't have to worry about deleting unwanted bits. Are your worries worse than mine? I don't know.
But if you need a compelling use case, consider making a stained glass image effect, where you're cutting things apart so you can give them different fills, and you certainly don't want to be losing bits of the shapes in the process.
Just recently I helped someone on Jabber to do just that. He had a shape which represented the frames of the stained glass mosaic, and I explained how to put a rect under that shape, divide it by the frame shape, and then paint each divided part by its own color. I absolutely don't see how extra division of the frame shape itself could be useful here.
On Thu, 4 Aug 2005, Kevin Wixson wrote:
Date: Thu, 04 Aug 2005 01:15:00 -0400 From: Kevin Wixson <kevin@...738...> To: bulia byak <buliabyak@...400...> Cc: Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Implementaion of Division Command
bulia byak wrote:
On 8/3/05, Kevin Wixson <kevin@...738...> wrote:
I illustrated the question at http://www.angelfire.com/mi/kevincharles/inkscape/division.html
What you propose might be useful too, but (1) I don't see a persuasive use case and
Bleugh. This thread confused the crap out of me. I think I have finally got straight what you are talking about so here goes.
Division is does exactly what it is supposed to do.
Microsoft Visio includes the latter functionality and it is Described as "Fragment" although i should mention the pieces are left in place, no extra spaces are added. (I think I may have seen similar functionality elsewhere but described as "Break Apart"). (Visio includes other operations that might be worth looking at too.)
The existance of functionality in other program is often a compelling reason to consider implementing it. If you can find examples it always helps to mention them. Does Illustrator or Freehand implement this functionality in some form or another and is there perhaps a better way to do it?
I would also be interested to know what bigger problem you are actually tryng to solve (to address bulias concern about this not really being necessary. Usability is often another kind of optimisation and the first rule of optimisation is "Dont optimize". It is important to avoid micro-optimisations (which I'm prone to) and step back and try and solve the bigger problems.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
participants (3)
-
Alan Horkan -
bulia byak -
Kevin Wixson