Re: GtkGLExt (was Re: Gtk 3.0)
Thanks Javier, it's good to know that EmmanueleBassi http://live.gnome.org/EmmanueleBassi is now taking care of GtkGLExt integration with GTK... Regards, Carlos Hello Carlos, 2009/12/3 Carlos Pereira jose.carlos.pere...@ist.utl.pt: That's why I asked in the first message of this thread, what are the plans regarding GtkGLExt. To the best of my knowledge, GtkGLExt is still the official way to bridge GTK and OpenGL: http://gtkglext.sourceforge.net/ are there plans to integrate this via Cairo and discard GtkGLExt? that was mentioned in this list years ago... OpenGL integration into GTK+ is part of project Ridley [1]. Here the bug report: [2] The project was recently moved to gnome git too [3] and seems to be quite active. [1] http://live.gnome.org/ProjectRidley [2] https://bugzilla.gnome.org/show_bug.cgi?id=119189 [3] http://mail.gnome.org/archives/gtkglext-list/2009-October/msg5.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
(Sorry, I'm sending this via my phone so it's not going to be nicely formatted; I apologize) I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) cairo should get GPU acceleration for 2D drawing, which is what most of users really care about; 3) if you want a 3D canvas you should be using Clutter. Integrating raw GL inside a gtk+ application is a niche requirement enough that I'm not at all sure it should be moved to gtk+ itself. And if you're dropping into raw GL there is no way you are not a niche use case. On 4 Dec 2009 18:13, Carlos Pereira jose.carlos.pere...@ist.utl.pt wrote: Thanks Javier, it's good to know that EmmanueleBassi http://live.gnome.org/EmmanueleBassi is now taking care of GtkGLExt integration with GTK... Regards, Carlos Hello Carlos, 2009/12/3 Carlos Pereira jose.carlos.pere...@ist.utl.pt: That's w... ___ gtk-app-devel-list mailing list gtk-app-devel-l...@g... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
Hi Emmanuele, I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 1) If you think GtkGlExt should not be integrated with GTK+ that's fine for me. 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... 4) Scientific/engineering applications often use OpenGL, which is a well established, well documented, industry-standard with a large, vibrant community, as these foruns clearly show: http://www.opengl.org/discussion_boards/ So all I am asking the GTK team is, please find a solution regarding OpenGL support for GTK-3.0... with or without GtkGLExt... Regards, Carlos 2) cairo should get GPU acceleration for 2D drawing, which is what most of users really care about; 3) if you want a 3D canvas you should be using Clutter. Integrating raw GL inside a gtk+ application is a niche requirement enough that I'm not at all sure it should be moved to gtk+ itself. And if you're dropping into raw GL there is no way you are not a niche use case. On 4 Dec 2009 18:13, Carlos Pereira jose.carlos.pere...@ist.utl.pt wrote: Thanks Javier, it's good to know that EmmanueleBassi http://live.gnome.org/EmmanueleBassi is now taking care of GtkGLExt integration with GTK... Regards, Carlos Hello Carlos, 2009/12/3 Carlos Pereira jose.carlos.pere...@ist.utl.pt: That's w... ___ gtk-app-devel-list mailing list gtk-app-devel-l...@g... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Should gtk_widget_draw be un-depreicated?
Presently the function gtk_widget_draw is deprecated in favor of gtk_widget_queue_draw. I need the great minds of gtk to think of a way I've missed to accomplish a certain task, or consider un-deprecating gtk_widget_draw. The context is a multi threaded application using gtk. In a thread that is not the main application thread that called gtk_init, a process waits to get the lock calling gtk_threads_enter. Then in a fairly tight loop at high thread priority it calls gtk_image_set_from_pixbuf to display an image, calls gtk_widget_draw, then starts a timer, waits for a process not related to the computer to send a response to the computer in reaction to the image, records a time for the reaction, then repeats the loop using different images. Timing is important and the images can change more than a few times per second. I've tried all sorts of non-deprecated combinations of gtk_widget_queue_draw, gtk_window_flush, gdk_flush, while(gtk_events_pending()) gtk_main_iteration(), etc. Doesn't work. The only answer I can think of to retain the ability to time most accurately, starting the moment that the image has been drawn is to use gtk_widget_draw right after setting the pixbuf. If there is a non-deprecated way to start a timer as soon as an image is known to be drawn without using gtk_widget_draw I'd need to be educated about it. If not I think there is a good argument to not deprecate gtk_widget_draw. Thanks one and all Harry Coin ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GDB error
Hi, I compile Hello world from official GTK tutorial this way: g++ -Wall -g main.cpp -o anc `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` Compilation is successfull and Hello world button program is running. But i have problems with debugging. I had them in Eclipse so I tried in command line with same results (OpenSUSE 64bit). As soon as debugger reach gtk_init() I get error Cannot find new threads: generic error I can add detailed output of my gdb if needed. Thanks! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote: I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 4) Scientific/engineering applications often use OpenGL, Exactly. I've been using GtkGLExt in a scientific app for years and I'm quite happy with it. Cutter does not cut it if you need to visualize scientific data in 3D. Unfortunately, scientific/engineering apps seems to *be* niche use. Look at how hard SourceForge tries to hide this software category even though it contains 50× more projects than VoIP which is promimently displayed... So I hope something like GtkGLExt will continue to be available, whether it's called GtkGLExt or not and is integrated into Gtk+ or not. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: GtkGLExt (was Re: Gtk 3.0)
I've sort of followed this chain sorry if I am rehashing something that has already been covered. IMHO I agree that GtkGLExt should be directly integrated into GTK. Most modern user interfaces (IE OS X (NextStep)) are integrating 3D directly into the windowing system. If I am not mistaken the panel is pure Open GL in OS X, and for sure the iChat multi session video window is pure OGL with reflection maps (they love to tout that). Their development toolset is chalked full of OpenGL examples, and composer... well I won't even go there. GTKGLext does NOT currently work well on OS X interface (even though there is a patch for it, which still needs to be changed to use the NSOpenGLView instead of the NSView but that is whole other story). Open GL is not only the standard scientific toolset, it is the de facto hardware acceleration tool set. I don't know of ANY video card vendor that DOES NOT have OpenGL support. In fact I can not think of any other hardware accelerated tool sets (OGL has been it since the early 90's) it WILL be the interface choice of the future. 2D desktops will quickly give way to 3D widgetry, as hardware acceleration improves even further. Just look at compiz! I've already got users asking me to make the app look more 3D, and it would be great to have the toolset to do so. Even though all were doing is simple EPR stuff. IE If I could create a 3D warehouse map that was navigable by the user to see where they have room to store a product, or look at a product space for a visual cue to order more. This is an old concept Motorola developed about its factories and training workers virtually. Of course, this is all a wish list, I can't demand of the community to do the work I my self have no time for, but it would be really really really supercalifragilisticexpialidocious-ly great to have a fully working OpenGL implementation in GTK for OS X, and if it is dropped for GTK 3.0, I'm afraid it will not serve the community well. I did not quite catch why it was not a good idea. Saying that is like saying it is not a good idea to have the printing subsystem, or input subsystem be exposed in GTK. GTK in essence is an abstraction layer, to hide the differences in interface functionality, giving the user (programer) a singe interface to write agains. Why should we not have the same thing for OpenGL, which is a component of the user interface? Again this is all MHO, and I certainly have not invested a dime in it, so wether it happens or not I will work around it, but it would be nice, very, very nice, to have an GTKOGLWindow in GTK's base library, or at least something like pango/cairo, as a compiler option module. EMAILING FOR THE GREATER GOOD Join me Date: Fri, 4 Dec 2009 22:26:05 +0100 From: y...@physics.muni.cz To: eba...@gmail.com; jose.carlos.pere...@ist.utl.pt Subject: Re: GtkGLExt (was Re: Gtk 3.0) CC: gtk-app-devel-list@gnome.org On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote: I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 4) Scientific/engineering applications often use OpenGL, Exactly. I've been using GtkGLExt in a scientific app for years and I'm quite happy with it. Cutter does not cut it if you need to visualize scientific data in 3D. Unfortunately, scientific/engineering apps seems to *be* niche use. Look at how hard SourceForge tries to hide this software category even though it contains 50× more projects than VoIP which is promimently displayed... So I hope something like GtkGLExt will continue to be available, whether it's called GtkGLExt or not and is integrated into Gtk+ or not. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, 2009-12-04 at 20:51 +, Carlos Pereira wrote: Hi Emmanuele, I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 1) If you think GtkGlExt should not be integrated with GTK+ that's fine for me. 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... I guess that you'll have to patch GtkGLExt, and submit patches for integration upstream. 4) Scientific/engineering applications often use OpenGL, which is a well established, well documented, industry-standard with a large, vibrant community, as these foruns clearly show: http://www.opengl.org/discussion_boards/ I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. people flee from OpenGL in disgust, and it's just OpenGL 3.x that's making some progress towards fixing the insane API that it exposes - unfortunately, no GL implementation provides the 3.x API yet. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. So all I am asking the GTK team is, please find a solution regarding OpenGL support for GTK-3.0... with or without GtkGLExt... GtkGLExt is an external project - the GTK+ team has nothing to do with it. even if (and I'm saying *if*) GTK+ provided GL integration for GdkWindows it would basically boil down to two functions: void gdk_window_gl_begin (GdkWindow *window); void gdk_window_gl_end (GdkWindow *window); plus a way to set up the GL context. that's mostly agreed upon, if you read the bug that Javier linked in his email. that's not even close to the API exposed by GtkGLExt. ciao, Emmanuele. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, 2009-12-04 at 22:26 +0100, David Nečas wrote: On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote: I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 4) Scientific/engineering applications often use OpenGL, Exactly. I've been using GtkGLExt in a scientific app for years and I'm quite happy with it. Cutter does not cut it if you need to visualize scientific data in 3D. clearly, since Clutter is a toolkit aimed at writing User Interfaces. :-) Clutter has a very different scope than raw OpenGL - otherwise we wouldn't even have bothered to write it. it's also one of the non-niche uses of OpenGL, now that the Linux graphics stack is getting more polished and we can actually use OpenGL for writing hardware accelerated user interfaces. ciao, Emmanuele. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
Emmanuele Bassi wrote: On Fri, 2009-12-04 at 20:51 +, Carlos Pereira wrote: Hi Emmanuele, I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 1) If you think GtkGlExt should not be integrated with GTK+ that's fine for me. 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... I guess that you'll have to patch GtkGLExt, and submit patches for integration upstream. We're interested. We're currently planning what might go into the next GtkGLExt release. We probably need to have a discussion about whether there should be another release targeting Gtk+ 2.x. I'll open this up on the gtkglext-list shortly. 4) Scientific/engineering applications often use OpenGL, which is a well established, well documented, industry-standard with a large, vibrant community, as these foruns clearly show: http://www.opengl.org/discussion_boards/ I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. It is a common requirement for apps that want to do 3D rendering with a cross-platform codebase. Biting off Clutter and its dependency chain is not something developers of such an app are likely to want to incur; and Clutter probably won't provide adequate functionality in a lot of cases. people flee from OpenGL in disgust, and it's just OpenGL 3.x that's making some progress towards fixing the insane API that it exposes - unfortunately, no GL implementation provides the 3.x API yet. For a lot of people using OpenGL (or various engines/wrappers like OpenSceneGraph and OGRE), there's no practical alternative to flee to. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. The volume of code currently using Clutter, cairo-gl, and cairo-drm would be dwarfed by that using OpenGL directly. I think your use of the term niche is a little unusual. even if (and I'm saying *if*) GTK+ provided GL integration for GdkWindows it would basically boil down to two functions: void gdk_window_gl_begin (GdkWindow *window); void gdk_window_gl_end (GdkWindow *window); plus a way to set up the GL context. that's mostly agreed upon, if you read the bug that Javier linked in his email. that's not even close to the API exposed by GtkGLExt. This is certainly a conversation that I'm interested in having. We're certainly aware that there's a good deal of chaff in the GtkGLExt API needs culling. On the other hand, what you're describing isn't *that* far from the parts of GtkGLExt that people actually use. (Well, currently the API has users make_current and then do the begin/end stuff at the GL level.) But I'd like to get us a bit farther along in doing that paring down before discussing this in depth. -- Braden McDaniel e-mail: bra...@endoframe.com http://endoframe.com Jabber: bra...@jabber.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, 2009-12-04 at 18:11 -0500, Braden McDaniel wrote: I have the impression that my message is not coming through correctly, because I keep saying the same things. :-) I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. It is a common requirement for apps that want to do 3D rendering with a cross-platform codebase. yes. and that, apart from games and scientific/technical applications, it's not at all common. Biting off Clutter and its dependency chain is not something developers of such an app are likely to want to incur; and Clutter probably won't provide adequate functionality in a lot of cases. which dependency chain? it's the same as gtk+. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. The volume of code currently using Clutter, cairo-gl, and cairo-drm would be dwarfed by that using OpenGL directly. I think your use of the term niche is a little unusual. the amount of code using OpenGL is relatively limited (hence niche) compared to the rest of applications in the GNOME stack (or even in the whole Linux ecosystem); it's *usage* is limited, not the size of the codebase. cairo-drm and cairo-gl are experimental surfaces that have less than 6 months each: it's obvious that the size codebase is limited. Clutter is a new project, compared to OpenGL, and yet *it's* *not* intended to cover the same usage of OpenGL. its intended use covers a canvas for writing applications, not molecule viewers or 3D shooters. that's why GtkGLExt can still be perfectly fine outside of the gtk+ codebase; it provides much more than setting up a GL context, which would be the agreed API for gtk+ to expose, and given the amount of applications actively requiring to drop into GL without any sort of canvas, then it might make sense to keep GtkGLExt exactly as it is. ciao, Emmanuele. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
2009/12/4 Carlos Pereira jose.carlos.pere...@ist.utl.pt: 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... Bug and patch filled upstream for SINGLE_INCLUDES issue: [1] Also, I've found some interesting threads about this topic here [2] (Sept 2003) and here [3] (Jan 2004). There was a initial RFC here: [4], attached in the bug [5] I posted in the previous mail. Regards. [1] https://bugzilla.gnome.org/show_bug.cgi?id=603829 [2] http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00220.html [3] http://mail.gnome.org/archives/gtk-devel-list/2004-January/msg00169.html [4] http://bugzilla-attachments.gnome.org/attachment.cgi?id=22045 [5] https://bugzilla.gnome.org/show_bug.cgi?id=119189 -- Javier Jardón Cabezas ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, Dec 4, 2009 at 8:02 PM, Emmanuele Bassi eba...@gmail.com wrote: (Sorry, I'm sending this via my phone so it's not going to be nicely formatted; I apologize) I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) cairo should get GPU acceleration for 2D drawing, which is what most of users really care about; 3) if you want a 3D canvas you should be using Clutter. If you want to do ACTUAL 3D rendering your choises are OpenGL and OpenGL, Clutter doesn't come anywhere near it. It's true that the API is getting better in 3.0+ but you can still do the same with 2.0+. Also it's a matter of personal taste. At the dawn of time John Carmack chose OpenGL and urged all GPU vendors to make OpenGL drivers because of the horrible DirectX API. Of course DirectX has come a long way since, but if you want any form of cross-platform support your only choice is still OpenGL. Integrating raw GL inside a gtk+ application is a niche requirement enough that I'm not at all sure it should be moved to gtk+ itself. And if you're dropping into raw GL there is no way you are not a niche use case. It may be niche as in not many apps use it, but that hardly makes it any less important. When companies like Autodesk ports ther many many $$$ apps to Linux they don't have the choice of using GTK+ As far as I can tell GTK+ is the only widget API on any PC platform that doesn't have an OpenGL widget/view. Not being able to use advanced 3D visualizations in modern day apps seems rather odd IMNSHO. Regards Jacob Kolding On 4 Dec 2009 18:13, Carlos Pereira jose.carlos.pere...@ist.utl.pt wrote: Thanks Javier, it's good to know that EmmanueleBassi http://live.gnome.org/EmmanueleBassi is now taking care of GtkGLExt integration with GTK... Regards, Carlos Hello Carlos, 2009/12/3 Carlos Pereira jose.carlos.pere...@ist.utl.pt: That's w... ___ gtk-app-devel-list mailing list gtk-app-devel-l...@g... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On 12/05/2009 12:28 AM, Emmanuele Bassi wrote: On Fri, 2009-12-04 at 18:11 -0500, Braden McDaniel wrote: I have the impression that my message is not coming through correctly, because I keep saying the same things. :-) I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. It is a common requirement for apps that want to do 3D rendering with a cross-platform codebase. yes. and that, apart from games and scientific/technical applications, it's not at all common. Biting off Clutter and its dependency chain is not something developers of such an app are likely to want to incur; and Clutter probably won't provide adequate functionality in a lot of cases. which dependency chain? it's the same as gtk+. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. The volume of code currently using Clutter, cairo-gl, and cairo-drm would be dwarfed by that using OpenGL directly. I think your use of the term niche is a little unusual. Agreed. the amount of code using OpenGL is relatively limited Correct - Now ask yourself why. IMO, the causes historically have been and are: - Lack of usable drivers, esp. on Linux. - Demands on CPU-powers (10 years ago, even simple wire-frame graphics were a CPU challenge on Linux). - For most desktop applications 2D is sufficient, even less need advanced 3D. Historically, these reasons were both causes for GUI-toolsets (such as Gnome) to favor other toolset libs on their low levels in favor of other toolset libs. The situation would be entirely different today, if Linux had performant OpenGL drivers and if GUI toolchains would have based their graphics works directly on OpenGL (or any other performant, low level 3D graphics API). Clutter is a new project, compared to OpenGL, and yet *it's* *not* intended to cover the same usage of OpenGL. its intended use covers a canvas for writing applications, not molecule viewers or 3D shooters. Future will tell if this isn't much more than yet another 3D library amongst those many already existing ones ;) that's why GtkGLExt can still be perfectly fine outside of the gtk+ codebase; it provides much more than setting up a GL context, which would be the agreed API for gtk+ to expose, and given the amount of applications actively requiring to drop into GL without any sort of canvas, then it might make sense to keep GtkGLExt exactly as it is. Agreed. Besides fixing bugs and reflecting Gtk API changes to it, I don't see much reasons for changing anything. Ralf ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
