Re: GtkFileSystemWin32 (was Re: Gtk+ 2.3 ABI breakage)

[Owen Taylor <otaylor redhat com>]

On Sat, 2003-11-15 at 15:45, Hans Breuer wrote:
> At 12:14 01.11.03 -0500, Owen Taylor wrote:
> >On Sun, 2003-11-02 at 10:55, Hans Breuer wrote:
> >> At 09:08 01.11.03 -0500, Owen Taylor wrote:
> >> >On Sat, 2003-11-01 at 13:57, Hans Breuer wrote:
> >> >
> >> >
> >> >I'm a bit curious how you are testing out testfilechooser, since
> >> >my expectation was that it would take substantial work to get
> >> >it to go on Win32. 
> >> >
> >> >(To get it to go right, GtkFileSystem needs to be ported to the Win32
> >> >shell API, which requires a change to GtkFilePath, though something
> >> >simple  similar to GtkFileSystemUnix is probably possible.)
> >> >
> >> The 'simple similar' does already exist on my local disk. 
> >> And here are some questions which arose while porting ;-)
> >> 
> >> - GtkFileSystemUnix and GtkFileSystemWin32 currently share a lot
> >>   of code, i.e. all which is using the abstraction already supplied
> >>   by GLib. Would a patch which introduces a common base class -
> >>   say GtkFileSystemGos - be acceptable ?
> >
> >I think the question here is: are we going to ship a "simple" 
> >GtkFileSystemWin32 with GTK+-2.4. If so, a GtkFileSystemSimple
> >base class would make sense. 
> 
> Not sure if I see the differnce here. Do you suggest to create
> more than one GtkFileSystem implementation for windoze ?
> Or should the built-in file system implementation always
> be limited ? This may be required/useful on *NIX to not make
> Gtk depend on gnome-vfs, but what would be the point on win32
> where the whole (ok the win9x/XP common) win32 api could 
> be used without additional dependencies.

What I'm saying is that my expectation is that a thoroughly shell-api
based file system model is going to very different from
GtkFileSystemUnix and that a common base class won't be useful.

One request - could someone please sed-job GtkFileSystemWin32 
to not be called GtkFileSystemUnix?

Thanks,
						Owen