View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000480||Scribus||General||public||2004-04-14 13:32||2009-07-16 01:20|
|Target Version||1.5.0||Fixed in Version||1.5.0svn|
|Summary||0000480: Being able to *switch* items in the Distribute/Align menu|
|Description||This feature doesn’t exist in any DTP program. Select two items, and simply switch them. Instead, users have to put one item aside, drag the other one in its place, reselect the one that was put aside and reposition it. When you need to be precise, you have to take note of the xy coordinates. Why not let the computer do the work!|
|Tags||No tags attached.|
... but i would implement it as a script...
it would be great to have a collection of scripts like in the gimp... what do you think about it?
Louis, what other options can we add here? I've just changed some of the 1.3.4cs dialog around and added two distribute items.
What if the user has 3 items selected, or more etc?
Let me know and it'll be in 1.3.4 on release.. whenever that is.
We could allow either 2 items to be selected and switched or 1 group of items and 1 item or 2 groups.
I cannot imagine how this feature would work with 3 or more items. But I know for sure the switch thing would be a great new feature no-one (afaik) offers at the moment!
Does that help?
"What if the user has 3 items selected, or more etc?"
What about rotating clockwise. Rotating two items clockwise or counterclockwise means switching, for more objects the number of steps to rotate can depend on the number of items.
Another option could be the change of the order of items: 1, 2, 3 -> 2, 1, 3
Don't you think that that rotating feature would be a bit akward to use? I am trying to think of a real-life situation where one would use this... find that a bit complicated (maybe not to implement but to use). I understand what you propose as a "move feature" rather than a "switch feature". What do you think? The switch feature is meant to be really simple to handle. You select 2 items (or groups) and you hit that button and they are switched.
To put more gravy around this, we could let the user states what coordinates are going to be taken in consideration when the switch occurs. Center, upper right, lower right, etc.
I'm not sure a rotate or whatever you want to call it would be that useful but it does solve the issue for two items/groups still.
1,2 -> 2,1
1,2,3 -> 3,1,2
1,2,3,4 -> 4,1,2,3
The idea of a basepoint to work on would be ok too. I'll let you discuss it while I sleep :).
Hmm, I don't think it's awkward. I was thinking about a page with three or more pictures on a pages, drawings for example. Let's assume:
1 (a portrait)
2 (an etching) 3 (a portrait)
4 (a lithograph)
The artwork may now be in a correct chronological order, but from an aesthetic point of view they'd be better distributed as follows:
2 (an etching)
1 (a portrait) 3 (a portrait)
4 (a lithograph)
So let's quickly switch the order. In this case this would require changing the order. OK, this is not really rotating, rather switching, but I hope you guess the idea.
Yes! I understand. My main concern is about the usability of the feature. Users are going to be placed in front of an array of possibilities. They might refrain them from using the feature although I understand it would be useful. I wonder if in that particular case it would not be faster to switch the 2 pairs of items... in 2 operations.
But at the same time, I didn't realize like Craig mentions it, that rotating 2 objects is the same as switching them! So this clears the way for 3 or more objects, like you said previously, clockwise (or counterclockwise?). More sophisticated moves would be handled in 2 or more operations...
Usability is a concern here, you're absolutely right. It starts with the desription: switch or rotate. Switch is obvious for 2 items, but 3 or more? On the other hand rotate would be clearer for 3 or more, IMHO. Switch/Rotate would be confusing since users might conclude, that the feature either switches or rotates.
I suggest "Switch" with a long tooltip, and a Wiki article on that topic ;)
||Interesting, but will the mathematical term be an intuitive one for average users? Also note that rotate is already used for rotating objects. This is no problem in the German translation since "rotieren" is not used yet, but what about English speaking users. You decide.|
||What about doing that in 2 steps? First, implement the switch feature, good for a pair of items. Then, after a while, if the need is raised, we have a rabbit in our hat and can add to this switch feature a little more...|
||Hehe, smart indeed. Implement a simple switch feature for two items, then wait if users request more. Louis, you have my vote!|
||Just two is enough for all moves anyway. :)|
My two thoughts on the matter:
1) first of all, what's this order 1,2,3,4 stuff mean in practice anyway? Scribus doesn't remember the order in which objects are selected, does it? And what if you used rubberband select?
How about letting the user set a reference angle and then determining the order of objects according to their positions in that direction--would default to 0, horizontal.
This would actually be useful for all the align and distribute functions.
2) For the switch, I'd vote for reversing the order rather than rotating if the user has more than 2 items selected, i.e. 1,2,3,4 -> 4,3,2,1. Seems more likely to be useful and easy to understand. (You have to do something if the user selects more than 2 anyway....)
[Edit: I suppose you could let the user specify a reference point and then rotate (or use the center of the selection), but that seems less likely to be useful.]
A refinement to that could be to reverse the spacing between objects as well:
1_2___3__4 -> 4_3___2__1 vs.
1_2___3__4 -> 4__3___2_1 .
Kind of like reflecting the whole set around its center, but without reflecting each object itself. (Although a real mirror function would also be a very nice addition.... :)
||Resolving for now.. basic swapping based on the X1,Y1 position is done|
||Tested. Well done. Thanks!|
|2004-04-14 13:32||louisdesjardins||New Issue|
|2004-04-19 11:03||ale||Note Added: 0001121|
||Note Added: 0001122|
|2004-04-21 20:40||ale||Note Added: 0001152|
|2004-07-05 00:48||cbradney||Status||new => assigned|
|2004-07-05 00:48||cbradney||Assigned To||=> fschmid|
|2004-12-08 19:18||cbradney||Assigned To||fschmid =>|
|2004-12-08 22:57||cbradney||Status||assigned => new|
|2006-02-06 18:21||jo-hannes||Status||new => acknowledged|
|2006-02-06 18:21||jo-hannes||Product Version||1.1.6 => 1.3|
|2006-09-27 20:36||cbradney||Note Added: 0012656|
|2006-09-27 20:37||cbradney||Status||acknowledged => assigned|
|2006-09-27 20:37||cbradney||Assigned To||=> cbradney|
|2006-09-27 20:57||louisdesjardins||Note Added: 0012659|
|2006-09-27 20:59||christoph_s||Note Added: 0012660|
|2006-09-27 21:15||louisdesjardins||Note Added: 0012664|
|2006-09-27 21:20||cbradney||Note Added: 0012666|
|2006-09-27 21:30||christoph_s||Note Added: 0012667|
|2006-09-27 21:50||louisdesjardins||Note Added: 0012672|
|2006-09-27 22:00||christoph_s||Note Added: 0012674|
|2006-09-27 22:04||cbradney||Note Added: 0012675|
|2006-09-27 22:12||christoph_s||Note Added: 0012676|
|2006-09-27 22:20||louisdesjardins||Note Added: 0012677|
|2006-09-27 22:24||christoph_s||Note Added: 0012678|
|2006-09-28 01:15||PLucAuclair||Note Added: 0012680|
|2006-10-06 19:56||mkoren||Note Added: 0012824|
|2006-10-06 20:08||mkoren||Note Added: 0012825|
|2006-10-06 20:11||mkoren||Note Edited: 0012824|
|2009-07-14 22:11||cbradney||Status||assigned => resolved|
|2009-07-14 22:11||cbradney||Fixed in Version||=> 1.5.0svn|
|2009-07-14 22:11||cbradney||Resolution||open => fixed|
|2009-07-14 22:11||cbradney||Note Added: 0022184|
|2009-07-14 22:16||cbradney||Target Version||=> 1.5.0|
|2009-07-16 01:20||christoph_s||Note Added: 0022199|
|2009-07-16 01:20||christoph_s||Status||resolved => closed|