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

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 
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
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 ;-)


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]