GLib plans for the next cycle

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

David Zeuthen
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 need to determine its D-Bus type.
> It sounds like with EggDBus that's not possible without you discovering
> the type by external means. If the C-side type system isn't powerful
> enough to express the D-Bus-side types (which GType isn't), then the
> C-side type system should be improved. Gluing the D-Bus type onto the
> side doesn't sound like a clean way to do this to me.

Keep in mind that the goal of EggDBus was just to provide an object
mapping using generated code. With generated code it is a non-issue
whether you have to pass just a GType or the pair (GType, D-Bus
signature) since all that happens from generated code.

Of course this approach is not very clean if your goal is to also
provide some a C API that is useful outside the context of generated
code. While I don't think that's compelling (you are going to lose type
safety for starters) apparently a lot of people want this kind of API. I
agree it's sensible to have.

> Apparently, back when Telepathy was started, dbus-glib used to have a
> similar problem with collections containing structs. It relied on
> inspecting the contents of a GValueArray to determine the type of the
> struct it represents, which obviously can't work for a(ss) since the
> array might be empty. (Rob Taylor fixed this by adding a parameterized
> struct type.) More recently, Rob McQueen had to fix dbus-glib to allow
> complex types in maps. If the binding gets the type system right and
> complete from the start, problems like this (and the current situation
> where dbus-glib can't send 16-bit ints, causing interoperability
> problems with bindings which expect them) won't arise later.

Yes, we probably want a type system where you can do e.g.

g_bus_send_message (connection,
                    "org.foo.SomeService",
                    "/org/foo/SomeObject",
                    "org.foo.SomeInterface.SomeMethod",
                    cancellable,
                    async_ready_callback,
                    G_TYPE_PTR_ARRAY (G_TYPE_PTR_ARRAY (G_TYPE_STRING)),
                    array_of_array_of_strings,
                    G_TYPE_HASH_TABLE (G_TYPE_STRING,
                                      G_TYPE_PTR_ARRAY (G_TYPE_STRING)),
                    hash_of_strings_to_ptr_array_of_strings,
                    G_TYPE_INVALID);

instead of

g_bus_send_message (connection,
                    "org.foo.SomeService",
                    "/org/foo/SomeObject",
                    "org.foo.SomeInterface.SomeMethod",
                    cancellable,
                    async_ready_callback,
                    G_TYPE_PTR_ARRAY, "aas",
                    array_of_array_of_strings,
                    G_TYPE_HASH_TABLE, "a{sas}",
                    hash_of_strings_to_ptr_array_of_strings,
                    G_TYPE_INVALID);

e.g. enable the API user to express a complete D-Bus signature via GType
instead of having to pass both the GType and the D-Bus signature.  That
is essentially what you are talking about right?

Personally I don't think it's a big deal having to do the latter. In my
view both of these approaches are much worse than having a generated
GInterface for the org.foo.SomeInterface D-Bus interface and having
GObject-derived classes for the structs you need. YMMV though.

> > The point is that you can always get to the D-Bus signature and from
> > that you can infer the complete type.
>
> dbus-python has shown that that's not true. When marshalling a dict (for
> instance), it has to guess what the type is, and it sometimes guesses
> wrongly, leading to hard-to-debug problems. It tries to quietly
> introspect behind your back to work around this, and that too causes
> problems.

Certainly if you pass your low-level code the D-Bus signature for a
single complete type (like the above example and like EggDBus does) no
guessing is _ever_ needed. I mean, the D-Bus signature _defines_ exactly
what to output so if you run into problems (e.g. with Python) maybe it's
because you have a problem decoding the native types the user passed in
(which sounds easy to run into with Python).

> > The set of distinct D-Bus signatures you encounter in a app where you
> > would need to do this (e.g. no need to do this for primitive types) is
> > most likely bounded to a couple of dozen types at the most (unless you
> > are some odd-ball corner case like a D-Bus version of gconf-editor) so I
> > don't think this is a big deal at all.
>
> I think regarding types more complicated than 'as', 'b', 'i' etc. as
> "odd-ball corner cases" is a mistake,

I think you misunderstood what I meant with odd-ball cases here. What I
meant was with a D-Bus-ified version gconf-editor being an oddball case
was simply ... that it would run into a lot of distinct types assuming
we'd store arbitrary variants in GConf. So a lot of types would be
registered with the G type system.

> particularly when talking about
> one of the core components of the GNOME platform. The fact that D-Bus
> has an expressive recursive type system is good, since it means you can
> model interesting concepts without forcing them into an incorrect
> representation. But for this to be useful, the binding has to support
> complex types just as much, if not more, than simple ones, particularly
> in a language like C.
>
> Telepathy uses some pretty complex D-Bus types; an example that comes to
> mind is 'a{ua(a{sv}as)}'. If working with this type in the standard GLib
> D-Bus binding is no less painful than it currently is with dbus-glib,
> then using a component of the GNOME stack with a standard GNOME binding
> will be unnecessarily difficult. I really don't want to end up in a
> situation where I have to use an external library instead of the one
> inside GLib to make working with Telepathy less painful.

The key to dealing with signatures like a{ua(a{sv}as)} is to have good
native type-system support for it. In C with GObject I'm fairly
convinced that unless you generated an easy to use GObject class per
struct type you are somewhat doomed (that's my experience with dbus-glib
anyway).

FWIW, with the object mapping I have in EggDBus (and what I essentially
propose for GLib) dealing with methods with signature a{ua(a{sv}as)} in
C and GObject isn't painful at all. You'd get a generated GObject class
for the (a{sv}as) structure (with a constructor and getters/setters for
the two elements) and the rest are just dealing hash tables and pointer
arrays. Piece of cake really.
 
Btw, if you examine the EggDBus source code you will find that the
test-cases covers even more interesting and bizarre signatures e.g.

http://cgit.freedesktop.org/~david/eggdbus/tree/src/tests/com.example.Frob.xml

and all these work fine. A goal of the EggDBus object mapping was in
fact to cover every really bizarre corner cases hence the test suite
being full of bizarre stuff like this

<method name="TestHashTableOfHashTablesOfStructures">
 <arg direction="in"  type="a{sa{s(ii)}}" name="hash_of_hash_of_points">

and dealing with that isn't at all unreasonable.

     David


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-3
In reply to this post by Will Thompson-5
Hi,

On Fri, Apr 3, 2009 at 2:56 PM, Will Thompson
<[hidden email]> 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 pass an int, or an array of
foo, so the marshaler marshals an int or an array of foo); or it can
be explicit (someone specifies the signature somewhere); but either
way, the two sides of an IPC connection have to agree in advance at
code-writing time what the signature of something is.
(Modulo overloading/variants, i.e. an agreement to do switching on
type at runtime, of course.)

The JavaScript/gjs dbus bindings work very well, and there's no dbus
signature stuck to a JS integer type to say what kind of integer it
is. The way it works is that you provide the interface and the types
get coerced. So if an interface takes an int8, you can pass in an
integer or a double or a bool or anything that can convert to int8,
and it gets converted.

The need for sticking all this extra goo in GType for dbus-glib's
benefit is arising because dbus-glib is broken. If all the design
decisions are correct, said goo should not be needed.

Which is good, because the goo is completely unnatural in C, not to
mention bloated. When was the last time you made a GHashTable full of
GValue and you were *not* using dbus-glib? The answer for me is I've
been writing "G" C for a decade and have never done this. A decent C
binding isn't going to "leak" freaky data types and data structures
into the rest of your program.

The only place this type info should need to be in a *value* (rather
than an interface description) is for variants. That's where GVariant
comes in.

> But for this to be useful, the binding has to support
> complex types just as much, if not more, than simple ones, particularly
> in a language like C.

The *binding* needs to support complex types, but the *language*
doesn't. In effect, libgobject defines a dialect or superset-language
of C. If it were true that GType and libgobject had to exactly support
all the types dbus does, it would also be true that to map dbus to
python or JavaScript, those languages would have to support exactly
all the types dbus does. But that isn't true.

The problem arises when you try to specify dbus signatures using the
type system of the *language* instead of the type system of *dbus*.
This is simply a bad idea. The introspection data - wherever it lives,
implicit or explicit - should be in dbus's signature format, or
something semantically equivalent. It doesn't make sense to express a
dbus signature (or more generally, the signature of a serialized data
blob) in GTypes, imo. Just makes a mess.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Ryan Lortie
In reply to this post by Gustavo Noronha Silva-5
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 stroke me. What about int32? Should it be added for completeness
> sake, or it is a non-issue?

On every platform on which glib currently runs "int" is exactly 32 bits
in size.

Maybe we get in trouble in some distant future time when we decide to
port to some exotic new platform, but for now it's not a problem.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Tim-Philipp Müller
In reply to this post by Havoc Pennington-3
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 a bone to people who cared. (...)
>
>  (snip commentary and what-ifs)
>
> There are many things to worry about in life, but this is not one of them.

I hear what you're saying, and I don't really have a strong opinion or
much detailed knowledge on the licensing subject myself, but I can't
help but feel that there's still something wrong about all this.

You tell people not to worry. But many people clearly do seem to worry.

It seems to me that by making GLib, the cornerstone of our platform,
depend on libdbus, we'd be creating a fair bit of uncertainty, and I
can't see that as being good for the platform.

At best this means inconvenience and hassle for people already building
on our platform while they evaluate the new situation for themselves. At
worst it deters people from considering or adopting it.

I don't think this is something we'd even be considering if there was a
good alternative.

Just to be clear, I'm very much in favour of adding DBus support to
GLib, I'm just a bit reluctant about shrugging off the dbus license
aspect like that.

Cheers
 -Tim


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-3
Hi,

On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller <[hidden email]> 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/msg00008.html

If it's a legitimate concern then someone specific will turn up and
make a rational argument that's responsive to the points I made.

As far as I'm concerned, libdbus's license situation is the same as
that of glib itself, because it's effectively the same as LGPL. And
guess what - the same bankrupt company that contributed to libdbus
contributed to glib and gtk, too. Plus hundreds of other people.
libdbus at least has relicense permission for every bit of code except
the codefactory bits.

If someone wants to do something productive, it would be great to add
to dbus/COPYING a note that all new code, and almost all existing
code, is MIT/X11. So if we do solve the codefactory code through
rewriting some files, the rest is all already relicensed. Otherwise it
isn't clear what license new patches are going in under. My only
question here is whether there were any missing relicense responses
other than the codefactory one.

> It seems to me that by making GLib, the cornerstone of our platform,
> depend on libdbus, we'd be creating a fair bit of uncertainty

Only because people have a whisper campaign about how there's some
unclear problem, when they (afaict) are just wrong.

I don't see a reason we should care about how "some people" have some
unspecified, unexplained (and as best I can figure, flat wrong)
worries; and these "some people" are not turning up. If someone shows
up and actually makes a convincing argument, that's different.

Even if there's a problem, which one sounds easier:

 * replace the parts of libdbus that CodeFactory wrote (which are
really not that large.)
 * reimplement the entirety of libdbus and dbus-daemon and port
everything using them

I would advocate lazy-replacing the codefactory code at the point that
it is clearly a practical issue. Which will be never.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Allin Cottrell
On Sun, 19 Apr 2009, Havoc Pennington wrote:

> On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller <[hidden email]> 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/msg00008.html
>
> If it's a legitimate concern then someone specific will turn up
> and make a rational argument that's responsive to the points I
> made.

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 a particle of doubt that the
license is not an issue (i.e., "afaict" is not good enough).

On a matter that may or may not be related, I'm concerned about
possible "over-extension" of GTK/glib.  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 supported".  After some
googling, it appears that one must have gvfs installed.  OK, I
download, build and install gvfs.  But it doesn't help.  Gvfs as
built on my system (without configure or compilation errors)
apparently can't handle URIs; I suppose this facility must depend
on yet further third-party libraries.  Avahi?  It's all
undocumented, so I'm only guessing.

This sort of thing is new, and IMO thoroughly obnoxious: up till
now, one could depend on GTK functions working provided one had
successfully installed the known stack of dependencies, which were
checked at compile time for GTK and friends.  Now we have GTK
functions that may or may not work depending on unspecified
dependencies.  Way NOT to go!

Allin Cottrell

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-3
Hi,

On Sun, Apr 19, 2009 at 8:05 PM, Allin Cottrell <[hidden email]> 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 a particle of doubt that the
> license is not an issue (i.e., "afaict" is not good enough).

I don't think "afaict" is a good summary of the detailed analysis of
the problem I also posted. "afaict" was just allowing for the fact
that someone could show up and have some counterargument, in an
"anything is possible" kind of sense.

Let's not have this "well just the fact that a question was raised is
a problem" claim. There's a problem if there's an actual problem.
Logic can be applied to the situation, the licenses can be read,
probabilities analyzed, and it's quite possible to reach a rational
conclusion.

I think my arguments are compelling. If someone else thinks
differently, they can say so, and explain their reasoning.

And let's not mix this licensing stuff in with technical arguments.
Some people are concerned about glib dependencies, others would rather
use a different dbus implementation than libdbus for technical
reasons, etc.; those are all fine discussions, but not related.

The bottom line is that dbus has an MIT/X11-equivalent license, with
the addition of a *weaker* patent clause than LGPL/GPL already have.
The license was written by a lawyer and is perfectly sane.

Havoc
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

David Zeuthen
In reply to this post by Allin Cottrell
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 <[hidden email]> 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/msg00008.html
> >
> > If it's a legitimate concern then someone specific will turn up
> > and make a rational argument that's responsive to the points I
> > made.
>
> 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 a particle of doubt that the
> license is not an issue (i.e., "afaict" is not good enough).

I think it is sufficient to observe that there already is an
overwhelming amount of GPLv2+ and LGPLv2+ software already linking to
libdbus-1 (including things like GVfs) and already shipped by major
stakeholders...

> On a matter that may or may not be related, I'm concerned about
> possible "over-extension" of GTK/glib.  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 supported".  After some
> googling, it appears that one must have gvfs installed.  OK, I
> download, build and install gvfs.  But it doesn't help.  Gvfs as
> built on my system (without configure or compilation errors)
> apparently can't handle URIs; I suppose this facility must depend
> on yet further third-party libraries.  Avahi?  It's all
> undocumented, so I'm only guessing.
>
> This sort of thing is new, and IMO thoroughly obnoxious: up till
> now, one could depend on GTK functions working provided one had
> successfully installed the known stack of dependencies, which were
> checked at compile time for GTK and friends.  Now we have GTK
> functions that may or may not work depending on unspecified
> dependencies.  Way NOT to go!

This is _supposed_ to work, there's already an unpleasant amount of work
in GIO to ensure that things work when things like GVfs (which requires
a modern flavor of Linux or UNIX) is not available.

Now, GIO may not work as well as when GVfs installed (e.g. automounting
storage devices won't work unless the OS actively assists with playing
games like modifying /etc/fstab) but basics like launching a program for
URIs _should_ work - e.g. http, mailto, file:///path/to/some.jpg file or
other well-known URIs schemes.

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 GConf under
in /desktop/gnome/url-handlers/<scheme>) so it's no surprise things
don't work if GVfs is not installed.

I think it would be reasonable if GIO at least handled file:// and maybe
also http:// and mailto:// (the former by using the MIME, the latter two
by include a search path of well-known applications like epiphany
firefox, evolution and thunderbird) and also the URI schemes used to
launch Yelp.

You should probably file a bug about this.

     David


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Allin Cottrell
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 supported".  After some googling, it appears
> > that one must have gvfs installed.  OK, I download, build and
> > install gvfs.  But it doesn't help.  Gvfs as built on my
> > system (without configure or compilation errors) apparently
> > can't handle URIs...
> >
> > This sort of thing is new, and IMO thoroughly obnoxious: up till
> > now, one could depend on GTK functions working provided one had
> > successfully installed the known stack of dependencies, which were
> > checked at compile time for GTK and friends.  Now we have GTK
> > functions that may or may not work depending on unspecified
> > dependencies...
>
> This is _supposed_ to work, there's already an unpleasant amount of work
> in GIO to ensure that things work when things like GVfs (which requires
> a modern flavor of Linux or UNIX) is not available.
>
> Now, GIO may not work as well as when GVfs installed (e.g. automounting
> storage devices won't work unless the OS actively assists with playing
> games like modifying /etc/fstab) but basics like launching a program for
> URIs _should_ work - e.g. http, mailto, file:///path/to/some.jpg file or
> other well-known URIs schemes.
>
> 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 GConf under
> in /desktop/gnome/url-handlers/<scheme>) so it's no surprise things
> don't work if GVfs is not installed.

Yes, that's right.  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 not in turn incorporate GConf support.  I thought I'd read
that GConf was supposed to be deprecated, or on the way there?

> I think it would be reasonable if GIO at least handled file://
> and maybe also http:// and mailto:// (the former by using the
> MIME, the latter two by include a search path of well-known
> applications like epiphany firefox, evolution and thunderbird)
> and also the URI schemes used to launch Yelp.

Agreed.

> You should probably file a bug about this.

OK, will do.

Allin Cottrell
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

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 GDesktopAppInfoLookup in GIO,
> > there's only one in GVfs  (that looks up stuff in GConf under
> > in /desktop/gnome/url-handlers/<scheme>) so it's no surprise things
> > don't work if GVfs is not installed.
>
> Yes, that's right.  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 not in turn incorporate GConf support.  I thought I'd read
> that GConf was supposed to be deprecated, or on the way there?

I don't understand what you propose? There is no in-use non-gconf
setting for mapping default handlers for entire uri scheme. So, we
lookup none which mean we then fall back to the per-mime default.

Its entierly unreasonable to have a file:// uri handler, as that would
open *all* types of local files, overriding your per-mime specs.


_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Allin Cottrell
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 not in turn incorporate GConf support.  I thought I'd read
> > that GConf was supposed to be deprecated, or on the way there?
>
> I don't understand what you propose? There is no in-use non-gconf
> setting for mapping default handlers for entire uri scheme. So, we
> lookup none which mean we then fall back to the per-mime default.

The uri I'm testing with gtk_show_uri is a simple http reference.
So far as I can tell the attempt to handle it grinds to a halt in
g_file_query_info with iface->query_info = NULL.  gnome_url_show
has no problem getting firefox to open it.

--
Allin Cottrell
Department of Economics
Wake Forest University

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Christian Dywan-2
In reply to this post by Alexander Larsson
Am Mon, 20 Apr 2009 17:00:41 +0200
schrieb Alexander Larsson <[hidden email]>:

> 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 GConf
> > > under in /desktop/gnome/url-handlers/<scheme>) so it's no
> > > surprise things don't work if GVfs is not installed.
> >
> > Yes, that's right.  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 not in turn incorporate GConf support.  I thought I'd read
> > that GConf was supposed to be deprecated, or on the way there?
>
> I don't understand what you propose? There is no in-use non-gconf
> setting for mapping default handlers for entire uri scheme. So, we
> lookup none which mean we then fall back to the per-mime default.
>
> Its entierly unreasonable to have a file:// uri handler, as that would
> open *all* types of local files, overriding your per-mime specs.

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.

Just my 2 pfennig,
    Christian
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

David Zeuthen
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 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...

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Cosimo Cecchi-2
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 already uses GIO since 2.24 [1] so yes, we would have that
loop already. OTOH, as libgnome depends on GConf, if you have gnome-open
available, you're likely to also have GConf already installed.

[1]
http://svn.gnome.org/viewvc/libgnome/trunk/libgnome/gnome-open.c?view=markup

Ciao,

Cosimo

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alexander Larsson
In reply to this post by Allin Cottrell
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 _is_ present (as it is now on my system), if GVfs
> > > does not in turn incorporate GConf support.  I thought I'd read
> > > that GConf was supposed to be deprecated, or on the way there?
> >
> > I don't understand what you propose? There is no in-use non-gconf
> > setting for mapping default handlers for entire uri scheme. So, we
> > lookup none which mean we then fall back to the per-mime default.
>
> The uri I'm testing with gtk_show_uri is a simple http reference.
> So far as I can tell the attempt to handle it grinds to a halt in
> g_file_query_info with iface->query_info = NULL.  gnome_url_show
> has no problem getting firefox to open it.

Well, if you don't have gvfs installed then you will not be able to
either look up the uri handler for the http uri scheme in gconf, nor
will you be able to query_info for the mime type of the file on the http
server. It should not grind to a halt though, can you explain in more
detail what happens?

For the gnome_url_show() case this calls the old gnome_vfs_url_show()
which reads the http scheme default from gconf. This is the same
behaviour as gtk_show_url would have if you had gvfs installed with
gconf support.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Allin Cottrell
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 present.  But more than that: it'll fail
> > > > even if GVfs _is_ present (as it is now on my system), if GVfs
> > > > does not in turn incorporate GConf support.  I thought I'd read
> > > > that GConf was supposed to be deprecated, or on the way there?
> > >
> > > I don't understand what you propose? There is no in-use non-gconf
> > > setting for mapping default handlers for entire uri scheme. So, we
> > > lookup none which mean we then fall back to the per-mime default.
> >
> > The uri I'm testing with gtk_show_uri is a simple http reference.
> > So far as I can tell the attempt to handle it grinds to a halt in
> > g_file_query_info with iface->query_info = NULL.  gnome_url_show
> > has no problem getting firefox to open it.
>
> Well, if you don't have gvfs installed then you will not be able to
> either look up the uri handler for the http uri scheme in gconf, nor
> will you be able to query_info for the mime type of the file on the http
> server. It should not grind to a halt though, can you explain in more
> detail what happens?

I put some debugging statements into some of the gio files, and
here's what I'm getting when I try to open the http reference:

g_io_module_load_module: loaded
  '/opt/gtk2/lib/gio/modules/libgvfsdbus.so'
g_io_module_load_module: loaded
  '/opt/gtk2/lib/gio/modules/libgiofam.so'
g_io_extension_point_lookup: 'gio-local-file-monitor' ->
  gio-local-file-monitor
g_io_extension_point_lookup: 'gio-local-directory-monitor' ->
  gio-local-directory-monitor
g_io_module_load_module: loaded
  '/opt/gtk2/lib/gio/modules/libgioremote-volume-monitor.so'
g_io_extension_point_lookup: 'gio-local-directory-monitor' ->
  gio-local-directory-monitor
g_io_extension_point_lookup: 'gio-local-file-monitor' ->
  gio-local-file-monitor
g_io_extension_point_lookup: 'gio-native-volume-monitor' ->
  gio-native-volume-monitor
g_io_extension_point_lookup: 'gio-vfs' -> gio-vfs
g_io_extension_point_lookup: 'gio-vfs' -> gio-vfs
g_io_extension_point_lookup: 'gio-desktop-app-info-lookup' ->
  gio-desktop-app-info-lookup
g_io_extension_point_lookup: ep = 0x9e92e18
g_file_query_info: iface->query_info = NULL
g_file_query_default_handler gave NULL for
  'http://gretl.sourceforge.net'

And an error message "Operation not supported".

Allin Cottrell

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alexander Larsson
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 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 not in turn incorporate GConf support.  I thought I'd read
> > > > > that GConf was supposed to be deprecated, or on the way there?
> > > >
> > > > I don't understand what you propose? There is no in-use non-gconf
> > > > setting for mapping default handlers for entire uri scheme. So, we
> > > > lookup none which mean we then fall back to the per-mime default.
> > >
> > > The uri I'm testing with gtk_show_uri is a simple http reference.
> > > So far as I can tell the attempt to handle it grinds to a halt in
> > > g_file_query_info with iface->query_info = NULL.  gnome_url_show
> > > has no problem getting firefox to open it.
> >
> > Well, if you don't have gvfs installed then you will not be able to
> > either look up the uri handler for the http uri scheme in gconf, nor
> > will you be able to query_info for the mime type of the file on the http
> > server. It should not grind to a halt though, can you explain in more
> > detail what happens?
>
> I put some debugging statements into some of the gio files, and
> here's what I'm getting when I try to open the http reference:

> And an error message "Operation not supported".

Thats not "grind to halt" really, but ok. What do you have built?
It seems to load a libgvfsdbus.so, so gvfs seems to be there, but with
no gconf module? Do you have a session dbus running?

If you have gvfs installed but not with gconf what should happen is that
the query_info on the uri should sniff the mimetype and launch app
depending on that.

Does gvfs stuff work at all in your installation? For instance, what
does "gvfs-info http://gretl.sourceforge.net" print? for me it does:

gvfs-info http://gretl.sourceforge.net
display name: /
edit name: /
type: unknown
size: 14276
attributes:
  etag::value: "37c4-467d4ae02f640"
  standard::display-name: /
  standard::edit-name: /
  standard::content-type: text/html
  standard::size: 14276
  id::filesystem: type=http,uri=http%3A%2F%2Fgretl.sourceforge.net,__mount_prefix=%2F
  time::modified: 1240063057
  time::modified-usec: 0

which should lanuch whatever app is registered for text/html.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Allin Cottrell
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 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 not in turn incorporate GConf support.  I thought I'd read
> > > > > > that GConf was supposed to be deprecated, or on the way there?
> > > > >
> > > > > I don't understand what you propose? There is no in-use non-gconf
> > > > > setting for mapping default handlers for entire uri scheme. So, we
> > > > > lookup none which mean we then fall back to the per-mime default.
> > > >
> > > > The uri I'm testing with gtk_show_uri is a simple http reference.
> > > > So far as I can tell the attempt to handle it grinds to a halt in
> > > > g_file_query_info with iface->query_info = NULL.  gnome_url_show
> > > > has no problem getting firefox to open it.
> > >
> > > Well, if you don't have gvfs installed then you will not be able to
> > > either look up the uri handler for the http uri scheme in gconf, nor
> > > will you be able to query_info for the mime type of the file on the http
> > > server. It should not grind to a halt though, can you explain in more
> > > detail what happens?
> >
> > I put some debugging statements into some of the gio files, and
> > here's what I'm getting when I try to open the http reference:
>
> > And an error message "Operation not supported".
>
> Thats not "grind to halt" really, but ok. What do you have built?
> It seems to load a libgvfsdbus.so, so gvfs seems to be there, but with
> no gconf module? Do you have a session dbus running?

That's right; no gconf module in gvfs but dbus-daemon --system is
running.

> If you have gvfs installed but not with gconf what should happen is that
> the query_info on the uri should sniff the mimetype and launch app
> depending on that.
>
> Does gvfs stuff work at all in your installation? For instance, what
> does "gvfs-info http://gretl.sourceforge.net" print?

It prints the same messages as I gave earlier, culminating in

g_file_query_info: iface->query_info = NULL
Error getting info: Operation not supported

But, e.g., "gvfs-info /usr/local/bin/mplayer" works fine.

Allin Cottrell
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alexander Larsson
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, 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 not in turn incorporate GConf support.  I thought I'd read
> > > > > > > that GConf was supposed to be deprecated, or on the way there?
> > > > > >
> > > > > > I don't understand what you propose? There is no in-use non-gconf
> > > > > > setting for mapping default handlers for entire uri scheme. So, we
> > > > > > lookup none which mean we then fall back to the per-mime default.
> > > > >
> > > > > The uri I'm testing with gtk_show_uri is a simple http reference.
> > > > > So far as I can tell the attempt to handle it grinds to a halt in
> > > > > g_file_query_info with iface->query_info = NULL.  gnome_url_show
> > > > > has no problem getting firefox to open it.
> > > >
> > > > Well, if you don't have gvfs installed then you will not be able to
> > > > either look up the uri handler for the http uri scheme in gconf, nor
> > > > will you be able to query_info for the mime type of the file on the http
> > > > server. It should not grind to a halt though, can you explain in more
> > > > detail what happens?
> > >
> > > I put some debugging statements into some of the gio files, and
> > > here's what I'm getting when I try to open the http reference:
> >
> > > And an error message "Operation not supported".
> >
> > Thats not "grind to halt" really, but ok. What do you have built?
> > It seems to load a libgvfsdbus.so, so gvfs seems to be there, but with
> > no gconf module? Do you have a session dbus running?
>
> That's right; no gconf module in gvfs but dbus-daemon --system is
> running.

gvfs needs a session bus, not a system bus, so you're falling back to a
non-gvfs system. Thus no http support.




_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

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 depends on a big stack of unspecified stuff?  At least this
should be mentioned in the documentation.  As I said before, up
till very recently one has been able to rely on GTK functions
"just working" so long as the compile-time dependencies are
satisfied.

Allin Cottrell
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
1234