On 10/13/06, Philip Ganchev <phil.ganchev@xxxxxxxxx> 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)
I may have been thinking about mnemonics, but they shouldn't interfere.
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/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?
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.
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
