On 10/12/06, David Gowers <00ai99@xxxxxxxxx> wrote:
On 10/12/06, Philip Ganchev <phil.ganchev@xxxxxxxxx> 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?
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 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
Agreed.
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 useful for all commands, and is better for both novices and advaned users.
> 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.
True. I suggested menu bar because the search essentially replaces its function. At any time, if you are using the command search, you don't need the menus, so they are taking up space. A status bar has a different function and may be useful to tell you what to do with the search mechanism, such as "Search for the command you want to invoke". 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 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.
The other possibility is to show all commands, so that the user can just browse the whole list. _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
