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 can
Hi,
On Fri, Apr 24, 2009 at 6:56 AM, Simon McVittie
simon.mcvit...@collabora.co.uk 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
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 print
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 practical
Havoc Pennington wrote:
Hi,
On Thu, Apr 23, 2009 at 1:24 PM, Robert McQueen
robert.mcqu...@collabora.co.uk 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
On Thu, Apr 23, 2009 at 6:24 PM, Robert McQueen
robert.mcqu...@collabora.co.uk 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
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
point
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
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 not
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 in
Am Mon, 20 Apr 2009 17:00:41 +0200
schrieb Alexander Larsson al...@redhat.com:
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
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
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-open
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
even if GVfs
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 GVfs is not
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:
As it's
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, Allin Cottrell
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 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/GPL
Hi,
On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell cottr...@wfu.edu 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.
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 throwing
Hi,
On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller t@zen.co.uk 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
On Sun, 19 Apr 2009, Havoc Pennington wrote:
On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller t@zen.co.uk 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
Hi,
On Sun, Apr 19, 2009 at 8:05 PM, Allin Cottrell cottr...@wfu.edu 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
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 t@zen.co.uk wrote:
You tell people not to worry. But many people clearly do seem to worry.
Well, why don't these many people
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
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 the
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
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 fairly
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
Hi,
On Fri, Apr 3, 2009 at 2:56 PM, Will Thompson
will.thomp...@collabora.co.uk 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
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
Hi,
On Thu, Apr 2, 2009 at 7:05 PM, Ryan Lortie de...@desrt.ca 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
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
raised
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 method
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 irrelevant. It's a
2009/3/2 Havoc Pennington havoc.penning...@gmail.com
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
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 years of
Hi,
On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen
mikkel.kamst...@gmail.com wrote:
2009/3/2 Havoc Pennington havoc.penning...@gmail.com
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
2009/3/3 Havoc Pennington h...@pobox.com
Hi,
On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen
mikkel.kamst...@gmail.com wrote:
2009/3/2 Havoc Pennington havoc.penning...@gmail.com
Anyway, I think there is no difference between method calls and
message passing. The only
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
2009/3/2 Mark Doffman mark.doff...@codethink.co.uk
SNIP
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
Hi Mikkel
SNIP
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 call it
Hi,
On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
mark.doff...@codethink.co.uk 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).
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
mark.doff...@codethink.co.uk wrote:
Both the throws and reply clauses are optional, but if a method does not
have a
On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman
mark.doff...@codethink.co.uk 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.
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
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 of the
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 connotations provided to
Hi,
On Wed, Feb 11, 2009 at 1:07 AM, Matthias Clasen
matthias.cla...@gmail.com 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
Hi,
On Fri, Feb 13, 2009 at 10:35 AM, Matthias Clasen
matthias.cla...@gmail.com 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
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
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:
Matthias Clasen schrieb:
On Fri, Feb 13, 2009 at 11:52 AM, Stefan Kost enso...@hora-obscura.de 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
Le mercredi 11 février 2009, à 11:31 +, Alberto Ruiz a écrit :
2009/2/11 Matthias Clasen matthias.cla...@gmail.com:
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
On Fri, Feb 13, 2009 at 10:25 AM, Vincent Untz vu...@gnome.org 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
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 that
On Fri, Feb 13, 2009 at 11:52 AM, Stefan Kost enso...@hora-obscura.de 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
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 matthias.cla...@gmail.com;:
This would allow us to move forward with several things in GTK+ that
will work much better if they can use DBus:
- session
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
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
2009/2/11 Matthias Clasen matthias.cla...@gmail.com:
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
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 force.
Am Mittwoch, den 11.02.2009, 11:31 + schrieb Alberto Ruiz:
2009/2/11 Matthias Clasen matthias.cla...@gmail.com:
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
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 classes
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+
66 matches
Mail list logo
