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... > 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 -- --------------------------------------------------------- Joshua Adam Ginsberg Cellphone: 970.749.8530 Rice University '02 Email: joshg myrealbox com St. Mark's School of Texas '98 -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- "All your code are belong to us." -The SCO Group ---------------------------------------------------------
Attachment:
signature.asc
Description: This is a digitally signed message part