Re: Proposal for making the GtkFileChooser code asynchronous



On Tue, 2005-11-15 at 13:46 +0100, markku vire suomi24 fi wrote:

> >   The functions 
> gtk_file_folder_list_children() and gtk_file_folder_get_info()
> >   will 
> not be changed.
> 
> Are these ones going to be blocking calls, or do they 
> return a partial result?

The idea is to remove gtk_file_folder_get_info() and add a toplevel
gtk_file_system_get_info (fs, path, callback) (right, Kris?).

Kris also had plans for folder_list_children(); it doesn't make much
sense to call it until the folder in question has emitted the
"finished-loading" signal.

> >   void gtk_file_system_set_widget 
> (GtkFileSystem *file_system,
> >                                    
> GtkWidget     *widget);
> 
> Currently both unix and gnome-vfs backend 
> return icon theme images. 
> Is there a reason why we couldn't just 
> return icon name, skip the widget
> parameter completely and let the 
> GtkFileSystemModel to handle the rest?

Very good question.

In the long run, I think I'd prefer to get a pixbuf rather than an icon
name.  Once we have finished making the file chooser fast, and along
with making the file system fully async, we can have the folders load in
stages:

   1. First stage just returns filenames
   2. Second stage returns the stat() info and basic mime-types
   3. Third stage returns slow mime-types for those that were ambiguous
      in (2).
   4. Fourth stage goes and loads the real thumbnails for files,
      replacing the generic MIME icons.

... Or something like that.  The idea is to be able to have per-file
thumbnails in the end and without a big performance hit.
 
  Federico




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