tag:old.nabble.com,2006:forum-1332Nabble - Gtk+ - Dev - General2009-12-02T15:53:30Ztag:old.nabble.com,2006:post-26618784Re: differences between Glade and GtkBuilder2009-12-02T15:53:30Z2009-12-02T15:53:30ZTristan Van BerkomOn Wed, Dec 2, 2009 at 6:52 PM, Shawn Bakhtiar <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26618784&i=0" target="_top" rel="nofollow">shashaness@...</a>></span> wrote:<br><div class="gmail_quote"><div>[...]<br><br>Note that this list is about the development of GTK+ itself, please address gtk-app-devel-list<br>
or gtk-list in the future for help using the GTK+ apis.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>I'm almost certain, that with glade you would load the xml (containing many top levels), then, call get the object you wanted out (which at that time it would construct and realize the widget making it visible)<div>
<br></div><div>It seems with GtkBuilder loading the XML and realizing it are done in the same step, which makes it so that each individual top level has to be in its own file? </div><div>Does it not make more sense to have a function that load the XML without realizing anything, then, as objects are requested, doing the actual construction and realization?</div>
</div></blockquote><div><br><br>FYI libglade and GtkBuilder work the same way in this respect;<br><br>Parsing the file builds the widget hierarchy.<br><br>If your widgets are getting realized in the process of parsing<br>
the file, it means that one of your toplevel widgets is set to be<br>visible at startup time (as the builder/libglade sets the toplevel to<br>be visible, this triggers the realize) - you can deffer the realization<br>of your widgets by building the toplevels in your project with the<br>
"visible" property set to False (and then showing/realizing them at a later<br>time)<br><br>Cheers,<br> -Tristan<br><br></div></div>
<br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26618784&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26616406Re: Proposal: Enable threads by default2009-12-02T13:03:15Z2009-12-02T13:03:15ZColin WaltersOn Wed, Dec 2, 2009 at 8:38 PM, Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616406&i=0" target="_top" rel="nofollow">alexl@...</a>> wrote:
<br>>
<br>> This particular instance is fixed, but there can be a lot more out
<br>> there. Why force every app to add this check when we could do it
<br>> ourselves.
<br><br>I'm not objecting to defaulting to working around this bug; it's
<br>certainly possible other applications do it. However the docs are
<br>pretty clear on how to call g_thread_init, and I was doing it wrong =)
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616406&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26616251RE: differences between Glade and GtkBuilder2009-12-02T12:52:54Z2009-12-02T12:52:54Zsbaka<html>
<head>
</head>
<body class='hmmessage'>
<br><br>Yes. They are all set to visible.<br><br><div>I'll change them in the GUI and see if that makes a difference.</div><div><br></div><div>I still think something in the process has changes, at least from the "user" perspective. </div><div><br></div><div>I'm almost certain, that with glade you would load the xml (containing many top levels), then, call get the object you wanted out (which at that time it would construct and realize the widget making it visible)</div><div><br></div><div>It seems with GtkBuilder loading the XML and realizing it are done in the same step, which makes it so that each individual top level has to be in its own file? </div><div>Does it not make more sense to have a function that load the XML without realizing anything, then, as objects are requested, doing the actual construction and realization?</div><div><br></div><div><br><br><br><table style="border-top:1px solid black;font-weight:bold;font-family:'Segoe UI',Tahoma,san-serif"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size:9pt;color:#0184CB;text-decoration:none" target="_top" rel="nofollow"><img style="border-style:none" src="http://gfx1.hotmail.com/mail/w4/pr01/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding:0px 24px;font-size:8pt;color:#3FB555;text-decoration:underline">Join me</span></a></td></tr></tbody></table><br><div class='shrinkable-quote'><br>> Subject: Re: <br>> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616251&i=0" target="_top" rel="nofollow">scott@...</a><br>> Date: Wed, 2 Dec 2009 13:37:42 -0500<br>> To: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616251&i=1" target="_top" rel="nofollow">shashaness@...</a><br>> <br>> <br>> On Dec 1, 2009, at 1:01 PM, Shawn Bakhtiar wrote:<br>> <br>> > Previously, I was able to open a Glade XML file with multiple top level windows, and only load the specific window I wanted from within that file. I have tried to re-write this routine, however, every time a call is made to gtk_builder_add_from_file it not only loads the file but it also loads and displays ALL the windows in that file. <br>> > <br>> > Should this not work like glade did before, where you would load the file, then call the objects you wanted to be displayed?<br>> <br>> Do you have the "visible" property set for all of the windows in the buildable xml?<br>> <br>> glade would also always construct all of the windows in the xml, but i think there was a default to *not* visible. (It would also construct them only when you parse the xml, so if you let them be destroyed, you had to parse the file again. I haven't used buildable enough to tell you if it behaves that way.)<br>> <br>> <br>> --<br>> I've been using emacs for 20+ years and have barely touched lisp. I wouldn't know lambda calculus if it took all its clothes off and waved a placard that reads "I am lambda calculus" in blinking 48-point Comic Sans.<br>> -- Dave Hodgkinson, on london.pm<br>> </div></div> </body>
</html><br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616251&i=2" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26616005Re: Proposal: Enable threads by default2009-12-02T12:38:12Z2009-12-02T12:38:12ZAlexander LarssonOn Wed, 2009-12-02 at 18:01 +0000, Colin Walters wrote:
<div class='shrinkable-quote'><br>> On Wed, Dec 2, 2009 at 11:03 AM, Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616005&i=0" target="_top" rel="nofollow">alexl@...</a>>
<br>> wrote:
<br>> >
<br>> > Running with this patch i ran into an issue while building
<br>> gnome-shell:
<br>> >
<br>> > GEN Gdm-1.0.gir
<br>> >
<br>> > GThread-ERROR **: GThread system may only be initialized once.
<br>> > aborting...
<br>> > Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0',
<br>> >
<br>> '--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/typ
<br>> es.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']'
<br>> returned non-zero exit status -5
<br>> >
<br>> > Not sure exactly what crashed, but obviously something ran:
<br>> > g_type_init() and then g_thread_init(). Maybe we need to make this a
<br>> > non-fatal warning?
<br>>
<br>> Nah, just a bug in the dumper. Fixed:
</div><br>This particular instance is fixed, but there can be a lot more out
<br>there. Why force every app to add this check when we could do it
<br>ourselves.
<br><br>--
<br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<br> Alexander Larsson Red Hat, Inc
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616005&i=1" target="_top" rel="nofollow">alexl@...</a> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616005&i=2" target="_top" rel="nofollow">alexander.larsson@...</a>
<br>He's a genetically engineered neurotic boxer with a robot buddy named Sparky.
<br>She's a warm-hearted out-of-work advertising executive with someone else's
<br>memories. They fight crime!
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26616005&i=3" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26613476Re: Proposal: Enable threads by default2009-12-02T10:01:14Z2009-12-02T10:01:14ZColin WaltersOn Wed, Dec 2, 2009 at 11:03 AM, Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26613476&i=0" target="_top" rel="nofollow">alexl@...</a>> wrote:
<div class='shrinkable-quote'><br>>
<br>> Running with this patch i ran into an issue while building gnome-shell:
<br>>
<br>> GEN Gdm-1.0.gir
<br>>
<br>> GThread-ERROR **: GThread system may only be initialized once.
<br>> aborting...
<br>> Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0',
<br>> '--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/types.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']' returned non-zero exit status -5
<br>>
<br>> Not sure exactly what crashed, but obviously something ran:
<br>> g_type_init() and then g_thread_init(). Maybe we need to make this a
<br>> non-fatal warning?
</div><br>Nah, just a bug in the dumper. Fixed:
<br><br>commit ffd9b39620c9665a8685363202b4f02fa895288c
<br>Author: Colin Walters <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26613476&i=1" target="_top" rel="nofollow">walters@...</a>>
<br>Date: Wed Dec 2 12:56:52 2009 -0500
<br><br> [dumper] Fix threads initialization
<br><br> Correctly guard with g_thread_supported, call g_thread_init before
<br> g_type_init.
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26613476&i=2" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26611346Re: Embedding the VTE Virtual Terminal2009-12-02T08:01:09Z2009-12-02T08:01:09ZEmmanuel Rodriguez<br><br><div class="gmail_quote">On Thu, Nov 26, 2009 at 3:07 PM, Stevenix <span dir="ltr"><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26611346&i=0" target="_top" rel="nofollow">steve.gnulinux@...</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Hi,<br>
<br>
I'm writing a Gui+Terminal application, where VTE is embedded on window, and<br>
the GUI Menu Items.<br>
<br>
And i'm trying to call this action...<br>
<br>
... calls to this action from the menu... (just fork a 'ls' command)<br>
<br>
But i'm unable to get the 'ls' listing ...<br>
<br>
void VimWindow (GtkWidget *widget, gpointer gdata)<br>
{<br>
GtkWidget *vte;<br>
vte = vte_terminal_new();<br>
[b]vte_terminal_fork_command(VTE_TERMINAL(vte), "ls", NULL,<br>
NULL, ".", FALSE, FALSE, FALSE);[/b]<br>
}<br>
<br></blockquote><div> <br>Try something like this (untested):<br>char [][] argv = {<br> "ls", NULL<br>}; <br></div></div>vte_terminal_fork_command(VTE_TERMINAL(vte), "ls", argv, NULL, ".", FALSE, FALSE, FALSE);<br>
<br>If I recall well the first "ls" is actually the name you want the users to see when they run ps while argv[0] has the name of the program to execute.<br clear="all"><br>-- <br>Emmanuel Rodriguez<br>
<br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26611346&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26608631Re: Proposal: Enable threads by default2009-12-02T05:11:18Z2009-12-02T05:11:18ZAlexander LarssonOn Wed, 2009-12-02 at 13:07 +0000, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608631&i=0" target="_top" rel="nofollow">jcupitt@...</a> wrote:
<div class='shrinkable-quote'><br>> 2009/12/2 Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608631&i=1" target="_top" rel="nofollow">alexl@...</a>>:
<br>> > On Wed, 2009-12-02 at 11:48 +0000, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608631&i=2" target="_top" rel="nofollow">jcupitt@...</a> wrote:
<br>> >> 2009/12/2 Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608631&i=3" target="_top" rel="nofollow">alexl@...</a>>:
<br>> >> > I'm certainly for this. Does anyone know of any system in use
<br>> where
<br>> >> > gthreads are not availible?
<br>> >>
<br>> >> One problem I've had in the past is writing mysql plugins.
<br>> >>
<br>> >> I help maintain an image processing library, and one use of the
<br>> >> library was a mysql plugin that added query-by-image-content. To
<br>> get
<br>> >> the plugin working we had to make sure we could run threadless.
<br>> >
<br>> > By threadless, do you mean not linking to the thread library, or do
<br>> you
<br>> > mean "don't spawn threads". Because initializing threads doesn't
<br>> mean
<br>> > we'll create threads, just that we make global us data threadsafe.
<br>>
<br>> Sorry, I wasn't clear. You mustn't even link to pthreads when building
<br>> mysql plugins.
<br>>
<br>> Or that used to be the case anyway. I tried a quick google but
<br>> couldn't find anything saying whether or not this was still a problem,
<br>> so this might all be a red herring anyway.
</div><br>I guess this is the same problem that we had recently, where its not
<br>allowed to dynamically link in libpthreads in a binary that doesn't link
<br>to libpthreads.
<br><br>--
<br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<br> Alexander Larsson Red Hat, Inc
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608631&i=4" target="_top" rel="nofollow">alexl@...</a> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608631&i=5" target="_top" rel="nofollow">alexander.larsson@...</a>
<br>He's an underprivileged ninja vampire hunter searching for his wife's true
<br>killer. She's a transdimensional nymphomaniac mermaid with the power to bend
<br>men's minds. They fight crime!
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608631&i=6" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26608581Re: Proposal: Enable threads by default2009-12-02T05:07:11Z2009-12-02T05:07:11Zjcupitt2009/12/2 Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608581&i=0" target="_top" rel="nofollow">alexl@...</a>>:
<div class='shrinkable-quote'><br>> On Wed, 2009-12-02 at 11:48 +0000, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608581&i=1" target="_top" rel="nofollow">jcupitt@...</a> wrote:
<br>>> 2009/12/2 Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608581&i=2" target="_top" rel="nofollow">alexl@...</a>>:
<br>>> > I'm certainly for this. Does anyone know of any system in use where
<br>>> > gthreads are not availible?
<br>>>
<br>>> One problem I've had in the past is writing mysql plugins.
<br>>>
<br>>> I help maintain an image processing library, and one use of the
<br>>> library was a mysql plugin that added query-by-image-content. To get
<br>>> the plugin working we had to make sure we could run threadless.
<br>>
<br>> By threadless, do you mean not linking to the thread library, or do you
<br>> mean "don't spawn threads". Because initializing threads doesn't mean
<br>> we'll create threads, just that we make global us data threadsafe.
</div><br>Sorry, I wasn't clear. You mustn't even link to pthreads when building
<br>mysql plugins.
<br><br>Or that used to be the case anyway. I tried a quick google but
<br>couldn't find anything saying whether or not this was still a problem,
<br>so this might all be a red herring anyway.
<br><br>John
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608581&i=3" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26608463Re: Proposal: Enable threads by default2009-12-02T04:58:29Z2009-12-02T04:58:29ZAlexander LarssonOn Wed, 2009-12-02 at 11:48 +0000, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608463&i=0" target="_top" rel="nofollow">jcupitt@...</a> wrote:
<br>> 2009/12/2 Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608463&i=1" target="_top" rel="nofollow">alexl@...</a>>:
<br>> > I'm certainly for this. Does anyone know of any system in use where
<br>> > gthreads are not availible?
<br>>
<br>> One problem I've had in the past is writing mysql plugins.
<br>>
<br>> I help maintain an image processing library, and one use of the
<br>> library was a mysql plugin that added query-by-image-content. To get
<br>> the plugin working we had to make sure we could run threadless.
<br><br>By threadless, do you mean not linking to the thread library, or do you
<br>mean "don't spawn threads". Because initializing threads doesn't mean
<br>we'll create threads, just that we make global us data threadsafe.
<br><br><br>--
<br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<br> Alexander Larsson Red Hat, Inc
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608463&i=2" target="_top" rel="nofollow">alexl@...</a> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608463&i=3" target="_top" rel="nofollow">alexander.larsson@...</a>
<br>He's a time-tossed coffee-fuelled gangster with a robot buddy named Sparky.
<br>She's a supernatural tomboy former first lady with the power to bend men's
<br>minds. They fight crime!
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26608463&i=4" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26607637Re: Proposal: Enable threads by default2009-12-02T03:48:07Z2009-12-02T03:48:07Zjcupitt2009/12/2 Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26607637&i=0" target="_top" rel="nofollow">alexl@...</a>>:
<br>> I'm certainly for this. Does anyone know of any system in use where
<br>> gthreads are not availible?
<br><br>One problem I've had in the past is writing mysql plugins.
<br><br>I help maintain an image processing library, and one use of the
<br>library was a mysql plugin that added query-by-image-content. To get
<br>the plugin working we had to make sure we could run threadless.
<br><br>I've not actually checked for years, perhaps mysql allows plugins to
<br>link to more stuff now.
<br><br>John
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26607637&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26607131Re: Proposal: Enable threads by default2009-12-02T03:03:18Z2009-12-02T03:03:18ZAlexander LarssonOn Tue, 2009-12-01 at 14:29 +0100, Alexander Larsson wrote:
<div class='shrinkable-quote'><br>> On Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote:
<br>> > This was previously discussed here, but was sort of hidden in a
<br>> > technical discussion so it got no replies. I'm starting over in
<br>> order
<br>> > to
<br>> > reach a wider target for the discussion.
<br>> >
<br>> > I'll start with the proposal and then explain the reasons for it:
<br>> >
<br>> > Starting with next glib release:
<br>> > * libgobject links to libgthread
<br>> > * g_type_init() starts with:
<br>> >
<br>> > #ifdef G_THREADS_ENABLED
<br>> > if (g_thread_supported())
<br>> > g_thread_init (NULL);
<br>> > #endif
<br>> >
<br>> > This means that everything above gobject can rely on thread
<br>> primitives
<br>> > being availible, and that global stuff in glib (mainloop, gslice,
<br>> > globals, etc) are threadsafe.
<br>>
<br>> I'm attaching a patch that implements this.
</div><br>Running with this patch i ran into an issue while building gnome-shell:
<br><br> GEN Gdm-1.0.gir
<br><br>GThread-ERROR **: GThread system may only be initialized once.
<br>aborting...
<br>Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0',
<br>'--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/types.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']' returned non-zero exit status -5
<br><br>Not sure exactly what crashed, but obviously something ran:
<br>g_type_init() and then g_thread_init(). Maybe we need to make this a
<br>non-fatal warning?
<br><br>--
<br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<br> Alexander Larsson Red Hat, Inc
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26607131&i=0" target="_top" rel="nofollow">alexl@...</a> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26607131&i=1" target="_top" rel="nofollow">alexander.larsson@...</a>
<br>He's a notorious bohemian librarian from a doomed world. She's a beautiful
<br>renegade lawyer with the soul of a mighty warrior. They fight crime!
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26607131&i=2" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26610308Re: [gnome-db] GObject Introspection Support and Gnome 3.02009-12-02T00:45:13Z2009-12-02T00:45:13ZVivien Malerba2009/12/2 Daniel Espinosa <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26610308&i=0" target="_top" rel="nofollow">esodan@...</a>>:
<br>> How is desirable to have support of GObjectInstrospection in a Gnome
<br>> component for the upcomming Gnome 3.0 release?
<br>>
<br>> What if I need to break ABI to get "easy support" of
<br>> GObjectIntrospection for a library?
<br><br>I would be very surprised if there wasn't any way to add introspection
<br>support without breaking the ABI, and I really don't want to break the
<br>ABI now.
<br><br>So please try to find a way for the few objects which are a problem
<br>and make special (not automatically generated) rules for them (if I
<br>remember correctly there are ony 2 or 3).
<br><br>Thanks a lot for the work you put in bringing introspection support to Libgda.
<br><br>Vivien
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26610308&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26604955Re: Proposal: Enable threads by default2009-12-02T00:04:44Z2009-12-02T00:04:44ZAlexander LarssonOn Tue, 2009-12-01 at 16:16 -0500, Dan Winship wrote:
<div class='shrinkable-quote'><br>> On 12/01/2009 03:36 PM, Alexander Larsson wrote:
<br>> > I don't think that is quite right. Its only safe to set this define
<br>> if
<br>> > you can guarantee there is no calls to your code before g_type_init
<br>> (or
<br>> > g_thread_init directly) is called.
<br>>
<br>> Hrmph. Could potentially add a define which would cause a G_LIKELY()
<br>> to be added in to G_THREAD_CF() when linking to gobject... but we'd want
<br>> to test that it actually had a measurable effect first.
</div><br>Actually, why are the thread primitives using g_thread_supported() at
<br>all? They're all virtualized anyway, can't we just change the default
<br>operation to be some non-NULL version that does what the
<br>!g_thread_supported case does?
<br>
<div class='shrinkable-quote'><br>> > I wouldn't mind this, but on the other hand its not really a large
<br>> > maintainance burden, is it?
<br>>
<br>> Continuing to maintain the existing code which we already know works
<br>> is not a large burden, but having to write non-threaded versions of *new*
<br>> APIs might suck (having to write *two* non-threaded versions of
<br>> GResolver did) and then after we write them they're never going to get
<br>> used and so they'll probably be all buggy anyway. And besides, who are
<br>> we providing the no-thread-support version for anyway? There used to
<br>> be some somewhat-relevant unixes without pthreads, but I don't think
<br>> there are any non-toy OSes that have that problem any more.
</div><br>I'm certainly for this. Does anyone know of any system in use where
<br>gthreads are not availible?
<br><br>Another aspect is that you might want to disable threads in e.g. an
<br>embedded system where they are not used. I'm not sure people actually do
<br>this though, since embedded systems large enough to run e.g. gtk or
<br>other gobject things are generally big enough that you can support
<br>threads and you're likely to actually want to use things like
<br>threadpools and async i/o.
<br><br>--
<br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<br> Alexander Larsson Red Hat, Inc
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26604955&i=0" target="_top" rel="nofollow">alexl@...</a> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26604955&i=1" target="_top" rel="nofollow">alexander.larsson@...</a>
<br>He's a lonely white trash assassin who dotes on his loving old ma. She's a
<br>vivacious foul-mouthed magician's assistant from the wrong side of the tracks.
<br>They fight crime!
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26604955&i=2" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26610305GObject Introspection Support and Gnome 3.02009-12-01T19:43:11Z2009-12-01T19:43:11ZDaniel EspinosaHow is desirable to have support of GObjectInstrospection in a Gnome
<br>component for the upcomming Gnome 3.0 release?
<br><br>What if I need to break ABI to get "easy support" of
<br>GObjectIntrospection for a library?
<br><br>--
<br>Trabajar, la mejor arma para tu superación
<br>"de grano en grano, se hace la arena" (R) (en trámite, pero para los
<br>cuates: LIBRE)
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26610305&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26599195Re: Proposal: Enable threads by default2009-12-01T13:16:32Z2009-12-01T13:16:32ZDan Winship-2On 12/01/2009 03:36 PM, Alexander Larsson wrote:
<br>> I don't think that is quite right. Its only safe to set this define if
<br>> you can guarantee there is no calls to your code before g_type_init (or
<br>> g_thread_init directly) is called.
<br><br>Hrmph. Could potentially add a define which would cause a G_LIKELY() to
<br>be added in to G_THREAD_CF() when linking to gobject... but we'd want to
<br>test that it actually had a measurable effect first.
<br><br>>> threads? Allowing threadless glib means we still need to have the
<br>>> non-threaded versions of GIOScheduler, GResolver, etc, lying around,
<br>>> but
<br>>> they'll never get used in normal builds.
<br>>
<br>> I wouldn't mind this, but on the other hand its not really a large
<br>> maintainance burden, is it?
<br><br>Continuing to maintain the existing code which we already know works is
<br>not a large burden, but having to write non-threaded versions of *new*
<br>APIs might suck (having to write *two* non-threaded versions of
<br>GResolver did) and then after we write them they're never going to get
<br>used and so they'll probably be all buggy anyway. And besides, who are
<br>we providing the no-thread-support version for anyway? There used to be
<br>some somewhat-relevant unixes without pthreads, but I don't think there
<br>are any non-toy OSes that have that problem any more.
<br><br>-- Dan
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26599195&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26598646Re: Proposal: Enable threads by default2009-12-01T12:36:48Z2009-12-01T12:36:48ZAlexander LarssonOn Tue, 2009-12-01 at 09:26 -0500, Dan Winship wrote:
<br>> On 12/01/2009 08:29 AM, Alexander Larsson wrote:
<br>> > In addition to enabling threads (if complied in) in g_type_init() it
<br>> > adds a G_THREADS_MANDATORY define that if set causes all the
<br>> > g_thread_supported() calls to be removed in the g_thread_* macros.
<br>>
<br>> Should probably add that to Cflags in gobject-2.0.pc.in too?
<br><br>I don't think that is quite right. Its only safe to set this define if
<br>you can guarantee there is no calls to your code before g_type_init (or
<br>g_thread_init directly) is called. This is true for gobject (must call
<br>g_type_init first) and gio (100% gtype library). However, one could
<br>imagine some library of e.g. utility functions that have stuff you can
<br>use before g_type_init() is called.
<br><br>> Also, do we want to get rid of the possibility of compiling glib
<br>> without
<br>> threads? Allowing threadless glib means we still need to have the
<br>> non-threaded versions of GIOScheduler, GResolver, etc, lying around,
<br>> but
<br>> they'll never get used in normal builds.
<br><br>I wouldn't mind this, but on the other hand its not really a large
<br>maintainance burden, is it?
<br><br>--
<br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<br> Alexander Larsson Red Hat, Inc
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26598646&i=0" target="_top" rel="nofollow">alexl@...</a> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26598646&i=1" target="_top" rel="nofollow">alexander.larsson@...</a>
<br>He's an obese devious vagrant fleeing from a secret government programme.
<br>She's a chain-smoking mutant opera singer with her own daytime radio talk
<br>show. They fight crime!
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26598646&i=2" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26596301(no subject)2009-12-01T10:01:15Z2009-12-01T10:01:15Zsbaka<html>
<head>
</head>
<body class='hmmessage'>
<div><br></div><div><br></div><div>Good morning all,</div><div><br></div><div>I have not been able to find anything in doc's that explains this:</div><div><br></div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><br></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span><span style="color: #b930a1">if</span>(self->priv->xml_filename != <span style="color: #b930a1">NULL</span> && self->priv->xml_main != <span style="color: #b930a1">NULL</span>){</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><br></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #008311"><span style="color: #000000"><span class="Apple-tab-span" style="white-space:pre"> </span></span>/* Load the xml object from the xml interface file Using the giving base name of window_name*/</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #008311"><span style="color: #000000"><span class="Apple-tab-span" style="white-space:pre"> </span></span>/* UPDATE 11272009 1102 NO BUG - migration to Gtkbuilder from libglade */</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #008311"><span style="color: #000000"><span class="Apple-tab-span" style="white-space:pre"> </span></span>//xml = glade_xml_new(self->priv->xml_filename, window_name, NULL);</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><span class="Apple-tab-span" style="white-space:pre"> </span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span>self->priv->xml = gtk_builder_new ();</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><span class="Apple-tab-span" style="white-space:pre"> </span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span><span style="color: #b930a1">if</span> (self->priv->xml != <span style="color: #b930a1">NULL</span>){</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><span class="Apple-tab-span" style="white-space:pre"> </span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span>gtk_builder_add_from_file (self->priv->xml, self->priv->xml_filename, <span style="color: #b930a1">NULL</span>);</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><span class="Apple-tab-span" style="white-space:pre"> </span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #008311"><span style="color: #000000"><span class="Apple-tab-span" style="white-space:pre"> </span></span>/* Set the main window to be parent to all */</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #008311"><span style="color: #000000"><span class="Apple-tab-span" style="white-space:pre"> </span> <span class="Apple-tab-span" style="white-space:pre"> </span> </span>//widget = glade_xml_get_widget (<span class="Apple-style-span" style="color: rgb(0, 0, 0); ">self->priv->xml</span>, <span class="Apple-style-span" style="color: rgb(0, 0, 0); ">self->priv->xml_main</span>);</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span>self->main_window = gtk_builder_get_object (self->priv->xml, self->priv->xml_main);</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><br></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span><span style="color: #b930a1">if</span>(self->main_window)</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span>gtk_widget_show (self->main_window); </p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><span class="Apple-tab-span" style="white-space:pre"> </span></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span>}</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo"><span class="Apple-tab-span" style="white-space:pre"> </span>}</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><font class="Apple-style-span" face="Verdana"><span class="Apple-style-span" style="font-size: 10pt; "><br></span></font></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><font class="Apple-style-span" face="Verdana"><span class="Apple-style-span" style="font-size: 10pt; ">Previously, I was able to open a Glade XML file with multiple top level windows, and only load the specific window I wanted from within that file. I have tried to re-write this routine, however, every time a call is made to gtk_builder_add_from_file it not only loads the file but it also loads and displays ALL the windows in that file. </span></font></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><font class="Apple-style-span" face="Verdana"><span class="Apple-style-span" style="font-size: 10pt; "><br></span></font></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><font class="Apple-style-span" face="Verdana"><span class="Apple-style-span" style="font-size: 10pt; ">Should this not work like glade did before, where you would load the file, then call the objects you wanted to be displayed?</span></font></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><font class="Apple-style-span" face="Verdana"><span class="Apple-style-span" style="font-size: 10pt; "><br></span></font></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; min-height: 13.0px"><font class="Apple-style-span" face="Verdana"><span class="Apple-style-span" style="font-size: 10pt; ">Either I have written this wrong, or there has been an implementation change, which I don't think is for the better. You should be able to load the objects (WITHOUT DISPLAYING) and then only show the ones you want. What am I missing here?</span></font></p></div><span class="Apple-style-span" style="font-size: 10pt; "><div><br></div>I used the converter, and I have fixed all the mess-ups using glade-3. But I can not find anywhere or any how to load the file without it displaying all top level windows.<br></span><br>Thanks in advance for your help<div>Shawn</div><div><br><br><br><table style="border-top:1px solid black;font-weight:bold;font-family:'Segoe UI',Tahoma,san-serif"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size:9pt;color:#0184CB;text-decoration:none" target="_top" rel="nofollow"><img style="border-style:none" src="http://gfx1.hotmail.com/mail/w4/pr01/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding:0px 24px;font-size:8pt;color:#3FB555;text-decoration:underline">Join me</span></a></td></tr></tbody></table></div> </body>
</html><br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26596301&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26593570GLib 2.22.3 released2009-12-01T07:19:19Z2009-12-01T07:19:19ZMatthias ClasenGLib 2.22.3 is now available for download at:
<br><br> ftp://ftp.gtk.org/pub/glib/2.22/
<br> <a href="http://download.gnome.org/sources/glib/2.22/" target="_top" rel="nofollow">http://download.gnome.org/sources/glib/2.22/</a><br><br>md5 sums:
<br>25b043b208883194c57219e41a230a29 glib-2.22.3.tar.bz2
<br>e699a93d62c01e0ee07caef3e11eddd8 glib-2.22.3.tar.gz
<br><br>sha1 sums:
<br>185d5b80adef96019daf7402cc6762cc4d37470d glib-2.22.3.tar.bz2
<br>3c4c1e197b955993261cf4c0e83da2a2e507d8ec glib-2.22.3.tar.gz
<br><br>This is another bug fix release in the stable 2.22 series.
<br><br>GLib is the low-level core library that forms the basis for projects
<br>such as GTK+ and GNOME. It provides data structure handling for C,
<br>portability wrappers, and interfaces for such runtime functionality as
<br>an event loop, threads, dynamic loading, and an object system.
<br><br>More information about GLib is available at:
<br><br> <a href="http://www.gtk.org/" target="_top" rel="nofollow">http://www.gtk.org/</a><br><br>An installation guide for the GTK+ libraries, including GLib, can
<br>be found at:
<br><br> <a href="http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html" target="_top" rel="nofollow">http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html</a><br><br><br>Overview of Changes from GLib 2.22.2 to GLib 2.22.3
<br>===================================================
<br><br>* Bugs fixed:
<br> 350200 GTypeModule derived class unref does not unload plugin
<br> 598899 GWin32DirectoryMonitor is broken
<br> 563627 g_get_prgname() threadsafety
<br> 572252 Bug in g_file_test() function.
<br> 577711 cross compile check for g++ broken
<br> 598712 can't detect text file with backspace
<br> 541236 not detecting exact content type
<br> 593856 file and directory monitors don't work with --disable-debug
<br> 593809 Nautilus does not restore the position of the icons...
<br><br>* Updated translations:
<br> Catalan Valencian
<br> Estonian
<br><br><br>Thanks to all contributors:
<br>Tor Lillqvist
<br>Tomas Bzatek
<br>Alexander Larsson
<br>Cody Russell
<br>Chris Wilson
<br>Tim Janik
<br>Sven Herzberg
<br>Benjamin Otte
<br>Carlo Bramini
<br>Hib Eris
<br>Mures Andone
<br>Ryan Lortie
<br><br><br>December 1, 2009
<br>Matthias Clasen
<br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26593570&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26592654Re: Proposal: Enable threads by default2009-12-01T06:26:37Z2009-12-01T06:26:37ZDan Winship-2On 12/01/2009 08:29 AM, Alexander Larsson wrote:
<br>> In addition to enabling threads (if complied in) in g_type_init() it
<br>> adds a G_THREADS_MANDATORY define that if set causes all the
<br>> g_thread_supported() calls to be removed in the g_thread_* macros.
<br><br>Should probably add that to Cflags in gobject-2.0.pc.in too?
<br><br>Also, do we want to get rid of the possibility of compiling glib without
<br>threads? Allowing threadless glib means we still need to have the
<br>non-threaded versions of GIOScheduler, GResolver, etc, lying around, but
<br>they'll never get used in normal builds.
<br><br>-- Dan
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26592654&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26592511GTK+ 2.18.4 released2009-12-01T06:15:32Z2009-12-01T06:15:32ZMatthias ClasenGTK+ 2.18.4 is now available for download at:
<br><br> ftp://ftp.gtk.org/pub/gtk/2.18/
<br> <a href="http://download.gnome.org/sources/gtk+/2.18/" target="_top" rel="nofollow">http://download.gnome.org/sources/gtk+/2.18/</a><br><br>md5 sums:
<br>311ec49d7cae0c0b431ab6235579f5a4 gtk+-2.18.4.tar.bz2
<br>6e532fcc073dc64e9664b0bc93aedf14 gtk+-2.18.4.tar.gz
<br><br>sha1 sums:
<br>7a7d6c38c30d2b1234d512ee5184ef4c3956e782 gtk+-2.18.4.tar.bz2
<br>eedc22a7d2e2d4e2d67af77d9c82b89d757b19ed gtk+-2.18.4.tar.gz
<br><br>This is a bug fix release in the stable 2.18 series.
<br><br>============
<br><br>GTK+ is a multi-platform toolkit for creating graphical user
<br>interfaces. Offering a complete set of widgets, GTK+ is suitable for
<br>projects ranging from small one-off tools to complete application
<br>suites.
<br><br>GTK+ has been designed from the ground up to support a range of
<br>languages, not only C/C++. Using GTK+ from languages such as Perl and
<br>Python (especially in combination with the Glade GUI builder) provides
<br>an effective method of rapid application development.
<br><br>GTK+ is free software and part of the GNU Project. However, the
<br>licensing terms for GTK+, the GNU LGPL, allow it to be used by all
<br>developers, including those developing proprietary software, without
<br>any license fees or royalties.
<br><br><br>Where to get more information about GTK+
<br>========================================
<br><br>Information about GTK+ including links to documentation can be
<br>found at:
<br><br><a href="http://www.gtk.org/" target="_top" rel="nofollow">http://www.gtk.org/</a><br><br>An installation guide for GTK+ 2.x is found at:
<br><br> <a href="http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html" target="_top" rel="nofollow">http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html</a><br><br>Common questions:
<br><br><a href="http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html" target="_top" rel="nofollow">http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html</a><br><a href="http://www.gtk.org/faq/" target="_top" rel="nofollow">http://www.gtk.org/faq/</a><br><br><br>Contributing
<br>============
<br><br>GTK+ is a large project and relies on voluntary contributions.
<br>We are actively searching for new contributors in various areas
<br>and invite everyone to help project development.
<br>If you are willing to participate, please subscribe to the project
<br>mailing lists to offer your help and read over our list of vacant
<br>project tasks:
<br> <a href="http://live.gnome.org/GtkTasks" target="_top" rel="nofollow">http://live.gnome.org/GtkTasks</a><br><br><br>Overview of Changes from GTK+ 2.18.3 to 2.18.4
<br>==============================================
<br><br>* Client-side windows:
<br> - Avoid some unnecessary exposes
<br> - Avoid unnecessary redraws related to clearing windows
<br><br>* Bugs fixed:
<br> 563010 Fix clearing the selection in GtkFileChooserButton
<br> 581150 GtkIconView tries to paint items with invalid sizes
<br> 601869 GtkUIManager assumes too much about popup menus
<br> 581145 Wrong positioning for fullscreen gedit toolbar animation
<br> 599118 Translators comment for "Finishing" labels
<br> 599321 gtk_selection_data_get_uris is broken on Windows
<br> 381371 Print margins not correct in WIN32 - not allowing...
<br> 599446 atk_object_set_name () assertion in gtk_tool_button_set_label
<br> 602725 fix setting icon-size on GICON images
<br> 588740 JPEG images open with blur effect?
<br> 602724 gailimage doesn't handle GTK_IMAGE_{GICON,ICON_NAME}...
<br> 561130 get_monitor_geometry segfaults if called with non-existant...
<br> 585383 Segfault in gdk_pixbuf__ico_image_save
<br> 123569 Catch contents being reparented out of socket
<br> 601611 gtk_selection_data_get_targets() reads X Atom data as GdkAtoms
<br> 601959 must release compose key before continuing compose sequence
<br> 603201 gtk_about_dialog_set_url_hook has no effect anymore
<br> 591438 dfb_events_dispatch is not thread safe
<br> 603128 Adding new UI that was recently removed may cause wrong order
<br><br><br>* Updated translations:
<br> Low German
<br> Romanian
<br> Russian
<br> Slovenian
<br><br>Thanks to all contributors:
<br>Tor Lillqvist
<br>Milan Crha
<br>Federico Mena Quintero
<br>Luca Ferretti
<br>Matt Barnes
<br>Peter Hutterer
<br>Ray Strode
<br>Adrian Johnson
<br>Alexander Larsson
<br>Christian Dywan
<br>Hans Breuer
<br>Michael Emmel
<br>Christian Persch
<br>Owen Taylor
<br>Felix Riemann
<br>David Jander
<br>Javier Jardón
<br><br><br>December 1, 2009
<br>Matthias Clasen
<br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26592511&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26591778Re: Proposal: Enable threads by default2009-12-01T05:29:33Z2009-12-01T05:29:33ZAlexander LarssonOn Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> This was previously discussed here, but was sort of hidden in a
<br>> technical discussion so it got no replies. I'm starting over in order
<br>> to
<br>> reach a wider target for the discussion.
<br>>
<br>> I'll start with the proposal and then explain the reasons for it:
<br>>
<br>> Starting with next glib release:
<br>> * libgobject links to libgthread
<br>> * g_type_init() starts with:
<br>>
<br>> #ifdef G_THREADS_ENABLED
<br>> if (g_thread_supported())
<br>> g_thread_init (NULL);
<br>> #endif
<br>>
<br>> This means that everything above gobject can rely on thread primitives
<br>> being availible, and that global stuff in glib (mainloop, gslice,
<br>> globals, etc) are threadsafe.
</div></div>I'm attaching a patch that implements this.
<br><br>In addition to enabling threads (if complied in) in g_type_init() it
<br>adds a G_THREADS_MANDATORY define that if set causes all the
<br>g_thread_supported() calls to be removed in the g_thread_* macros.
<br><br>We then pass -DG_THREADS_MANDATORY in gobject and gio if threads are
<br>enabled, letting us avoid a bunch of checks of the
<br>g_threads_got_initialized global variable. I'm not sure how important
<br>this is, but it got rid of 2186 bytes of code in libgobject.so, and it
<br>just seems wrong to constantly check this when its always true.
<br><br>--
<br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<br> Alexander Larsson Red Hat, Inc
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26591778&i=0" target="_top" rel="nofollow">alexl@...</a> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26591778&i=1" target="_top" rel="nofollow">alexander.larsson@...</a>
<br>He's an immortal pirate gangster from the 'hood. She's an orphaned
<br>nymphomaniac detective on the trail of a serial killer. They fight crime!
<br><br /><tt>[gobject-enable-threads.patch]</tt><br /><hr align="left" width="300" /><tt>diff --git a/configure.in b/configure.in
<br>index 723311f..9b4510b 100644
<br>--- a/configure.in
<br>+++ b/configure.in
<br>@@ -2349,6 +2349,7 @@ case $host in
<br> ;;
<br> esac
<br>
<br>+AM_CONDITIONAL(HAVE_THREADS, [test "$have_threads" != "none"])
<br> AC_DEFINE_UNQUOTED(G_THREAD_SOURCE,"gthread-$have_threads.c",
<br> [Source file containing theread implementation])
<br> AC_SUBST(G_THREAD_CFLAGS)
<br>diff --git a/gio/Makefile.am b/gio/Makefile.am
<br>index 9dc2e02..62350cb 100644
<br>--- a/gio/Makefile.am
<br>+++ b/gio/Makefile.am
<br>@@ -41,6 +41,10 @@ TESTS = abicheck.sh pltcheck.sh
<br> endif
<br> endif
<br>
<br>+if HAVE_THREADS
<br>+THREAD_FLAGS=-DG_THREADS_MANDATORY
<br>+endif
<br>+
<br> AM_CPPFLAGS = \
<br> -DG_LOG_DOMAIN=\"GLib-GIO\" \
<br> -I$(top_builddir) \
<br>@@ -48,6 +52,7 @@ AM_CPPFLAGS = \
<br> -I$(top_srcdir)/glib \
<br> -I$(top_srcdir)/gmodule \
<br> $(GLIB_DEBUG_FLAGS) \
<br>+ $(THREAD_FLAGS) \
<br> -DG_DISABLE_DEPRECATED \
<br> -DGIO_COMPILATION \
<br> -DGIO_MODULE_DIR=\"$(GIO_MODULE_DIR)\"
<br>diff --git a/glib/gthread.h b/glib/gthread.h
<br>index 019d0db..7a0abba 100644
<br>--- a/glib/gthread.h
<br>+++ b/glib/gthread.h
<br>@@ -198,7 +198,11 @@ GMutex* g_static_mutex_get_mutex_impl (GMutex **mutex);
<br> (cond, mutex, abs_time, G_MUTEX_DEBUG_MAGIC, G_STRLOC) : TRUE)
<br> #endif /* G_ERRORCHECK_MUTEXES */
<br>
<br>+#if defined(G_THREADS_ENABLED) && defined(G_THREADS_MANDATORY)
<br>+#define g_thread_supported() 1
<br>+#else
<br> #define g_thread_supported() (g_threads_got_initialized)
<br>+#endif
<br> #define g_mutex_new() G_THREAD_UF (mutex_new, ())
<br> #define g_cond_new() G_THREAD_UF (cond_new, ())
<br> #define g_cond_signal(cond) G_THREAD_CF (cond_signal, (void)0, (cond))
<br>diff --git a/gobject-2.0-uninstalled.pc.in b/gobject-2.0-uninstalled.pc.in
<br>index 1aab1b5..d9378a5 100644
<br>--- a/gobject-2.0-uninstalled.pc.in
<br>+++ b/gobject-2.0-uninstalled.pc.in
<br>@@ -1,6 +1,6 @@
<br> Name: GObject Uninstalled
<br> Description: Object/type system for GLib, Not Installed
<br>-Requires: glib-2.0-uninstalled
<br>+Requires: glib-2.0-uninstalled,gthread-2.0-uninstalled
<br> Version: @VERSION@
<br> Libs: ${pc_top_builddir}/${pcfiledir}/gobject/libgobject-2.0.la
<br> ## cflags contains builddir in addition to srcdir because of gmarshal.h
<br>diff --git a/gobject-2.0.pc.in b/gobject-2.0.pc.in
<br>index 31fe34d..41505a9 100644
<br>--- a/gobject-2.0.pc.in
<br>+++ b/gobject-2.0.pc.in
<br>@@ -5,7 +5,7 @@ includedir=@includedir@
<br>
<br> Name: GObject
<br> Description: GLib Type, Object, Parameter and Signal Library
<br>-Requires: glib-2.0
<br>+Requires: glib-2.0,gthread-2.0
<br> Version: @VERSION@
<br> Libs: -L${libdir} -lgobject-2.0
<br> Cflags:
<br>diff --git a/gobject/Makefile.am b/gobject/Makefile.am
<br>index b5902d3..7579dc9 100644
<br>--- a/gobject/Makefile.am
<br>+++ b/gobject/Makefile.am
<br>@@ -6,12 +6,17 @@ include $(top_srcdir)/Makefile.decl
<br>
<br> SUBDIRS = . tests
<br>
<br>+if HAVE_THREADS
<br>+THREAD_FLAGS=-DG_THREADS_MANDATORY
<br>+endif
<br>+
<br> AM_CPPFLAGS = \
<br> -DG_LOG_DOMAIN=\"GLib-GObject\" \
<br> -I$(top_srcdir) \
<br> -I$(top_srcdir)/glib \
<br> -I$(top_builddir) \
<br> $(GLIB_DEBUG_FLAGS) \
<br>+ $(THREAD_FLAGS) \
<br> -DG_DISABLE_DEPRECATED \
<br> -DGOBJECT_COMPILATION \
<br> -DG_DISABLE_CONST_RETURNS
<br>@@ -31,7 +36,7 @@ TESTS = abicheck.sh pltcheck.sh
<br> endif
<br> endif
<br>
<br>-libglib = $(top_builddir)/glib/libglib-2.0.la
<br>+libglib = $(top_builddir)/glib/libglib-2.0.la $(top_builddir)/gthread/libgthread-2.0.la
<br>
<br> # libraries to compile and install
<br> lib_LTLIBRARIES = libgobject-2.0.la
<br>diff --git a/gobject/gtype.c b/gobject/gtype.c
<br>index cc3b9df..0d816b7 100644
<br>--- a/gobject/gtype.c
<br>+++ b/gobject/gtype.c
<br>@@ -4180,7 +4180,12 @@ g_type_init_with_debug_flags (GTypeDebugFlags debug_flags)
<br> GTypeInfo info;
<br> TypeNode *node;
<br> volatile GType votype;
<br>-
<br>+
<br>+#ifdef G_THREADS_ENABLED
<br>+ if (!g_thread_get_initialized())
<br>+ g_thread_init (NULL);
<br>+#endif
<br>+
<br> G_LOCK (type_init_lock);
<br>
<br> G_WRITE_LOCK (&type_rw_lock);
<br></tt><hr align="left" width="300" /><br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26591778&i=2" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26610301Gtk Critical Error While Using Cairo and Pango.2009-12-01T03:03:17Z2009-12-01T03:03:17ZAjay BalarHello everyone,<br><br>I am having following example code which i am using to Draw background of a window plus a GtkImage On It. I am drawing background of GtkWindow by use of Cairo on Expose Event. I am Adding One GtkImage on this window and in that GtkImage i ma adding Text Using Pango but this image is not visible.<br>
<br><br>You can try and run this program.<br>It will just display window with given PNG image as background. but not the image on it. when i use export XLIB_SKIP_ARGB_VISUALS=1 on terminal then it displays both Window and Image on it but Transparency of background image is Lost.<br>
<br><br>Code<br><br>--------------------------------------------------------------------------------------------------------------------------------<br><br>#include <gtk/gtk.h><br>#include "string.h"<br><br>
gboolean DrawTextOnImage(GtkWidget *image, const gchar *markup, const gchar* fg_color)<br>{<br> g_return_val_if_fail( image != NULL, FALSE );<br> g_return_val_if_fail( markup != NULL, FALSE );<br><br> gint x, y, pwidth, pheight;<br>
GdkGC *gc;<br> GdkPixmap *pixmap;<br> GdkPixbuf *pixbuf;<br> GdkColor color;<br> GdkBitmap *mask;<br> PangoRectangle extents;<br> GtkRequisition req;<br><br> pixbuf = gtk_image_get_pixbuf( GTK_IMAGE(image) );<br>
gdk_pixbuf_render_pixmap_and_mask( pixbuf, &pixmap, &mask, 1 );<br><br> if (fg_color == NULL)<br> gdk_color_parse("black", &color);<br> else<br> gdk_color_parse(fg_color, &color);<br>
<br> gc = gdk_gc_new( GDK_DRAWABLE( pixmap ) );<br> gdk_gc_set_rgb_fg_color(gc, &color);<br><br> PangoLayout *layout;<br> layout = pango_layout_new( gtk_widget_get_pango_context(image));<br> pango_layout_set_markup( layout, markup, strlen(markup) );<br>
pango_layout_get_pixel_extents (layout, &extents, NULL);<br><br> gtk_widget_size_request( image, &req );<br><br> x = image->allocation.x;<br> y = image->allocation.y;<br><br> gdk_draw_layout( GDK_DRAWABLE(pixmap),<br>
gc,<br> x + (req.width - extents.width) / 2,<br> y + (req.height - extents.height) / 2,<br> layout);<br><br> g_object_unref (G_OBJECT (gc));<br> g_object_unref (G_OBJECT (layout));<br>
<br> GdkColormap *cmap = NULL;<br> cmap = gtk_widget_get_colormap(image);<br> gdk_drawable_get_size(pixmap, &pwidth, &pheight);<br><br> pixbuf = gdk_pixbuf_get_from_drawable( NULL, pixmap, cmap,<br> 0 , 0,<br>
0 , 0,<br> pwidth, pheight );<br><br> g_object_unref( pixmap );<br><br> GdkPixmap *new_pixmap;<br> gdk_pixbuf_render_pixmap_and_mask( pixbuf, &new_pixmap, NULL, 1 );<br><br> gtk_image_clear( GTK_IMAGE(image) );<br>
gtk_image_set_from_pixmap( GTK_IMAGE(image), new_pixmap, mask );<br><br> g_object_unref( pixbuf );<br> g_object_unref( cmap );<br><br> return TRUE;<br>}<br><br>G_MODULE_EXPORT gboolean window_expose_cb(GtkWidget *widget, GdkEventExpose *event, gpointer data)<br>
{<br> char *img_path = g_build_filename( "background.png", NULL);<br> cairo_surface_t *g_imgGlass;<br> g_imgGlass = cairo_image_surface_create_from_png( img_path );<br> g_free( img_path );<br><br>
cairo_t *cr;<br>
cr = gdk_cairo_create(widget->window);<br> cairo_set_source_surface(cr, g_imgGlass, 0, 0);<br> cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);<br> cairo_paint(cr);<br> cairo_destroy(cr);<br><br> return FALSE;<br>
}<br><br><br>int main( int argc, char *argv[])<br>{<br> GtkWidget *window;<br> GtkWidget *image;<br> GdkScreen* screen;<br> GdkColormap* colormap;<br><br> gtk_init(&argc, &argv);<br><br> window = gtk_window_new(GTK_WINDOW_TOPLEVEL);<br>
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);<br> gtk_window_set_default_size(GTK_WINDOW(window), 350, 100);<br> gtk_window_set_title(GTK_WINDOW(window), "XYZ");<br> gtk_container_set_border_width(GTK_CONTAINER(window), 5);<br>
gtk_window_set_resizable( GTK_WINDOW(window), FALSE );<br> gtk_window_set_decorated(GTK_WINDOW(window), FALSE);<br> gtk_widget_set_app_paintable(window, TRUE);<br> gtk_window_set_opacity(GTK_WINDOW(window), 1);<br>
<br> gtk_widget_set_events(window, GDK_EXPOSURE_MASK<br> | GDK_ENTER_NOTIFY_MASK<br> | GDK_LEAVE_NOTIFY_MASK<br> | GDK_BUTTON_PRESS_MASK<br> | GDK_BUTTON_RELEASE_MASK<br>
| GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK);<br><br> g_signal_connect(G_OBJECT(window), "expose-event", G_CALLBACK(window_expose_cb), NULL);<br> g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit), NULL );<br>
<br><br> image = gtk_image_new_from_file("Button_normal.png");<br> gtk_container_add(GTK_CONTAINER(window), image );<br><br> DrawTextOnImage(image, "<span size='large'><b>Some Text</b></span>", "#FFFFFF" );<br>
<br> screen = gtk_widget_get_screen(window);<br> colormap = gdk_screen_get_rgba_colormap(screen);<br> gtk_widget_set_colormap(window, colormap);<br><br> gtk_widget_show_all(window);<br> gtk_main();<br>
<br> return 0;<br>}<br>--------------------------------------------------------------------------------------------------------------------------------<br><br>Some times i get these types of Warnings and Errors:<br><br>
--------------------------------------------------------------------------------------------------------------------------------<br>(gtkimage:4536): Gtk-CRITICAL **: gtk_widget_set_colormap: assertion `GDK_IS_COLORMAP (colormap)' failed<br>
(gtkimage:6146): Gdk-WARNING **: Attempt to draw a drawable with depth 16 to a drawable with depth 32<br>--------------------------------------------------------------------------------------------------------------------------------<br>
<br>This is how my out put is coming when i set XLIB_SKIP_ARGB_VISUALS=1 and when i set it to 0 i am not able to see the GtkImage on window.<br><br>This is the pout put screen shot Click Here <br><image "src=<a href="http://farm3.static.flickr.com/2678/4149277123%5F8e9138766f%5Fo.jpg" target="_blank" rel="nofollow">http://farm3.static.flickr.com/2678/4149277123%5F8e9138766f%5Fo.jpg</a>"/><br>
<br>why this must be happening can some one please provide some help on this issue?<br>I am really Stuck on this.<br>Any Expert for Cairo, Pango and Gtk+ here please help?<br><br><br>Thanks,<br><br>AB.<br><br>
<br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26610301&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26610299GtjComboBox question2009-12-01T00:15:40Z2009-12-01T00:15:40ZikorotHi, ALL,
<br>Is there a function to show a list box of a combo box?
<br><br>It looks like gtk_combo_box_popup() is what I'm looking for,
<br>but the documentation says that it should be used with an
<br>accessibility pack.
<br><br>Thank you.
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26610299&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26584619Re: A few comments on GVariant2009-11-30T16:25:08Z2009-11-30T16:25:08ZRyan LortieHi,
<br><br>On Mon, 2009-11-30 at 21:08 +0100, Christian Persch wrote:
<br>> schrieb Ryan Lortie <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26584619&i=0" target="_top" rel="nofollow">desrt@...</a>>:
<br>> > Note that you can do in-place parsing of:
<br>> >
<br>> > "( { 'zero': 0, 'one': 1, 'two': 2 }, '' )"
<br>> >
<br>> > if you prefer.
<br>>
<br>> If I have to build the string at runtime, I can just as well use
<br>> GVariantBuilder directly.
<br><br>Sorry. I should have mentioned. This also works:
<br><br>g_variant_new_parsed ("{ 'zero': %i, 'one': %i, 'two': %i }", 0, 1, 2);
<br><br>Where the part after the '%' is any GVariant format string -- the
<br>arguments are collected from the varargs list as if you were using
<br>g_variant_new() with that string.
<br><br>I hope that makes things nicer.
<br><br>cheers
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26584619&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26584470GTK+ 2.19.1 released2009-11-30T16:10:17Z2009-11-30T16:10:17ZMatthias ClasenGTK+ 2.19.1 is now available for download at:
<br><br> ftp://ftp.gtk.org/pub/gtk/2.19/
<br> <a href="http://download.gnome.org/sources/gtk+/2.19/" target="_top" rel="nofollow">http://download.gnome.org/sources/gtk+/2.19/</a><br><br>md5 sums:
<br>d11e2044aedc49e155832c54dc9ac548 gtk+-2.19.1.tar.bz2
<br>d0a5dc39ba91dfacaed68f2ef5d36e8e gtk+-2.19.1.tar.gz
<br><br>sha1 sums:
<br>daf7252027555212091896d96244fdc141ebbfa8 gtk+-2.19.1.tar.bz2
<br>4d0175ff31ad7fba61d2deb6a80933ebb6bda7e0 gtk+-2.19.1.tar.gz
<br><br>This is a development release leading up to GTK+ 2.20.
<br><br>Notes:
<br><br> * This is an unstable development release.
<br> It has had only little testing and there are unfinished
<br> features and plenty of bugs in this release. It should
<br> definitively not be used in production.
<br><br> * Installing this version will overwrite your existing
<br> copy of GTK+ 2.18. If you have problems, you'll need
<br> to reinstall GTK+ 2.18.
<br><br> * GTK+ 2.20 will be source and binary compatible with
<br> the GTK+ 2.18 series; however, the new API additions
<br> are not yet finalized, so there may be incompatibilities
<br> between this release and the final 2.20 release.
<br><br> * Bugs should be reported to <a href="http://bugzilla.gnome.org" target="_top" rel="nofollow">http://bugzilla.gnome.org</a>.
<br><br><br>What is GTK+
<br>============
<br><br>GTK+ is a multi-platform toolkit for creating graphical user
<br>interfaces. Offering a complete set of widgets, GTK+ is suitable for
<br>projects ranging from small one-off tools to complete application
<br>suites.
<br><br>GTK+ has been designed from the ground up to support a range of
<br>languages, not only C/C++. Using GTK+ from languages such as Perl and
<br>Python (especially in combination with the Glade GUI builder) provides
<br>an effective method of rapid application development.
<br><br>GTK+ is free software and part of the GNU Project. However, the
<br>licensing terms for GTK+, the GNU LGPL, allow it to be used by all
<br>developers, including those developing proprietary software, without
<br>any license fees or royalties.
<br><br><br>Where to get more information about GTK+
<br>========================================
<br><br>Information about GTK+ including links to documentation can be
<br>found at:
<br><br><a href="http://www.gtk.org/" target="_top" rel="nofollow">http://www.gtk.org/</a><br><br>An installation guide for GTK+ 2.x is found at:
<br><br> <a href="http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html" target="_top" rel="nofollow">http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html</a><br><br>Common questions:
<br><br><a href="http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html" target="_top" rel="nofollow">http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html</a><br><a href="http://www.gtk.org/faq/" target="_top" rel="nofollow">http://www.gtk.org/faq/</a><br><br><br>Contributing
<br>============
<br><br>GTK+ is a large project and relies on voluntary contributions.
<br>We are actively searching for new contributors in various areas
<br>and invite everyone to help project development.
<br>If you are willing to participate, please subscribe to the project
<br>mailing lists to offer your help and read over our list of vacant
<br>project tasks:
<br> <a href="http://live.gnome.org/GtkTasks" target="_top" rel="nofollow">http://live.gnome.org/GtkTasks</a><br><br><br>Overview of Changes from GTK+ 2.19.0 to 2.19.1
<br>==============================================
<br><br>* Client-side windows:
<br> - Avoid some unnecessary exposes
<br> - Avoid unnecessary redraws related to clearing windows
<br><br>* GtkNotebook gained an 'action area'
<br><br>* GtkStatusbar gained a 'message area'
<br><br>* GtkToolPalette is a new container to show tool items
<br> in collapsible groups in a grid
<br><br>* gdk-pixbuf can now handle compressed TIFF images
<br><br>* GSEAL work:
<br> - New accessor: gtk_window_get_window_type()
<br><br>* Bugs fixed:
<br> 590017 Does not compile under MinGW32 + Wine
<br> 569430 Gail should include a reciprocal relationship for NODE_CHILD_OF
<br> 598758 Need context for a propper translation
<br> 594535 No accesor for GtkStatusbar->label and ->frame
<br> 602725 fix setting icon-size on GICON images
<br> 599402 Landscape and Reverse Landscape icons need to be swapped
<br> 588740 JPEG images open with blur effect?
<br> 601337 Only use gdk_input_select_events() if XINPUT_NONE is defined
<br> 598050 Flickering in a gtk_socket
<br> 600158 Do not use static GTypeInfo and GInterfaceInfo
<br> 561973 Problem dragging images from Firefox to GTK+ app on Windows
<br> 601512 Remove unnecessary check in GtkTreeModelFilter
<br> 600222 Check for existence of cairo-svg.h in configure.in
<br> 595498 No accesor for GTK_WINDOW ()->type
<br> 116650 "action area" for GtkNotebook (e.g. for tab close button)
<br> 600150 GtkColorSelection tooltip issues
<br> 480065 wrong tree collapsed (or expanded) after having scrolled
<br> 596473 Second double-click of GtkTreeView row doesn't emit...
<br> 601869 GtkUIManager assumes too much about popup menus
<br> 581145 Wrong positioning for fullscreen gedit toolbar animation
<br> 602724 gailimage doesn't handle GTK_IMAGE_{GICON,ICON_NAME}...
<br> 561130 get_monitor_geometry segfaults if called with non-existant...
<br> 597026 Missing include for memset()
<br> 585383 Segfault in gdk_pixbuf__ico_image_save
<br> 597865 Move documentation from templates to inline comments
<br> 123569 Catch contents being reparented out of socket
<br> 561334 Incorrect named constant in documentation of two GtkButton...
<br> 601611 gtk_selection_data_get_targets() reads X Atom data as GdkAtoms
<br> 601409 action area presence modifies notebook behaviour
<br> 603268 wrong Since: markers in toolpalette merge
<br> 603271 wrong toolbar style
<br> 601959 must release compose key before continuing compose sequence
<br> 603302 Incorrectly warn about links on text with color and underline
<br> 603201 gtk_about_dialog_set_url_hook has no effect anymore
<br> 591438 dfb_events_dispatch is not thread safe
<br> 589842 GtkAction API to have its menu item proxies have always-show...
<br> 584700 TIFF pixbuf loader should support compression
<br> 603128 Adding new UI that was recently removed may cause wrong order
<br> 601682 Print preview should use gtk_show_uri by default
<br> 596083 Deprecate notebook label packing functionality
<br><br>* Updated translations:
<br> Estonian
<br> Galician
<br> Japanese
<br> Low German
<br> Norwegian bokmål
<br> Punjabi
<br> Slovenian
<br> Spanish
<br> Swedish
<br><br>Thanks to all contributors:
<br>Alexander Larsson
<br>Tor Lillqvist
<br>Tomas Bzatek
<br>Chris Wilson
<br>Tim Janik
<br>Cody Russell
<br>Sven Herzberg
<br>Benjamin Otte
<br>Carlo Bramini
<br>Hib Eris
<br>Paolo Bonzini
<br>Stéphane Démurget
<br>Ryan Lortie
<br>Javier Jardón
<br>Vincent Untz
<br>Christian Dywan
<br>Juan A. Suarez Romero
<br>Xan Lopez
<br>Christian Persch
<br>Will Thompson
<br>Kristian Rietveld
<br>Michael Natterer
<br><br><br>November 30, 2009
<br>Matthias Clasen
<br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26584470&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26582480Re: A few comments on GVariant2009-11-30T13:42:00Z2009-11-30T13:42:00ZBehdad Esfahbod-3On 11/30/2009 08:30 AM, Matthias Clasen wrote:
<div class='shrinkable-quote'><br>> On Mon, Nov 30, 2009 at 7:27 AM, Christian Persch<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26582480&i=0" target="_top" rel="nofollow">chpe@...</a>> wrote:
<br>>> Hi;
<br>>>
<br>>>
<br>>> - g_variant_type_matches docs say: "This function defines a bounded
<br>>> join-semilattice over GVariantType for which G_VARIANT_TYPE_ANY is
<br>>> top."
<br>>> If you do want to go into that much detail, there should be a
<br>>> more complete definition of how that ... thing ... is constructed :-)
<br>>
<br>> I'd just drop that kind of thing; I did study lattice theory and know
<br>> what a bounded join-semilattice is, but I doubt this information will
<br>> help anybody to use GVariant...
</div><br>Isn't the hierarchy simply a tree?
<br><br>behdad
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26582480&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26582076Re: A few comments on GVariant2009-11-30T13:18:10Z2009-11-30T13:18:10ZSimon McVittie-6On Mon, 30 Nov 2009 at 21:08:54 +0100, Christian Persch wrote:
<br>> We do have that already with G_GINT*_FORMAT, G_GS[S]IZE_FORMAT,
<br>> G_GOFFSET_FORMAT, and at least the G[S]SIZE one is useful.
<br><br>I was under the impression that those were mainly to support the fact that the
<br>right printf character varies by platform? For instance, gsize can either be
<br>%u or %lu, and goffset could reasonably be anything from %i to %lli.
<br><br>There's no G_GINT_FORMAT, because it would be %i everywhere by definition,
<br>but because printf formats and default promotions (varargs) are defined in
<br>terms of int/long/long long instead of 16/32/64 bit types, the fixed-length
<br>types need these macros.
<br><br> S
<br><br /> <br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26582076&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (809 bytes) <a href="http://old.nabble.com/attachment/26582076/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26581127Re: A few comments on GVariant2009-11-30T12:15:27Z2009-11-30T12:15:27ZChristian PerschHi;
<br><br>Simon McVittie <simon mcvittie collabora co uk> wrote:
<div class='shrinkable-quote'><br>> On Mon, 30 Nov 2009 at 13:27:02 +0100, Christian Persch wrote:
<br>> > - space efficiency: I was trying to build a variant containing some
<br>> > data, and multiple dicts to get at the data from various keys. i.e
<br>> > "a{sv}a{sv}a{sv}". I though that if I constructed the data
<br>> > GVariants first, and then added these to the dicts (i.e.
<br>> > v=g_variant_new(), add (key1, v) to dict1, add (key2, v) to dict2
<br>> > etc), the resulting blob (g_variant_flatten
<br>> > + get the data out) would contain that data only once instead of
<br>> > once for each dict it was in.
<br>>
<br>> The D-Bus serialization format (which is also the GVariant
<br>> serialization format) doesn't have backreferences to
<br>> previously-serialized data, so yes, your data will get duplicated if
<br>> you do this.
<br>>
<br>> In practice, the big cost on D-Bus tends to be number of round trips /
<br>> wait-for-reply operations, rather than the number of bytes
<br>> transferred, so a bit of redundancy isn't a big deal.
<br>>
<br>> I can see that the tradeoffs for storage on disk aren't the same as
<br>> the tradeoffs for D-Bus; but, gzip the blob? :-)
</div><br>Yes, I tried to use GVariant to store lots of data on disk, to be
<br>mmaped, and not for transfer over dbus or network. So space efficiency
<br>would be good, but by using gzip I would lose the ability to just mmap
<br>the data directly.
<br><br>Regards,
<br> Christian
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26581127&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26581033Re: A few comments on GVariant2009-11-30T12:08:54Z2009-11-30T12:08:54ZChristian PerschHi;
<br><br>Am Mon, 30 Nov 2009 11:31:10 -0500
<br>schrieb Ryan Lortie <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26581033&i=0" target="_top" rel="nofollow">desrt@...</a>>:
<div class='shrinkable-quote'><br>> On Mon, 2009-11-30 at 13:27 +0100, Christian Persch wrote:
<br>> > - There really should be a GVariant tutorial, not just the API
<br>> > docs. If I hadn't at least had a vague idea what GVariant does, I
<br>> > would have been completely helpless with the API docs. Even so, I
<br>> > had to proceed by trial-and-error by copying what the tests do...
<br>>
<br>> I totally agree with this. I've even considered using
<br>> example/tutorial style documentation in place of full proper
<br>> reference documentation in some places since it's difficult to
<br>> formally describe, for example, GVariant format strings, but quite
<br>> easy to show how to use them by example.
</div><br>Agreed. The examples in tests/ helped me greatly to understand how it's
<br>supposed to work.
<br><div class='shrinkable-quote'><br>> > - Type strings: to construct them, you need to remember which
<br>> > character is which type. There are the G_VARIANT_TYPE_* defines,
<br>> > but they are non-concatenable, i.e. you can't construct a type
<br>> > string like G_VARIANT_TYPE_A G_VARIANT_TYPE_B but have to use "ab"
<br>> > which makes typos uncaught at the compiler stage. Could there also
<br>> > be concatenable #defines for these?
<br>>
<br>> My attitude about this is that you should "just deal". Basically,
<br>> reserve some extra brain cells for it and memorise it -- just like
<br>> printf. The fact that it's the same as the DBus type system means
<br>> that you can even share those brain cells. :)
<br>>
<br>> Consider if we had to write things like:
<br>>
<br>> g_strdup_print ("int: " G_PRINTF_TYPE_INTEGER ", "
<br>> "float: " G_PRINTF_TYPE_FLOAT "\n", 234, 2.5);
</div><br>We do have that already with G_GINT*_FORMAT, G_GS[S]IZE_FORMAT,
<br>G_GOFFSET_FORMAT, and at least the G[S]SIZE one is useful.
<br><br>Personally, I find it much easier to type more
<br>(maybe "G_VARIANT_TYPE_XYZ_S") instead of thinking more ("which
<br>character correspond type XYZ to, again")? Plus, it's typo-safe at
<br>compile-time.
<br><br>Then again, thanks to GVariant's liberal use of g_error(), you find out
<br>quickly about typos at runtime.
<br><br>> I think this really injures the readability.
<br><br>True.
<br><br>> > - g_variant_builder_add[_value]: should this return the
<br>> > passed-in GVariantBuilder* instead of void, so one can chain
<br>> > calls?
<br>>
<br>> That's an interesting proposal. It's very evil in terms of refcounts,
<br>> but the refcounting semantics of GVariantBuilder are fairly unbindable
<br>> at this point anyway, so who cares about some extra magic? :)
<br>>
<br>> Can you give me a good example of a use case you have here?
<br><br>Since the g_variant_new ("aX", N, <v1>, <v2>, ..., <vN>) way didn't
<br>exist anymore, my first idea was to do something like this:
<br><br>v = g_variant_builder_end (
<br> g_variant_builder_add (
<br> ...
<br> g_variant_builder_add (
<br> g_variant_builder_add (
<br> g_variant_builder_new (...),
<br> <v1>)
<br> <v2>)
<br> <v3>)
<br> ...
<br> <vN>)
<br><br>Not very elegant, and backwards, but works for short arrays.
<br><div class='shrinkable-quote'><br>> Do you have another method you'd prefer for array construction? Maybe
<br>> one that collects each array item from the varargs list? Is that
<br>> evil?
<br>>
<br>> > This appears to have been changed from earlier code; in the
<br>> > removed glib/tests/gvariant-complex.c test, it was done this way:
<br>> >
<br>> > variant = g_variant_new ("(a{si}s)",
<br>> > 3,
<br>> > "zero", 0,
<br>> > "one", 1,
<br>> > "two", 2,
<br>> > "");
<br>> >
<br>> > IMHO a vastly more convenient way to build an array in one step,
<br>> > in case one already knows how many elements one has and what they
<br>> > are.
<br>> >
<br>> > Could there again be a convenience method like this?
<br>>
<br>> mmm. Yes. It used to be like that, indeed. The reason that I
<br>> removed it was because it was not possible to have a dual of it for
<br>> g_variant_get() and I'm trying to keep g_variant_new() as similar to
<br>> g_variant_get() as is possible.
</div><br>Ok.
<br><br>> Note that you can do in-place parsing of:
<br>>
<br>> "( { 'zero': 0, 'one': 1, 'two': 2 }, '' )"
<br>>
<br>> if you prefer.
<br><br>If I have to build the string at runtime, I can just as well use
<br>GVariantBuilder directly.
<br><br>On the other hand, if the string is known at compile time, that brings
<br>me to one point I forgot to mention in the original mail. It'd be great
<br>if there was a standalone gvariant compiler (à la glib-genmarshal /
<br>glib-mkenums) that takes gvariant markup input, and writes, chosen by a
<br>command line option, one of
<br><br>- a binary blob that I can then use with g_variant_from_file(), and
<br><br>- source code (static const guint8 myvariant_data[] = { ... }), that
<br> I can use with g_variant_from_data().
<br><div class='shrinkable-quote'><br>> > - space efficiency: I was trying to build a variant containing some
<br>> > data, and multiple dicts to get at the data from various keys. i.e
<br>> > "a{sv}a{sv}a{sv}". I though that if I constructed the data
<br>> > GVariants first, and then added these to the dicts (i.e.
<br>> > v=g_variant_new(), add (key1, v) to dict1, add (key2, v) to dict2
<br>> > etc), the resulting blob (g_variant_flatten
<br>> > + get the data out) would contain that data only once instead of
<br>> > once for each dict it was in. Well, it didn't work :-)
<br>> > Was that a naive/dumb thing to expect, or can this be made to
<br>> > work?
<br>> >
<br>> > I ended up doing "ava{su}a{su}a{su}", first putting the data into
<br>> > an array, then the index of the data in the array into the dicts.
<br>> > Is that the best way for this?
<br>>
<br>> This is the recommended way, yes. If you have the data appearing
<br>> multiple times then it will appear multiple times. There is no
<br>> compression here.
</div><br>Ok.
<br><br>> > - gvariant-*.c fail to #include "config.h"
<br>>
<br>> What's the policy on this sort of thing? Include everywhere or only
<br>> include if needed?
<br><br>Afaik it's "everywhere".
<br><div class='shrinkable-quote'><br>> > - the code uses literal 'X' / "X" in many places; IMHO using
<br>> > G_VARIANT_TYPE_CLASS_X / G_VARIANT_TYPE_X would make the code more
<br>> > readable / informative
<br>>
<br>> All I can say to this is that it's easier to type this:
<br>>
<br>> case 'a': case 'b': case 'c': case 'd':
<br>>
<br>> than:
<br>>
<br>> case G_VARIANT_TYPE_CLASS_ALPHA:
<br>> case G_VARIANT_TYPE_CLASS_BETA:
<br>> case G_VARIANT_TYPE_CLASS_GAMMA:
<br>> case G_VARIANT_TYPE_CLASS_DELTA:
</div><br>Indeed, it's easier to type, but the long form is easier to read and
<br>for code review. Anyway, it's not that important; just a personal
<br>preference.
<br><br>> > - g_variant_parse_full is rather unusual in that it returns an error
<br>> > not in a GError but a GVariantParseError. Could this be
<br>> > implemented instead by fixing bug 124022
<br>> > [<a href="https://bugzilla.gnome.org/show_bug.cgi?id=124022" target="_top" rel="nofollow">https://bugzilla.gnome.org/show_bug.cgi?id=124022</a>] and then using
<br>> > that to put the extra data into a GError?
<br>>
<br>> Does this bug have any hope of being fixed any time soon?
<br><br>I just attached a patch there, which should at least raise the
<br>probability a bit :-)
<br><br>> The GSettings schema file parser calls the _full variant to parse
<br>> default values out of schema files. The extra information is used to
<br>> tie-in to the error reporting system of that parser which does
<br>> Vala-style reporting of the lcation of errors.
<br>> ^^^^^^^
<br><br>I see. In that case, it's indeed good to have more info.
<br><br>Regards,
<br> Christian
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26581033&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26580989Re: Merging gobject-performance-2 branch2009-11-30T12:06:01Z2009-11-30T12:06:01ZAlexander LarssonOn Mon, 2009-11-30 at 08:18 -0500, Matthias Clasen wrote:
<div class='shrinkable-quote'><br>> On Mon, Nov 30, 2009 at 5:52 AM, Alexander Larsson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26580989&i=0" target="_top" rel="nofollow">alexl@...</a>>
<br>> wrote:
<br>>
<br>> > Now, how do we get this branch merged? A whole lot of people have
<br>> > reviewed this and everyone seems to think it looks good. The
<br>> speedups
<br>> > and scalability changes in this branch are very important for
<br>> threaded
<br>> > apps.
<br>>
<br>> I've just done a glib 2.23.0 release. Merging the performance branch
<br>> now seems like the right thing to me; if Tim wants to review this,
<br>> there is some time before the next release. We need to get things
<br>> moving here...
</div><br>All right. I rebased this to the current master (fixing one conflict),
<br>cleaned it up a bit (reordered and joined commits, etc), then merged it
<br>to master.
<br><br>--
<br>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
<br> Alexander Larsson Red Hat, Inc
<br> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26580989&i=1" target="_top" rel="nofollow">alexl@...</a> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26580989&i=2" target="_top" rel="nofollow">alexander.larsson@...</a>
<br>He's an old-fashioned coffee-fuelled farmboy searching for his wife's true
<br>killer. She's a violent cigar-chomping research scientist looking for love in
<br>all the wrong places. They fight crime!
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26580989&i=3" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26577710Re: A few comments on GVariant2009-11-30T08:38:18Z2009-11-30T08:38:18ZSimon McVittie-6On Mon, 30 Nov 2009 at 13:27:02 +0100, Christian Persch wrote:
<br>> - space efficiency: I was trying to build a variant containing some
<br>> data, and multiple dicts to get at the data from various keys. i.e
<br>> "a{sv}a{sv}a{sv}". I though that if I constructed the data
<br>> GVariants first, and then added these to the dicts (i.e.
<br>> v=g_variant_new(), add (key1, v) to dict1, add (key2, v) to dict2
<br>> etc), the resulting blob (g_variant_flatten
<br>> + get the data out) would contain that data only once instead of once
<br>> for each dict it was in.
<br><br>The D-Bus serialization format (which is also the GVariant serialization
<br>format) doesn't have backreferences to previously-serialized data, so yes,
<br>your data will get duplicated if you do this.
<br><br>In practice, the big cost on D-Bus tends to be number of round trips /
<br>wait-for-reply operations, rather than the number of bytes transferred, so
<br>a bit of redundancy isn't a big deal.
<br><br>I can see that the tradeoffs for storage on disk aren't the same as the
<br>tradeoffs for D-Bus; but, gzip the blob? :-)
<br><br>(Having backreferences would break compatibility between GVariant and D-Bus,
<br>and would also break the desirable property that parts of a message are
<br>entirely independent - as I understand it, GVariant takes advantage of that
<br>internally.)
<br><br>> - there should be a convenience function that takes a dictionary
<br>> variant and turns it into a GHashTable (I was surprised that
<br>> g_variant_lookup[_value] just iterates over the whole thing until a
<br>> match is found)
<br><br>As I mentioned on a related bug, I'd be inclined to say that the lookup
<br>function should construct a cache the first time, and query it subsequently
<br>(so it'd be O(n) the first time it was used, and O(1) thereafter).
<br><br>> - the code uses literal 'X' / "X" in many places; IMHO using
<br>> G_VARIANT_TYPE_CLASS_X / G_VARIANT_TYPE_X would make the code more
<br>> readable / informative
<br><br>Perhaps it's a sign that I do too much D-Bus, but I find code that uses the
<br>plain signature strings ("a{sv}") to be much, much more readable than
<br>DBUS_TYPE_ARRAY DBUS_TYPE_STRUCT_ENTRY_BEGIN DBUS_TYPE_STRING DBUS_TYPE_VARIANT
<br>DBUS_TYPE_STRUCT_ENTRY_END (or whatever the libdbus constants are really
<br>called).
<br><br>The signature characters are all quite mnemonic, apart from the 16- and 64-bit
<br>integers (I can never remember whether 't' or 'x' is the unsigned one).
<br><br>There's lots of prior art, notably printf/scanf and Python's Py_BuildValue /
<br>PyArgs_ParseTuple.
<br><br>Regards,
<br> Simon
<br><br /> <br />_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26577710&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (809 bytes) <a href="http://old.nabble.com/attachment/26577710/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26577584Re: A few comments on GVariant2009-11-30T08:31:10Z2009-11-30T08:31:10ZRyan LortieHi Christian
<br><br>On Mon, 2009-11-30 at 13:27 +0100, Christian Persch wrote:
<br>> Hi;
<br>>
<br>> I've been playing with the gvariant branch of glib a bit, and have a
<br>> few questions / remarks / code comments. I hope they're marginally
<br>> useful :-)
<br><br>Thanks so much for this feedback. It's extremely valuable.
<br><br>> - There really should be a GVariant tutorial, not just the API docs. If
<br>> I hadn't at least had a vague idea what GVariant does, I would have
<br>> been completely helpless with the API docs. Even so, I had to proceed
<br>> by trial-and-error by copying what the tests do...
<br><br>I totally agree with this. I've even considered using example/tutorial
<br>style documentation in place of full proper reference documentation in
<br>some places since it's difficult to formally describe, for example,
<br>GVariant format strings, but quite easy to show how to use them by
<br>example.
<br><br>> - Type strings: to construct them, you need to remember which character
<br>> is which type. There are the G_VARIANT_TYPE_* defines, but they are
<br>> non-concatenable, i.e. you can't construct a type string like
<br>> G_VARIANT_TYPE_A G_VARIANT_TYPE_B but have to use "ab" which makes
<br>> typos uncaught at the compiler stage. Could there also be
<br>> concatenable #defines for these?
<br><br>My attitude about this is that you should "just deal". Basically,
<br>reserve some extra brain cells for it and memorise it -- just like
<br>printf. The fact that it's the same as the DBus type system means that
<br>you can even share those brain cells. :)
<br><br>Consider if we had to write things like:
<br><br> g_strdup_print ("int: " G_PRINTF_TYPE_INTEGER ", "
<br> "float: " G_PRINTF_TYPE_FLOAT "\n", 234, 2.5);
<br><br>I think this really injures the readability.
<br><br>> - g_variant_type_matches docs say: "This function defines a bounded
<br>> join-semilattice over GVariantType for which G_VARIANT_TYPE_ANY is
<br>> top."
<br>> If you do want to go into that much detail, there should be a
<br>> more complete definition of how that ... thing ... is constructed :-)
<br><br>It's a bit of an easter-egg in the docs. I don't mind too much to
<br>remove it.
<br><br>> - g_variant_builder_add[_value]: should this return the
<br>> passed-in GVariantBuilder* instead of void, so one can chain calls?
<br><br>That's an interesting proposal. It's very evil in terms of refcounts,
<br>but the refcounting semantics of GVariantBuilder are fairly unbindable
<br>at this point anyway, so who cares about some extra magic? :)
<br><br>Can you give me a good example of a use case you have here?
<br><br>> - collection behaviour of g_variant_new: "a" types are collected as
<br>> GVariantBuilder. This seems very inconvenient to me, since one cannot
<br>> then build the whole thing in just the one call.
<br><br>But there are modifiers. Arrays of strings can be converted from a strv
<br>with '^as'. Arrays of constant-sized items (ie: ints, floats, and even
<br>structure types of these things) can be constructed using, for example,
<br>'&ai'.
<br><br>Do you have another method you'd prefer for array construction? Maybe
<br>one that collects each array item from the varargs list? Is that evil?
<br><div class='shrinkable-quote'><br>> This appears to have been changed from earlier code; in the removed
<br>> glib/tests/gvariant-complex.c test, it was done this way:
<br>>
<br>> variant = g_variant_new ("(a{si}s)",
<br>> 3,
<br>> "zero", 0,
<br>> "one", 1,
<br>> "two", 2,
<br>> "");
<br>>
<br>> IMHO a vastly more convenient way to build an array in one step, in
<br>> case one already knows how many elements one has and what they are.
<br>>
<br>> Could there again be a convenience method like this?
</div><br>mmm. Yes. It used to be like that, indeed. The reason that I removed
<br>it was because it was not possible to have a dual of it for
<br>g_variant_get() and I'm trying to keep g_variant_new() as similar to
<br>g_variant_get() as is possible.
<br><br>Note that you can do in-place parsing of:
<br><br> "( { 'zero': 0, 'one': 1, 'two': 2 }, '' )"
<br><br>if you prefer.
<br><div class='shrinkable-quote'><br>> - space efficiency: I was trying to build a variant containing some
<br>> data, and multiple dicts to get at the data from various keys. i.e
<br>> "a{sv}a{sv}a{sv}". I though that if I constructed the data
<br>> GVariants first, and then added these to the dicts (i.e.
<br>> v=g_variant_new(), add (key1, v) to dict1, add (key2, v) to dict2
<br>> etc), the resulting blob (g_variant_flatten
<br>> + get the data out) would contain that data only once instead of once
<br>> for each dict it was in. Well, it didn't work :-)
<br>> Was that a naive/dumb thing to expect, or can this be made to work?
<br>>
<br>> I ended up doing "ava{su}a{su}a{su}", first putting the data into
<br>> an array, then the index of the data in the array into the dicts.
<br>> Is that the best way for this?
</div><br>This is the recommended way, yes. If you have the data appearing
<br>multiple times then it will appear multiple times. There is no
<br>compression here.
<br><br>> - almost all functions are missing Since: markers; the Since: marked in
<br>> the G_TYPE_GVARIANT definition mistakenly says 2.14
<br><br>Noted.
<br><br>> - gvariant-*.c fail to #include "config.h"
<br><br>What's the policy on this sort of thing? Include everywhere or only
<br>include if needed?
<br><br>> - g_variant_markup_parser_end_element uses lots of
<br>> g_ascii_strto[u]ll/g_ascii_strtod but does no error- or overflow
<br>> checks? Other things are error-checked in there, so if this is
<br>> not-checked on purpose, a comment may be in order.
<br><br>I'll look into that.
<br><div class='shrinkable-quote'><br>> - how about having a variant of g_variant_print that operates on a
<br>> provided (buffer, len) ?
<br>>
<br>> - +#ifndef GSIZE_TO_LE
<br>> +#if GLIB_SIZEOF_SIZE_T == 4
<br>> +# define GSIZE_TO_LE GUINT32_TO_LE
<br>> +#else
<br>> +# define GSIZE_TO_LE GUINT64_TO_LE
<br>> +#endif
<br>> +#define GSIZE_FROM_LE GSIZE_TO_LE
<br>> +#endif
<br>>
<br>> Shouldn't these byteswapping macros be made public like the
<br>> existing repertoire in gtypes.h ?
</div><br>Matthias?
<br><br>> - there should be a convenience function that takes a dictionary
<br>> variant and turns it into a GHashTable (I was surprised that
<br>> g_variant_lookup[_value] just iterates over the whole thing until a
<br>> match is found)
<br><br><br><br>> - the code uses literal 'X' / "X" in many places; IMHO using
<br>> G_VARIANT_TYPE_CLASS_X / G_VARIANT_TYPE_X would make the code more
<br>> readable / informative
<br><br>All I can say to this is that it's easier to type this:
<br><br> case 'a': case 'b': case 'c': case 'd':
<br><br>than:
<br><br> case G_VARIANT_TYPE_CLASS_ALPHA:
<br> case G_VARIANT_TYPE_CLASS_BETA:
<br> case G_VARIANT_TYPE_CLASS_GAMMA:
<br> case G_VARIANT_TYPE_CLASS_DELTA:
<br><br>> - g_variant_parse_full is rather unusual in that it returns an error
<br>> not in a GError but a GVariantParseError. Could this be
<br>> implemented instead by fixing bug 124022
<br>> [<a href="https://bugzilla.gnome.org/show_bug.cgi?id=124022" target="_top" rel="nofollow">https://bugzilla.gnome.org/show_bug.cgi?id=124022</a>] and then using
<br>> that to put the extra data into a GError?
<br><br>Does this bug have any hope of being fixed any time soon?
<br><br>I could also just eliminate the "fancy" error reporting, but I think it
<br>can be really helpful (see below).
<br><br>> Actually, for what is this _full variant useful at all to have as a
<br>> public function — can't it just be private? It seems to only be used
<br>> in g_variant_parse().
<br><br>The GSettings schema file parser calls the _full variant to parse
<br>default values out of schema files. The extra information is used to
<br>tie-in to the error reporting system of that parser which does
<br>Vala-style reporting of the lcation of errors.
<br> ^^^^^^^
<br><br>> That's it for now.
<br><br>Thanks :)
<br><br>Cheers
<br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26577584&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26577187Re: A few comments on GVariant2009-11-30T08:08:16Z2009-11-30T08:08:16ZRyan LortieOn Mon, 2009-11-30 at 08:30 -0500, Matthias Clasen wrote:
<br>> I'd just drop that kind of thing; I did study lattice theory and know
<br>> what a bounded join-semilattice is, but I doubt this information will
<br>> help anybody to use GVariant...
<br><br>OTOH, just this morning I woke up to:
<br><br><br>07:35 -!- Irssi: Starting query in gnome with wjt
<br>07:35 <wjt> > This function defines a bounded join-semilattice over
<br> GVariantType for which G_VARIANT_TYPE_ANY is top.
<br>07:35 <wjt> you are my hero :D
<br><br><br>:)
<br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26577187&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26576892Re: GDBus API/usage questions2009-11-30T07:51:42Z2009-11-30T07:51:42ZDavid ZeuthenHey Travis,
<br><br>I've been on vacation the past two weeks so my reply is a bit delayed.
<br><br>On Wed, 2009-11-25 at 11:57 -0800, Travis Reitter wrote:
<div class='shrinkable-quote'><br>> Hi David,
<br>>
<br>> I'm porting e-d-s's libebook from dbus-glib to gdbus and I've run into
<br>> a couple confusing bits of GDBus:
<br>>
<br>> * g_dbus_connection_bus_get() always seems to end in this failure:
<br>>
<br>> GLib-DBus-Standalone:ERROR:gdbusprivate.c:259:connection_setup_add_watch:
<br>> assertion failed: (dbus_watch_get_data (watch) == NULL)
<br>>
<br>> Is this intentional? Should there just be some simple tracking to
<br>> avoid running the setup on the same connection twice? Is it a case of
<br>> the connection being set up upon the original _get() and again when
<br>> creating a proxy for it?
</div><br>Nope, bus_get() just be able to be called multiple times - I think
<br>there's even a test-case for it.
<br><br>> * I've worked around the above problem in my own code by using
<br>> g_dbus_connection_bus_get_private(), but I just bumped into this same
<br>> problem within gdbusproxywatching, just doing something similar to
<br>> example-watch-proxy.c
<br>>
<br>> * How is service activation supposed to work with GDBus? I don't see
<br>> any way to get the DBusConnection for a given GDBusProxy or
<br>> GDBusConnection -- should I just use dbus_bus_get(), or am I missing
<br>> some convenience API?
<br><br>There's some work remaining to be done here - see
<br><br><a href="http://mail.gnome.org/archives/gtk-devel-list/2009-October/msg00075.html" target="_top" rel="nofollow">http://mail.gnome.org/archives/gtk-devel-list/2009-October/msg00075.html</a><br><br>> * I seem to have a race between a service handling daemon exiting
<br>> (which it does a few seconds after all clients disconnect) and a
<br>> client connecting to it (and then failing when it gets a timeout
<br>> calling one of its methods). I assume I need to watch for the proxy
<br>> disappearing (as above), but, like I said, I can't seem to get that to
<br>> work
<br><br>I need to look into that (and add tests for it) - service activation
<br>isn't really tested yet. And APIs like g_bus_own_name() probably needs
<br>to be changed as it is inherently racey (when you register objects in
<br>the name_owned handler it is usually too late).
<br><br>> * When I create a proxy for a D-Bus object that has neither signals
<br>> nor properties, the proxy creation fails unless I pass
<br>> (G_DBUS_PROXY_FLAGS_DO_NOT_LOAD_PROPERTIES |
<br>> G_DBUS_PROXY_FLAGS_DO_NOT_CONNECT_SIGNALS). Is that expected?
<br><br>No, sounds like a bug. We should have tests for this.
<br><div class='shrinkable-quote'><br>> Here's my branch that works (except for that race condition):
<br>>
<br>> <a href="http://git.gnome.org/cgit/evolution-data-server/log/?h=treitter-client-gdbus" target="_top" rel="nofollow">http://git.gnome.org/cgit/evolution-data-server/log/?h=treitter-client-gdbus</a><br>>
<br>> Here's the branch where I'm trying to watch the proxy (and obviously
<br>> doesn't work; it's a direct descendant of the branch above, though I
<br>> accidentally mangled the refs, so it doesn't appear to be):
<br>>
<br>> <a href="http://git.gnome.org/cgit/evolution-data-server/log/?h=treitter-client-gdbus-watch-proxy" target="_top" rel="nofollow">http://git.gnome.org/cgit/evolution-data-server/log/?h=treitter-client-gdbus-watch-proxy</a><br>>
<br>> Am I doing anything obviously wrong in the -watch-proxy branch?
</div><br>I'll look at your branches - hopefully soon depending on what else I
<br>need to work on in December. Thanks a lot for trying this out!
<br><br>Cheers,
<br>David
<br><br><br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26576892&i=0" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>tag:old.nabble.com,2006:post-26574744Re: A few comments on GVariant2009-11-30T05:30:46Z2009-11-30T05:30:46ZMatthias Clasen-2On Mon, Nov 30, 2009 at 7:27 AM, Christian Persch <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26574744&i=0" target="_top" rel="nofollow">chpe@...</a>> wrote:
<br>> Hi;
<br>>
<br>>
<br>> - g_variant_type_matches docs say: "This function defines a bounded
<br>> join-semilattice over GVariantType for which G_VARIANT_TYPE_ANY is
<br>> top."
<br>> If you do want to go into that much detail, there should be a
<br>> more complete definition of how that ... thing ... is constructed :-)
<br><br>I'd just drop that kind of thing; I did study lattice theory and know
<br>what a bounded join-semilattice is, but I doubt this information will
<br>help anybody to use GVariant...
<br>_______________________________________________
<br>gtk-devel-list mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26574744&i=1" target="_top" rel="nofollow">gtk-devel-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br>