On 10/12/06, David Gowers <[EMAIL PROTECTED]> wrote:
On 10/12/06, Philip Ganchev <[EMAIL PROTECTED]> 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

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

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


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

> 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

Reply via email to