On Dec 22, 2009, at 11:15 PM, Nicolas Dufour wrote:

Hi,

Roland Meub has posted a patch to implement this nice feature (see https://bugs.edge.launchpad.net/inkscape/+bug/171944). It compiles and works correctly on Ubuntu 9.10, and the only glitch I've found is related to 3Dbox (unexpected translations). Could a C++ expert review this code and commit?

Looks promising... however has anyone examined what this does to the raw SVG internally?

I'm wondering how "clean" the XML might be afterwards.

On 12/23/09, bulia byak wrote:

...

Roland Meub has posted a patch to implement this nice feature (see https://bugs.edge.launchpad.net/inkscape/+bug/171944). It compiles and works correctly on Ubuntu 9.10, and the only glitch I've found is related to 3Dbox (unexpected translations). Could a C++ expert review this code and commit?

Is it any better than: select both, h, v, select one, h, v, select the other, h, v? If not then perhaps it's a bit of a waste to spend toolbar space on something that can be easily achieved with this sequence?

The same feature is implemented in Scribus 1.3.5 as part of align'n'distribute dialog and it's better and faster than any sequence of actions.

Just my 0.02c.

Alexandre

On Wed, Dec 23, 2009 at 12:33 PM, bulia byak <buliabyak@...400...> wrote:

Oh yes - that's a better idea: if we have this button it should be in Align and Distribute.

Looking at the dialog, here's what we need to do: create a new section there, Rearrange, just below Distribute, and put four buttons there: Arrange connector network (removing the "Connector network layout" section), then the new Exchange positions, then Randomize positions, and then Unclump. Will be more compact and make more sense this way.

On Wed, Dec 23, 2009 at 12:44 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:

On 12/23/09, bulia byak wrote:

...

Oh yes - that's a better idea: if we have this button it should be in Align and Distribute. And ideally, generalized for any number of objects, not just two, exchanging their positions circularly.

Clockwise, counter-clockwise or both? :)

clockwise by default, I think - we don't need both directions, would be overkill :)

On Wed, Dec 23, 2009 at 12:58 PM, Nicolas Dufour <nicoduf@...48...> wrote:

It already works with any number of objects (and even groups each group being used as one object), exchanging their positions circularly...

That's great - so it means we just need to move it from toolbar to the dialog.

On Sat, Dec 26, 2009 at 1:42 PM, Roland Meub <roland.meub@...173...> wrote:

I like this solution. (I hesitate to put it into the dialog because it seemed to be already confusing. But with your proposal the dialog is much clearer)

I'll try to change the dialog as you described and then re-submit a patch for this.

Thank you!

Hi,

disclaimer: I haven't looked at the patch yet. Just a few random thoughts coming to mind:

2009/12/29 Roland Meub <roland.meub@...173...>:

Just a few words to clarify the logic behind the rotation order: The current implementation exchanges positions of objects according to the order in which they where selected: The 1st selected object moves to postion of 2nd, the 2nd to the position of the 3rd,  ... and the last to the position of the first.

So what is the order when the user selects the objects by drawing a rubberband around them, or by using "Select All" (Ctrl+A)? I suppose that it is predictable, but is it transparent to the user? And does it result in the behaviour the user expects (whatever that may be)? I think that the current behaviour is useful, but it's potentially dangerous to assume that it is always what the user wants.

This brings me to the question whether we should really try to implement a strict (for example clockwise) rotate order. The point is, that it's not ever possible to decide the right order. Imagine cases where all three objects are located at the same Y or X position)

One option would be to break ties by taking z-order into account. Or to move those objects as if they were a single object. But what does 'located at the same X' position mean anyway? When looking at the left border, the right border, the rotation center, ...? Just a few points to consider.

Max

P.S.: The issues you encountered with 3D boxes are indeed not caused by your code. Maybe they are already fixed by my recent commits. Otherwise I will take a look at them soon-ish.

Maximilian Albert schrieb:

Hi,

disclaimer: I haven't looked at the patch yet. Just a few random thoughts coming to mind:

2009/12/29 Roland Meub <roland.meub@...173...>:

This brings me to the question whether we should really try to implement a

...

strict (for example clockwise) rotate order. The point is, that it's not ever possible to decide the right order. Imagine cases where all three objects are located at the same Y or X position)

One option would be to break ties by taking z-order into account. Or to move those objects as if they were a single object. But what does

Might be an option but it seems not be very transparent to the user

'located at the same X' position mean anyway? When looking at the left border, the right border, the rotation center, ...? Just a few points to consider.

With, 'located at the same X position' I've meant that the center points of two objects are located at the same X position. (What You'll get when you align one object by the center of an other)

Max

P.S.: The issues you encountered with 3D boxes are indeed not caused by your code. Maybe they are already fixed by my recent commits. Otherwise I will take a look at them soon-ish.

On Tue, Dec 29, 2009 at 2:51 PM, Maximilian Albert <maximilian.albert@...1439...> wrote:

So what is the order when the user selects the objects by drawing a rubberband around them, or by using "Select All" (Ctrl+A)? I suppose that it is predictable, but is it transparent to the user? And does it result in the behaviour the user expects (whatever that may be)?

And that is exactly the reason why using selection order is a bad idea. Better use z-order. In a typical situation, it will correspond to the order objects are created, which makes more sense that the random order or selection.

But a still better and more useful approach is to dedect a clockwise order, as I wrote before. This may not be always easy, but it's an interesting mathematical challenge. For example: calculate a center point of objects and rotate clockwise a ray from this center, and process objects in the order in which this ray crosses their bbox centers.

Why not do both options, and make a switch in the align dialog for them?

JF

On 12/30/2009 05:36 PM, bulia byak wrote:

On Tue, Dec 29, 2009 at 2:51 PM, Maximilian Albert <maximilian.albert@...1439...> wrote:

...

So what is the order when the user selects the objects by drawing a rubberband around them, or by using "Select All" (Ctrl+A)? I suppose that it is predictable, but is it transparent to the user? And does it result in the behaviour the user expects (whatever that may be)?

And that is exactly the reason why using selection order is a bad idea. Better use z-order. In a typical situation, it will correspond to the order objects are created, which makes more sense that the random order or selection.

But a still better and more useful approach is to dedect a clockwise order, as I wrote before. This may not be always easy, but it's an interesting mathematical challenge. For example: calculate a center point of objects and rotate clockwise a ray from this center, and process objects in the order in which this ray crosses their bbox centers.

Most of the code to rotate the Z order already exists ib the restack extension.

-Rob A.

On 12/31/09, bulia byak <buliabyak@...400...> wrote:

On Thu, Dec 31, 2009 at 10:55 AM, Joshua Facemyer <jfacemyer@...400...> wrote:

...

Why not do both options, and make a switch in the align dialog for them?

Not a switch then, but just two different buttons in the Arrange section: "Rotate z-order" and "Rotate spatially".

-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

---

This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

bulia byak schrieb:

But a still better and more useful approach is to dedect a clockwise order, as I wrote before. This may not be always easy, but it's an interesting mathematical challenge. For example: calculate a center point of objects and rotate clockwise a ray from this center, and process objects in the order in which this ray crosses their bbox centers.

Using the center point of all selected objects is a good starting point. With this it seems to be pretty easy to compute a clockwise sorting order. (Much easier than I thought first) I've just coded following sorting algorithm and am about to create a new patch: - First compute the angle of a vector from overall center point to the center points of the selected objects and sort this (lowest first gives a clockwise order) - If object vectors have the same angle, sort according to the length of the vector (longest first) - If the vector length is also identical, sort according to the z-order.

Roland