Re: Proposal for making the GtkFileChooser code asynchronous
- From: Kristian Rietveld <kris gtk org>
- To: Federico Mena Quintero <federico ximian com>
- Cc: gtk-devel-list gnome org, "markku vire suomi24 fi" <markku vire suomi24 fi>
- Subject: Re: Proposal for making the GtkFileChooser code asynchronous
- Date: Tue, 22 Nov 2005 12:07:42 +0100
On Tue, Nov 15, 2005 at 01:07:51PM -0600, Federico Mena Quintero wrote:
> On Tue, 2005-11-15 at 13:46 +0100, markku vire suomi24 fi wrote:
> > Are these ones going to be blocking calls, or do they
> > return a partial result?
They will certainly not be blocking of course ;)
> The idea is to remove gtk_file_folder_get_info() and add a toplevel
> gtk_file_system_get_info (fs, path, callback) (right, Kris?).
We are indeed going to add a toplevel gtk_file_system_get_info(), I was
not thinking of removing gtk_file_folder_get_info() though. Does it
make sense to remove it? I don't think leaving it were it is now will
hurt anything.
> 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.
The idea is that you get the requested GtkFileFolder via a callback,
then you will be notified of any newly added files via the "files-added"
signal. My plan was to have folder_list_children() return a partial
result here. Until "finished-loading" is received, then
folder_list_children() can return a list of children of the entire
folder.
-kris.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]