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

[Hans Breuer <Hans Breuer org>]

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.

>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.
>
There is some shellapi stuff already needed to get the file icons
[
  it's ExtractAssociatedIcon() and I already have modified my
  local testfilechooser to do an icon preview based on it, see
  http://hans.breuer.org/ports/gtk-file-chooser-win32.png 
]
and probably some more to add default bookmarks to common
filesystem places, but still the base file system implementation
could (should?) keep using GLibs file functions.

>How would use see GtkFileSystemSimple working? 
>
> - filename_get_info() would need to be virtualized in 
>   GtkFileSystemSimpleClass
why not GdkPixbuf* GtkFileSytem::icon_for_file(name, width, height)

> - list_roots() and create_folder() probably can simply
>   be implemented in the child classes.
>
list_roots(), get_root_info(), parse() and get_info() are the
only members currently reimplemented on win32, this is about
20% of the code from gtkfilesystemunix.c.

>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?)
>
I personally highly dislike to present the desktop as root, and 
windoze doesn't do (AFAIK it's Mac OSX which puts the disks on
the desktop. I like to keep them within my computer under the desk ;-)

Curently there are simply multiple roots - one for each partition -
and one could simply add 'Network Places' and other links like
the ugly 'My Files' at the same level.

>> - 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.
>
As noted above : it is possible and with some caching should even 
be fast enough ...

>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.
>
At least I like the Gnome icons seen in Nautilus much more than the
stuff common on windoze. I'd suggest to make the selection of icons
themable with at least three levels :
- no icons at all
- built-in icons without 'mime' (icons only based on file attributes)
- full blown (prettiest and slowest)

> [...]
>I would like to see any introduction of a base class or changes to the
>non-Win32 specific code posted here and discussed first.
>
Ok, so I'll play a little more with the copy&paste approach
and see where it gets us ;-)

Thanks,
	Hans

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert