Re: notes from file selector talk

One of the things I really miss in a file selector is bookmarks.  There
are so many times the file selector opens in the place I don't want to
be and having bookmarks point to most used directories would be great.  

Working on for or five projects and going right to them from the file
selector would be nice.  This could also be handled by symlinks I guess
but not in exactly the same way and it would mean that the file selector
always opens at say $HOME.

Also if I'm in directory X and open an app from the command line I would
like the file selector to default to directory X not my $HOME.

TAB completion is a must have.

On Fri, 2002-07-19 at 14:13, Luis Villa wrote:
> These are a relatively unstructured set of notes from the Summit's file
> selector 'work'shop, which was itself relatively unstructured :)
> Hopefully it'll spur some more discussion and movement towards actually
> finishing libegg's :) [Yes, we're counting on you, Anders :)
> Luis
> Notes follow:
> File Selector talk:
> API (talking about this sucks):
> 	*possibly break gtk rule and make fs opaque
> 	*possibly present as object and not widget
> 	*possibly want to open resources and not just files
> 		*problem because we need it in both gtk and with fancy gnome-y features (specifically gnome-vfs)
> 		*java has a file system object, anders's code has something like this
> 	*just to be explicit: must be able to use gnome-vfs as well as file system, others
> 	*Michael, Owen, Chris and Havoc argue about virtualization of the widget, to be talked about later :) 
> UI:
> *from email- 'UI should be determined by usability team'
> 	*anna says 'maybe we shouldn't try to innovate on this one'- just copy/lift from someone else
> 		*screenshot as many different ones as possible, compare features, how extensible, etc.
> 		*OS/X one is only one substantially different from Windows filesel
> 			*would have advantage of being easy to implement
> *keyboard entry, something like tab completion except maybe using something other than tab
> 	*other possibly keynav issues are in directory selection [don't forget file name]
> *do *jpg as a filter entry
> *possible location-bar style auto-complete
> *Havoc rqt's
> 	*load mode
> 		*needs single and multiple select modes
> 	*save mode
> 		*don't forget file name when doing keynav
> 	*dir selection mode
> 		*single/multiple selects
> 	*ability to add preview widget (perhaps in different locations?)
> 	*auxiliary widgets of other types (like gimp's file type thing)
> 	*native mime system interface and icons
> 	*opaque
> *history-ish thing-y (possibly drop-down from text entry)
> *question: is the file selector nearly a file manager or does it do it very simple and interop with your file manager
> 	*or is it extensible so you can choose to do both :)
> 	*minimally requires a 'just open nautilus' button 
> 	*possibly optional: consistency with icons, previews, etc. from nautilus
> *what about widget embedded in a dialog? [did I get that order right?]
> 	*can this be done in such a way that it looks right?
> *simplicity
> *possibility of hiding previews
> *what directory do we open in?
> 	*per app?
> 	*per mime type?
> *user overridable filters (what if gnome-vfs guesses wrong or can't guess for whatever reason)
> *can't stretch icons (we all agree on this :) <- we all agreed, dammit
> Process:
> *we need (probably) a UI dictator
> 	*must be doing testing
> *Anders is the only one writing it- what's the interaction between coder and UI design?
> 	*basically completely up to Anders at this point- we hope it works out :)
> URLs:
> 	*
> 	*
> 	*
> 	*
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
George Farris - VE7FRG
George gmsys com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]