notes from file selector talk



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:
	*http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/AHIGDialogs/iSaving_Clos_ng_Behavior.html
	*http://java.sun.com/j2se/1.4/docs/api/javax/swing/JFileChooser.html
	*http://doc.trolltech.com/3.0/qfiledialog.html
	*http://mail.gnome.org/archives/gnome-libs-devel/2002-March/msg00002.html





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