Re: Some Ideas about Previewing and Multiple Media handling in Nautilus [was: Killing Views Part 2 ... ]

[Ryan McDougall <ryan mcdougall telusplanet net>]

On Thu, 2003-06-05 at 12:04, Joshua Adam Ginsberg wrote:
> I guess my biggest reason for wanting to not obfuscate the Nautilus
> window is that I can see the scenario where a user is flipping through a
> directory of documents looking for one that she can't remember what it's
> called so can't do a search for it... she opens up her documents folder
> and enables preview mode... she peruses the names of various documents
> in the folder and previews those she thinks might be the one she's
> looking for...
> 
> If the Nautilus window is obfuscated by the preview, she can't see the
> names of other documents while the preview is enabled... This would
> impede her search...
> 
> Maybe a sane compromise might be that when preview mode is enabled, a
> new pane (perhaps on the right side of the Nautilus window) appears to
> mirror the sidebar... this would create a better sense of association
> with the Nautilus window itself that you seem to want with the tooltips
> but without covering any of the content with its preview...

Anyhting would be an improvement, and I would be excited to see a
solution implemented with drawers or some other, but I dont think my
style would not interfere with her search, because the window that
obscures the view-pane would auto close when she stopped mouse-over. In
my mind, its a nautilus equivalent of looking at a stamp collection with
a magnifying glass:  when your face is in the glass, sure you cant see
some of the other stamps, but you can easily move the magnifying glass
or set it down. The automatic open/close behavior is key in my mind.

> 
> 
> > Sounds like gtk needs os/x "drawers" :)
> 
> Alan's suggestion of drawers might work even better than an additional
> pane... I'm very interested to see some screenies of Shaun's work, if
> he's got some...
> 
> Alex: any comments on this whole thread?
> 
> -jag
> 
> > Specifically, the basic nature of the window itself, I think, is the
> > only thing at issue. I guess you simply agreed with my second email so
> > you didnt need to comment further. While I know we shouldnt be copying
> > metacity functionality, I dont think metacity knows what we are trying
> > to accomplish in Nautilus, and Im not sure it can aid us in our mission.
> > I have included a picture of a scenario that took me WAY too long to
> > create in gimp ( does anyone know how to draw a rectangle in gimp?! ).
> > Basically Nautilus computes the expected size of the View Window, and
> > asks metacity to place it at one for the four corners of the Icon from
> > whence it came, along with an adornment that points to the originating
> > file. What it doesnt show is that when the mouse over stops, the window
> > vanishes after a couple seconds. Also note I forget to add the
> > meta-data.
> 
> > Please excuse me if this is a very tall order to accomplish, but I
> > really hope it isnt. In fact, in my mind I was thinking all along that
> > the view window should be implemented as a Tool Tip style window. A Tool
> > Tip is simply a special case of a very useful possible GTK widget that
> > has the same behavior, but can accomodate an arbitrary child widget (
> > besides tool text ). This kind of widget would be enormously useful,
> > indeed XP has it and, as Ive mentioned previously, I find it could be
> > employed in such a way as this. In XP the widget has a little adornment
> > that points to the parent widget, just like a dialogue bubble in a comic
> > points to the speaker. If such a widget existed in actuality
> > implementing my idea would be very easy: slam the bonobo component into
> > the "ToolTip Style" widget.
> > 
> > In so far as the window obfuscating the Nautilus window, well yes it
> > does. If Im going to View a File, my eyes are going to be on the View
> > Window, and they couldnt possibly be needing the Nautilus view-pane. The
> > *key* behavior that resolves the whole issue, is that the View Window
> > never needs to be activly called or dismissed, its automatic on
> > mouse-over. The old way one had to click on the file to View, then click
> > back when he was done viewing, and my concern is that without the
> > "automaticness" your solution may be not very different from the old.
> > 
> > Thanks for hammering out this idea with me Josh, it is indeed very
> > helpful for fleshing out ideas! Im excited that we have a real solution,
> > and that it may be implemenable. Even my "ToolTip Style" version is
> > doable with a little GTK hacking!
> > 
> > Cheers,
> > Ryan