On Thu, 1 Feb 2007, D John Anderson wrote:
I was thinking of a palette that acted the same as the single line text
entry field, except that it contained space for more than one line. As
you typed new commands the old commands would scroll up, giving you a
history of previous commands you entered. Following the conventions of
other shells, typing up arrow might go back in the command history so
you could choose previous commands without a lot of retyping.
You don't need multiple lines for command line history though. All the
shells that I've used that implemented this, simply changed the contents
of the bottom line on the screen when you backtrack through the history.
This is the case even in Emacs, where you do have a proper screen editor,
and I'm pretty sure it is to be clear about what is being edited now vs.
what was entered in the past. I don't think it's worth the screen real
estate in the end.
The main problem is whether the single entry/search will be confusing to
the user. Maybe for discoverability it should be search by default (the
simple case) and entry on slash prefix (the more advanced case), I don't
know. The current spec is reasonable enough to me (entry first, especially
if automatically switching to search on Cmd-F shortcut), but maybe that's
because I know about it already and because I enter new items far more
than I need to search for them by their contents. It will be interesting
to try it out in a5 and see what the initial impressions are.
Re: the shape of the text widget
Is it the rounded edge or the little magnifying lens that indicates that
it's a search widget? When the field is in the command line mode, the
rounded space could be used to indicate this, for example put a ">" or
something like that.
Davor
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
