It seems that for consistency the Move tool should act like a transform tool --- because after all, it *is* a transform tool. That is, if there is a selection, it should move the contents of the selection, otherwise it should move the layer.

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

On Wed, Sep 27, 2006 at 09:01:29PM +0200, Rapha?l Quinet wrote:

So I am wondering... What should be the behavior of the Move tool when a selection exists? Wouldn't it be good to have the ability to move the selected pixels (and create a floating selection) instead of moving the whole layer? This could be optional (new checkbox in the tool options) because sometimes it is also useful to move the whole layer while keeping the selection intact. But I guess that it would be better to have the new option active by default.

i am trying to think of a case where i have a selection and i am trying to move a path and i cannot come up with one.

i have had problems where i wanted the tool to move either a selection or a path and it was set to move layers. the little bit of frustration is not worth it to me to change the behavior of the tool for.

Edit/Undo is always there for these things without complicating the gui even more in the name of simplicity.

just my opinion,

carol

On Wed, 27 Sep 2006 22:39:40 +0200, Raphaël Quinet wrote:

it would be nice if the rectangle and ellipse selection tools (not the base rectangle tool) would take Alt into account before the selection is confirmed and behave as if the selection had been confirmed: Alt = move selection mask, Alt+Ctrl = move selected pixels, Alt+Shift = copy selected pixels. It should not be necessary to press Enter before being able to move it.

What ? I have to "confirm" a selection? (sometimes?) , Cntl-Alt what?

Hey this is seriously confused as well as confusing. This is a classic case of bottom up design.

What's the best way run a reveiw the situation?

On Wed, 27 Sep 2006 22:14:38 +0200, William Skaggs wrote:

It seems that for consistency the Move tool should act like a transform tool --- because after all, it *is* a transform tool. That is, if there is a selection, it should move the contents of the selection, otherwise it should move the layer.

-- Bill

I pick up on this because I think it illustrates very well a major short-coming in the user interface of the GIMP. It is developer-centric not user-centric.

Bill, to you it *is* a transform tool because you are close to the code and you know the way is it implemented. To the user it *is not* a transform tool. It's just a tool off the palette like any other that is called "Move" and that carries the hint "move layers, selections and other objects".

The user makes a selection then picks the move tool to move it. "The fool!" you cry.

Well what do you expect him to do? That seems like a perfectly logical way to do it and I would bet you 9/10 new users will do exactly that.

You might see it as a lateral translation effected by simple transform matrix multiplication. The user just wants to move a bit to one side.

I think this larger issue needs looking at from the top down. Gimp has gradually built up around the code. The USER interface now needs to be reorganised from a user (task oriented) point of view.

I had already thought of opening a bug on this point.

Many thanks to Raphaël for bringing it up.

BTW How do I move a rectangular selection ?! I don't mean move the selection outline, how do I move the part of the image selected?

And while we're here , why is the rect selection tool not on the palette with the ellipse and free-style tools, do I really have to go off to Tools | Selection Tools | Rectangle ?

Hi,

On Wed, 2006-09-27 at 23:21 +0200, gg@catking.net wrote:

Bill, to you it *is* a transform tool because you are close to the code and you know the way is it implemented. To the user it *is not* a transform tool. It's just a tool off the palette like any other that is called "Move" and that carries the hint "move layers, selections and other objects".

It's not even a transform tool from the code point of view. It has just been sorted into the Transform tools category since that seemed to describe it best.

Sven

On Wed, 27 Sep 2006 23:34:13 +0200, Raphaël Quinet wrote:

If you are using a development version, it is likely that your toolrc has not been updated since a while. I recommend that you just delete it and restart GIMP. Just rm ~/.gimp-2.3/toolrc. -Raphaël

thanks , that got it.

On Thu, 28 Sep 2006 00:10:16 +0200, Sven Neumann wrote:

Hi,

On Thu, 2006-09-28 at 00:04 +0200, gg@catking.net wrote:

Thanks, I was led to thinking it was by Bills comment and did not bother checking the source.

My point is, moving a selection is probably not transforming it in the mind of the user. Shear , perspective , mirror , flip would seem to fit as
transformations.

cut, paste, move, copy, I would see at edit functions.

There are probably grey areas as with most things but I think it would be
good to take a step back and review the UI. It's easy to be too close to thing as they evolve and not see some of the defects.

Sure, don't take anything in the user interface as set in stone. There's nothing that couldn't be changed. But it is also important to see the big picture and it is very easy to jump to quick conclusions when it comes to user interface design.

BTW, you probably meant to send this to the mailing-list.

Sven

Indeed I did , thx.

There's nothing that couldn't be changed. But it is also important to see the
big picture and it is very easy to jump to quick conclusions when it comes to user interface design.

Oh fer sure. I dont expect to look at this and come up with all the right answers but I have a few overall impressions and some specifics that may be worth looking at.

1/ In general I find it needs too many mouse/keyboard actions to achieve a simple operation.

1a/ specific: undo : edit | undo . This must be one of the most common actions I want a one click solution, in the same window as I am editting in.

There's always cntl-Z cntl-Y but that means dropping the mouse and diverting my attention away fron the screen. Very slow.

1b/ I pull up a dlg. the first text entry is highlighted so I can type to replace , fine. But if I want to edit it eg 100 to 400, I go to select the "1" with the mouse and the editted text gets dragged. Huh? So I have to click to deselect the reselect the bit I want.

2/ I am continually repeating the same placement/configuration operations where once should be enough.

2a/ It seems none of the filters retain thier position and size, although they retains _some_ of their settings.

specific: Filters | Motion Blur ... I resize to get a more visible preview size and move it out of the way of other things on the screen. Next time I use it I dont want to start again.

While this is probably down to the plugin writer, at least the "common" filters should be vetted/modded to retain size/pos before being integrated. And it should be recommended for all plug-ins.

2b/ If I use a dlg on one image and set, say units to pixels , if I open another image or even duplicate I have to reset the same options.

specific: Image | Scale Image , set to percent . Duplicate image , Scale Image : back to default pixels.

2c/ I have select for tools to store settings but this seems limitted.

specific: again the Scale Image dlg. units combo. This is held for the time I edit an image but not affected by the config option :tools store settings.

2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point.

All these are minor things on their own but the overall effect is _several times_ more mouse actions than are really needed to get a job done.

There's lots of things it does well too, but no sense in opening bugs and threads here to comment on what does not need fixing ;)

Bill, to you it *is* a transform tool because you are close to the code and you know the way is it implemented. To the user it *is not* a transform tool. It's just a tool off the palette like any other that is called "Move" and that carries the hint "move layers, selections and other objects".

It's not even a transform tool from the code point of view. It has just been sorted into the Transform tools category since that seemed to describe it best.

Sven

Well, I was quite aware that it is different from a code point of view -- what I was trying to say is that it feels like a transform tool from a *functional* point of view. Moving feels to me like it should group logically with operations like Rotating and Flipping. After all, isn't Rotating just a freer kind of Moving? This may just be my math background coming through, but that's the way it feels intuitively to me that it ought to be grouped.

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

From: Rapha�l Quinet

As a side note, it would be nice if the rectangle and ellipse selection tools (not the base rectangle tool) would take Alt into account before the selection is confirmed and behave as if the selection had been confirmed: Alt = move selection mask, Alt+Ctrl = move selected pixels, Alt+Shift = copy selected pixels. It should not be necessary to press Enter before being able to move it.

Well, that's a bug, then. The objective for Rectangle Select is that you should be able to do anything with the selection while it remains modifiable that you would be able to do after turning it into a fixed selection. To the extent that you can't, it's a bug. In this case the tool simply is not handling the Alt modifier correctly -- thanks for pointing it out, and I hope I can remember it long enough to get around to fixing it.

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

On Thu, 28 Sep 2006 01:52:56 +0200, William Skaggs wrote:

The user makes a selection then picks the move tool to move it. "The fool!" you cry.

Well what do you expect him to do? That seems like a perfectly logical way
to do it and I would bet you 9/10 new users will do exactly that.

Wow, I must have explained it really badly, because I was trying to say exactly what you just said.

:-)

-- Bill

LOL, in that case "I'm with Bill all the way on this." ;)

We're agreed about how this tool should operate but I'd still like to review how some of these items are classed as transformations. I dont think that makes sense to the user. I covered that in a reply to Sven.

Hi,

On Thu, 2006-09-28 at 02:13 +0200, gg@catking.net wrote:

We're agreed about how this tool should operate but I'd still like to review how some of these items are classed as transformations. I dont think that makes sense to the user.

Well, we can't really decide that without doing some usability research. We aren't users, so we can't create categories in a way that makes sense to the users.

This would probably be a nice task for card sorting. Make a pile of cards with tool names (and perhaps tool icons) on them and ask a number of selected users to sort them into a bunch of piles. You could predefine categories or you could ask the users to come up with their own categories. There are standard protocols for analyzying the results.

Sven

While "moves" might not be considered to be within the category of Transformations, they are commonly associated with them. A google of "CAD translations and transformations" will readily display how the two operations are commonly paired. Perhaps a better question to ask would be what graphics programs *don't* associate these operations?

Regarding the current user interface (in CVS), I fail to see any logic in having the selection tools possessing the ability to move selection contents, it is much simpler and more intuitive if they limit themselves to selecting regions and not engage in modifying drawables.

A minor related note: the Affect Selection option of the Move Tool displays two identical "Move Selection" options, both of which are always(?) grayed out.

I understand the tools are under development and am not complaining; the work being done is most excellent and I look forward to the time these usability issues are resolved.

On Thu, 2006-09-28 at 02:13 +0200, gg@catking.net wrote:

We're agreed about how this tool should operate but I'd still like to review how some of these items are classed as transformations. I dont think that makes sense to the user. I covered that in a reply to Sven.

Aha... so which of the tools under "Transform Tool" is not doing a transform? I don't see any that wouldn't prefectly fit into the catrgory.

ciao,
--mitch

On Thu, 28 Sep 2006 13:48:29 +0200, Michael Natterer wrote:

On Thu, 2006-09-28 at 02:13 +0200, gg@catking.net wrote:

We're agreed about how this tool should operate but I'd still like to review how some of these items are classed as transformations. I don't think that makes sense to the user. I covered that in a reply to Sven.

Aha... so which of the tools under "Transform Tool" is not doing a transform? I don't see any that wouldn't perfectly fit into the category.

ciao,
--mitch

Mitch, please look back over the thread.

As quick reply because I'm repeating what has already been said, I don't think moving a selection a bit to one side would seen as a "transforming" it by someone who did not have a maths background. It's an example of a broader issue.

cheers.

On 9/28/06, saulgoode wrote:

Regarding the current user interface (in CVS), I fail to see any logic in having the selection tools possessing the ability to move selection contents, it is much simpler and more intuitive if they limit themselves to selecting regions and not engage in modifying drawables.

I agree completely.

A minor related note: the Affect Selection option of the Move Tool

displays two identical "Move Selection" options, both of which are always(?) grayed out.

Either you are misunderstanding what is actually there, or your build is messed up.
Try rebuilding from scratch, and then checking your assertion above.

On Thu, 2006-09-28 at 14:11 +0200, gg@catking.net wrote:

On Thu, 28 Sep 2006 13:48:29 +0200, Michael Natterer

Aha... so which of the tools under "Transform Tool" is not doing a transform? I don't see any that wouldn't perfectly fit into the category.

ciao,
--mitch

Mitch, please look back over the thread.

As quick reply because I'm repeating what has already been said, I don't
think moving a selection a bit to one side would seen as a "transforming"
it by someone who did not have a maths background. It's an example of a
broader issue.

I did read the thread, and moving *is* transforming. Yes mathematically and correctly. Making it a non-transform tool UI-wise makes no sense to me whatsoever. What else should it be then?

And what broader issue are you talking about?

ciao, --mitch

On Thu, 2006-09-28 at 21:48 +0930, David Gowers wrote:

On 9/28/06, saulgoode wrote:

Regarding the current user interface (in CVS), I fail to see any logic
in having the selection tools possessing the ability to move selection
contents, it is much simpler and more intuitive if they limit themselves
to selecting regions and not engage in modifying drawables.

I agree completely.

In Current CVS, you have to press alt+shift or alt+control to actually move the pixels with a selection tool. Nobody does that accidentially, and it's a powerful tool for power users. I see no reason to remove it.

A minor related note: the Affect Selection option of the Move Tool
displays two identical "Move Selection" options, both of which are
always(?) grayed out.

Either you are misunderstanding what is actually there, or your build is messed up.
Try rebuilding from scratch, and then checking your assertion above.

Well, should we simply hide these options when they make no sense? It's IMHO better to change the text to something that's actually happening and make them insensitive. That's the whole reasoning behind that.

ciao,
--mitch

On 9/28/06, Michael Natterer wrote:

On Thu, 2006-09-28 at 21:48 +0930, David Gowers wrote:

On 9/28/06, saulgoode wrote:

Regarding the current user interface (in CVS), I fail to see any logic
in having the selection tools possessing the ability to move selection
contents, it is much simpler and more intuitive if they limit themselves
to selecting regions and not engage in modifying drawables.

I agree completely.

In Current CVS, you have to press alt+shift or alt+control to actually move the pixels with a selection tool. Nobody does that accidentially, and it's a powerful tool for power users. I see no reason to remove it.

That is definitely a great feature, and I understand why it can't be assigned to a single key. I think it still needs to be made more accessible (personally I'd rate it as more important than being able to intersect the selection with the old selection; however it's less obvious than the intersect function)
Looks like I've comprehensively misunderstood what saulgoode was trying to say. -- Sorry, saulgoode.

Either you are misunderstanding what is actually there, or your build

is messed up.
Try rebuilding from scratch, and then checking your assertion above.

Well, should we simply hide these options when they make no sense? It's IMHO better to change the text to something that's actually happening and make them insensitive. That's the whole reasoning behind that.

What I meant here is that the only circumstances in which the 'affect selection' option of the Move tool is greyed out is when there is no image open, and that there is exactly one instance of it, not two. Oh, wait.. I see what saulgoode meant now. I think that it could be improved (the second radio option could be N/A and selecting 'affect selection' would force the radio selection to the first option (and set the radio group insensitive, as before))

Hi,

On Thu, 2006-09-28 at 14:39 +0200, Raphaël Quinet wrote:

2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point.

Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools.

Indeed. The image is also not filled with the last used color if the user switches to the Bucket Fill tool. Doing this for the transform tools would be very inconsistent.

Sven

On 9/28/06, Michael Natterer wrote:

In Current CVS, you have to press alt+shift or alt+control to actually move the pixels with a selection tool. Nobody does that accidentially, and it's a powerful tool for power users. I see no reason to remove it.

A feature being useful doesn't justify its misplacement in the command structure. Maybe that is stating things a bit harshly but "selection operations" should be limited to operating on selections. I am a great fan of overloading commands but there needs to be some basic and comprehensible limits to what groups of commands do, otherwise they cease to be "groups".

How is it any more of a "power tool" to hold ALT+CTRL while a Selection Tool is active versus pressing another key (such as "M") to activate a Move Tool? Especially since the result is a floating selection for which "selecting" will no longer be of any use (you can either Anchor or continue to Move).

And if moving the selection contents is such a useful tool to have at one's disposal (with which I would heartily agree), why is it an almost hidden auxiliary function of the Selection Tool -- with no equivalent elsewhere in the toolbox?

OFF-TOPIC: A screenshot of the Move Tool "double option" window is available at http://flashingtwelve.brickfilms.com/GIMP/Screenshots/Move.png

That was compiled from Monday's CVS. I will try rebuilding this weekend.

------------------------------------------------ "It is amazing what you can accomplish if you do not care who gets the credit." -- Harry S. Truman

On Thu, 28 Sep 2006 14:39:39 +0200, Raphaël Quinet wrote:

On Thu, 28 Sep 2006 01:42:12 +0200, gg@catking.net wrote: [...]

1/ In general I find it needs too many mouse/keyboard actions to achieve a
simple operation.

1a/ specific: undo : edit | undo . This must be one of the most common actions I want a one click solution, in the same window as I am editting in.

There's always cntl-Z cntl-Y but that means dropping the mouse and diverting my attention away fron the screen. Very slow.

Well, the undo shortcut is probably not assigned to Ctrl-Z by accident. Did you notice that there is no Z in "undo"? Something like Ctrl-U could have been used instead (and was used in the past). But many applications use Ctrl-Z. If you are a right-handed english-speaking user (or at least someone with a qwerty keyboard), you can see that Ctrl and Z are close to each other and can be pressed easily with the left hand while the right hand is on the mouse. You might complain about discrimination against lefties or foreigners, but at least for a large percentage of the users, the Ctrl-Z shortcut can be found easily without diverting attention from the screen or mouse.

Yes, I know cntl-Z can be hit with one hand but I am going to scrabble around unless I look, in which we're back to my original point. A close to hand undo button would be a lot faster.

1b/ I pull up a dlg. the first text entry is highlighted so I can type to
replace , fine. But if I want to edit it eg 100 to 400, I go to select the
"1" with the mouse and the editted text gets dragged. Huh? So I have to click to deselect the reselect the bit I want.

Solving this problem would probably require disabling drag & drop from the input fields. I am not sure that anyone uses that feature anyway, at least for the short entry fields that we have in most dialogs (except for the text tool). I agree that it is more likely that someone who clicks and drags in one of these short input fields wants to select some digits instead of dragging the whole number elsewhere.

This should probably be submitted in Bugzilla.

Done.

2/ I am continually repeating the same placement/configuration operations
where once should be enough.

2a/ It seems none of the filters retain thier position and size, although
they retains _some_ of their settings.

Right. We do not even have an API allowing the plug-ins to retain their size and position easily. Although the current API based on gimp_get_data() and gimp_set_data() could be used for that, every plug-in writer would have to write hacks around gimp_dialog_new() or gimp_dialog_run() in order to resize the window correctly. In addition, the filters that have a more complex layout with resizeable panes inside the window would also have to remember the size of each of them (e.g. Filters->Map->Bump Map) and those that have multiple tabs should remember which tab is active.

Taking Bump Map as an example, this is a good case in point. The preview autorescales so all we need is size and position to be reatained. Many of these previews are too small to see the effect clearly. That's my main reason to resize the dlg.

I think technical difficulties of implementation need to be separated from UI discussion until the value of the idea has been assessed. I would have other comments about the flexibility on API implementations.

specific: Filters | Motion Blur ... I resize to get a more visible preview size and move it out of the way of other things on the screen. Next time I use it I dont want to start again.

While this is probably down to the plugin writer, at least the "common" filters should be vetted/modded to retain size/pos before being integrated. And it should be recommended for all plug-ins.

I agree. Please submit this improvement proposal in Bugzilla. It may even be useful to remember the window positions (for the plug-ins) accross gimp sessions. In this case, this information should probably go into the pluginrc or something similar.

Done.

2b/ If I use a dlg on one image and set, say units to pixels , if I open another image or even duplicate I have to reset the same options.

specific: Image | Scale Image , set to percent . Duplicate image , Scale Image : back to default pixels.

Although it would make sense for Duplicate, I am not sure that it would be good to always remember the last values used when you create a new image. The defaults can be set in Preferences->Default Image and I would like these values to be used.

I was refering to scale image, duplicate was mentioned to show that each instance of the dlg reverts while the same instance retains. Rather inconsistant. Settings could be stored when the dlg is closed so that the same dlg on another image can retain them.

2c/ I have selected for tools to store settings but this seems limitted.

specific: again the Scale Image dlg. units combo. This is held for the time I edit an image but not affected by the config option :tools store settings.

I do not understand what you expect in this case. Things like the resolution, units, grid spacing and so on are a property of the image. The Scale Image dialog should just use what is specified for that image. But maybe I misunderstood what you meant.

I dont see what "tool store settings" does. I see some data about brushes if I plough through the configs but if I choose to work in percent rather than pixels this is not remembered.

May be this just needs to be more complete.

2d/ I set a value , eg rotation degrees or scale percent. Next time I pull
up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I
dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point.

Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools.

Well I looked at this with rotate. The preview on the image just shows the outline that will be rotated but does not move the image/selection until the dlg closes. This indeed seems the best of both worlds if it retains my last rotation setting. I either hit "go" or reset as you suggest.

There are different behaviours on both shear and perspective. That should probably be a bug report in itself.

If all were aligned to the rotate model this could work very well.

All these are minor things on their own but the overall effect is _several
times_ more mouse actions than are really needed to get a job done.

Right. This kind of usability feedback is useful and should be discussed here or in Bugzilla. Thanks for your comments.

No problem. In trying to debug a couple of issues I rapidly became frustrated with the ammount of time I was wasting on these repeated manouvres. If there's a willingness to address some of these points that's great.

-Raphaël

On Thu, 28 Sep 2006 19:12:57 +0200, Sven Neumann wrote:

Hi,

On Thu, 2006-09-28 at 14:39 +0200, Raphaël Quinet wrote:

2d/ I set a value , eg rotation degrees or scale percent. Next time I

pull

up the dlg it's back to NOP settings : zero degrees or 100% scaling.

Now I

dont necessarily want the same value but one thing it's sure I dont

need

is a NOP. Last entered value would be a better starting point.

Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools.

Indeed. The image is also not filled with the last used color if the user switches to the Bucket Fill tool. Doing this for the transform tools would be very inconsistent.

Sven

Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time you use it.

Bucket-fill remembers its settings but does not apply them until you ask. Rotate shows the selection outline rotated but not the pixels so if it remembered this would work well without arbitarily transforming the image before required.

If the other transforms were made consistant with rotate, all could retain values and you would have the best of both worlds and be more consistant than the current situation.

What do you think would be the best way to align these differences?

Hi,

On Thu, 2006-09-28 at 22:50 +0200, gg@catking.net wrote:

I think technical difficulties of implementation need to be separated from UI discussion until the value of the idea has been assessed. I would have other comments about the flexibility on API implementations.

I don't think this needs much further discussion. We already have plans for adding a GimpPlugInDialog widget and porting the plug-ins to it. Such a dialog would provide a framework for loading and storing plug-in settings or at least for changing the defaults. It could also take care of session management such as setting the window size.

I dont see what "tool store settings" does. I see some data about brushes if I plough through the configs but if I choose to work in percent rather than pixels this is not remembered.

IIRC, the dialog currently takes the unit from the image that is being edited. This seems to make some sense to me and it might be difficult to decide when it makes sense to use percent instead. Or perhaps percent would even be a better default? We should ask some users.

Well I looked at this with rotate. The preview on the image just shows the outline that will be rotated but does not move the image/selection until the dlg closes. This indeed seems the best of both worlds if it retains my last rotation setting. I either hit "go" or reset as you suggest.

IIRC, the Rotate tool shows a preview of the rotation by default. If it shows only the outline for you, then you probably changed the default rotate tool settings.

Sven

Hi,

On Thu, 2006-09-28 at 23:01 +0200, gg@catking.net wrote:

Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time you use it.

Your "accusations" are unfair. First of all, your GIMP setup seems somewhat screwed. Try to reset the tool options or remove the ~/.gimp-2.3/tool-options folder. And you also ignore the fact that a lot of thought has gone into the current behaviour. It would help if you could appreciate that and ask before you jump to conclusions quickly.

Also you need to admit that your usage of GIMP is just one possible way of using it. We don't know much about you yet, so we can't tell if your usage patterns are in any way representative for a large user group.

We are willing to do changes. But very often people forget to see all aspects of user interface design. Are you sure that you have thought about all possible user scenarious? Are you sure that you understood the rationale behind the current behaviour? If not, it might be a good idea to ask those questions first.

Sven

On Thu, 28 Sep 2006 12:32:33 +0200, saulgoode wrote:

A google of
"CAD translations and transformations" will readily display how the two operations are commonly paired. Perhaps a better question to ask would be what graphics programs *don't* associate these operations?

Be careful not to prejudice that answer with the question you ask. Gimp is not CAD. CAD users will be architechs and engineers and probably see things in a more mathematical way like most of us here do.

If you do the search you suggest you are not likely to find links saying these two are unrelated. The fact you use "translations" rather than "move" will also bias what you find. Your background is unconsciously affecting the question and hence the answer.

It is a basic technique of market researcher and opinion polls. Word the question in such a way as to get the replies your client wants.

Perhaps a better question to ask would be what graphics programs *don't* associate these operations?

Yes, a quick look at PS and PSP for a start.

Bills idea of some more serious user research is good, though there's the same danger of prejudicing the result if you're not careful.

You'd have to explain the function of each tool without any reference to Gimp since asking the user test each tool and classify it will necessarily implant an association in his mind.

A quick scan of other software would be a good starting point to see if Gimp does some of this better or worse and pick up a few ideas.

I read somewhere of a technique of studying UI design with imaginary stereotype users with a specific, typical task to do. Then looking at the steps they would have to go through and imagine how they would likely go about it.

On Thu, 28 Sep 2006 23:21:15 +0200, Sven Neumann wrote:

Hi,

On Thu, 2006-09-28 at 23:01 +0200, gg@catking.net wrote:

Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time
you use it.

Your "accusations" are unfair. First of all, your GIMP setup seems somewhat screwed. Try to reset the tool options or remove the ~/.gimp-2.3/tool-options folder. And you also ignore the fact that a lot of thought has gone into the current behaviour. It would help if you could appreciate that and ask before you jump to conclusions quickly.

Also you need to admit that your usage of GIMP is just one possible way of using it. We don't know much about you yet, so we can't tell if your usage patterns are in any way representative for a large user group.

We are willing to do changes. But very often people forget to see all aspects of user interface design. Are you sure that you have thought about all possible user scenarios? Are you sure that you understood the rationale behind the current behaviour? If not, it might be a good idea to ask those questions first.

Sven

Sven, (and the rest of the team) please don't take any of this the wrong way.

I made a list of things that I found held me back. This is in no way suggesting that no-one has put any thought into this interface , clearly they have. By and large it works very well. I would like to help you improve it.

I clearly stated that all of the issues were minor but the overall effect was that a lot more mouse input was required than was really necessary.

I listed a number of points , not as a means of ripping it apart, but to give clear indications where I could identify lost time and hence give something concrete to look into rather than broad unjustified comments.

You will appreciate it also takes time to go through all this and give precise, hopefully useful, criticisms.

Neither do I assume my way of working is typical, it almost certainly is not, because like most of you on this list I have a technical programmers background and a good knowledge of maths.

What I say about settings is not that the one's I choose are in any way better or typical but that there is a need to retain user settings in order to avoid a lot of unwarranted repetition.

Sorry if I have a bit of a blunt style , I do tend to come straight to the point. This is not meant to be dismissive or disrespectful of the work that has been done.

We all also know email is a lousy form of communication and it's easy to take things the wrong way. You and Bill in particular have been very helpful in helping find my way around the code and I've felicitated you on the openness of your approach.

Let's not let irritations drift drift in the way here.

Thanks for your time and comments.

On 9/27/06, Raphaël Quinet wrote:

This is a different issue from what was discussed here. You can toggle between moving layers, selection masks or paths by using the modifiers: Ctrl or Alt (this will soon be indicated in the status bar). I don't

How will this be indicated? Is it via 'discovery mode' or 'explicit mode'?

Discovery mode = Press shift, the description changes.

Explicit mode = At the bottom of the toolbox (or in a tooltip, or ...) a guide: [Move] = Pick Layer/Guide
[Shift] = Move Layer/Guide
[Ctrl] = Pick Path
[Ctrl][Shift] = Move Path
[Alt] = Move Selection
[Alt][Shift] = Move Selection (again?)

These are the 2.2.13 options. I have to say I don't see a difference between 'pick' and 'move' for the normal/shifted case but I didn't try too hard. The [Alt] selections are very confusing, too. [Alt]-drag moved the window (KDE grabs it); [Alt][Shift]-drag picks "the other move" but the mouse cursor looks like a "ø". And [Shift][Alt]-drag shows "move layer" in the tool menu but drags an outline that doesn't affect the image if the entire image is masked, then returns to the [Alt][Shift] tool options; while if the mask is not present behaves like a regular move and returns to the [Alt][Shift] tool options with the mouse cursor now a "ø".

Hmm. Selection/Quickmask confuses me. Things that operate on selections have icons that look like quickmasks. Anyway ...

The 'scale' tool has the largest toolbar options area (2.2.13). With the toolbar maximized on my 1280x1024 screen, there's lots of blank space on the bottom where the shift-modifiers can be explicitly enumerated (it looks like they already are in this case, but a uniformity would be good). I'm not positive, but this could also be helpful for informing the user of "pre-use" and "during-use" modifiers, like the wacky select add/remove/square/center/move tools.

I'm thinking of something that just looks like the list I have above, but with widgets for the [shift] keys, bottom aligned to the toolbox. Alternately, they could be in a giant tooltip, but this would prevent showing the 'during-use' modifiers.

Does this seem like a valid use of the toolbox option pane?

Chris

On 10/4/06, Christopher Curtis wrote:

These are the 2.2.13 options. I have to say I don't see a difference between 'pick' and 'move' for the normal/shifted case but I didn't try

Move moves the current item; pick moves the item that it thinks you're clicking on. In 2.3.x, the tool options indicate this clearly.

Does this seem like a valid use of the toolbox option pane?

Too much has changed since 2.2 . I recommend you try a 2.3.x version, your comments on that would be more relevant. The main comment from your mail that does apply is '[Alt]-drag moved the window (KDE grabs it)' -- however, in 2.3.x, you can use [Alt-Shift]-drag OK, so it could be improved but it's also easy to work around.