Re: Proposal for making the GtkFileChooser code asynchronous
From: James Henstridge [EMAIL PROTECTED] ... So if the two packages were not upgraded in lock-step, you'd just lose features rather than create instability. I guess its in the eye of the beholder, but this seems to be really splitting hairs. The concern is incompatibility, not instability. I think not being able to do something (supported) you could do before, classes as an incompatibility. - Joseph Kowalski ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated proposal for making the GtkFileChooser code asynchronous
On Fri, Dec 09, 2005 at 09:27:02PM +0100, Soeren Sandmann wrote: If you cancel an operation such as create_folder() before the callback is called, what are the semantics? 1 the operation will not have been completed, ie., no folder was created and no folder will be created 2 the operation may or may not be completed depending on where the thread happens to be when you cancel the operation 3 the operation will be completed anyway 4 something else Number 1 seems impossible to implement with threads without getting into hairy things like thread cancellation. Number 2 seems nasty, and 3 makes cancelling pretty useless. Also, the callback is always called, even if you cancel the operation, right? Yes, the callback is always called. In the callback the cancelled flag in GtkFileSystemHandle will have to be checked. This flag will only be TRUE if all of the following conditions are true: - The user requested the operation to be cancelled. - The operation was cancelled while being executed. - The temporary results got rolled back. If the operation was already completed, we cannot roll back the changes and the cancellation will thus be ignored. That means that if you cancel a create folder operation and the folder was already created, the result cannot be rolled back and the cancelled flag will be set to FALSE. The function gtk_file_system_get_info() itself does not take an GError argument. All errors will be reported via the callback, this means that error handling will only have to be implemented at a single place. The error argument of the callback will be NULL when no error occurred. Shouldn't error be const, or are you expected to free it (if so, why?)? You're not expected to free it, I'll make the error arguments const. thanks, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated proposal for making the GtkFileChooser code asynchronous
One thing that isn't clear to me, from my admittedly superficial reading of the proposals, is how the need to notify clients of changes to the file chooser list will be implemented. For accessibility, we will need to fire notifications via ATK of all changes to the file chooser list. This means we need GtkFileChooser signals to connect to here in libgail. I am a little concerned about the workability of this proposal from an accessibility POV anyhow - mainly I am concerned about how to manage the amount of 'chatter' caused by a continuously-growing list of objects. The existing chooser can be considered a snapshot which only changes in response to user actions, which is a more manageable problem. regards Bill ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated proposal for making the GtkFileChooser code asynchronous
Kristian Rietveld [EMAIL PROTECTED] writes:
1. Let's start out with a somewhat more general change. We need to be able
to cancel currently running asynchronous operations. For this we need
to have a handle on an operation, so we need to introduce a
GtkFileSystemHandle. The GtkFileSystemHandle will be a GObject:
struct _GtkFileSystemHandle
{
GObject parent_instance;
GtkFileSystem *file_system;
guint cancelled : 1; /* indicates whether the operation
has been cancelled or not */
};
struct _GtkFileSystemHandleClass
{
GObjectClass parent_class;
};
File system backends can of course subclass GtkFileSystemHandle and
add their own fields as required. We will add a call which we can use to
actually cancel an operation:
void gtk_file_system_cancel_operation (GtkFileSystemHandle
*handle);
If you cancel an operation such as create_folder() before the callback
is called, what are the semantics?
1 the operation will not have been completed, ie., no folder
was created and no folder will be created
2 the operation may or may not be completed depending on where
the thread happens to be when you cancel the operation
3 the operation will be completed anyway
4 something else
Number 1 seems impossible to implement with threads without getting
into hairy things like thread cancellation. Number 2 seems nasty, and
3 makes cancelling pretty useless.
Also, the callback is always called, even if you cancel the operation,
right?
The function gtk_file_system_get_info() itself does not take an
GError argument. All errors will be reported via the callback, this means
that error handling will only have to be implemented at a single place.
The error argument of the callback will be NULL when no error
occurred.
Shouldn't error be const, or are you expected to free it (if so, why?)?
Soren
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated proposal for making the GtkFileChooser code asynchronous
On Fri, 2005-12-09 at 17:47 +, Bill Haneman wrote: One thing that isn't clear to me, from my admittedly superficial reading of the proposals, is how the need to notify clients of changes to the file chooser list will be implemented. For accessibility, we will need to fire notifications via ATK of all changes to the file chooser list. This means we need GtkFileChooser signals to connect to here in libgail. Kris's changes don't touch the widgetry at all. They are all in the backend. GAIL will see whatever it is accustomed to see from the file chooser's widgets. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated proposal for making the GtkFileChooser code asynchronous
Soeren Sandmann [EMAIL PROTECTED] writes: Also, the callback is always called, even if you cancel the operation, right? If it isn't, then - How do you free the user data you passed in? - What good is the handle passed to the callback? You can't do anything with it, except cancelling the operation which by then is already complete. Even if the callback is always called, it looks to me like a single gboolean was_cancelled parameter would be sufficient to cover any possible use of the handle. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated proposal for making the GtkFileChooser code asynchronous
On Fri, 2005-12-09 at 21:50 +, Bill Haneman wrote: GAIL is not used to the widgets having stuff added to the list asynchronously. Are you saying that this change will not cause the list to be incrementally grown? Right now the file chooser tries to load the whole current folder in under 0.5 seconds. If it succeeds, it will appear to Gail and the user as if the list had been set up with a fully pre-built model. If it times out, it will put what it has in the list, and then will add incoming files incrementally. So, most of the time you don't see it adding files incrementally, because it is actually able to pull in the whole list of files in under 0.5 sec. Kris's changes don't modify that behavior, AFAIK. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On Tue, Nov 22, 2005 at 10:09:29AM -0600, Federico Mena Quintero wrote: On Tue, 2005-11-22 at 12:07 +0100, Kristian Rietveld wrote: 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. Take it out. Let's clean out the old API. I've been thinking about this, suppose we have a scenario where we want to retrieve one or more properties of all files in a given directory. With gtk_file_folder_get_info() we would get the folder, wait for it to finish loading and then retrieve the properties and process the data in a simple loop, since gtk_file_folder_get_info() is synchronous. I think it makes sense to leave gtk_file_folder_get_info() in, since this is IMHO a lot easier than getting a callback for each file, and do some bookkeeping to figure out whether all files have been processed. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On Tue, 22 Nov 2005, Kristian Rietveld wrote: On Fri, Nov 11, 2005 at 11:06:17AM +0100, Tim Janik wrote: gboolean gtk_file_system_cancel_operation (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GError **error); hm, since with GtkFileSystemHandle you already have an extra object/structure per operation, couldn't you simply store the GtkFileSystem*file_system pointer in it, so this can become (plus cancellation-cant-fail): void gtk_file_system_cancel_operation (GtkFileSystemHandle *handle); and, if the handles are really only in place for asyncronous operations, wouldn't naming it like that make more sense: void gtk_file_async_handle_cancel_operation (GtkFileAsyncHandle *handle); I went with the name gtk_file_system_cancel_operation() for now, because the cancel operation needs to be implemented by the GtkFileSystem backend. So I think it makes sense here to have the prefix gtk_file_system_. Also, I guess you are also thinking of dropping the GtkFileSystem argument from all callbacks, if we decide to include it in the GtkFileSystemHandle? yes, i don't see a point in dragging the GtkFileSystem alongside a private handle that you can use to store anything inside anyway. this gets especially cumbersome with gtk/signals/main-loops as in most places we only have a single data pointer available. oh, and is this actually going to be a ref-countable object? The plan was to have each async function return a newly allocated handle, which is not ref-countable. i can't exactly envision the ways this is going to be used in, but it might make sense to have this handle actually be a GObject, so that the file system user can at least reference count it when passing it around (could already be useful for e.g. passing a handle as data argument to an idle handler or signal handler). i think this has been raised in some of the other comment emails already: since the callback handler will have to deal with errors anyway, you could make it easier on the caller if you removed the error argument from all the gtk_file_system_*() functions and deliver the errors only through the callback. that means the caller has to implement error handling only once. Yep. shouldn't this have a GtkFileSystemHandle* ? same here, shouldn't this have a GtkFileSystemHandle* ? Yes, I forgot to add those in my mail. GdkPixbuf *gtk_file_system_volume_get_icon (GtkFileSystem *file_system, GtkFileSystemVolume *volume, gint pixel_size, GError **error); couldn't you just leave gtk_file_system_volume_render_icon() the way it is, and introduce GdkPixbuf* gtk_file_info_render_icon (GtkFileInfo *file_info, GtkWidget *widget, gint pixel_size, GError **error); instead of introducing a _get variant that just takes the widget argument implicitely from some place else? This sounds like a very good idea, and should be possible to do (unless I am overlooking something). I will also adapt the propsal at this point. great. would you mind sending around an updated API proposal then, that incorporates all your alteration plans? thanks, -kris. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On Tue, Nov 15, 2005 at 01:07:51PM -0600, Federico Mena Quintero wrote: On Tue, 2005-11-15 at 13:46 +0100, [EMAIL PROTECTED] 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On Fri, Nov 11, 2005 at 11:06:17AM +0100, Tim Janik wrote: gboolean gtk_file_system_cancel_operation (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GError **error); hm, since with GtkFileSystemHandle you already have an extra object/structure per operation, couldn't you simply store the GtkFileSystem*file_system pointer in it, so this can become (plus cancellation-cant-fail): void gtk_file_system_cancel_operation (GtkFileSystemHandle *handle); and, if the handles are really only in place for asyncronous operations, wouldn't naming it like that make more sense: void gtk_file_async_handle_cancel_operation (GtkFileAsyncHandle *handle); I went with the name gtk_file_system_cancel_operation() for now, because the cancel operation needs to be implemented by the GtkFileSystem backend. So I think it makes sense here to have the prefix gtk_file_system_. Also, I guess you are also thinking of dropping the GtkFileSystem argument from all callbacks, if we decide to include it in the GtkFileSystemHandle? oh, and is this actually going to be a ref-countable object? The plan was to have each async function return a newly allocated handle, which is not ref-countable. i think this has been raised in some of the other comment emails already: since the callback handler will have to deal with errors anyway, you could make it easier on the caller if you removed the error argument from all the gtk_file_system_*() functions and deliver the errors only through the callback. that means the caller has to implement error handling only once. Yep. shouldn't this have a GtkFileSystemHandle* ? same here, shouldn't this have a GtkFileSystemHandle* ? Yes, I forgot to add those in my mail. GdkPixbuf *gtk_file_system_volume_get_icon (GtkFileSystem *file_system, GtkFileSystemVolume *volume, gint pixel_size, GError **error); couldn't you just leave gtk_file_system_volume_render_icon() the way it is, and introduce GdkPixbuf* gtk_file_info_render_icon (GtkFileInfo *file_info, GtkWidget *widget, gint pixel_size, GError **error); instead of introducing a _get variant that just takes the widget argument implicitely from some place else? This sounds like a very good idea, and should be possible to do (unless I am overlooking something). I will also adapt the propsal at this point. thanks, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On Tue, 8 Nov 2005, Kristian Rietveld wrote: Hi, 1. Let's start out with a somewhat more general change. We need to be able to cancel currently running asynchronous operations. For this we need to have a handle on an operation, so we need to introduce a GtkFileSystemHandle which would be defined the same way as GtkFileFolder -- each backend can provide it's own handle object. Of course we add a call which we can use to actually cancel an operation: gboolean gtk_file_system_cancel_operation (GtkFileSystem*file_system, GtkFileSystemHandle *handle, GError **error); hm, since with GtkFileSystemHandle you already have an extra object/structure per operation, couldn't you simply store the GtkFileSystem*file_system pointer in it, so this can become (plus cancellation-cant-fail): void gtk_file_system_cancel_operation (GtkFileSystemHandle *handle); and, if the handles are really only in place for asyncronous operations, wouldn't naming it like that make more sense: void gtk_file_async_handle_cancel_operation (GtkFileAsyncHandle *handle); oh, and is this actually going to be a ref-countable object? The gboolean return value will indicate success or failure, in the latter case the error will be provided via GError. 2. Addition of gtk_file_system_get_info(), so we are able to retrieve information about a file without having to create a folder. This is useful in for example GtkPathBar. Prototypes: typedef void (* GtkFileSystemGetInfoCallback) (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GtkFileInfo *file_info, GError *error, gpointer data); GtkFileSystemHandle *gtk_file_system_get_info (GtkFileSystem *file_system, const GtkFilePath *path, GtkFileInfoType types, GtkFileSystemGetInfoCallback callback, gpointer data, GError **error); i think this has been raised in some of the other comment emails already: since the callback handler will have to deal with errors anyway, you could make it easier on the caller if you removed the error argument from all the gtk_file_system_*() functions and deliver the errors only through the callback. that means the caller has to implement error handling only once. typedef void (* GtkFileSystemGetFolderCallback) (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GtkFileFolder *folder, GError *error, gpointer data); 4. gtk_file_system_create_folder() needs to be changed in order to be able to operate asynchronously. The new prototypes: typedef void (* GtkFileSystemCreateFolderCallback) (GtkFileSystem *file_system, const GtkFilePath *path GError*error, gpointer data); shouldn't this have a GtkFileSystemHandle* ? typedef void (* GtkFileSystemVolumeMountCallback) (GtkFileSystem *file_system, GtkFileSystemVolume *volume, GError *error, gpointer data); same here, shouldn't this have a GtkFileSystemHandle* ? 6. Right now gtk_file_system_render_icon() is synchronous, because it needs some information about the file in order to be able to render a suitable icon. We think that loading icons asychronously, during the asynchronous folder loading process, is the way to go. Because we need a widget to render icons for us, we need to add: void gtk_file_system_set_widget (GtkFileSystem *file_system, GtkWidget *widget); this will make it hard to render the icon for different widgets, say if you need to display it in more than one place. Then we will add an icon field to GtkFileInfo, appropriate get/set functions and GTK_FILE_INFO_ICON. We will remove gtk_file_system_render_icon(). Now we have gtk_file_system_set_widget(), we plan on changing
Re: Proposal for making the GtkFileChooser code asynchronous
On Wed, Nov 09, 2005 at 06:27:50PM -0500, Matthias Clasen wrote: typedef void (* GtkFileSystemCreateFolderCallback) (GtkFileSystem *file_system, const GtkFilePath *path GError *error, gpointer data); Any reason why the GtkFileSystemGetFolderCallback gets a handle passed in, while the others don't ? Oh, oops, all callbacks are supposed to get a handle passed of course ;) -kris. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On Tue, 2005-11-08 at 15:08 +0100, Kristian Rietveld wrote: Hi, The last few weeks I have been working on making the GtkFileChooser code asynchronous. I've been making quite a bit of progress and hope to get the changes in on time for GTK+ 2.10. However, one of the most important changes is making the GtkFileSystem API suitable for asynchronous operation, which should not be a problem since GtkFileSystem is not supported API for general use (see gtkfilesystem.h). In this mail I will propose a set of changes to the GtkFileSystem API. If people are ok with these changes, I can go ahead and adapt all components -- GtkFileChooser*, GtkFileSystemUnix, GtkFileSystemGnomeVFS -- to the new GtkFileSystem API. 1. Let's start out with a somewhat more general change. We need to be able to cancel currently running asynchronous operations. For this we need to have a handle on an operation, so we need to introduce a GtkFileSystemHandle which would be defined the same way as GtkFileFolder -- each backend can provide it's own handle object. Of course we add a call which we can use to actually cancel an operation: gboolean gtk_file_system_cancel_operation (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GError **error); The gboolean return value will indicate success or failure, in the latter case the error will be provided via GError. I don't see why we need any error indication here. If canceling can fail, failing silently should be fine, I think. 2. Addition of gtk_file_system_get_info(), so we are able to retrieve information about a file without having to create a folder. This is useful in for example GtkPathBar. Prototypes: typedef void (* GtkFileSystemGetInfoCallback) (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GtkFileInfo *file_info, GError *error, gpointer data); GtkFileSystemHandle *gtk_file_system_get_info (GtkFileSystem *file_system, const GtkFilePath *path, GtkFileInfoType types, GtkFileSystemGetInfoCallback callback, gpointer data, GError **error); If the return value of gtk_file_system_get_info() is NULL, and the error argument is non-NULL a description of the error will be provided in there. Only errors which occurred before the asynchronous information acquisition process started will be reported this way. All other errors will be reported via the callback. 3. Change gtk_file_system_get_folder(). We cannot directly return a folder here, because we need to access the file system to figure out if the given path is really a folder. Let's use the following as a new call: typedef void (* GtkFileSystemGetFolderCallback) (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GtkFileFolder *folder, GError *error, gpointer data); GtkFileSystemHandle *gtk_file_system_get_folder (GtkFileSystem *file_system, const GtkFilePath *path, GtkFileInfoType types, GtkFileSystemGetFolderCallback callback, gpointer data, GError **error); If the return value of gtk_file_system_get_folder() is NULL, and the error argument is non NULL a description of the error will be provided in there. As with the other functions, only errors which occurred before the actual asynchronous operation started will be reported this way. Using this new call would work as follows: I. Call gtk_file_system_get_folder(). II. The callback provided will be called to tell whether the folder exists or not. If it exists, you will be provided with a pointer to a valid GtkFileFolder, if not the process ends here.
Proposal for making the GtkFileChooser code asynchronous
Hi, The last few weeks I have been working on making the GtkFileChooser code asynchronous. I've been making quite a bit of progress and hope to get the changes in on time for GTK+ 2.10. However, one of the most important changes is making the GtkFileSystem API suitable for asynchronous operation, which should not be a problem since GtkFileSystem is not supported API for general use (see gtkfilesystem.h). In this mail I will propose a set of changes to the GtkFileSystem API. If people are ok with these changes, I can go ahead and adapt all components -- GtkFileChooser*, GtkFileSystemUnix, GtkFileSystemGnomeVFS -- to the new GtkFileSystem API. 1. Let's start out with a somewhat more general change. We need to be able to cancel currently running asynchronous operations. For this we need to have a handle on an operation, so we need to introduce a GtkFileSystemHandle which would be defined the same way as GtkFileFolder -- each backend can provide it's own handle object. Of course we add a call which we can use to actually cancel an operation: gboolean gtk_file_system_cancel_operation (GtkFileSystem*file_system, GtkFileSystemHandle *handle, GError **error); The gboolean return value will indicate success or failure, in the latter case the error will be provided via GError. 2. Addition of gtk_file_system_get_info(), so we are able to retrieve information about a file without having to create a folder. This is useful in for example GtkPathBar. Prototypes: typedef void (* GtkFileSystemGetInfoCallback) (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GtkFileInfo *file_info, GError *error, gpointer data); GtkFileSystemHandle *gtk_file_system_get_info (GtkFileSystem *file_system, const GtkFilePath *path, GtkFileInfoType types, GtkFileSystemGetInfoCallback callback, gpointer data, GError **error); If the return value of gtk_file_system_get_info() is NULL, and the error argument is non-NULL a description of the error will be provided in there. Only errors which occurred before the asynchronous information acquisition process started will be reported this way. All other errors will be reported via the callback. 3. Change gtk_file_system_get_folder(). We cannot directly return a folder here, because we need to access the file system to figure out if the given path is really a folder. Let's use the following as a new call: typedef void (* GtkFileSystemGetFolderCallback) (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GtkFileFolder *folder, GError *error, gpointer data); GtkFileSystemHandle *gtk_file_system_get_folder (GtkFileSystem *file_system, const GtkFilePath *path, GtkFileInfoType types, GtkFileSystemGetFolderCallback callback, gpointer data, GError **error); If the return value of gtk_file_system_get_folder() is NULL, and the error argument is non NULL a description of the error will be provided in there. As with the other functions, only errors which occurred before the actual asynchronous operation started will be reported this way. Using this new call would work as follows: I. Call gtk_file_system_get_folder(). II. The callback provided will be called to tell whether the folder exists or not. If it exists, you will be provided with a pointer to a valid GtkFileFolder, if not the process ends here. III. A directory load will immediately start, children will be added via the files-added signal until you receive a finished-loading signal. The functions gtk_file_folder_list_children() and gtk_file_folder_get_info() will not be changed. 4.
Re: Proposal for making the GtkFileChooser code asynchronous
I would say that it is clear that we are going to break the API completely here, and also not continuing to support the old API. Third party code should not notice anything of these changes, except for third party code using the GtkFileSystem API. Since the GtkFileSystem API is not supported, We might consider GNOME to be 3rd-party code. If someone installs this future GTK+ 2.10 without also updating the rest of GNOME then GNOME would be broken. Smart package-managers would prevent this situation, of course. Maybe we can live with that. I assume that there isn't much code out there using the GtkFileSystem API. In order to not have that kind of code crash and burn on a system with a newer GTK+, we need to build in some kind of protection. Does anyone have suggestions on this one? Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
Murray Cumming wrote: Only if he installed that from-source GTK+ over his packaged GTK+. That is always a pretty stupid thing to do. Then what is the alternative? Fedora Core 3 (for example) is less than 2 years old, yet newer GNOME RPMs will not be available for that distro. There is no choice but to install GTK from source. Heck, I'm sure no new GNOME RPMs will be released for Fedora 4, the latest version of Fedora. Heck, even if he doesn't overwrite his packaged GTK (by installing to /usr/local for example), that still doesn't solve the problem because he has to mess with LD_LIBRARY_PATH to run that specific app. Furthermore, many, many people are complaining about the constant need to update their distribution just to be able to use newer software. For normal libraries, they can just install the latest version. Why not GTK? GTK has promised backwards compatibility. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On 08/11/05 09:14, Murray Cumming wrote: I would say that it is clear that we are going to break the API completely here, and also not continuing to support the old API. Third party code should not notice anything of these changes, except for third party code using the GtkFileSystem API. Since the GtkFileSystem API is not supported, We might consider GNOME to be 3rd-party code. If someone installs this future GTK+ 2.10 without also updating the rest of GNOME then GNOME would be broken. Smart package-managers would prevent this situation, of course. Maybe we can live with that. The only part of Gnome that makes use of this API is the gnome-vfs GtkFileSystem implementation, which is installed in /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so on my system. Provided that the new version of GTK doesn't look in that directory for filesystem implementations, then upgrading should not cause any crashes (although apps would no longer be able to select non-local files). So if the two packages were not upgraded in lock-step, you'd just lose features rather than create instability. James. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/8/2005 6:08 AM, Kristian Rietveld wrote: I assume that there isn't much code out there using the GtkFileSystem API. In order to not have that kind of code crash and burn on a system with a newer GTK+, we need to build in some kind of protection. Does anyone have suggestions on this one? Why not keep the current API and invent a new one for async operation? Use gtk_file_system_async_foo() and the like, and just deprecate the current API. If you install a header file to a public system location, no matter what you say, it's a public interface. If you want to change that API incompatibly, you're obligated to increment gtk's major version. IM(NS)HO, of course. -brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDcQNp6XyW6VEeAnsRAmEyAJ0d22ACUMDUufb23jtNxO94l+PGtACfSxj8 yPxEUoo1NclyaA/JNRd/7n4= =EMPS -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On Tue, 2005-11-08 at 11:58 -0800, Brian J. Tarricone wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/8/2005 6:08 AM, Kristian Rietveld wrote: I assume that there isn't much code out there using the GtkFileSystem API. In order to not have that kind of code crash and burn on a system with a newer GTK+, we need to build in some kind of protection. Does anyone have suggestions on this one? Why not keep the current API and invent a new one for async operation? Use gtk_file_system_async_foo() and the like, and just deprecate the current API. If you install a header file to a public system location, no matter what you say, it's a public interface. If you want to change that API incompatibly, you're obligated to increment gtk's major version. IM(NS)HO, of course. We did two things precisely to allow this kind of change: - We explicitly marked the filechooser interfaces as unstable and not public. To use them, you have to define the symbol: GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED I have no sympathy for someone who defines that symbol and then wants us to support the interfaces they used! - We install the modules in a versioned directory. Because we *knew* that we weren't going to get GtkFileSystem right the first time, and we wanted the flexibility to change it going forward. And if you've fooled around in the FileChooser's guts, you'll also know that it would be a really bad idea to try and support a GtkFileSystemEx ... we have a hard enough time to get everything working right doing things one way, without gobs of (likely basically untested) compat code as well. Regards, Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for making the GtkFileChooser code asynchronous
On Tue, Nov 08, 2005 at 03:08:16PM +0100, Kristian Rietveld wrote: The last few weeks I have been working on making the GtkFileChooser code asynchronous. I've been making quite a bit of progress and hope to get the changes in on time for GTK+ 2.10. Great news! Here are some comments to your proposal: 1. Let's start out with a somewhat more general change. We need to be able to cancel currently running asynchronous operations. For this we need to have a handle on an operation, so we need to introduce a GtkFileSystemHandle which would be defined the same way as GtkFileFolder -- each backend can provide it's own handle object. Of course we add a call which we can use to actually cancel an operation: gboolean gtk_file_system_cancel_operation (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GError **error); The gboolean return value will indicate success or failure, in the latter case the error will be provided via GError. In what way can cancelling an operation fail and why should it concern the file chooser? 2. Addition of gtk_file_system_get_info(), so we are able to retrieve information about a file without having to create a folder. This is useful in for example GtkPathBar. Prototypes: typedef void (* GtkFileSystemGetInfoCallback) (GtkFileSystem *file_system, GtkFileSystemHandle *handle, GtkFileInfo *file_info, GError *error, gpointer data); GtkFileSystemHandle *gtk_file_system_get_info (GtkFileSystem *file_system, const GtkFilePath *path, GtkFileInfoType types, GtkFileSystemGetInfoCallback callback, gpointer data, GError **error); If the return value of gtk_file_system_get_info() is NULL, and the error argument is non-NULL a description of the error will be provided in there. Only errors which occurred before the asynchronous information acquisition process started will be reported this way. All other errors will be reported via the callback. If this was a public, often-used API, I would recomment against returning an error here and instead use the callback for all error handling. This means that you need only one error handler, instead of two (that would probably duplicate some functionality). But since there will probably only one user of this API and multiple providers, doing it like this is probably better, since it is easier to implement. I would say that it is clear that we are going to break the API completely here, and also not continuing to support the old API. Third party code should not notice anything of these changes, except for third party code using the GtkFileSystem API. Since the GtkFileSystem API is not supported, I assume that there isn't much code out there using the GtkFileSystem API. In order to not have that kind of code crash and burn on a system with a newer GTK+, we need to build in some kind of protection. Does anyone have suggestions on this one? As others have suggested, please make sure that the old plugins are not loaded to prevent crashes. Older GNOME versions should not crash with newer gtk+ versions. I think just renaming the search path is an okay solution. - Sebastian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
