Re: [Nautilus-list] FW: Preview Release Comments

["John Sullivan" <sullivan eazel com>]

on 1/12/01 5:26 PM, Ben Ford at bford talontech com wrote:

<stuff deleted>

>>> 8.    For the "Show Properties" funciton,  it would be nice if I could
>>> select multiple files and have it open one window so I can set the
>>> properties of those files to a common property (ie. If I want to
>>> put the same emblem on multiple files,  have only one window
>>> come up to do that.  This is possible in gmc.)
>> 
>> This idea has come up before. It's tricky from a UI point of view to make it
>> work well and be understandable. Some of the properties shown (e.g. "name")
>> can't possibly apply to multiple files. You've got to have a way to
>> distinguish "applies to none/applies to some/applies to all" for each
>> property that can be set on multiple files. Switching from "applies to some"
>> to "applies to all" is probably a one-way change, which can be frustrating.
>> 
>> I tried to test how this works in GMC right now, but when I selected two
>> icons and right-clicked on one the menu didn't include "Properties..." like
>> it usually does. How do you invoke this behavior in GMC?
> 
> Many word processors will work in a similar fashion.  If you have a paragraph
> with a line bolded and a nother line italicized, and you select all the text,
> both the bold and italics will appear greyed out.  Basically, if an entire
> selection matches a property, then that property is displayed, if not, it is
> greyed, but you can click it and change the whole selection's properties.
> (Being greyed is supposed to mean mean not editable so maybe a different
> color?)
> 
> Is it worth the coding?  Probably not.

I'm quite familiar with the three-state concept; in fact, I helped establish
it on the Macintosh in System 7 (dashes next to menu items to mean that they
apply to part of the selection). Nonetheless, the meaning of these
three-state widgets is not obvious to everyone, and the behavior is not
ideal. Part of the awkward behavior is due to the one-way nature of the
switch from "some" to "all" -- I've seen checkboxes that cycle
some/all/none/some to address this, but I think that's awkward also. In
addition, some of the properties in the Properties window are text-based,
which make no sense in a three-state design. Perhaps the multiple-file
Properties window would just leave these ones out, but that might confuse
people who wonder why they sometimes see certain properties in the window
and other times don't. My point is not that there's no UI approach for
making the properties window work with multiple files simultaneously, but
that the solutions may cause usability problems on par with the problems
they're trying to solve.
 
> 
> I had an idea a while back and the thread unfortunately died before anything
> was
> resolved.  Is their anybody working to improve the clipboard concept,
> specifically to make it multi-dimensional?  My suggestion was to make a
> sidebar
> component where you could copy items to and then paste them out of order.  I
> think that it should be a component of the Gnome environment rather than
> specifically Nautilus; there could be a panel applet and all.  I like the idea
> of being able to see the clipboard in the sidebar.  Will we be able to code
> third party sidebar components so that I can implement this for myself?

It should already be possible to code third party sidebar components. You'll
need to use libnautilus to hook up the basic sidebar interactions, but your
code needn't be part of Nautilus.

I've heard the "sidebar clipboard" idea discussed a few times also. It might
work well. Eazel might even try to do it eventually, though it's not
currently planned. If somebody else wanted to give it a shot, that would be
great.

John