On Thu, 2007-05-03 at 09:16 -0500, Jerry Haltom wrote:
> I think HAL should be able to return to us UUIDs which would be valid
> between machines.
Correct (the UID is composed from a number of sources including
filesystem UUID/filesystem label and, if the media is not removable,
also make/model/s
On Thu, 03 May 2007 16:52:39 -0400, Havoc Pennington wrote:
> Carl Worth wrote:
> "cairo model" is probably confusing - write_to_png is a more typical and
> essentially GError-equivalent model, while "cairo_t model" is the thing
> that people mean is unique to Cairo.
Yeah, we can get in a lot of c
Hi,
Havoc Pennington wrote:
> In GLib/GTK it's library bugs vs. app bugs, D-Bus maintains the same
> distinction for _dbus_return_if_fail vs. _dbus_assert *but* D-Bus makes
> them both fatal so it doesn't matter much anyhow.
>
And as Benjamin pointed out, D-Bus ships with assertions disabled i
Hi,
Carl Worth wrote:
> Sure. If you want the object to remain usable after an error, then it
> shouldn't shut down. And note that that with cairo, we do have
> functions that do return an error indication instead of shutting down,
> (cairo_surface_write_to_png, for example).
>
> So I think a fai
On 5/3/07, Carl Worth <[EMAIL PROTECTED]> wrote:
> So that looks to me like if you modified _cairo_error to do the
> equivalent of g_assert, you'd basically get what you want for your
> recoverable and unavoidable cases. But that would leave you with
> always having g_assert and never g_return_if_f
On Thu, 03 May 2007 15:41:43 -0400, Havoc Pennington wrote:
> I'd be for that in the case that the API has a "required ending call,"
> the equivalent of close(). Then you can "force" error checking on that
> last call with a GError or warn_if_unused approach and in theory people
> could skip the in
On Thu, 2007-05-03 at 12:43 -0400, Ray Strode wrote:
> Rather than propagating an I/O errors to apps using the stick at the
> time of removal, it could tell the user to reinsert the stick and
> continue where it left off.
Surely brings back memories from the Amiga ("You MUST replace the disk
in dr
I'm usually a lurker here, just chiming in on this:
On Qui, 2007-05-03 at 16:48 +0200, Alexander Larsson wrote:
> But the user can't mount a kernel mount. Only root can do that. In fact,
> this is one of the primary reasons we're creating a user space vfs. So
> that any user can create a cifs moun
On Thu, 03 May 2007 14:11:02 -0400, Havoc Pennington wrote:
> Yeah, I think this keeps the Cairo model from being "fully general" - it
> only works for some types of operations or objects.
Sure. If you want the object to remain usable after an error, then it
shouldn't shut down. And note that that
On Thu, 2007-05-03 at 16:59 +0200, Alexander Larsson wrote:
> The selection of whether to do local or remote i/o is done when
> instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> depending on the uri and the default GVfs instance loaded. However, the
> mapping from URI to what
Hi,
Benjamin Otte wrote:
> To bring up some examples: GdkPixbufLoaders, GKeyFile, GBookmarkFile,
> GMarkup.
I'd be for that in the case that the API has a "required ending call,"
the equivalent of close(). Then you can "force" error checking on that
last call with a GError or warn_if_unused ap
On 5/3/07, Havoc Pennington <[EMAIL PROTECTED]> wrote:
>
> Yeah, I think this keeps the Cairo model from being "fully general" - it
> only works for some types of operations or objects. Another thing about
> the Cairo model is that it's either weird or possibly broken if an
> object is used by mult
On Thu, 2007-05-03 at 10:14 +0200, Alexander Larsson wrote:
> The way a normal application uses gvfs is by the gio apis. Essentially
> you hand over a uri, and this uri is parsed by custom uri-type specific
> code into a mount specification (info about a gvfs mountpoint) and a
> path into it. Each
Hi,
Carl Worth wrote:
> On Thu, 3 May 2007 11:11:39 +0200, "Benjamin Otte" wrote:
>>I much prefer the cairo model, where basically the
>> object keeps its own GError and has a function like cairo_status [3]
>> that gives you the last error that occured.
>
> It's worth pointing
> The selection of whether to do local or remote i/o is done when
> instantiating the GFile. We instantiate a GLocalFile or a GDaemonFile
> depending on the uri and the default GVfs instance loaded. However, the
> mapping from URI to what should be done with the file must be done by
> purely in-pro
> Will it work. I guess, yes. However, it will be slower for gvfs apps,
> and I still think the aliasing is gonna be confusing. I.E there will be
> two visible locations that map to the same place. Code will look at a
> particular location name and don't expect things like a delete in this
> place
On Wed, 2007-05-02 at 14:55 +0200, Alexander Larsson wrote:
> On Tue, 2007-05-01 at 22:34 -0500, Jerry Haltom wrote:
> > I've been reading back in the discussion this February, about GVFS and
> > Alex's design and such. Read the postings about legacy VFS integration
> > and creating a Fuse mount po
On Wed, 2007-05-02 at 00:19 -0400, David Zeuthen wrote:
>
> This uuid could be private to GVFS and there would be a lookaside
> table
I think HAL should be able to return to us UUIDs which would be valid
between machines. Which is interesting, as it means uris such as these
could be saved in sho
On Thu, 3 May 2007 11:11:39 +0200, "Benjamin Otte" wrote:
>I much prefer the cairo model, where basically the
> object keeps its own GError and has a function like cairo_status [3]
> that gives you the last error that occured.
It's worth pointing out an additional aspect of the
Hi,
> allowing you to put up dialogs such as
>
> +--+
> | The application Frobnicator is trying to access a file on a |
> | device that is not available right now. To continue please |
> | attach the device
On 4/28/07, Havoc Pennington <[EMAIL PROTECTED]> wrote:
Hi,
I read over the GooCanvas code and wrote down everything I thought of,
some of it is half-baked or quarter-baked, but hopefully helpful in some
way.
Looks like a pretty good list. I would add that, at least for widget-y uses,
layout
On Thu, 2007-05-03 at 09:38 -0500, Jerry Haltom wrote:
> > Will it work. I guess, yes. However, it will be slower for gvfs apps,
> > and I still think the aliasing is gonna be confusing. I.E there will be
> > two visible locations that map to the same place. Code will look at a
> > particular locat
On Thu, 2007-05-03 at 09:27 -0500, Jerry Haltom wrote:
> Sure, but that hasn't helped the user any. He still has to remember
> where he mounted a remote machine, and do the mounting manually. What
> I'm talking about would be a GVFS schema for cifs:// that would actually
> create a kernel mount. Or
On Mon, 2007-04-30 at 12:52 -0400, Havoc Pennington wrote:
> Something like:
> - get a few reviews and comments on candidate codebases
> - iterate codebases accordingly
> - try to get a couple real-world apps to try them out
> - iterate accordingly
> - get review and feedback from gtk ma
--- Matthias Clasen <[EMAIL PROTECTED]> wrote:
> GLib 2.12.12 is now available for download at:
>
> ftp://ftp.gtk.org/pub/glib/2.12/
> http://download.gnome.org/sources/glib/2.12/
>
> glib-2.12.12.tar.bz2 md5sum: 0b3a42098243d054475ff6eb51ed2be1
> glib-2.12.12.tar.gzmd5sum: 6c6a61e4b08f
Hello!
I've fought a few hours with the working of GTKFileChooserButton. I
wanted to have a menu item and the button in toolbar opening the same
GTKFileChooserDialog. To make this happen I've constructed the
GTKFileChooserButton using the constructor, that allows passing my
custom GTKFIleChooserDi
Hi,
I had an initial look at gvfs in particular the Inputstream and
Outputstream implementations, and some comments came to my mind, in
particular about the API. So I thought I'd post them as early as
possible.
These comments are about the code in
http://www.gnome.org/~alexl/git/gvfs.git from toda
On Thu, 2007-05-03 at 00:50 -0400, David Zeuthen wrote:
> Or maybe I'm missing something? Feel free to tell me to read docs and/or
> the code if my question is stupid and the answer already lies there.
> Thanks!
Its true that there is a form of mapping going on with the fuse layer.
Here is how it
28 matches
Mail list logo