Re: filesel notes

[Havoc Pennington <hp redhat com>]

Dan Winship <danw ximian com> writes:
> >  h) Ability to use the native platform file selector for
> >     GNOME/Win32/OSX/etc., or alternatively allow writing a
> >     per-platform filesel that emulates the native one closely.
> 
> Allowing it to be replaced with a different Gtk-based file selector is
> one thing, but using the OS's native file selector would just be a giant
> UI wart. We don't use native widgets anywhere else, why here?
> 

Other toolkits do this, such as Qt and I think some less popular ones.
I don't know the rationale. Perhaps emulating the platform UI
precisely is difficult.

I don't understand why it would be a UI wart; users want us to fit in
to the platform. I can imagine it being an API/implementation
nightmare though. e.g. I don't know how we'd make a native filesel a
GtkWidget/GtkWindow. Clearly we would need some clue as to how to
implement this in order to proceed with this feature. I was hoping Tor
and Hans might have thoughts. Probably we could make the API abstract
enough that filesel isn't even necessarily a GtkWidget, but I don't
know if it's worth it.

Most toolkits are sort of a mix of wrappers and emulating, there's a
spectrum; with GTK/Swing on one end, then Qt is mostly emulating but
uses native file and print dialogs, WxWindows and SWT are sort of
confusing hybrids, AWT is almost all wrapper I think, etc.  Clearly
you sort of _have_ to use the native print dialog, given how printer
drivers on Windows work.

Havoc