Re: File Dialog



-> > 	Question: Since the CList holds pixmaps, why would a GtkIconList
-> > would be necessary?
-> 
-> Because you don't want a single column of icons.

	Heh, actually, according to the Interface Hall of Shame, you
*would* want a single column.  They trash the Windows9x FileSel because
the user needs to scan vertically and horizontally, and scroll to the
right (past the directories) to get to the files.  They praise the
Windows3.1 FileSel for the same reasons.

	My widget (currently in the design stage) will have two columns in
the right-hand window: files, and directories.  But I digress...


-> I suppose someone could do a file selector with optional list/icon
-> views, with only the list view in this release, using jrb's widget. It
-> would need to keep the tree widget private though so people wouldn't
-> use it directly.

	Can I take this to mean you _would_ consider a new FileSel widget
for Gtk2, assuming a good one came along?


-> Also there's the issue of hooks to enable the dialog to become
-> GNOME-ified, I believe this would mean all the filesystem access
-> functions should be virtual methods, at a minimum.

	I would like to have the "issues of hooks to enable the dialog to
become GNOME-ified" clearly defined.  I want to make sure I do whatever's
necessary with my widget.

	The FileSel is a bit tricky because it deals with things like what
icons to use for different file types... and how to determine a file's
type.  And drag'n'drop behaviour between the other filemanagers (Nautilus,
GMC) and external applications.  I'm not sure how the Gtk+ FileSel should
work, given that it will probably want to use CORBA in its Gnome
incarnation.  Will simply making all the functions virtual suffice?  Any
advice on how to proceed would be greatly appreciated.

	For now, I'm just trying to find a tree + list layout that people
will are happy with.


--Derek






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