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

[Owen Taylor <otaylor redhat com>]

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. If somebody is going to tackle the
shell-API based setup in the near future, and GtkFileSystemWin32
is just a placeholder a cut-and-paste is likely best.

How would use see GtkFileSystemSimple working? 

 - filename_get_info() would need to be virtualized in 
   GtkFileSystemSimpleClass
 - list_roots() and create_folder() probably can simply
   be implemented in the child classes.

That might get you basically working. But you'd probably want some
more customization as well to make it appear at least superficially
like the heirarchy you get with the windows file selector.
(If you presented the desktop as the root, can you get to
Desktop/My Computer/C: or whatever with the standard file system
navigation functions?)

> - To get file type specific icons (MIME handling in GtkFsUnix) on
>   win32 (probably based on FindExecutable and ExtractIcon to use
>   the system defaults) it appears to be required to extend GtkFileInfo
>   to take a GdkPixbuf, which would be created from the backend data.
>   Am I right or do you have some other plan ?

A simple pixbuf in GtkFileInfo doesn't really work, since the same
GtkFileInfo will be used for icons at different sizes. 

Various possibilities exist:

 A) Virtualize GtkFileInfo - make it a GObject... rather
    expensive. And add a get_icon() / render_icon() method. (See
    below for why render_icon() might be needed.)

 B) Add a separate GtkIconRenderer virtualized object that you'd 
    set on the  GtkFileInfo that would have a get_icon() / 
    render_icon() method.

    This would have the advantage that the object could be shared - 
    for instance, for GtkFileSystem Unix if you passed the
    GtkFileInfo into the get_icon() method then one GtkIconRenderer
    would work for the entire system, since the icon is completely
    determined by GdkScreen and mime-type.
    
 C) Just add a get_icon() / render_icon() method to GtkFileSystem.
    Federico was going to try this approach and see how it worked
    out in practice.

One question is whether we *can* get a GdkPixbuf for the icons on
Windows ... or whether we'll need a "draw_icon" virtual function instead
that takes a GdkDrawable. It appears that generally what you'll get
for icons is a HICON. Extracting that into a GdkPixbuf is going
to be somewhat expensive, even if it's possible.

If we end up with a "draw icon" primitive, that will require 
a custom cell renderer, but that's not a big deal.

> - For basic devices like floppy, cdrom, fixed disk, ram disk it would
>   be nice if Gtk stock icons could be used. At the moment there is
>   a gnome icon dependency ("gnome-fs-*") which I'd like to avoid 
>   for win32.

The gnome-fs-* is just a stop-gap, and needs to be fixed to use generic
names. It's no more right on Unix than it is on Windows. (Except that
it finds icons in the context of a gnome-2.4 install.)

But if we can get the real Win32 icons that's considerably better...
certainly what user's will expect is the same icons they get in
Explorer.

> - How do you want all this to be processed ? Should I commit what
>   I have (gtkfilesystemwin32.[hc] and some small portability
>   changes to other files) or do you want to review win32
>   specific patches ?

I don't have the time and knowledge to review a gtkfilesystemwin32.[ch];
so I'm fine if you go ahead and commit that. (Maybe get Tor to review.)

I would like to see any introduction of a base class or changes to the
non-Win32 specific code posted here and discussed first.

Thanks,
						Owen