Re: File Dialog



-> My reaction to that then is that we should skip the GTK selector
-> revision for now. There is no point creating an incompatible GTK
-> selector, then a GNOME selector that's different in look &
-> feel. Shades of the 100-menu-APIs disaster.

	So what are you suggesting?  That we wait for a Gnome FileSelector
widget to be finalized, so that we can then create a trimmed-down,
non-CORBA, widget kit-only version for Gtk+?  If that's the case, we're
stuck with the bastardized Son-of-Motif widget forever.

	How can Gtk+ get a file selector based on the Gnome widget if
Gnome is going to use components for its file selection U.I.?  (A: It
can't.)

	A File Selector is really just "get the filename", "set the
filename", and maybe "show/hide the extra (file ops) buttons".  It's not a
huge, complicated API that will be a core part of the application
structure--it's really just a programming convenience to save app authors
some trouble.  The current widget is universally hated, just ask the
Gnome-UI list.  I would like to see something that looks a little more
modern, more like Win9x and Mac, instead of a holdback from the Windows3.1
era.

	I could understand not wanting to rush a widget into the 2.0
release, but not considering a better widget because Gnome will use a
different underlying architecture makes no sense.


--Derek







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