Well, one big difference between Chandler's pseudo CLI and real
CLIs is that we're not displaying the results of the command in the
same field as the command itself. We have the rest of the UI for that.
I'm not sure why it's okay to load multiple commands into the
palette, but it's not okay to include /Find in that list of commands.
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 could resize the palette to include as many lines as
you'd like: one or many. You could also add some UI to the palette,
e.g. some buttons, that would enter some common commands. So in
either the palette or the current search field I was proposing
displaying the results of the command in the application, not the
widget itself.
So the issue isn't about multiple commands in the palette, it's about
not confusing the meaning of a search box by requiring that you type
"/search". I hoped to avoid this confusion by putting quick entry in
a different widget, one that worked even better for quick entry than
the search box, leaving search to be the familiar search we all know
and love.
4) As for the sidebar, we discussed this issue on the list over
the summer and agreed that coming up with a good design to deal
with an adjustable sidebar was beyond the scope of Preview. See
discussion here: http://wiki.osafoundation.org/Journal/
WhyTheSidebarIsFixedWidthForNow
I read the link, but didn't understand the details of the design
you're proposing. The main thing I'm confused about is this passage:
1. An alternate layout for the mini-calendar so that it doesn't
float in the middle of a sidebar that is much wider than the mini-
calendar itself.
2. A custom splitter tha won't make the divider between the
sidebar and the summary pane take up more pixels. (see Apple Mail,
iTunes and iPhoto as examples).
3. The ability to 'snap back' to the original width.
These are design issues that would need to be dealt with if we
introduced an adjustable width splitter between the sidebar and
summary pane. Could you elaborate on what in particular is
confusing for you?
I don't understand what the screen looks like as you move the
splitter between the sidebar and summary view, e.g. "an alternate
layout" doesn't make it clear what the alternate layout is. I think a
screen shot of the sidebar/minicalendar and summary view with
different positions of the splitter would help me understand the
proposal.
If on the other hand you're not making a concrete proposal, but
instead pointing out the "design issues that would need to be dealt
with", I was thinking about solving the issues by either scaling the
minicalendar to take up the extra space or tiling it to fill the
extra space.
It's not the graph, it's the word Relevance. I imagine the graph
can be shortened to whatever the width of the column, could we do
Rank instead? I can file a bug for this.
If you look at how I implemented it, the column I added is already
titled "Rank" not "Relevance" and the column is resizable with the
graph adjusting as it is resized.
The term "relevance" is the term Andi used, presumably from PyLucene.
Among people who work on search, relevance is probably more commonly
used than rank. However, we don't use the term Relevance used
anywhere in the Chandler UI.
We can also adjust the initial size of the column to any width and
put the column in an order in the table.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
