Egg file selector comments ...

[Michael Meeks <michael ximian com>]

Hi James,

On Tue, 2002-09-17 at 01:53, James Henstridge wrote:
> The file chooser in libegg uses a small file system abstraction object. 

	And this is my major problem with it :-)

	I have no particular problem with this being an internal implementation
detail between libgnomeui and gtk+; _but_ I feel that it profoundly
misses the mark, and presents too much concrete API to the user that
will be hard to support in future.

	I'd far prefer to see an API that provides a virtual-ish object like
this:

struct GtkFileSel2 {
	GtkWindow parent;

	gpointer  private; /* or whatever */
};

struct GtkFileSel2Class {
	char  *set_initial_uri      (GtkFileSel2 *, const char *);
	void   set_can_select_multi (GtkFileSel2 *, gboolean);
	char **get_selected_uris    (GtkFileSel2 *);
	void   add_preview_widget   (GtkFileSel2 *, GtkWidget *w);
	...
	/* signals */
	void   selection_changed    (GtkFileSel2 *);
	void   current_dir_changed  (GtkFileSel2 *);
	...
};

char *gtk_file_sel2_cheesy_open (GdkScreen *); /* and other cheesy
						  variants */

	And not much else; particularly if we construct an API that ties us to
pixmaps of a certain size, one labels per file etc. we limit our options
dramatically for eg. plugging nautilus in / wholesale file-selector
replacement.

	I know some are concerned that making things too abstract will
encourage anarchy - so sees this as a sort of feature ;-) but I think
that's a fairly bad argument for providing an API that will be far more
future proof. There is also the argument that a few applications will be
able to provide previews of some files [ eg. xcf ] that other apps can't
- but this seems not such a massive win, vs. a good abstraction.

	Of course - my proposed API above hides a wider range of native file
selectors far better than the 'push images at it' thing. It can also be
used to handle high latency, asynchronous directory loads /
thumb-nailing, massive file systems etc. in a transparent (hidden) way -
without API expansion needed at each stage. [ just as a random example
of problems with the API I saw. ]

	So ... in summary, I'm personally not in favour of pushing the libegg
file selector _API_ as a public API. [ that is, unless it changed
recently ]. There is no need for yet another 'virtual filesystem' API -
especially one that limited and simplistic; IMHO we should avoid that
approach at all costs.

	Of course, the implementation itself may be very good; and the current
API sufficient for a first cut private API between libgnomeui and gtk+.
I just think we need to focus primarily on a flexible public API before
we get involved in implementation.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot