NEW: Ensure selected objects don't overlap each other
Tim Dwyer from the office next to mine has been working on code to move rectangles by the minimal amount enough that they no longer overlap.
Now he's spent a few days adding this to Inkscape (with a little help from me, njh & possibly Brisgeek): in the Align & Distribute dialog box near the existing Clump/Unclump buttons. (Unclump merely reduces overlap, whereas Remove Overlaps completely removes overlap.)
You can also think of it like the Distribute edge-to-edge buttons, except that it moves things only enough to ensure that they don't overlap; e.g. if applied to a set of objects that are roughly in a grid arrangement, then the new code probably does what the user wants (preserve the grid nature), whereas existing Distribute edge-to-edge would put the objects in a long diagonal line (unless the user does extra work, acting in small groups at a time).
This should be a significant addition to Inkscape's usability for diagramming.
Interface changes welcome; e.g. I wonder if it should be in the same box as Distribute; though having the separate box does make it clearer that the Hor/Vert Gap settings apply only to the Remove Overlap option.
pjrm.
Forgot to mention: You'll want to re-install share/icons/icons.svg for the new stuff to appear in the Align & Distribute dialog box.
E.g. from your build directory do cd share/icons && make install
pjrm.
The feature itself is definitely useful and works as expected. I have a few cosmetic comments:
On 11/23/05, Peter Moulder <Peter.Moulder@...38...> wrote:
near the existing Clump/Unclump buttons.
There's no "Clump" button... :)
(Unclump merely reduces overlap, whereas Remove Overlaps completely removes overlap.)
It's not fair to comare them that way. It's not the _goal_ of Unclump to remove overlaps. Anyway, can you please add a description of the new feature to Release Notes on wiki, and I'll edit that part there. (There must be some sort of comparison of Unclump and Remove overlaps in any case, as people are likely to ask about that.)
The icon is noisy and unclear. It takes quite some time to read it. Much better would be just an icon showing 4 different-sized rects side-by-side without overlaps. No arrows.
Please don't use All Initial Capitals except in menu commands.
It's better to avoid abbreviations like "Hor." and "Vert." They look ugly and unprofessional, and they still take too much space, making the dialog almost twice as wide as before. Please consider making the spinbuttons narrower and labelling them H and V (or small icons showing gaps with dimension lines).
I think the gap values should be stored in prefs across sessions.
Why gaps can't be negative? I think this would make sense sometimes.
Please indicate in which units are the gaps measured, at least in the tooltips. In principle you should also provide a unit selector here, but this will make the dialog even more crowded, so let's not do it for now.
Why did you move the Unclump and Randomize buttons? They were not in random positions. Please return them to where they were.
Logically, you set the gaps first, and do the remove overlaps later. Therefore, the gap spinbuttons must be on the left, and the button on the right within their frame.
Finally, I'm not sure about the "Remove overlaps" frame being on the same level as "Align" and "Distribute". To me, it is a type of distributing. So I suggest to move the "Remove overlaps" frame inside "Distribute", at the bottom.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Wed, Nov 23, 2005 at 06:28:57AM -0400, bulia byak wrote:
On 11/23/05, Peter Moulder <Peter.Moulder@...38...> wrote:
near the existing Clump/Unclump buttons.
There's no "Clump" button... :)
I meant the Randomize button.
(Unclump merely reduces overlap, whereas Remove Overlaps completely removes overlap.)
It's not fair to comare them that way. It's not the _goal_ of Unclump to remove overlaps.
I wasn't trying to say that the Unclump button is buggy, I was just trying to introduce it by way of comparison with existing similar buttons. The comparison is particularly useful insofar as the Unclump and Distribute buttons are sometimes used to help remove overlaps (whether or not that's the intended use of the Unclump button).
Why gaps can't be negative? I think this would make sense sometimes.
I asked Tim earlier today whether we could allow negative values. He said that he hadn't considered the possibility when writing the code (which was before he'd thought of adding it to Inkscape), so he isn't immediately confident that it would always work. I'll mention it again tomorrow.
Finally, I'm not sure about the "Remove overlaps" frame being on the same level as "Align" and "Distribute". To me, it is a type of distributing. So I suggest to move the "Remove overlaps" frame inside "Distribute", at the bottom.
I hadn't considered that possibility.
I'll pass on your comments to Tim.
pjrm.
On Wed, 23 Nov 2005, bulia byak wrote:
Date: Wed, 23 Nov 2005 06:28:57 -0400 From: bulia byak <buliabyak@...400...> To: Peter Moulder <Peter.Moulder@...38...>, inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: Ensure selected objects don't overlap each other
The feature itself is definitely useful and works as expected. I have a few cosmetic comments:
On 11/23/05, Peter Moulder <Peter.Moulder@...38...> wrote:
near the existing Clump/Unclump buttons.
There's no "Clump" button... :)
(Unclump merely reduces overlap, whereas Remove Overlaps completely removes overlap.)
It's not fair to comare them that way. It's not the _goal_ of Unclump to remove overlaps. Anyway, can you please add a description of the new feature to Release Notes on wiki, and I'll edit that part there. (There must be some sort of comparison of Unclump and Remove overlaps in any case, as people are likely to ask about that.)
The icon is noisy and unclear. It takes quite some time to read it. Much better would be just an icon showing 4 different-sized rects side-by-side without overlaps. No arrows.
Please don't use All Initial Capitals except in menu commands.
It's better to avoid abbreviations like "Hor." and "Vert."
There is no benefit to using Abbreviations and deciphering them can slow you down (think of it like reading l33t-sp34k). Translations will be of variable length, and the system can require different font sizes (accessibility) so you cannot assume fixed size for strings when designing your layout.
They look ugly and unprofessional, and they still take too much space, making the dialog almost twice as wide as before. Please consider making the spinbuttons narrower and labelling them H and V (or small icons showing gaps with dimension lines).
The use of H. and V. takes some getting used to but it is consistent with other parts of Inkscape. Icons might be a more compact way to represent Horizontal and Vertical.
- Alan
On 11/23/05, Alan Horkan wrote:
The use of H. and V. takes some getting used to but it is consistent with other parts of Inkscape. Icons might be a more compact way to represent Horizontal and Vertical.
The only common and recognizable way to show horizontal and vertical anything would be arrows. Are you sure they are really that compact? :)
Alexandre
Quoting Alexandre Prokoudine <alexandre.prokoudine@...400...>:
The only common and recognizable way to show horizontal and vertical anything would be arrows.
That might not be a bad idea -- arrows communicate extra information: not only an axis, but a direction.
In principle folks should remember which way is positive and which way is negative, but in practice a little reminder would not hurt.
Especially if we are going to be fixing the coordinate system one of these days.
-mental
Quoting Alan Horkan <horkana@...44...>:
The use of H. and V. takes some getting used to but it is consistent with other parts of Inkscape. Icons might be a more compact way to represent Horizontal and Vertical.
I'd vote for H and V or icons as well, because of the translation issue.
-mental
On 11/23/05, Peter Moulder <Peter.Moulder@...38...> wrote:
Tim Dwyer from the office next to mine has been working on code to move rectangles by the minimal amount enough that they no longer overlap.
I have a file where the result of Remove Overlaps is unpredictable. I select all in that file and do Remove Overlaps, it gives me one of two configurations randomly. I then undo and do it again, and I can get the same configuration or another one. Is this kind of behavior normal for this algorithm?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Wed, Nov 23, 2005 at 10:08:59PM -0400, bulia byak wrote:
On 11/23/05, Peter Moulder <Peter.Moulder@...38...> wrote:
Tim Dwyer from the office next to mine has been working on code to move rectangles by the minimal amount enough that they no longer overlap.
I have a file where the result of Remove Overlaps is unpredictable. I select all in that file and do Remove Overlaps, it gives me one of two configurations randomly. I then undo and do it again, and I can get the same configuration or another one. Is this kind of behavior normal for this algorithm?
If you mail me the file then I'll pass it to Tim to look at.
The best explanation we can think of is if undoing & redoing involved slight changes to the coordinates (e.g. because "undo" means reading back from string and not necessarily restoring exactly the same floating point value).
When making discrete decisions like whether a box should be moved above, left, right or below another one, naturally there are certain knife-edge points on the boundary between two of those discrete choices: e.g. if two boxes are centre-aligned then there are (at least) two equally good ways of forcing them not to overlap, so a small change in coordinates can affect which way we choose. (Similarly, if two boxes' closest corners lie on a 45° line then left-right and up-down are equally good ways of resolving the overlap.)
If non-determinism can be reproduced even when starting by opening the file rather than using Undo, then I wondered whether selection order could ever change the result (in cases where two solutions are equally good, such as the examples above).
Are the two possible outcomes both reasonable, or is one noticeably better/worse?
pjrm.
On 11/23/05, Peter Moulder <Peter.Moulder@...38...> wrote:
If you mail me the file then I'll pass it to Tim to look at.
I just submitted a bug with that file because it also causes a crash with large negative gaps (I must admit I increased the gap limits myself in the dialog in CVS, but I do think the limits of 100px were too small).
When making discrete decisions like whether a box should be moved above, left, right or below another one, naturally there are certain knife-edge points on the boundary between two of those discrete choices:
This is understandable, but note that I run into this test case on one of the first tries, i.e. without much testing.
If non-determinism can be reproduced even when starting by opening the file rather than using Undo, then I wondered whether selection order could ever change the result (in cases where two solutions are equally good, such as the examples above).
Yes, I just tried that. Even without undo it gives different results upon load. The selection method is always Ctrl+A.
Are the two possible outcomes both reasonable, or is one noticeably better/worse?
I'd say one is definitely more compact (and thus "better") than the other. But, even in the better one, at least one rect is still positioned nonoptimal - see the second bug that I just submitted.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 11/24/05, bulia byak <buliabyak@...400...> wrote:
On 11/23/05, Peter Moulder <Peter.Moulder@...38...> wrote:
Tim Dwyer from the office next to mine has been working on code to move rectangles by the minimal amount enough that they no longer overlap.
I have a file where the result of Remove Overlaps is unpredictable. I select all in that file and do Remove Overlaps, it gives me one of two configurations randomly. I then undo and do it again, and I can get the same configuration or another one. Is this kind of behavior normal for this algorithm?
Back in my school days when I was programming in Pascal it was always a good idea to enable randomizer before using random, otherwise it always gave the same result ;-)
I think this is exactly the same case with extrapolation to C/C++.
Alexandre
I'd just like to propose that we change names from Remove Overlaps to Spacing. If you can give a negative value it's not removing overlaps. Additionally, a function called remove overlaps should be a non-configurable action (like unclump), it should do just what it says with no tweaking. Any thoughts?
-Josh
Joshua A. Andler wrote:
I'd just like to propose that we change names from Remove Overlaps to Spacing. If you can give a negative value it's not removing overlaps. Additionally, a function called remove overlaps should be a non-configurable action (like unclump), it should do just what it says with no tweaking. Any thoughts?
I agree with your analysis.
Aaron Spike
--- "Joshua A. Andler" <joshua@...533...> wrote:
I'd just like to propose that we change names from Remove Overlaps to
Spacing. If you can give a negative value it's not removing overlaps.
Additionally, a function called remove overlaps should be a non-configurable action (like unclump), it should do just what it says with no tweaking. Any thoughts?
-Josh
Sounds sensible to me.
__________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
participants (8)
-
unknown＠example.com -
Aaron and Sarah Spike -
Alan Horkan -
Alexandre Prokoudine -
bulia byak -
John Cliff -
Joshua A. Andler -
Peter Moulder