On 10/12/06, Philip Ganchev wrote:

Hi.

I have a suggestion for a new and simple way to interact with GIMP.

A major difficulty in using GIMP, in my experience, is that the menus are too many and too deep. To invoke an action on an image, or to open a dialog box, the user spends a lot of time and concentration navigating the menus, usually with the mouse. And, despite best efforts to organize the menus, finding the right item for the operation you want can be difficult.

A more efficient alternative would be to let the user try to express his intention more freely, and show him a menu of options that might be what he wants. This is in effect search for the right command, and the user sees the list of options *as he types*. A command is any conventional menu item or folder in the current menu hierarchy.

A query matches substrings of names or descriptions of commands. The names and descriptions of matching commands appear in a drop down box underneath the query box. The user can hit Enter to select the first entry, or use the arrow keys to select another entry, then press Enter. Thus the selection of actions and menus shrinks as the user types. If a query contains multiple words, they are matched as a conjunction (not as a string).

For example. if the user types "size", he sees the options "Scale image - resize the image", "Set canvas size", and "Print size". Selecting the first option invokes resize mode, as if the item "Image / Scale image" had been selected from the conventional menu.

I really like this kind of interface. Consider this, though:

it doesn't map directly to normal menus. For example, there are layer->transform menus and image->transform menus, both of which contain identically-named entries. It's more like function-name completion; in that case, no ambiguity exists because only one function of the same name can ever be apparent. How do you make it convenient to choose either rotate the layer 90degrees or rotate the image 90degrees? I reckon that might require the addition of a separate string to use for completion instead of menu name.

It's possible that the menu registration code could address this (generating unique completable command names); in that case you'd need to avoid the possibility of newly added menu items causing the existing completion behaviour to change (ie. where you type the same sequence but now get a different and likely wrong result.)

The search can be invoked with a key combination like Control+F

(or

perhaps just by typing?).

If this was implemented, I'd expect it to replace the menus, so personally I would expect to just hit the Menu key and start typing. Ctrl-F is quite unwieldy (if the function is going to be commonly used, a single key trigger is highly desireable)

What do you mean by just typing? clearly you cannot just type when the completion is not yet active -- that would conflict with keyboard shortcuts. And if

I am not sure if the query box should be

visible all the time, or appear when the keys are pressed and dissapear when the command is executed.

Personally I'd like it to show in place of the current statusbar message (sort of like an inverted browser URL field). In a program as big as the gimp, eliminating unnecessary widgets is important; so i suggest that probably such a thing would work best with a temporarily visible query box
The third option you presented, "appear when the keys are pressed and dissapear when the command is executed." == modality, which tends to be confusing and should be avoided if possible

If it is the latter, it can replace the menu bar, to save window

It can, maybe.. personally I don't have a menu bar, but I do have a status bar. I expect there will be some who have a menu bar, but not a status bar. It warrants some thought.

space. The the list should not obscure too much of the image. So,

the size of the results box should be constrained, and a scrollbar should appear if needed.

The history of executed commands (and their descriptions) appears in reverse order the results box, if the user clicks on or presses the Down arrow key in an empty query box.

sounds okay.

Hi Phillip,

The two major use cases when this would be a more efficient interface is for us GIMPers who already know what functionality they want and don't need to go three levels deep, but also for novice users for who it will perhaps be easier to search for 'replace color' instead of browsing through the menu tree. If filters and functions have some additional metadata, providing for example name of the same functionality in competing graphic packages, things would become easier to discover for novices.

Additionally this interface would allow to provide not only a brief name of the function, but also a small graphic demonstrating the function where applicable. I envisioned using a tile-based interface for this not unlike the beagle-search tool* but never gotten to mock things up. Feel like speccing things up? ;)

This would be a nice summer of code project for next year.

* http://upload.wikimedia.org/wikipedia/en/5/54/Beagle-search.png

On 10/13/06, Philip Ganchev wrote:

On 10/12/06, David Gowers wrote:

On 10/12/06, Philip Ganchev wrote:

[...]

it doesn't map directly to normal menus. For example, there are layer->transform menus and image->transform menus, both of which contain identically-named entries. It's more like function-name completion; in

that

case, no ambiguity exists because only one function of the same name can ever be apparent. How do you make it convenient to choose either rotate

the

layer 90degrees or rotate the image 90degrees? I reckon that might

require

the addition of a separate string to use for completion instead of menu name.

Every command should have a description, such as "transform, rotate the layer 90 degrees". If you type "rotate" you would see both "transform, rotate the image 90 degrees" and "transform rotate the layer 90 degrees". If you type "rotate layer" or "layer rotate", you would not see the former.

I would argue that you need the "transform" part of the description above, because "rotate" commands should show up if a user searches for "transform".

It's possible that the menu registration code could address this

(generating

unique completable command names); in that case you'd need to avoid the possibility of newly added menu items causing the existing completion behaviour to change (ie. where you type the same sequence but now get a different and likely wrong result.)

The descriptions can perhaps be automatically generated from the menu system. But it is probably better to edit them manually, to make sure they are concise and meaningful.

How bad would it be if a new command appeared where you are used to seeing an old one? It would be bad mostly if you have habituated to a particular query pattern for a particular command, so that you hit Enter without selecting from the results.

This can be avoided if the order of commands is predefined. New commands would have the least priority, unless they are explicilty moved relative to others. For example if I add a new command "rotate colors" and query for "rotate", it would appear after "rotate image" and "rotate layer", even though it comes before them alphabetically.

The search can be invoked with a key combination like Control+F

(or
perhaps just by typing?).

If this was implemented, I'd expect it to replace the menus, so

personally I

would expect to just hit the Menu key and start typing. Ctrl-F is quite unwieldy (if the function is going to be commonly used, a single key trigger is highly desireable)

A single key would definitely be peferable. What is the menu key? Is it a standard key, found on most keyboards?

Unfortunately not. It is a key found on keyboards with the 'Windows' keys or their equivalent. GTK treats it as an indication to pop up the menus (Alt does sort-of the same thing; Shift-F10 does exactly the same thing)

What do you mean by just typing? clearly you cannot just type when the

completion is not yet active -- that would conflict with keyboard

shortcuts.

And if

Something missing here?

I may have been thinking about mnemonics, but they shouldn't interfere.

The third option you presented, "appear when the keys are pressed and dissapear when the command is executed." == modality, which tends to be confusing and should be avoided if possible

Actually, the pop-up and dissapearance is not modal. The definition of "modality" that I know is "a difference in responce to the same user gesture depending on the system state, while the current state is not the user's locus of attention" (modified from The Humane Interface). There is no difference in response with respect to popup.

There is modality in that typing a key in search mode shows you commands that match that key, while in normal mode it executes a command. A way to avoid that is to use a quasi-mode, such as searching only while Alt is pressed, and executing the selected command when Alt is released. This may work, though I expect it would be ergonomically hard.

Instead, I would suggest that the single-keystroke commands be removed. The search system does the same job in a much more general, discoverable, understandable way (since it gives feedback). It is

I cannot agree with that. I use those commands a lot, to switch paint tools for instance; there is no way that I could get the same speed of workflow if I was *required* to use the search system for basics like that.

I think you overlook that, the value of keyboard shortcuts to a user's workflow.

"transform, rotate the layer 90 degrees" That sounds awkward. In general, I think this form would be good VERB NOUN [..] (CATEGORY)

where [..] is any additional part; category could be more that one, comma-separated, but would usually be only one.)

so in this case

Rotate layer 90 degrees (transform)

I believe that you will find that leaving out the 'the' is necessary to make some of the longer command descriptions reasonably readable.

On 10/13/06, Philip Ganchev wrote:

This can be avoided if the order of commands is predefined. New commands would have the least priority, unless they are explicilty moved relative to others. For example if I add a new command "rotate colors" and query for "rotate", it would appear after "rotate image" and "rotate layer", even though it comes before them alphabetically.

This is a good idea; I cannot comment on what tecnical aspects would be needed to make it work.

There is modality in that typing a key in search mode shows you commands that match that key, while in normal mode it executes a command. A way to avoid that is to use a quasi-mode, such as searching only while Alt is pressed, and executing the selected command when Alt is released. This may work, though I expect it would be ergonomically hard.

A fairly nice way would be like this

Alt-R (release alt) otate layer

More of the initial letters could be typed with alt if it suited the user. And of course, the query should be terminatable by pressing Escape.

If there is no menu bar, the query box can pop up over the image. Or

it can move the image down to make space when it appears.

The first of these suggestions would work well. The second would almost certainly be very irritating.

Philip Ganchev wrote:

On 10/12/06, Jakub Steiner wrote:

The two major use cases when this would be a more efficient interface is for us GIMPers who already know what functionality they want and don't need to go three levels deep, but also for novice users for who it will perhaps be easier to search for 'replace color' instead of browsing through the menu tree. If filters and functions have some additional metadata, providing for example name of the same functionality in competing graphic packages, things would become easier to discover for novices.

I agree that the commands should be searchable by many terms. But I think all terms should be part of the description, not be metadata.

We should probably check how emacs does this - the M-x whatever-command is pretty close to this proposal, and there are ways to seach for specific commands as well.

HTH, Michael

On Fri, 2006-10-13 at 01:04 +0200, Michael Schumacher wrote:

Philip Ganchev wrote:

On 10/12/06, Jakub Steiner wrote:

The two major use cases when this would be a more efficient interface is for us GIMPers who already know what functionality they want and don't need to go three levels deep, but also for novice users for who it will perhaps be easier to search for 'replace color' instead of browsing through the menu tree. If filters and functions have some additional metadata, providing for example name of the same functionality in competing graphic packages, things would become easier to discover for novices.

I agree that the commands should be searchable by many terms. But I think all terms should be part of the description, not be metadata.

We should probably check how emacs does this - the M-x whatever-command is pretty close to this proposal, and there are ways to seach for specific commands as well.

No. You don't want to look at emacs code. Really. Such an interface is easy enough to implement, should we ever decide to want it. I seriously doubt its usefullness for the vast majority of GIMP users.

ciao, --mitch

Michael Natterer writes:
> No. You don't want to look at emacs code. Really.

While talking about Emacsish features, one feature I often miss in GUI apps is something equivalent to Emacs's C-h c (describe-key-briefly).

I.e., a way to find out what a certain keypress does. The main use case for this would be when you by accident press the wrong key, and you don't immediately notice anything happening, but you still are afraid that by mistake you have done damage to your document.

OK, so in most well-written apps Undo will undo any such inadvertent changes. (But if you don't know if your accidental keypress did anything or not, you don't know what Undo will undo...). It helps a bit if the menu entry for Undo says what the last operation that are to be undone is called. Or if the app has a history feature. But still...

--tml

On 10/12/06, Philip Ganchev wrote:

Hi.

I have a suggestion for a new and simple way to interact with GIMP.

A major difficulty in using GIMP, in my experience, is that the menus are too many and too deep. To invoke an action on an image, or to open a dialog box, the user spends a lot of time and concentration navigating the menus, usually with the mouse. And, despite best efforts to organize the menus, finding the right item for the operation you want can be difficult.

A more efficient alternative would be to let the user try to express his intention more freely, and show him a menu of options that might be what he wants. This is in effect search for the right command, and the user sees the list of options *as he types*. A command is any conventional menu item or folder in the current menu hierarchy.

I guess you should have a menu or a similar interface in addition/tandem with a query interface. I have implemented a similar solution in my prototypes of more advanced layer interfaces and added one more thing, items can exist in multiple locations in the menu system with the aim to make it easier finding what you are looking for when only browsing the menu as well.

http://pippin.gimp.org/tmp/search-menu.gif contains a recorded animation of the UI elements I've been using.

/Øyvind K.

On Fri, Oct 13, 2006 at 09:19:29AM +0200, Michael Natterer wrote:

On Fri, 2006-10-13 at 01:04 +0200, Michael Schumacher wrote:

No. You don't want to look at emacs code. Really. Such an interface is easy enough to implement, should we ever decide to want it. I seriously doubt its usefullness for the vast majority of GIMP users.

Why not??! As a user, I would very much welcome an emacs-style interface. Ctrl-H a (apropos) would logically do what is being discussed here. Ctrl-H c to describe the command associated with a key would be excellent as well. Those commands run lightning-fast in emacs compared with the snail-like workings of the gimp/gtk. But whatever you do, please, please, PLEASE do not do as one poster suggested and eliminate single-keystroke commands!! The ability to assign your own keys to gimp commands on the fly is one of its shining features, IMHO.

Scott Swanson

* Philip Ganchev [061013 23:09]:

On 10/13/06, Øyvind Kolås wrote:

http://pippin.gimp.org/tmp/search-menu.gif contains a recorded animation of the UI elements I've been using.

I did not understand what is the purpose of the interface in the animation. I see that you have some searching, but there is a lot of use of the mouse, which is generally inefficient.

The purpose of the animation was not to demonstrate search, it is just demonstrating the capabilities of a very rough prototype. Which is also the reason the menu was used for browsing the available operations most of the time.

That user interface was not, and still is not in a state where use by normal users would be encouraged; and it is still too early to put too much focus on a GUI for that system anyways since the architechture has many issues that needs to be fixed on a deeper level.

/Øyvind K. --
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/

On 10/14/06, Philip Ganchev wrote:

Unfortunately not. It is a key found on keyboards with the 'Windows'

keys or

their equivalent. GTK treats it as an indication to pop up the menus

(Alt

does sort-of the same thing; Shift-F10 does exactly the same thing)

You're not suggesting that Shift+F10 is better than Control+F, right? At least Control key and 'F' key are close to each-other.

Not on my keyboard. 12cm from the corner of ctrl to the corner of F; 13cm from the other ctrl key to the corner of F; 8.5cm from the corner of shift to the corner of F10.

However, no, I wasn't suggesting that. Merely that the menu key should be supported for this purpose and indicated as the preferred method when possible. i.e. 'use the Menu key to access the menu searching function; If you don't have a Menu key on your keyboard, use Ctrl+F'

The people I know who use Gimp use it only occasionally, and they do not use shortcuts. I did not know they existed until someone mentioned it in reply to my post.

I find it difficult to believe that you are in a position to comment on gimp usability, without experience with such a vital feature. Even the horrific MSPaint has keyboard shortcuts.

I also wonder how you could have possibly missed them, since they are printed right next to the menu items, just as is standard in modern UI design.

I suppose there are ergonomic advantages to one-hand command invocation if

1. you hold the mouse with the other hand, and 2. there is a keyboard shortcut for the action you want, and 3. you know what it is without having to check.

How many command shortcuts can a user be expected to remember? 10? 20? So we are choosing between the ergonomic convenience of one-key

I think I have about 40 memorized, of 60-70 I've defined (all custom -- I deleted every default one.); I admit I am atypical, however.

invocation for 20 commands, and the cognitive convenience of the

general search for all commands, current and future.

That's true, but tools are -- as their name implies -- used a lot. In particular, I often use the selection tools in combination with each other or with Blend or Bucketfill tools.

You say that moving your hand from the mouse to the keyboard takes too

long.

I haven't commented on that subject at all (and it is not normally a problem for me -- I typically have the layout left to right keyboard, tablet, mouse; I draw righthandedly and key lefthandedly, using the mouse without putting down the tablet stylus when needed.)

However, moving a hand from the mouse to the keyboard -- which I remember from the bad old days when I didn't have a tablet -- is indeed a significant speed hit.

You must edit with lightning speed. For me, moving my hand to

the keyboard is negligible compared to choosing the right points on the image to apply the selected tool, choosing the right color, etc.

All I mean is that I have also memorized many menu mnemonics, which are comparable to this proposed method WRT number of keystrokes, and using them is extremely sluggish compared to keyboard shortcuts.

An example of the magnitude of the difference is picking colors by moving through a palette -- '(' and ')' are the shortcuts for that by default -- and manually finding an appropriate spot on the image and eyedropping. It's also directly comparable to your search idea. I say this completely seriously -- if I couldn't do such things as select between palette colors or tools quickly, or swap between FG/BG colors, GIMP would be almost entirely useless to me. I do not intend to work with chains around my wrists.

I use Gimp for creation PRIMARILY; It sounds as if you are thinking of GIMP as a tool for primarily editing and secondarily creation.

The factors that you discard the significance of effect revision speed a lot. Everything that interrupts your workflow is evil. This amounts to anything more complex than a single-part keypress/mouseclick/tablet gesture. An exclusive implementation of your scheme requires constant searching and MANY keypresses.

Example: I want to select pencil tool. P (choice of .. a lot of items)
PE (choice of .. a lot of items)
PEN (choice of 'Open', 'Open Location','Open as Layer', 'Sharpen (selection)','Blur / Sharpen', 'Sharpen (drawable)','Pencil' ) PENC (selects 'Pencil')

versus keyboard shortcut 'N' (or Shift+P in a vanilla gimp setup)

versus menu mnemonics 'Alt-T-P-N'

That was one of the most conservative examples I could find; at best, it only matches the number of keypresses needed to use the existing menu access methods. Arguably, you could implement it to sort the items by how early the search strings occur; then you might be able to type pe[Enter] -- If you were looking for pencil tool rather than perspective tool.

Another example is UNDO/REDO! I cannot even really take seriously the suggestion of having such a vital feature immediately available.

Do you really think that it could justifyably replace the existing system, with such a non-performance?

I believe that you will find that leaving out the 'the' is necessary to

make some of the longer command descriptions reasonably readable.

Perhaps. I thought that using whole sentences would be clearer. For example, "rotate layer 90 degrees" can be taken as a phrase about a kind of layer, a "rotate layer". Clarity is important.

Thats true, although rotating a rotate layer probably wouldn't make much sense anyway :)

On Sat, Oct 14, 2006 at 04:55:04AM -0400, Philip Ganchev wrote:

I suppose there are ergonomic advantages to one-hand command invocation if 1. you hold the mouse with the other hand, and 2. there is a keyboard shortcut for the action you want, and 3. you know what it is without having to check.

This is probably as good a place as any to ask: with this idea, has the impact on graphics tablet users been considered? If we're talking about this idea as a menu replacement (as opposed to a menu alternative), I think you're going to piss those users off. With menus you never have to go near the keyboard for editing if you don't want to; I'd imagine most tablet users stay well clear from the keyboard when working, as they tend to be quite bulky (the tablets, not the users). The keyboard gets pushed off to one side and the tablet comes to the fore.

Although I don't have a tablet, that's how I use the gimp. The only time I go near the keyboard is entering text (rare) and entering numbers (slightly more common). For most tasks I'm entirely mouse-driven. If someone insisted I use the keyboard (and with both hands, if I'm typing full words) I would not be a happy user.

On 10/15/06, Alex Pounds wrote:

On Sat, Oct 14, 2006 at 04:55:04AM -0400, Philip Ganchev wrote:

I suppose there are ergonomic advantages to one-hand command invocation

if

1. you hold the mouse with the other hand, and 2. there is a keyboard shortcut for the action you want, and 3. you know what it is without having to check.

This is probably as good a place as any to ask: with this idea, has the impact on graphics tablet users been considered? If we're talking about this idea as a menu replacement (as opposed to a menu alternative), I think you're going to piss those users off. With menus you never have to go near the keyboard for editing if you don't want to; I'd imagine most tablet users stay well clear from the keyboard when working, as they tend to be quite bulky (the tablets, not the users). The keyboard gets pushed off to one side and the tablet comes to the fore.

This is true; navigating the menus is quite quick by tablet (or the UI in general; it works far better than a mouse for UI navigation generally)

Another issue is tear-off menus. The current functionality can be quite useful when performing a group of similar operations. I would expect the ability to tear off the currently selected search items to be a crucial part of a search feature.

I've considered the idea of making keyboard shortcuts modifier-only.. This is not too bad. It does have the following issues: * There is no good reason to prohibit the F1,F2...F12 keys from being assigned without modifier (or the insert/home/end/pageup/pagedown keys), but if this is not done then it is inconsistent. * Requiring modifiers limits the number of keys available for effective keyboard shortcuts.
On my keyboard, this means something like

123 ',.
aoe
;qj

on the left

and

[]\ l/=
ns-
wvz

on the right.

I think some, other things can be fixed without much complication. For instance, menu item selection is modal: if there are two conflicting mnemonics in a menu, then pressing that mnemonic the first time will select the first, pressing it again will select the second. The reason qualifies as modal is that it seems to be stored between menu accesses.

For an example (with recent cvs) try this:

Alt-C-A (then dismiss the menu) Alt-C-A (then dismiss)
Alt-C-A (then dismiss)

On Fri, 13 Oct 2006 12:15:51 +0200, Øyvind Kolås wrote:

On 10/12/06, Philip Ganchev wrote:

Hi.

I have a suggestion for a new and simple way to interact with GIMP.

A major difficulty in using GIMP, in my experience, is that the menus are too many and too deep. To invoke an action on an image, or to open a dialog box, the user spends a lot of time and concentration navigating the menus, usually with the mouse. And, despite best efforts to organize the menus, finding the right item for the operation you want can be difficult.

A more efficient alternative would be to let the user try to express his intention more freely, and show him a menu of options that might be what he wants. This is in effect search for the right command, and the user sees the list of options *as he types*. A command is any conventional menu item or folder in the current menu hierarchy.

I guess you should have a menu or a similar interface in addition/tandem with
a query interface. I have implemented a similar solution in my prototypes of more advanced layer interfaces and added one more thing, items can exist in multiple locations in the menu system with the aim to make it easier finding what you are looking for when only browsing the menu as well.

http://pippin.gimp.org/tmp/search-menu.gif contains a recorded animation of the UI elements I've been using.

/Øyvind K.

I also find as a user that menus often go too deep.

One sub-menu is acceptable , two starts to get unwieldy. Eg. I ofter copy a selection and Paste As New , this is three levels deep. I'd like to see this at the same level as Cut: Cut | Paste | Paste as New. I crated a hot-key as a work around but as others have said , I would rather keep my eyes on the screen except for typing numbers etc.

Another improvement would to clean up some menus. The Blur menu seems to contain several, largely equivalent filters. Two would suffice and could be incorporated into Enhance.

I also created a bug about making sure sub-menus did not jump from one side to the other. This is appalling from a usability point of view but the comment did not get a very positive response.

Sometimes "logical grouping" of functions takes precedence over usability. Some real basics like flip and rotating an image to straighten it up should be on the image menu.

Some anomolies could be looked at, I can free-rotate a layer but not an image.

Colors | Retinex ?? What's that supposed to tell the user? It seems to be an enhancment filter to me.

Making the menus a bit more usable may reduce the calls for a replacement.

my-2c

/gg

gg wrote:

I also find as a user that menus often go too deep.

One sub-menu is acceptable , two starts to get unwieldy. Eg. I ofter

copy

a selection and Paste As New , this is three levels deep. I'd like to

see

this at the same level as Cut: Cut | Paste | Paste as New. I crated a hot-key as a work around but as others have said , I would rather keep

my

eyes on the screen except for typing numbers etc.

Is there a reason you don't use tear-off menus? Having small sub-menus actually enhances this utility.

Another improvement would to clean up some menus. The Blur menu seems to contain several, largely equivalent filters. Two would suffice and could be incorporated into Enhance.

Which two would suffice? Personally, I find all of them useful and I wouldn't recommend combining filters that use different algorithms into one interface -- not only would this complicate maintenance and development but menu grouping is a great indicator of a command's function.

I also created a bug about making sure sub-menus did not jump from one side to the other. This is appalling from a usability point of view but the comment did not get a very positive response.

If your proposal were accepted, there would be reports submitted complaining that all the submenus appear on the left when there might be only one that's overly-long. My preference is to minimize the number of times that my eyes have to "jump" from the far right of menu text to the far left of sub-menu (much less appalling to just "continue reading left to right").

Some real basics like flip and rotating an image to straighten it up should be on the image menu.

Erm, they are.

Some anomolies could be looked at, I can free-rotate a layer but not an image.

Erm, you can.

Colors | Retinex ?? What's that supposed to tell the user?

It tells me that it performs an operation called Retinex on the image. If I did not know what the word Retinex meant then, just like any other word with which I was unfamiliar, I would look it up. If Retinex is an inaccurate description of the processing taking place, a change in name might be called for but otherwise I would submit that the purpose of the GIMP is not to serve as a dictionary of graphics terms.

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

On 10/15/06, Saul Goode wrote:

Some anomolies could be looked at, I can free-rotate a layer but not an image.

Erm, you can.

That is true, but it is non-obvious; and particularly, I only just discovered (due to your prompt) that transforms apply to all linked objects, not just the linked objects of the same type as the object that you are visibly transforming.

I think it might well be worth adding an additional mode to transform tools, that ignores linked status and simply transforms everything that can be -- layers, channels, paths.

For anyone else's interest, the quickest way to transform the image is:

* Link all the items (layers, channels, or paths) -- for each kind of item, shift-click on the 'linked' field of any one item until all are linked (max 2 clicks needed per kind of item)
* Use the transform tool in Layer or Path transform mode.

Colors | Retinex ?? What's that supposed to tell the user?

It tells me that it performs an operation called Retinex on the image. If I did not know what the word Retinex meant then, just like any other word with which I was unfamiliar, I would look it up. If Retinex is an inaccurate description of the processing taking place, a change in name might be called for but otherwise I would submit that the purpose of the GIMP is not to serve as a dictionary of graphics terms.

Agreed. The manual should give a brief overview, which it does in this case:

" "Retinex" improves visual rendering of an image when lighting conditions are not good.
While our eye can see colors correctly when light is low, cameras and video cams can't
manage this well. The MSRCR (MultiScale Retinex with Color Restoration) algorithm, which
is at the root of the "Retinex" filter, is inspired by the eye biological mecanisms to
adapt itself to these conditions. "Retinex" stands for Retina + cortex.

Besides digital photography, Retinex algorithm is used to make the information in
astronomical photos visible and detect, in medicine, poorly visible structures in X-rays
or scanners.
"

On Sun, 15 Oct 2006 04:36:53 +0200, Saul Goode wrote:

gg wrote:

I also find as a user that menus often go too deep.

One sub-menu is acceptable , two starts to get unwieldy. Eg. I ofter

copy

a selection and Paste As New , this is three levels deep. I'd like to

see

this at the same level as Cut: Cut | Paste | Paste as New. I crated a hot-key as a work around but as others have said , I would rather keep

my

eyes on the screen except for typing numbers etc.

Is there a reason you don't use tear-off menus? Having small sub-menus actually enhances this utility.

I assume a "tear-off" menu is the context menu I get from a right-mouse click. I dont see the gain here, it's actually one click more than using the edit menu.

If I misunderstood, could you explain what a tear-off is?

Another improvement would to clean up some menus. The Blur menu seems to contain several, largely equivalent filters. Two would suffice and could be incorporated into Enhance.

Which two would suffice? Personally, I find all of them useful and I wouldn't recommend combining filters that use different algorithms into one interface -- not only would this complicate maintenance and development but menu grouping is a great indicator of a command's function.

This menu could use some work, pixise is not a blur, it may be better in distortions menu.
Gaussian blur, Selective Gaussian blur and tile seem to do basically the same thing with more or less options on the interface. I have not looked at the source but it seems they could be combined. This may actually reduce any future maintainance.

Whether the non-adjustable blur is useful next to these may be worth thinking about.

Motion blur clearly is a separate tool.

If sharpen is an "enhancement" so is it's complement blur. It would probably be helpful for them to be together in Enhancement menu.

I also created a bug about making sure sub-menus did not jump from one side to the other. This is appalling from a usability point of view but the comment did not get a very positive response.

If your proposal were accepted, there would be reports submitted complaining that all the submenus appear on the left when there might be only one that's overly-long. My preference is to minimize the number of times that my eyes have to "jump" from the far right of menu text to the far left of sub-menu (much less appalling to just "continue reading left to right").

I'm not sure we're talking the same language here.

my complaint was exactly that , that from one submenu to another the submenu can come up left or right which is visually distruptive.

http://bugzilla.gnome.org/show_bug.cgi?id=358816

Some real basics like flip and rotating an image to straighten it up should be on the image menu.

Erm, they are.

I dont know what gimp you are looking at, I refer to 2.3.12 from cvs. There are no rotate operations on the image menu, all are in a submenu.

Some anomolies could be looked at, I can free-rotate a layer but not an image.

Erm, you can.

Can you please clarify what you mean. I look at the Image | Transform and I only get the simple 90deg and flip options.

Where do you see rotate image?

Colors | Retinex ?? What's that supposed to tell the user?

It tells me that it performs an operation called Retinex on the image. If I did not know what the word Retinex meant then, just like any other word with which I was unfamiliar, I would look it up. If Retinex is an inaccurate description of the processing taking place, a change in name might be called for but otherwise I would submit that the purpose of the GIMP is not to serve as a dictionary of graphics terms.

The hint is good here. "Enhance contrast with Retinex method" . So what is the key information here?
I would suggest "Enhance contrast" makes more sense as an entry in the color menu than an obscure name of the algorithm used. The hint then gives the extra info about what method is applied.

Thanks for your detailed reply.

/gg

On 10/15/06, gg@catking.net wrote:

Is there a reason you don't use tear-off menus? Having small sub-menus actually enhances this utility.

I assume a "tear-off" menu is the context menu I get from a right-mouse click.

Which is wrong ;-)

http://www.fifi.org/doc/gnumeric-doc/html/C/figures/tear-off-menu.png

Alexandre

gg wrote:
I assume a "tear-off" menu is the context menu I get from a right-mouse click. I dont see the gain here, it's actually one click more than using the edit menu.

If I misunderstood, could you explain what a tear-off is?

The menus that you obtain with a right-click have a dotted line across the top. If you click on that dotted line, a menu window is created with just that sub-menu. By right-clicking on "Edit" and selecting the dotted line at the top of the "Edit->Paste As" sub-menu, you will create a menu dialog that will make the "Paste As New Image" command just a mouse-click away at all times.

Such tear-offs lose their utility if commands are all clumped together on a top-level menu. For this reason, I question the wisdom of the GNOME HIG discouraging nesting of menus (or at least the idea that three levels is excessive, especially if the menu bar is itself to be considered a menu).

----
Your comments on the enhancements and blurs has some merit, I just think it is important to recognize the development and maintenance process of the GIMP when making such decision. The different blur methodologies are different plug-ins and it seems you are suggesting that they be combined into a generic blur which permits the user to choose different options.

Several difficulties would arise with this consolidation which are best summarized as discarding the benefits of the entire plug-in approach to the GIMP's development (division of labor, isolation of bugs, incremental improvements, the project's "bus factor").

In general, I think the greatest benefit to the GIMP's progression would be for there to be more of a focus on organizing and simplifying things from developer's standpoint. There is much more to be gained by facillitating the task of potential contributors working on innovative techniques and algorithms than there is from increasing the GIMP's userbase. "Usability" should not be entirely ignored, but nor should it come at the cost of "develop-ability".

my complaint was exactly that , that from one submenu to another the submenu can come up left or right which is visually distruptive.

http://bugzilla.gnome.org/show_bug.cgi?id=358816

Reading the text of a menu item leaves your eyes at the end of the text. If the sub-menu appears to the right, your eyes do not have to "jump" at all -- they are already positioned at the start of the sub-menu's text (this is a Good Thing).

If the sub-menu appears to the left of the menu, your eyes must "jump" from the right (end) of the menu text and find the left (start) of the sub-menu (this is a Bad Thing).

Your suggestion could be viewed as a preference for the consistency of all Things behaving Badly in the same manner over only having Bad Things occur when the Good Thing is not feasible. I am not saying that your suggestion is entirely without merit but you should not be so "apalled" that others do not share your preference.

There are no rotate operations on the image menu, all are in a submenu.

I guess we will have to agree to disagree on submenus. I think that the taxonomic information that is imparted to the commands is valuable enough to justify the inconvenience of descending into them.

Some anomolies could be looked at, I can free-rotate a layer but not an image.

Erm, you can.

Can you please clarify what you mean. I look at the Image | Transform

and

I only get the simple 90deg and flip options.

Where do you see rotate image?

You are correct in that it is not on the Image menu and also that consistency in the menus' appearances might hold some benefit. However, my own preference would be that consistency in a menu's commands behavior is more vital.

A week or two ago, I suggested that Arbitrary Rotation be removed from the Layer menu because it *behaves* anomalously to the other commands on that menu (it honors the selection while most of the other Layer commands ignore the selection and operate on the entire layer). Without such commonality of behavior, the user is forced to memorize (or use trial-and-error) which commands on the Layers menu honor the selection. IMO, this the main reason for grouping tools, operations, and commands into separate categories and should be more rigorously "enforced".

I would suggest "Enhance contrast" makes more sense as an entry in the color menu than an obscure name of the algorithm used. The hint then

gives

the extra info about what method is applied.

Your suggestion isn't entirely invalid, I just feel that you are being somewhat solipsistic in wanting to draw the line of what is an "obscure" term in the field of graphics arts. Perhaps *you* are unfamiliar with the term (at this point in time) but would you suggest that if *you* were unfamiliar with the CMYK colorspace (or even RGB, as many newcomers to the field are), the GIMP developers should cater their terminology to the limitations of your vocabulary. At what point is the line drawn? My own preference is to tend towards the wishes of the developer of the command (Fabien Pelisson), out of respect for his contribution.

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

On Thu, 2006-10-12 at 18:33 -0400, Philip Ganchev wrote:

I would love to make the description more formal, if someone tells me how. Is that what you mean by "spec things up"?

Hi
Yea, I meant to write a functional specification of how this is supposed to work. Joel Spolski has written a nice introduction to functional specifications:

http://www.joelonsoftware.com/articles/fog0000000036.html

Some other issues you raised - I thought tiles would make a better use of space, but having a single column would work just as well as we really need to present just a few results.

As for the graphic, I would think a lot of effects can be illustrated with a graphic. An image shouldn't actually get processed (at least not at run-time), but a sample graphic processed with a filter may illustrate its effect better than a description. To emphasize the effect, the thumbnail could be split, with the left side being the original sample image and the right side with the effect applied.

cheers

How about a large "toolbar" window?

When an operation is needed, the toolbar window pops up with a key press. Remember, many software have a quick reference card of one or two pages. One could typeset the card in the toolbar window (possibly multiple pages) and add transparent buttons over it. No patent pending.

The toolbar window has always the operations typeset at the same locations if so wanted. That is the second plus over the deep menus which have no fixed layout between the menu windows.

BTW, the emacs style command system was also a good idea. E.g., "Esc x filters-noise-spread" and "ctrl-x n s". Emacs also has the command apropos something which helps in finding the suitable commands.

Juhana

Omar a écrit :

Saul Goode a écrit :

gg wrote:
I assume a "tear-off" menu is the context menu I get from a right-mouse click. I dont see the gain here, it's actually one click more than using the edit menu.

If I misunderstood, could you explain what a tear-off is?

The menus that you obtain with a right-click have a dotted line across the top. If you click on that dotted line, a menu window is created with just that sub-menu. By right-clicking on "Edit" and selecting the dotted line at the top of the "Edit->Paste As" sub-menu, you will create a menu dialog that will make the "Paste As New Image" command just a mouse-click away at all times.

Such tear-offs lose their utility if commands are all clumped together on a top-level menu. For this reason, I question the wisdom of the GNOME HIG discouraging nesting of menus (or at least the idea that three levels is excessive, especially if the menu bar is itself to be considered a menu).

DON'T touch/remove "TEAR-OFF menu"! NEVER! :) This is one of the best Gimp's UI concept here.

Thank you

Regards -Omar

ps: sorry to play the intruder in this ML :)

Omar wrote:

Saul Goode a écrit :

The menus that you obtain with a right-click have a dotted line across the top. If you click on that dotted line, a menu window is created with just that sub-menu. By right-clicking on "Edit" and selecting the dotted line at the top of the "Edit->Paste As" sub-menu, you will create a menu dialog that will make the "Paste As New Image" command just a mouse-click away at all times.

Such tear-offs lose their utility if commands are all clumped together on a top-level menu. For this reason, I question the wisdom of the GNOME HIG discouraging nesting of menus (or at least the idea that three levels is excessive, especially if the menu bar is itself to be considered a menu).

DON'T touch/remove "TEAR-OFF menu"! NEVER! :) This is one of the best Gimp's UI concept here.

ps: sorry to play the intruder in this ML :)

I was worth it. (-:

My sister-in-law uses that feature extensively. She had to use PhotoShop recently; the moaning & wailing which ensued about such features' absence was incredible. She does professional photography. Her site is at http://www.goldenlight.bur.st/

Cheers; Leon

On Thu, 19 Oct 2006 02:12:39 +0200, Leon Brooks wrote:

Omar wrote:

Saul Goode a écrit :

The menus that you obtain with a right-click have a dotted line across the top. If you click on that dotted line, a menu window is created with just that sub-menu. By right-clicking on "Edit" and selecting the dotted line at the top of the "Edit->Paste As" sub-menu, you will create a menu dialog that will make the "Paste As New Image" command just a mouse-click away at all times.

Such tear-offs lose their utility if commands are all clumped together on a top-level menu. For this reason, I question the wisdom of the GNOME HIG discouraging nesting of menus (or at least the idea that three levels is excessive, especially if the menu bar is itself to be considered a menu).

DON'T touch/remove "TEAR-OFF menu"! NEVER! :) This is one of the best Gimp's UI concept here.

ps: sorry to play the intruder in this ML :)

I was worth it. (-:

My sister-in-law uses that feature extensively. She had to use PhotoShop recently; the moaning & wailing which ensued about such features' absence was incredible. She does professional photography. Her site is at http://www.goldenlight.bur.st/

Ahh! More hidden treasure.

Nice feature , shame there is absolutely nothing in a line of ------------- to suggest this actually does something. I always thought it was a gimp oddity and someone had decided to style the menus this way. In fact it is a _menu entry_ .

Conclusion: how about giving it a meaningful label rather than "--------" . "Tear off" would be enough to raise the curiosity and once clicked this excellent feature would be imediately available to all users.

Thanks to Saul for explaining it's existance to me.

and , yes, I agree about HIG and not nesting menus , that was one of my main points when I started this discussion. The Paste As .. menu is one level too many.

Glad we are all agreed. ;)

Hi,

On Thu, 2006-10-19 at 11:07 +0200, gg@catking.net wrote:

Conclusion: how about giving it a meaningful label rather than "--------" . "Tear off" would be enough to raise the curiosity and once clicked this excellent feature would be imediately available to all users.

Suggest that to the GTK+ developers then. This is not a GIMP feature, it's provided by GTK+ (but disabled by default IIRC).

I strongly disagree with adding a label to it though as that would IMO clutter the menus too much. This is a power-user feature and it should be sufficient to mention it in the user manual.

Sven

On 10/19/06, gg@catking.net wrote:

Nice feature , shame there is absolutely nothing in a line of ------------- to suggest this actually does something.

To me, if I can select a menu item, it does something. Personally I had no trouble discovering this feature. I agree that it could be improved, and it should be non-textual (as in, it shouldn't look like any other menu entry.)

The ----------- seems fairly obvious to me, though - perforation marks showing that you can 'tear off here'

Checking the UI again, if there is any confusion as to the function of --------, shouldn't -------- get a tooltip saying 'Tear off this menu'?

On Thu, 2006-10-19 at 19:52 +0930, David Gowers wrote:

Checking the UI again, if there is any confusion as to the function of --------, shouldn't -------- get a tooltip saying 'Tear off this menu'?

As Sven said, discussing this here makes no sense whatsoever, please bring it up on a gtk mailing list.

ciao, --mitch

Michael Natterer wrote:

On Thu, 2006-10-19 at 19:52 +0930, David Gowers wrote:

Checking the UI again, if there is any confusion as to the function of --------, shouldn't -------- get a tooltip saying 'Tear off this menu'?

As Sven said, discussing this here makes no sense whatsoever, please bring it up on a gtk mailing list.

Hokay, but before we start there, is there a particular outcome which GIMP wants from the discussion? Shaded bar instead of dash-dash? Tool-tips? Something else? Something specific?

We may just get what we ask for, so let's ask for something particularly useful, no?

Cheers; Leon

Hi,

On Thu, 2006-10-19 at 20:21 +0800, Leon Brooks wrote:

Hokay, but before we start there, is there a particular outcome which GIMP wants from the discussion? Shaded bar instead of dash-dash? Tool-tips? Something else? Something specific?

I don't see any need for a change here. IMO the visual appearance of the tear-off menus is quite good. It's unobtrusive and still recognizable, especially to those who have worked with other toolkits that support this concept. And the look reminds me of perforation marks, a very good metaphor to use here.

Sven

On 10/19/06, Leon Brooks wrote:

Hokay, but before we start there, is there a particular outcome which GIMP wants from the discussion? Shaded bar instead of dash-dash? Tool-tips? Something else? Something specific?

I agree with Sven, however, having tooltip would be helpful.

Alexandre

Hi,

On Thu, 2006-10-19 at 16:22 +0200, pgi@piments.com wrote:

A short helpful text item like "tear-off" would not take make the menu a single pixel larger nor would it "clutter" the menu more than a meainingless line of hyphens.

Yes, it would. It would distract the user's view from the actual menu entries and makes it harder to quickly scan the menu.

The "tear along the dotted line" that the current entry presumably is supposed to represent has no meaning until you are aware of the feature and what it is called. There is not analogy elsewhere this I am aware off that would cause a user to understand this otherwise.

Well, all other toolkits that have tear-off menus do it pretty much the same way and use pretty much the same visual representation.

Having a tooltip on the menu might be a good idea. Please propose it to the GTK+ developers and stop discussing this here any further.

Sven

On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote:

all other toolkits that have tear-off menus

'still interested to know what "all the other toolkits" are.

On 10/20/06, gg wrote:

On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote:

all other toolkits that have tear-off menus

'still interested to know what "all the other toolkits" are.

Qt

Alexandre

Omar a écrit :

Alexandre Prokoudine a écrit :

On 10/19/06, Leon Brooks wrote:

Hokay, but before we start there, is there a particular outcome which GIMP wants from the discussion? Shaded bar instead of dash-dash? Tool-tips? Something else? Something specific?

I agree with Sven, however, having tooltip would be helpful.

Reading the manual would be helpful for the noob, too! :)

Or it would be helpful to take the user for smarter than he is. (my own approach(copyleft) )

Okay, it's not politically correct.

cheers -Omar

Omar a écrit :

Alexandre Prokoudine a écrit :

On 10/20/06, gg wrote:

On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote:

all other toolkits that have tear-off menus

'still interested to know what "all the other toolkits" are.

Qt

OpenMotif :)

-Omar

On Fri, Oct 20, 2006 at 02:24:48AM +0200, Omar wrote:

Omar a ?crit :

Alexandre Prokoudine a ?crit :

On 10/20/06, gg wrote:

On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote:

all other toolkits that have tear-off menus

'still interested to know what "all the other toolkits" are.

Qt

OpenMotif :)

And it's not just unix stuff, Microsoft Office has had them for a while too. IIRC they do have a tooltip for the "------" bit.

-Yosh

On Fri, 20 Oct 2006 02:19:43 +0200, Omar wrote:

Reading the manual would be helpful for the noob, too!

Which manual ? Gimp? This is not gimp. GTK, Gnome , the "Linux" manual?

This type of comment is either just trying to be smart or a cop-out.

Users, noob or otherwise, should not need to RTFM just to use the menu! To suggest they do means the interface is failing.

This menu issue can be dropped here since it's a gtk feature but this attitude needs a Cntl-X .

Calling things "power-user" features because they are obscure or smuggly saying RTFM when the interface is cryptic will not make Gimp (or anything else) easier to use.

This echos the Corrective Rotation discussion. Some really good features where Gimp could shine are being hidden from the user by poor interface design compounded by a reluctance to review some decisions that may not have been the best choice.

If the user sees something he cant use or cant understand he may be expected to search a specific chapter in the manual to explain it. If a feature is not apparent he's not going to have any reason to search.

Also NO-ONE is going to pick up the manual and read it A-Z , let's not dream. Neither should this be necessary.

On Fri, 20 Oct 2006 02:36:29 +0200, Manish Singh wrote:

On Fri, Oct 20, 2006 at 02:24:48AM +0200, Omar wrote:

Omar a ?crit :

Alexandre Prokoudine a ?crit :

On 10/20/06, gg wrote:

On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote:

all other toolkits that have tear-off menus

'still interested to know what "all the other toolkits" are.

Qt

OpenMotif :)

And it's not just unix stuff, Microsoft Office has had them for a while too. IIRC they do have a tooltip for the "------" bit.

-Yosh

On 10/13/06, Philip Ganchev wrote:

On 10/13/06, Øyvind Kolås wrote:

I have implemented a similar solution in my prototypes of more advanced layer interfaces and added one more thing, items can exist in multiple locations in the menu system with the aim to make it easier finding what you are looking for when only browsing the menu as well.

Adding an item to more than one menu is probably a good idea. It must have been tried before, and perhaps even user tested, but I haven't researched to know whether it was useful or confusing.

http://pippin.gimp.org/tmp/search-menu.gif contains a recorded animation of the UI elements I've been using.

I did not understand what is the purpose of the interface in the animation. I see that you have some searching, but there is a lot of use of the mouse, which is generally inefficient[1].

Perhaps you'll find the interface in http://pippin.gimp.org/gegl/gegl-20061105.gif easier to decode, since that is a screengrab made to illustrate such a type to find a filter interface. In that interface I copied the mozilla behavior of focusing "the location bar" with ctrl+L probably a suboptimal choice but it worked for my experiment[1].

/Øyvind K.

1: I am increasingly annoyed with people assuming that when I present functional prototypes of things that they are in a form even considered final enough for an end user to use. In most cases they are sketches or scaffolding on top of code that I am actually developing. It is probably not a solution if I start complaining that buttons in mockups do not work when I press them.

On 11/6/06, gg@catking.net wrote:

On Mon, 06 Nov 2006 11:10:59 +0100, Øyvind Kolås wrote:

Perhaps you'll find the interface in http://pippin.gimp.org/gegl/gegl-20061105.gif easier to decode

very interesting. Obviously sliders would be more intuitive when you get further on , a contrast change of 2.25 does not have any meaning to most people.

The user interface presented there is a very simple and naive representation of the parameters of the operation itself, if custom GUI's were available for the operations they would probably be used instead, for most of these things, integrating the user interaction in the view itself would probably also be beneficial. Popups like this are quite annoying if they can be avoided.

It's probably only of use in being able to log a numerical value for future reference, documenting what was done or repeating with the same parameters later. That is to say it's worth having numerical input but is slider is more relevant most of the time.

Well for brightness/contrast for instance, I think something like the "curves" like UI provided at
http://pippin.gimp.org/bauxite/old_screenshots/2004-06-15.png combined with entries would probably be superior to just separate sliders for brightness/contrast.

Could you briefly outline how you capture the sequence of events and prepare the gif amin. , it's a very good way to present things sometimes.

Byzanz, http://www.gnomefiles.org/app.php?soft_id=1261 , is used to capture from the screen to a gif animation.

/Øyvind K.

On 11/6/06, Øyvind Kolås wrote:

Well for brightness/contrast for instance, I think something like the "curves" like UI provided at
http://pippin.gimp.org/bauxite/old_screenshots/2004-06-15.png combined with entries would probably be superior to just separate sliders for brightness/contrast.

Another example would be UFRaw and curve in Correction tab.

Alexandre

On 10/12/06, Philip Ganchev wrote:

where applicable. I envisioned using a tile-based interface for this not unlike the beagle-search tool* but never gotten to mock things up. Feel like speccing things up? ;)

[rearranged]

* http://upload.wikimedia.org/wikipedia/en/5/54/Beagle-search.png

I added a very simple thing like this to my image processing app. a couple of years ago. I have about 350 menu items :-( so it really helps finding things (I use it myself sometimes).

You can see it on the RHS of this screenshot:

http://www.vips.ecs.soton.ac.uk/images/Screenshot-nip2-7.10.10.png

The localised descriptions of the menu items are displayed in a list. As you type in the search box, the list expands and contracts showing matching items. Double-clicking on an item activates that menu action. There's a tickbox in the View menu which shows and hides the browser (with a little animation), or you can drag on the pane handle.

As well as the localised description, if you scroll to the right it also displays the path to the menu item, the action arguments and the keyboard shortcut (if any).

Hi,

we are asking for a volunteer to fix the Plug-In Browser for several years now. The GimpBrowser widget in libgimpwidgets was designed especially to allow this sort of search interface and all that needs to be done is to port the Plug-In Browser to it and to extend it a little so that you can also run plug-ins from it.

Now if you guys would spend less time discussing things that have already been discussed to dead and would do some coding instead...

Sven