Reviewing GVariant
So, today I've built the gsettings branch and set out to review GVariant to make sure it is ready to be merged. I started by reading the docs, and I can't help myself, but I still don't like this GVariantType thing very much. After toiling on this for months, it is probably as obvious to Ryan as GType is to Tim, but for the rest of us, not so much. Just to run down the concepts you meet while reading this chapter, mostly without introduction or explanation: - type classes - basic types, maybe types, container types - 'any' types - generic types - variant types and type strings - element types - generic tuple type - wildcard types and concrete types - type 'matching' I'd really like to call for some reduced excess and some clarity of exposition. - This whole thing would be a lot more digestible if you added a long introduction that explains the type system and introduced the terminology. - If you can't explain clearly in the docs why type classes are a useful thing to have, do away with them. - Get your terminology straight. Do types 'match' other types or do they match values ? Are generic types the same as any types ? And maybe the same as wildcard types as well ? - Unexplained obscurities: Whats this business with defining tuple types via callbacks ? On to the GVariant docs. The terminological uncertainty continues. Does a GVariant _have_ a value, or _is_ it a value ? The introduction says it has a value, whereas the rest of the docs seem to be written assuming that a variant is a value. "'r' means exactly the same as 'r'" ?! "Nested '@' characters may not appear." - this is unclear. Do you mean "Consecutive '@' characters may not appear." ? g_variant_print() should xref g_variant_markup_print(). GVariantIter docs seem to confuse next() and next_value(). E.g. they talk about next() returning NULL when in reality it returns FALSE. The concepts of flattening and serialization could be explained in the introduction. (I've not stopped to point out the numerous instances of parameter name confusion). So much for today, I'll look at the code tomorrow. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus API Questions; was: GDBus/GVariant plans for next GLib release
2009/10/27 Mikkel Kamstrup Erlandsen : > 2009/10/27 David Zeuthen : >> Hey Mikkel, >> >> On Mon, 2009-10-26 at 23:52 +0100, Mikkel Kamstrup Erlandsen wrote: >>> > I just looked over the newly introduced >>> > g_dbus_connection_register_subtree() and related data structures, and >>> > I think it will fit very nicely with what I am going to need. All in >>> > all it looks really sweet, good work. >>> > >>> > One thing though is that as I read it objects in a subtree must be >>> > known before method calls are accepted to them? For my use case in >>> > Zeitgeist I was hoping that I could completely get rid of a "Manager" >>> > type of interface, and just implicitly create objects in the tree >>> > whenever calls where made to them. This does not look possible as it >>> > stands? >>> > >>> > Maybe allowing '*' as a wildcard node name in the subtree enumeration >>> > function? >> >> I'm actually a bit wary of introducing this kind of functionality - >> mainly, I guess, because it screws with the notion that a D-Bus service >> export a set of objects. In particular it makes it hard to >> debug/introspect the service - for example, in extreme abuses of such a >> feature (not the use-case you are suggesting though), you can't really >> use e.g. d-feet to get an idea of what kind of objects are exported and >> known by the service. >> >> The subtree functionality is really just for performance hacks - the >> intended use is to avoid creating a huge amount of objects. For example, >> one use case is export the subtree /org/foo/Project/processes/ >> where is, say, a UNIX process id. With the subtree handler, no >> object creation over is necessary. >> >> Anyway, your original use case does seem sound and reasonable - it >> reduces overhead insofar that the client saves a round-trip to a >> hypothetical Manager.CreateObject() method that would be needed if we >> didn't have this. It does make it less intuitive insofar that remote >> object creation is this magical thing with automatically appearing >> nodes... but I guess that's fine. > > Not to mention the built in race condition you have if the exported > objects can also be deleted via the manager. All client apps would > have to precede all calls to an object by a Create() message (and it > would still be racy). Anyway, enough about this :-) I think it is > probably a fragment of my REST/web background where such patterns are > more common. > >>> I had a stab at this myself. The wildcard idea seemed like a bad one, >>> so I instead added another gboolean param to >>> g_dbus_connection_register_subtree(), @is_dynamic. >>> >>> If is_dynamic is TRUE then objects need not be in the enumerated list >>> of objects in order to be introspected and dispatched. Pretty simple. >>> >>> No matter the simplicity I still managed to screw up one of the unit >>> tests. I will fix it and add some specific tests for the dynamic case >>> if you give the "go" for this David. >> >> Sounds good to me. I'd prefer a GDBusSubtreeFlags flag enumeration with >> a G_DBUS_SUBTREE_FLAGS_DISPATCH_TO_UNENUMERATED_NODES member instead of >> @is_dynamic. Just for future proofing and all. Maybe it would also be >> nice to pass a "gboolean enumerated" to @introspect and @dispatch that >> indicates whether the node was enumerated (or not). > > That sounds like a better idea. I'll have another stab at this tonight > if the kids allow me :-) They did :-) Attached is a series of patches (0001 should be identical to my previous) implementing what you describe, except adding the gboolean enumerated arg to @introspect and @dispatch. I will get around to that. The failing unit tests I described was really just me b0rking up the linking between some installed gdbus components and my devel version. I have them running now[1] and I added some testing for the dynamic objects as well (see 0003). -- Cheers, Mikkel [1]: One caveat is that I see some errors about refcount on GVariants from the /gdbus/method-calls-in-thread test every now and then, but it runs mostly. Looks like a race, but it is unrelated to my hacks. You've probably already seen it yourself. From d569ee5b89b8865747a153fb3848764c52a4c865 Mon Sep 17 00:00:00 2001 From: Mikkel Kamstrup Erlandsen Date: Tue, 27 Oct 2009 20:45:34 +0100 Subject: [PATCH 1/3] Add a @is_dynamic gboolean parameter to g_dbus_connection_register_subtree(). This will be reworked to use an enumeration/flag instead for better future extensibility --- gdbus/example-subtree.c |1 + gdbus/gdbusconnection.c | 24 ++-- gdbus/gdbusconnection.h |1 + gdbus/tests/export.c|3 +++ 4 files changed, 23 insertions(+), 6 deletions(-) diff --git a/gdbus/example-subtree.c b/gdbus/example-subtree.c index 041a8f4..f870589 100644 --- a/gdbus/example-subtree.c +++ b/gdbus/example-subtree.c @@ -332,6 +332,7 @@ on_name_acquired (GDBusConnection *connection, registration_id = g_dbus_connection_register_subtree (connection,
RE: error building git head GTK on OS X ... IM symbols missing etc.
Success!
I had to manually edit the ige-mac-integration's Makefile in the src directory
and delete -Werror.
I still have to build libglade and mysql before I can build my app and test.
EMAILING FOR THE GREATER GOOD
Join me
From: shashan...@hotmail.com
To: k...@gtk.org
Subject: RE: error building git head GTK on OS X ... IM symbols missing etc.
Date: Tue, 27 Oct 2009 15:52:02 -0400
CC: gtk-devel-list@gnome.org
rm -rf the freetype-2.3.11 files from both gtk/source/pkgs and /gtk/source
re-run jhbuild build meta-gtk-osx-core
its working.
EMAILING FOR THE GREATER GOOD
Join me
From: shashan...@hotmail.com
To: k...@gtk.org
Subject: RE: error building git head GTK on OS X ... IM symbols missing etc.
Date: Tue, 27 Oct 2009 13:40:40 -0400
CC: gtk-devel-list@gnome.org
Yep. That fixed it.
For some reason I still had to download and install libiconv before I can run
phase 2 of the meta-gtk-osx-core, when building glib it complains using header
without any libraries present?
Also, the script crashes out on the freetype module. gzip complains about a bad
file. I downloaded the same version from the website, but now it won't compile
with "do not know how to make start".
I don't have any more time for this today... but I will keep cranking and
reporting here.
Thanks for all the help.
EMAILING FOR THE GREATER GOOD
Join me
> Subject: Re: error building git head GTK on OS X ... IM symbols missing etc.
> From: k...@gtk.org
> Date: Tue, 27 Oct 2009 17:31:03 +0100
> CC: jra...@ceridwen.us; gtk-devel-list@gnome.org
> To: shashan...@hotmail.com
>
> On Oct 27, 2009, at 5:25 PM, Shawn Bakhtiar wrote:
> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=
> > \"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -
> > DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include -
> > DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo -
> > MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC -
> > o .libs/gatomic.o
> > /var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s:
> > 103:Incorrect register `%rdx' used with `l' suffix
>
> Ah yes, I think I have stumbled on this as well. This is probably
> caused because the default jhbuildrc for the Mac forces a build for
> the 486:
>
> # When building on intel, force build to be 486, since glib won't
> # enable asm atomic operations otherwise.
> #
> try:
> _f = os.popen("uname -p")
> if _f.read().startswith("i386"):
> append_autogenargs("glib", "--build=i486-apple-darwin")
>
> I changed the last line to:
>
> append_autogenargs("glib", "--build=x86_64-apple-darwin")
>
> And that fixed it for me. (If you have a Mac with a Core2 processor,
> the user land will be in 64-bit in Snow Leopard).
>
>
> regards,
>
> -kris.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: error building git head GTK on OS X ... IM symbols missing etc.
rm -rf the freetype-2.3.11 files from both gtk/source/pkgs and /gtk/source
re-run jhbuild build meta-gtk-osx-core
its working.
EMAILING FOR THE GREATER GOOD
Join me
From: shashan...@hotmail.com
To: k...@gtk.org
Subject: RE: error building git head GTK on OS X ... IM symbols missing etc.
Date: Tue, 27 Oct 2009 13:40:40 -0400
CC: gtk-devel-list@gnome.org
Yep. That fixed it.
For some reason I still had to download and install libiconv before I can run
phase 2 of the meta-gtk-osx-core, when building glib it complains using header
without any libraries present?
Also, the script crashes out on the freetype module. gzip complains about a bad
file. I downloaded the same version from the website, but now it won't compile
with "do not know how to make start".
I don't have any more time for this today... but I will keep cranking and
reporting here.
Thanks for all the help.
EMAILING FOR THE GREATER GOOD
Join me
> Subject: Re: error building git head GTK on OS X ... IM symbols missing etc.
> From: k...@gtk.org
> Date: Tue, 27 Oct 2009 17:31:03 +0100
> CC: jra...@ceridwen.us; gtk-devel-list@gnome.org
> To: shashan...@hotmail.com
>
> On Oct 27, 2009, at 5:25 PM, Shawn Bakhtiar wrote:
> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=
> > \"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -
> > DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include -
> > DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo -
> > MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC -
> > o .libs/gatomic.o
> > /var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s:
> > 103:Incorrect register `%rdx' used with `l' suffix
>
> Ah yes, I think I have stumbled on this as well. This is probably
> caused because the default jhbuildrc for the Mac forces a build for
> the 486:
>
> # When building on intel, force build to be 486, since glib won't
> # enable asm atomic operations otherwise.
> #
> try:
> _f = os.popen("uname -p")
> if _f.read().startswith("i386"):
> append_autogenargs("glib", "--build=i486-apple-darwin")
>
> I changed the last line to:
>
> append_autogenargs("glib", "--build=x86_64-apple-darwin")
>
> And that fixed it for me. (If you have a Mac with a Core2 processor,
> the user land will be in 64-bit in Snow Leopard).
>
>
> regards,
>
> -kris.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: error building git head GTK on OS X ... IM symbols missing etc.
Yep. That fixed it.
For some reason I still had to download and install libiconv before I can run
phase 2 of the meta-gtk-osx-core, when building glib it complains using header
without any libraries present?
Also, the script crashes out on the freetype module. gzip complains about a bad
file. I downloaded the same version from the website, but now it won't compile
with "do not know how to make start".
I don't have any more time for this today... but I will keep cranking and
reporting here.
Thanks for all the help.
EMAILING FOR THE GREATER GOOD
Join me
> Subject: Re: error building git head GTK on OS X ... IM symbols missing etc.
> From: k...@gtk.org
> Date: Tue, 27 Oct 2009 17:31:03 +0100
> CC: jra...@ceridwen.us; gtk-devel-list@gnome.org
> To: shashan...@hotmail.com
>
> On Oct 27, 2009, at 5:25 PM, Shawn Bakhtiar wrote:
> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=
> > \"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -
> > DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include -
> > DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo -
> > MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC -
> > o .libs/gatomic.o
> > /var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s:
> > 103:Incorrect register `%rdx' used with `l' suffix
>
> Ah yes, I think I have stumbled on this as well. This is probably
> caused because the default jhbuildrc for the Mac forces a build for
> the 486:
>
> # When building on intel, force build to be 486, since glib won't
> # enable asm atomic operations otherwise.
> #
> try:
> _f = os.popen("uname -p")
> if _f.read().startswith("i386"):
> append_autogenargs("glib", "--build=i486-apple-darwin")
>
> I changed the last line to:
>
> append_autogenargs("glib", "--build=x86_64-apple-darwin")
>
> And that fixed it for me. (If you have a Mac with a Core2 processor,
> the user land will be in 64-bit in Snow Leopard).
>
>
> regards,
>
> -kris.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: error building git head GTK on OS X ... IM symbols missing etc.
On Oct 27, 2009, at 2:06 AM, Kristian Rietveld wrote: On Tue, Oct 27, 2009 at 1:50 AM, Paul Davis > wrote: just tried a jhbuild of gtk on OS X (tiger). things went well until it got to the link stage in the input methods code. i got a large number of messages of this form, one for each (every?) IM module: does anybody have any clues what this might be? the missing symbol is always _res_9_init See bug 586510. It appears that on Tiger we need to explicitly link against libresolv, this is not needed on Leopard and higher. I also reported this when I ran into it (bug 590482), there seems to be a patch which has not been reviewed yet. Unless the GLib maintainers object I will review and commit a patch for this then :) For the record, 586150. Looks like Paul and Dan Winship have taken up the matter there. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: error building git head GTK on OS X ... IM symbols missing etc.
On Oct 27, 2009, at 5:25 PM, Shawn Bakhtiar wrote:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=
\"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -
DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include -
DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo -
MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC -
o .libs/gatomic.o
/var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s:
103:Incorrect register `%rdx' used with `l' suffix
Ah yes, I think I have stumbled on this as well. This is probably
caused because the default jhbuildrc for the Mac forces a build for
the 486:
# When building on intel, force build to be 486, since glib won't
# enable asm atomic operations otherwise.
#
try:
_f = os.popen("uname -p")
if _f.read().startswith("i386"):
append_autogenargs("glib", "--build=i486-apple-darwin")
I changed the last line to:
append_autogenargs("glib", "--build=x86_64-apple-darwin")
And that fixed it for me. (If you have a Mac with a Core2 processor,
the user land will be in 64-bit in Snow Leopard).
regards,
-kris.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: error building git head GTK on OS X ... IM symbols missing etc.
On clean copy of SL (upgraded) Xcode 3.2: downloaded and ran: prompt> sh gtk-osx-build-setup.shprompt> export PATH=$PATH:/Users/sbakhtiar/.local/binprompt> jhbuild bootstrapprompt> jhbuild build meta-gtk-osx-bootstrapprompt> jhbuild build meta-gtk-osx-core libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=\"GLib\" -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include -DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo -MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC -o .libs/gatomic.o /var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s:103:Incorrect register `%rdx' used with `l' suffixmake[4]: *** [gatomic.lo] Error 1make[3]: *** [all-recursive] Error 1make[2]: *** [all] Error 2make[1]: *** [all-recursive] Error 1make: *** [all] Error 2*** Error during phase build of glib: ## Error running make *** [2/11] Any ideas? EMAILING FOR THE GREATER GOOD Join me > Subject: Re: error building git head GTK on OS X ... IM symbols missing etc. > From: jra...@ceridwen.us > Date: Mon, 26 Oct 2009 22:30:54 -0700 > To: p...@linuxaudiosystems.com > CC: gtk-devel-list@gnome.org > > > On Oct 26, 2009, at 4:50 PM, Paul Davis wrote: > > > just tried a jhbuild of gtk on OS X (tiger). things went well until it > > got to the link stage in the input methods code. i got a large number > > of messages of this form, one for each (every?) IM module: > > > > > > Cannot load module > > /Users/paul/gtk/source/gtk+/modules/input/im-am-et.la: > > dlopen(/Users/paul/gtk/source/gtk+/modules/input/.libs/im-am-et.so, > > 10): Symbol not found: _res_9_init > > Referenced from: /Users/paul/gtk/inst/lib/libgio-2.0.0.dylib > > Expected in: flat namespace > > > > does anybody have any clues what this might be? the missing symbol is > > always _res_9_init > > > Found it, after a bit of searching. It's defined in /usr/include/ > resolv.h, included from gio/gionetworkingprivate.h > > It doesn't show up in my SL build from today. I can't see from > configure why it would pick it up for your build but not for mine. > Search for lresolv in configure and config.log; maybe you can see why > it's getting picked up on yours. > > Regards, > John Ralls > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: error building git head GTK on OS X ... IM symbols missing etc.
On Tue, Oct 27, 2009 at 1:50 AM, Paul Davis wrote: > just tried a jhbuild of gtk on OS X (tiger). things went well until it > got to the link stage in the input methods code. i got a large number > of messages of this form, one for each (every?) IM module: > > does anybody have any clues what this might be? the missing symbol is > always _res_9_init See bug 586510. It appears that on Tiger we need to explicitly link against libresolv, this is not needed on Leopard and higher. I also reported this when I ran into it (bug 590482), there seems to be a patch which has not been reviewed yet. Unless the GLib maintainers object I will review and commit a patch for this then :) -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDBus API Questions; was: GDBus/GVariant plans for next GLib release
2009/10/27 David Zeuthen : > Hey Mikkel, > > On Mon, 2009-10-26 at 23:52 +0100, Mikkel Kamstrup Erlandsen wrote: >> > I just looked over the newly introduced >> > g_dbus_connection_register_subtree() and related data structures, and >> > I think it will fit very nicely with what I am going to need. All in >> > all it looks really sweet, good work. >> > >> > One thing though is that as I read it objects in a subtree must be >> > known before method calls are accepted to them? For my use case in >> > Zeitgeist I was hoping that I could completely get rid of a "Manager" >> > type of interface, and just implicitly create objects in the tree >> > whenever calls where made to them. This does not look possible as it >> > stands? >> > >> > Maybe allowing '*' as a wildcard node name in the subtree enumeration >> > function? > > I'm actually a bit wary of introducing this kind of functionality - > mainly, I guess, because it screws with the notion that a D-Bus service > export a set of objects. In particular it makes it hard to > debug/introspect the service - for example, in extreme abuses of such a > feature (not the use-case you are suggesting though), you can't really > use e.g. d-feet to get an idea of what kind of objects are exported and > known by the service. > > The subtree functionality is really just for performance hacks - the > intended use is to avoid creating a huge amount of objects. For example, > one use case is export the subtree /org/foo/Project/processes/ > where is, say, a UNIX process id. With the subtree handler, no > object creation over is necessary. > > Anyway, your original use case does seem sound and reasonable - it > reduces overhead insofar that the client saves a round-trip to a > hypothetical Manager.CreateObject() method that would be needed if we > didn't have this. It does make it less intuitive insofar that remote > object creation is this magical thing with automatically appearing > nodes... but I guess that's fine. Not to mention the built in race condition you have if the exported objects can also be deleted via the manager. All client apps would have to precede all calls to an object by a Create() message (and it would still be racy). Anyway, enough about this :-) I think it is probably a fragment of my REST/web background where such patterns are more common. >> I had a stab at this myself. The wildcard idea seemed like a bad one, >> so I instead added another gboolean param to >> g_dbus_connection_register_subtree(), @is_dynamic. >> >> If is_dynamic is TRUE then objects need not be in the enumerated list >> of objects in order to be introspected and dispatched. Pretty simple. >> >> No matter the simplicity I still managed to screw up one of the unit >> tests. I will fix it and add some specific tests for the dynamic case >> if you give the "go" for this David. > > Sounds good to me. I'd prefer a GDBusSubtreeFlags flag enumeration with > a G_DBUS_SUBTREE_FLAGS_DISPATCH_TO_UNENUMERATED_NODES member instead of > @is_dynamic. Just for future proofing and all. Maybe it would also be > nice to pass a "gboolean enumerated" to @introspect and @dispatch that > indicates whether the node was enumerated (or not). That sounds like a better idea. I'll have another stab at this tonight if the kids allow me :-) -- Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
