Hi,
On Fri, Apr 24, 2009 at 6:56 AM, Simon McVittie
wrote:
> As mentioned above, dropping my use of libdbus' "helpful" object path mapping
> and just using a filter function was a net code reduction.
Getting pretty off-topic, but the object path mapping in
DBusConnection isn't intended to be a c
On Thu, 23 Apr 2009 at 21:11:13 +0100, Robert McQueen wrote:
> dbus-python has had to duplicate a lot of the checking that libdbus does
> to validate calls before calling methods in libdbus, because whilst
> libdbus requires the application programmer gets stuff right at all
> times, dbus-python ca
On Thu, Apr 23, 2009 at 6:24 PM, Robert McQueen
wrote:
> Havoc Pennington wrote:
>>
>> Nobody has yet explained (to my satisfaction anyway) how the libdbus
>> license has an issue the LGPL does not have. Perhaps we should get
>> Luis or SFLC on the case, but I'm not sure it's worth their time.
>
>
Havoc Pennington wrote:
> Hi,
>
> On Thu, Apr 23, 2009 at 1:24 PM, Robert McQueen
> wrote:
>> My belief is that the problem is that under certain implementations
>> of LGPL, the stuff you link the LGPL library to must also be LGPL
>> compatible, and that the AFL patent clause is not.
>
> This d
Havoc Pennington wrote:
> Hi,
Hi Havoc,
> Just for the record, my comment on this has always been that the
> license issues were not earth-shattering to begin with, and the
> relicensing was just throwing a bone to people who cared. Not sure
> "large chunk" is super accurate, either. As a practic
On Tue, 2009-04-21 at 11:38 -0700, Brian J. Tarricone wrote:
> Alexander Larsson wrote:
> > It just feels like you want to have a cake (non-local file i/o) and not
> > pay for it (supply dependencies).
>
> No, he just wants a sane default implementation. If the CUPS backend
> isn't compiled, the
On Tue, 21 Apr 2009, Havoc Pennington wrote:
> On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell wrote:
> > IANAL, but... Hypothesis: Monster Corp distributes D-BUS under
> > AFL, while believing that DB in fact violates patents held by
> > Monster Corp. �MC then sues users of DB. �MC can no longe
Alexander Larsson wrote:
On Mon, 2009-04-20 at 18:45 -0400, Allin Cottrell wrote:
On Mon, 20 Apr 2009, Alexander Larsson wrote:
gvfs needs a session bus, not a system bus, so you're falling back to a
non-gvfs system. Thus no http support.
>>
OK, I suppose I can get this working on my own sys
On Mon, 2009-04-20 at 18:45 -0400, Allin Cottrell wrote:
> On Mon, 20 Apr 2009, Alexander Larsson wrote:
>
> > gvfs needs a session bus, not a system bus, so you're falling back to a
> > non-gvfs system. Thus no http support.
>
> OK, I suppose I can get this working on my own system, but my main
Hi,
On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell wrote:
> On Sun, 19 Apr 2009, Havoc Pennington wrote:
>> The license was written by a lawyer and is perfectly sane.
>
> "Sane" and "written by a lawyer" are surely orthogonal to
> desirability from the point of view of free software.
The contr
On Sun, 19 Apr 2009, Havoc Pennington wrote:
> I think my arguments are compelling. If someone else thinks
> differently, they can say so, and explain their reasoning...
>
> The bottom line is that dbus has an MIT/X11-equivalent license, with
> the addition of a *weaker* patent clause than LGPL/GP
On Mon, 20 Apr 2009, Alexander Larsson wrote:
> gvfs needs a session bus, not a system bus, so you're falling back to a
> non-gvfs system. Thus no http support.
OK, I suppose I can get this working on my own system, but my main
point is: why does GTK include a function such as gtk_show_uri
which
On Mon, 2009-04-20 at 16:54 -0400, Allin Cottrell wrote:
> On Mon, 20 Apr 2009, Alexander Larsson wrote:
>
> > 00, Allin Cottrell wrote:
> > > On Mon, 20 Apr 2009, Alexander Larsson wrote:
> > >
> > > > On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote:
> > > > > On Mon, 20 Apr 2009, Alexand
On Mon, 20 Apr 2009, Alexander Larsson wrote:
> 00, Allin Cottrell wrote:
> > On Mon, 20 Apr 2009, Alexander Larsson wrote:
> >
> > > On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote:
> > > > On Mon, 20 Apr 2009, Alexander Larsson wrote:
> > > >
> > > > > On Mon, 2009-04-20 at 10:43 -0400,
On Mon, 2009-04-20 at 14:36 -0400, Allin Cottrell wrote:
> On Mon, 20 Apr 2009, Alexander Larsson wrote:
>
> > On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote:
> > > On Mon, 20 Apr 2009, Alexander Larsson wrote:
> > >
> > > > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote:
> > > >
On Mon, 20 Apr 2009, Alexander Larsson wrote:
> On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote:
> > On Mon, 20 Apr 2009, Alexander Larsson wrote:
> >
> > > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote:
> > > > As it's currently coded gtk_show_uri is bound
> > > > to fail if GVf
On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote:
> On Mon, 20 Apr 2009, Alexander Larsson wrote:
>
> > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote:
> > > As it's currently coded gtk_show_uri is bound
> > > to fail if GVfs is not present. But more than that: it'll fail
> > > ev
On Mon, 2009-04-20 at 12:45 -0400, David Zeuthen wrote:
> That would give you a nice circular dependency if xdg-open(1) is ever
> ported to use GIO [1] which is not at all unlikely...
>
> David
>
> [1] : under GNOME, xdg-open(1) uses gnome-open(1) which AFAICT uses
> gnome-vfs2...
gnome-op
On Mon, 2009-04-20 at 18:31 +0200, Christian Dywan wrote:
> What about using "xdg-open" if GVfs is not available OR if gconf is
> not available? That's a tiny script that can be easily installed
> anywhere, even on less modern boxes.
That would give you a nice circular dependency if xdg-open(1) is
Am Mon, 20 Apr 2009 17:00:41 +0200
schrieb Alexander Larsson :
> On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote:
> > On Sun, 19 Apr 2009, David Zeuthen wrote:
>
> > > I could be wrong, but just briefly looking at the code it looks
> > > like there is no default implementation of GDesktop
On Mon, 20 Apr 2009, Alexander Larsson wrote:
> On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote:
> > As it's currently coded gtk_show_uri is bound
> > to fail if GVfs is not present. But more than that: it'll fail
> > even if GVfs _is_ present (as it is now on my system), if GVfs
> > does
On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote:
> On Sun, 19 Apr 2009, David Zeuthen wrote:
> > I could be wrong, but just briefly looking at the code it looks like
> > there is no default implementation of GDesktopAppInfoLookup in GIO,
> > there's only one in GVfs (that looks up stuff i
On Sun, 19 Apr 2009, David Zeuthen wrote:
> On Sun, 2009-04-19 at 20:05 -0400, Allin Cottrell wrote:
> > I've recently been trying to purge my GTK app of "deprecated"
> > stuff, and I tried replacing gnome_url_show() with
> > gtk_show_uri(). No go; on invoking gtk_show_uri() I get
> > "operation
On Sun, 2009-04-19 at 20:05 -0400, Allin Cottrell wrote:
> On Sun, 19 Apr 2009, Havoc Pennington wrote:
>
> > On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller wrote:
> > > You tell people not to worry. But many people clearly do seem to worry.
> >
> > Well, why don't these many people post a r
Hi,
On Sun, Apr 19, 2009 at 8:05 PM, Allin Cottrell wrote:
> Havoc may well be right with regard to libdbus, but IMO the burden
> of proof rests the other way; that is, if code that is not under
> *GPL is to be made part of glib, the onus is on those who would
> make the addition to show without
On Sun, 19 Apr 2009, Havoc Pennington wrote:
> On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller wrote:
> > You tell people not to worry. But many people clearly do seem to worry.
>
> Well, why don't these many people post a rational response to my
> points? I have not seen a rebuttal to
> http
Hi,
On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller wrote:
> You tell people not to worry. But many people clearly do seem to worry.
Well, why don't these many people post a rational response to my
points? I have not seen a rebuttal to
http://mail.gnome.org/archives/gtk-devel-list/2009-April
On Thu, 2009-04-02 at 20:34 -0400, Havoc Pennington wrote:
> > - What of the license issues?
> > GLib is LGPL. libdbus-1 is not. (...)
>
> Just for the record, my comment on this has always been that the
> license issues were not earth-shattering to begin with, and the
> relicensing was just t
Gustavo Noronha wrote:
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
- What do we do about the added 16bit integer types that are supported
by the DBus protocol, but don't have corresponding fundamental types in
GObject ? EggDbus currently has fundamental types for them.
It just st
Hi,
On Fri, Apr 3, 2009 at 2:56 PM, Will Thompson
wrote:
> I don't think that relying on having correct introspection data to
> marshall messages is a sound idea for a DBus binding.
There's no way you can marshal a message without the introspection data.
It can be implicit (i.e. you happen to p
On Fri, 2009-04-03 at 19:56 +0100, Will Thompson wrote:
> I don't think that relying on having correct introspection data to
> marshall messages is a sound idea for a DBus binding. The C
> representation of an 'a{uas}' where the values are all the empty list
> should contain all the information you
David Zeuthen wrote:
> On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:
>> Even if we have support for querying the element type of an array, for
>> example, we can get into situations where we can still have type errors.
>> Consider the case of an array of arrays of strings (which is a fa
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
> - What do we do about the added 16bit integer types that are supported
> by the DBus protocol, but don't have corresponding fundamental types in
> GObject ? EggDbus currently has fundamental types for them.
It just stroke me. What about i
On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:
> - Do we want glib depending on libdbus?
>It is my understanding that the intention is that glib is at the
>bottom of the stack. I felt like the reason that the GIO/gvfs split
>occured the way it did was in a large part because th
On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:
> Hi
>
> Matthias Clasen wrote:
> > One thing that has been tossed around for a long time is that it would
> > be really good to have DBus support on the Glib level.
>
> Agree strongly, but I'm not sure of the timing. A couple of people have
Hi,
On Thu, Apr 2, 2009 at 7:05 PM, Ryan Lortie wrote:
> - How does it fit with gobject-introspection?
> - Do we need code generation?
I'm on the same page with you here, but I think the fix is to split
the object mapping from the other pieces (as outlined in my long
manifesto previously). Then
Hi
Matthias Clasen wrote:
One thing that has been tossed around for a long time is that it would
be really good to have DBus support on the Glib level.
Agree strongly, but I'm not sure of the timing. A couple of people have
raised a few questions with me recently (in light of the noise I've
2009/3/3 Havoc Pennington
> Hi,
>
> On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen
> wrote:
> > 2009/3/2 Havoc Pennington
> >>
> >> Anyway, I think there is no difference between method calls and
> >> message passing. The only difference is in whether the client side API
> >> is made
Hi,
On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen
wrote:
> 2009/3/2 Havoc Pennington
>>
>> Anyway, I think there is no difference between method calls and
>> message passing. The only difference is in whether the client side API
>> is made to look just like a native object. But that'
Hi Brian,
>> I understand that there is no difference on-the-wire between a
>> function-call and message passing. The difference is in peoples
>> perceptions and expectations.
>>
>> When I read CORBA IDL and see:
>>
>> int AFunction (int, int);
>>
>> Because of the connotations provided to me by y
2009/3/2 Havoc Pennington
> Anyway, I think there is no difference between method calls and
> message passing. The only difference is in whether the client side API
> is made to look just like a native object. But that's totally
> orthogonal to the IDL and to the wire protocol.
>
To quote yourse
On Tue, 03 Mar 2009 10:55:33 +0100 Alexander Larsson wrote:
> On Mon, 2009-03-02 at 22:26 +, Rob Taylor wrote:
> > Brian J. Tarricone wrote:
> > > Whether or not the object is local (in-process) or not is
> > > irrelevant. Whether or not the method call is sync or async is
> > > also irrelevan
On Mon, 2009-03-02 at 22:26 +, Rob Taylor wrote:
> Brian J. Tarricone wrote:
> > Whether or not the object is local (in-process) or not is irrelevant.
> > Whether or not the method call is sync or async is also irrelevant. It's
> > a method call, pure and simple. DBus itself even calls them me
Hi Brian,
Thanks for your reply,
>> I understand that there is no difference on-the-wire between a
>> function-call and message passing. The difference is in peoples
>> perceptions and expectations.
>>
>> When I read CORBA IDL and see:
>>
>> int AFunction (int, int);
>>
>> Because of the connotat
Brian J. Tarricone wrote:
> Mark Doffman wrote:
>
>> I understand that there is no difference on-the-wire between a
>> function-call and message passing. The difference is in peoples
>> perceptions and expectations.
>>
>> When I read CORBA IDL and see:
>>
>> int AFunction (int, int);
>>
>> Because
Mark Doffman wrote:
I understand that there is no difference on-the-wire between a
function-call and message passing. The difference is in peoples
perceptions and expectations.
When I read CORBA IDL and see:
int AFunction (int, int);
Because of the connotations provided to me by years of proc
On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
wrote:
> Hello Everyone,
I think the DBus list would be interested too.
> I feel that the D-Bus introspection XML is used badly. For writing a
> D-Bus specification there is too little information to understand a
> protocol. Although numerous extensio
Hi Havoc,
Thanks for the reply. I have also changed the subject of this which I
should have done in the initial e-mail.
> Hi,
>
> On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
> wrote:
>> Both the throws and reply clauses are optional, but if a method does not
>> have a reply it should not have
Hi,
On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
wrote:
> Both the throws and reply clauses are optional, but if a method does not
> have a reply it should not have a throws clause.
This is perhaps a misunderstanding. All methods have replies (in the
wire protocol). You may choose to ignore or n
Hello all,
There were some glaring errors in the example IDL I provided.
> On to the syntax:
>
> My idea for the IDL syntax is to remain close to the 'C' family of
> languages, and is most places to C#.
>
> Elements can be namespaced using:
>
> namespace {
>
> }
>
Should be:
namespac
Hi Mikkel
>
>>
>>
>>
>> Methods are declared by:
>>
>> method methodName {
>>enumName anenum;
>> } reply {
>>structName astruct;
>> } throws (ErrorOne, ErrorTwo);
>>
>
> If you are so keen on clearing out that this is not really a 'method' then
> why is it declared as such? Why
2009/3/2 Mark Doffman
>
>
>
> Methods are declared by:
>
> method methodName {
>enumName anenum;
> } reply {
>structName astruct;
> } throws (ErrorOne, ErrorTwo);
>
If you are so keen on clearing out that this is not really a 'method' then
why is it declared as such? Why not cal
Hello Everyone,
There has been some discussion about an IDL for EggDBus. I have also
recently started working on a D-Bus IDL so would like to get some
feedback on the syntax and how well the IDL would fit when generating
EggDBus bindings.
I have been working on D-Bus AT-SPI and the IDL is born ou
Hi,
On Fri, Feb 13, 2009 at 10:35 AM, Matthias Clasen
wrote:
>
> Not sure what that 'something else' would be on win32 or os x. Anyway,
> dbus works fine on os x, as far as I know. And I think there is a
> working win32 port around (even if it hasn't been merged back into
> dbus proper yet).
The
Hi,
On Wed, Feb 11, 2009 at 1:07 AM, Matthias Clasen
wrote:
> There is also some work by Ryan Lortie on a Glib-compatible Dbus api
> called gbus. It is lower-level than EggDbus, and might be suitable as a
> replacement for libdbus. While I have no clear idea yet how EggDbus and
> gbus will eventu
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
> With 2.20 winding down, I think now would be a good time to talk about
> what should happen in Glib 2.22.
As has been discussed on bugzilla, I'd like to also get DNS resolving
and network support into gio in the next release. Related bugs
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
> - Where do we put this ? Inside libgobject (since it is more or less
> DBus bindings for GObject) or inside libgio (since it uses the GIO async
> pattern and some utility classes from GIO) or separate ?
>
>My proposal: Add it as a se
Matthias Clasen schrieb:
> On Fri, Feb 13, 2009 at 11:52 AM, Stefan Kost wrote:
>> hi,
>> Matthias Clasen schrieb:
>>> With 2.20 winding down, I think now would be a good time to talk about
>>> what should happen in Glib 2.22.
>> What about
>> http://bugzilla.gnome.org/show_bug.cgi?id=348080
>> "G
From: "Vincent Untz", Date: 14/02/2009 01:25 :
> Le mercredi 11 février 2009, à 11:31 +, Alberto Ruiz a écrit :
>> 2009/2/11 Matthias Clasen ;:
>>> This would allow us to move forward with several things in GTK+ that
>>> will work much better if they can use DBus:
>>> - session support
>>> - u
On Fri, Feb 13, 2009 at 11:52 AM, Stefan Kost wrote:
> hi,
> Matthias Clasen schrieb:
>> With 2.20 winding down, I think now would be a good time to talk about
>> what should happen in Glib 2.22.
>
> What about
> http://bugzilla.gnome.org/show_bug.cgi?id=348080
> "GObject property bindings like in
hi,
Matthias Clasen schrieb:
> With 2.20 winding down, I think now would be a good time to talk about
> what should happen in Glib 2.22.
What about
http://bugzilla.gnome.org/show_bug.cgi?id=348080
"GObject property bindings like in libexo"
there is a patch attached. This is one of the feature tha
Matthias Clasen wrote:
> On Fri, Feb 13, 2009 at 10:25 AM, Vincent Untz wrote:
>> In the end I don't expect the use of dbus in the rest of the glib/gtk+
>> stack API to be visible (but maybe I'm naive here).
...
> That being said, I'd expect that at least for some of the anticipated
> use cases of
On Fri, Feb 13, 2009 at 10:25 AM, Vincent Untz wrote:
>> Would DBus be swappable here for something else on non freedesktop
>> environments? (Windows, Mac)
>
> Just wondering if an easy way like "make this API UNIX-only" is an
> option that can be considered?
>
> In the end I don't expect the use
Le mercredi 11 février 2009, à 11:31 +, Alberto Ruiz a écrit :
> 2009/2/11 Matthias Clasen :
> > With 2.20 winding down, I think now would be a good time to talk about
> > what should happen in Glib 2.22.
> >
> > One thing that has been tossed around for a long time is that it would
> > be real
On Wed, 2009-02-11 at 09:56 +, Ross Burton wrote:
> On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
> > - Where do we put this ? Inside libgobject (since it is more or less
> > DBus bindings for GObject) or inside libgio (since it uses the GIO
> > async
> > pattern and some utility cl
Am Mittwoch, den 11.02.2009, 11:31 + schrieb Alberto Ruiz:
> 2009/2/11 Matthias Clasen :
> > With 2.20 winding down, I think now would be a good time to talk about
> > what should happen in Glib 2.22.
> >
> > One thing that has been tossed around for a long time is that it would
> > be really g
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
> - What do we do about collections ? EggDbus adds typesafe GObject
> wrappers around GHashTable and GArray. Other people have grandiose plans
> to force java/.net style collection interfaces into GObject.
You are using the phrase "To forc
2009/2/11 Matthias Clasen :
> With 2.20 winding down, I think now would be a good time to talk about
> what should happen in Glib 2.22.
>
> One thing that has been tossed around for a long time is that it would
> be really good to have DBus support on the Glib level.
Would this support be optional
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
> - Where do we put this ? Inside libgobject (since it is more or less
> DBus bindings for GObject) or inside libgio (since it uses the GIO
> async
> pattern and some utility classes from GIO) or separate ?
>
>My proposal: Add it as a s
Hi,
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote:
> A while ago David put forward his work on EggDbus and wrote a very
> detailed mail [1] with arguments for why it would be very good to have
> DBus support on the Glib level, why dbus-glib is not good enough, and
> how his EggDbus bind
With 2.20 winding down, I think now would be a good time to talk about
what should happen in Glib 2.22.
One thing that has been tossed around for a long time is that it would
be really good to have DBus support on the Glib level.
This would allow us to move forward with several things in GTK+ tha
71 matches
Mail list logo
