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
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
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
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
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
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,
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
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
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,
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
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);
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
On Wed, Nov 09, 2005 at 06:27:50PM -0500, Matthias Clasen wrote:
typedef void (* GtkFileSystemCreateFolderCallback) (GtkFileSystem
*file_system,
const GtkFilePath
*path
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
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
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
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
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
-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
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
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
21 matches
Mail list logo
