Re: GTK+ 2.16.6 released
On Sat, Aug 29, 2009 at 4:47 PM, Matthias Clasen mcla...@redhat.com wrote: GTK+ 2.16.6 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.16/ http://download.gnome.org/sources/gtk+/2.16/ Any chance or problem for the windows binaries on the website/ftp? I'm too used to update my runtime using the binary bundle that Tor usually makes available on the website :) -- Bye, Gabry ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ 2.16.6 released
Any chance or problem for the windows binaries on the website/ftp? Sorry, I had forgotten to upload them. Should be there soonish. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Tristan Van Berkom wrote: On Wed, Sep 9, 2009 at 2:53 AM, Emmanuel Touzeryemmanuel.touz...@free.fr wrote: Hi, [...] You know what I'm thinking... I think that this is from times where people used to build GUIs in the code... When they were writing all the container embedding and all, in C, building their dialogs. At that time that convention surely helped, you were constantly adding widgets to containers and so on. Today this is done in gtkbuilder and so what we have left is code not doing so much embedding in code (though obviously it happens) but Yes I would say its a historical thing, and I certainly hope that using GtkBuilder can be the standard in the end (I guess we still have lots of ground to cover). Only over my dead body ;-) Carlos Cheers, -Tristan Indeed. Not building interfaces manually may save time now and then, but it hinders your understanding of what is happening. For instance when you want to dynamically make interface changes at run time your left with simple hide show tricks. I can remember more than once when I wanted to tweak someone else's UI so as to do something like add a button that breaks out some widgets into a new window or adds some more widget filled h/vboxes in the mix, only to start looking at the code and see no code. Simple things become intrusive. Using helper tools is fine and wonderful, just don't strive for oversimplifying everyone else's world. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
On Thu, Sep 10, 2009 at 2:12 PM, Thomas Stover tho...@wsinnovations.com wrote: [...] Indeed. Not building interfaces manually may save time now and then, but it hinders your understanding of what is happening. For instance when you want to dynamically make interface changes at run time your left with simple hide show tricks. I can remember more than once when I wanted to tweak someone else's UI so as to do something like add a button that breaks out some widgets into a new window or adds some more widget filled h/vboxes in the mix, only to start looking at the code and see no code. Simple things become intrusive. Using helper tools is fine and wonderful, just don't strive for oversimplifying everyone else's world. Im not exactly sure what your trying to say, my understanding is that in the modern world you create widget subclasses when you need composite/dynamic widgets, all widgets are generally layed out in some kind of form, or multiple forms. Thats my understanding of the bleeding edge of the GUI, I think the OSX tools (Xcode/Interface Builder) are a little bit ahead of us on this front ... but not by much, considering that what we can potentially pull off is not restricted to Obj-C or any particular platform. Ofcourse I dont always read the headlines, so I would love to hear what other people think is the bleeding edge to strive for in the world of GUI development, really. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Tristan Van Berkom wrote: Im not exactly sure what your trying to say, my understanding is that in the modern world you create widget subclasses when you need composite/dynamic widgets, all widgets are generally layed out in some kind of form, or multiple forms. Thats my understanding of the bleeding edge of the GUI, I think the OSX tools (Xcode/Interface Builder) are a little bit ahead of us on this front ... but not by much, considering that what we can potentially pull off is not restricted to Obj-C or any particular platform. Ofcourse I dont always read the headlines, so I would love to hear what other people think is the bleeding edge to strive for in the world of GUI development, really. Cheers, -Tristan Well that's pretty much how I see it, but creating new derived widgets is not always the same thing as dynamic interface manipulation. The issue that grabbed my attention more was the notion of always using GtkBuilder. I'm just saying I love the ability create and manipulate an entire interface in code the old fashion way. Being old and crusty (I'm 29), I take pleasure in questioning fashionable, main stream, sacred cow, gratuitously overused, technology. Near the top of that list is anything to do with XML. I miss the more agitated-old-timer-at-the-bar C code or die attitude that once was synonymous with the way I perceived FOSS. So while some articulate clearly of bleeding edge, I'll keep mumbling about often forgotten romantic concepts of yesteryear like fun. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
On Thu, Sep 10, 2009 at 3:24 PM, Thomas Stover tho...@wsinnovations.com wrote: [...] Well that's pretty much how I see it, but creating new derived widgets is not always the same thing as dynamic interface manipulation. The issue that grabbed my attention more was the notion of always using GtkBuilder. I'm just saying I love the ability create and manipulate an entire interface in code the old fashion way. Being old and crusty (I'm 29), I take pleasure in questioning fashionable, main stream, sacred cow, gratuitously overused, technology. Near the top of that list is anything to do with XML. I miss the more agitated-old-timer-at-the-bar C code or die attitude that once was synonymous with the way I perceived FOSS. So while some articulate clearly of bleeding edge, I'll keep mumbling about often forgotten romantic concepts of yesteryear like fun. Gah, I turned 30 this year !!! haha My opinion here is that things change, the code we wrote in the last 10 years can be here to stay, like we dont have to go and write it again. Instead the tasks that used to take time can now be considered script monkey tasks, and the rest of us C code or die hackers can move on to more interesting things that give more leverage to the young and upcoming script monkeys which may one day mature into real hackers ;-) This is my sales pitch to get hackers to help me actually write Glade in C, which I bet is still alot more fun than writing up interfaces using Glade or straight C, ... any takers ;-P Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Tristan Van Berkom wrote: On Thu, Sep 10, 2009 at 3:24 PM, Thomas Stover tho...@wsinnovations.com wrote: [...] Well that's pretty much how I see it, but creating new derived widgets is not always the same thing as dynamic interface manipulation. The issue that grabbed my attention more was the notion of always using GtkBuilder. I'm just saying I love the ability create and manipulate an entire interface in code the old fashion way. Being old and crusty (I'm 29), I take pleasure in questioning fashionable, main stream, sacred cow, gratuitously overused, technology. Near the top of that list is anything to do with XML. I miss the more agitated-old-timer-at-the-bar C code or die attitude that once was synonymous with the way I perceived FOSS. So while some articulate clearly of bleeding edge, I'll keep mumbling about often forgotten romantic concepts of yesteryear like fun. Gah, I turned 30 this year !!! haha My opinion here is that things change, the code we wrote in the last 10 years can be here to stay, like we dont have to go and write it again. Instead the tasks that used to take time can now be considered script monkey tasks, and the rest of us C code or die hackers can move on to more interesting things that give more leverage to the young and upcoming script monkeys which may one day mature into real hackers ;-) This is my sales pitch to get hackers to help me actually write Glade in C, which I bet is still alot more fun than writing up interfaces using Glade or straight C, ... any takers ;-P Cheers, -Tristan ok, I'll drink to that. PyGtk works somewhat towards the same end in my boat. -- www.thomasstover.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Hi, Indeed. Not building interfaces manually may save time now and then, but it hinders your understanding of what is happening. For instance when you want to dynamically make interface changes at run time your left with simple hide show tricks. I can remember more than once when I wanted to tweak someone else's UI so as to do something like add a button that breaks out some widgets into a new window or adds some more widget filled h/vboxes in the mix, only to start looking at the code and see no code. Simple things become intrusive. Using helper tools is fine and wonderful, just don't strive for oversimplifying everyone else's world. My wish of that change was really not about simplifying anything but about having real types in declarations. It startles me that it doesn't seem to bother people much that all the widget variables are declared as GtkWidget*. That is the only reason I would like to change anything. Otherwise I did write GUIs in GTK completely by hand, in GTK1.2, I believe at that time there was no glade at all. And probably it's impossible to write any serious program without having some of that too (in my current for fun project I have 2 widgets that are a combination of existing widgets, for both at this point I generate the GUI by hand). emmanuel ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
Emmanuel Touzery wrote: It startles me that it doesn't seem to bother people much that all the widget variables are declared as GtkWidget*. Well, if you want you can use variables of type GtkWidgetOfTypeX * and type cast on the call of constructor. You have to type cast back to GtkWidget * allot, but I've done that sometimes. At least then more of your mistakes are caught by the compiler instead of g_assert(). Most API functions work in terms of widgets, while only when you need to do widget type specific operations do the derived types come into play. In other object oriented languages perhapses the constructors would return a derived class instance pointer and let the language work out when a base class is compatible or not. Here though, once you have an entire system based around typecasting, you just have to accept the trade offs of no-nonsense vs learning curve we are fortunate enough to have. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Idle Function Not Getting Called
On Wed, 9 Sep 2009 12:23:07 -0400 (EDT) Marshall Lake ml...@mlake.net wrote: I tried G_PRIORITY_HIGH_IDLE with similar results ... the idle function is called only with the following code: g_idle_add_full (G_PRIORITY_HIGH_IDLE, (GSourceFunc) idlefunc, NULL, NULL); while (gtk_events_pending ()) gtk_main_iteration (); If the while loop is not part of the coding then the idle function (idlefunc) is not called. The difference with using G_PRIORITY_HIGH_IDLE is that some of the buttons inside the dialogs drawn in the idle function are not displayed. But they still react to user clicks if clicked in the right area. I expect this is linked to your GDK drawing functions statement above. Then you must have some function blocking between your call to g_idle_add_full() and control returning to the main loop. Anything in a GTK+ signal or event handler must not block. This means in practice that nothing should block after your call to gtk_main(). After spending more time with my code I'm just not seeing it. Below is the pertinent code. AddName() is called from a drop-down menu item. Via debug code I've seen that the program flow is as it should be ... all functions are exited. The first idle function (PlayNetGame()) is added, executed, and exited as it should be. The second idle function (PlayTheGame()) is added but is never called. Does anyone see what might be blocking the call of PlayTheGame() or have any other suggestions? I have not tried to find it in the code, but as your application is multi-threaded you are showing the symptoms of a deadlock, either by recursive locking or more likely by out of order locking. Can you run the code through a deadlock checker, or if not can you by appropriate breakpoints find out if it is occurring in a mutex lock? Although not relevant to your problem I should add to my comment that you should not block after your call to gtk_main(). You can block in a further recursive call to gtk_main() (modal dialogs generally do that) but that is fine as main loop events continue to be serviced. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
