RE: GTK and OSX: a call to sanity
EmmanuelYour an ass (as in donkey) But don't be offended by my tone, I only say this because I care about what happens the the OS X version of GTK. John has been working his tail off, all the while responding to dump developers like me, while I can't get a tweet out of an elites like you. I'm sick of your crap man! I was one of the people on this list who pushed to get John what little rights he does have, and like one post said, if you ACTUALLY cared, you would be making good positive suggestions, not ripping into the ONE person who actually has taken a vested interest in fulfilling, what the website touts as already there. When I first started down this path, the website claimed OS X, but when I got working everything was in taters, and if it had not been for John's tireless efforts, your claim on the website that the product works on OS X would be an outright lie! When I finally downloaded the source, it was full of NEEDS TO BE IMPLEMENTED all over it, and if I had a smidgen of skill I would be helping John. So take a cold shower, and if you have any decency you would issue John a formal apology on this list. But I doubt you will. Date: Wed, 7 Sep 2011 08:25:24 +0100 From: eba...@gmail.com To: p...@linuxaudiosystems.com Subject: Re: GTK and OSX: a call to sanity CC: gtk-devel-list@gnome.org hi Paul; On 2011-09-06 at 18:18, Paul Davis wrote: On Tue, Sep 6, 2011 at 6:07 PM, Emmanuele Bassi eba...@gmail.com wrote: otherwise you're just forking gtk, and using the resources of the gtk project to give an aura of officiality to what is essentially your own personal project. I'd politely request that you stop using this tone in connection with this issue. I am a gtk contributor and I want to start helping with the OSX backend because I got a new MBP and I'm working on gtk and clutter and I want them both to work on my brand new machine. the first thing I noticed when I wanted to build my applications was that I had to go on a website that has nothing to do with gtk.org, download a jhbuild moduleset from a location that is not on gnome.org, follow a mailing list that is not on gnome.org and file bugs on a bug tracking system that is not on gnome.org now, tell me: what does it look like to you? to me, and not just to me, it looks like a fork. John says it isn't, and I believe him; so I want to fix the situation where it looks like one. I read bugzilla emails for gtk (I know: shocker) and people file bugs against the moduleset and the build on bugzilla.gnome.org; John has to direct them to a separate bugzilla and to a separate mailing list. I want to fix this. Windows and Linux build issues and support are handled on gnome.org: the Quartz backend of gtk is not in any regard special and it should not need separate resources. There has always been a level of antagonism between developers working on GTK for OS X and the core development team. It rises and falls, and at present, things are generally in remarkably good shape, where most of what is required to get a fully functional GTK for OS X is right there in the tarball releases. and if you try to actually contribute, that's where the bubble bursts. But when you start ripping into one of the only people willing to actually step up and take any responsibility for the issues faced by those of us that actually want to use GTK+ as a cross-platform development toolkit where the platforms include OS X, its remarkably scary. Other people have walked away from the effort because of the perception of the core GTK guys just don't give a shit, and it doesn't help in any way that you take such an argumentative tone with john. that's the problem: I *am* a core gtk guy, and I *give* a shit. Mitch is a core gtk guy and he gives a shit. Kris is a core gtk guy and he gives a shit. you already have three. aside from the backend development and the toolkit development, what I give a shit about is also the marketing of said toolkit; from a marketing perspective, this whole divide is terrible and it has to be rectified. we're already getting pummeled by people thinking that other toolkits with better marketing are superior — let's not give them other ammunition. I also give a shit about the use vs. them attitude: if the gtk-osx project is handled like its own thing, in its own ghetto, then it won't make it any easier to get traction inside the team. attending IRC team meetings, discussing new features directly during the design phase, coming to hackfests and to GUADEC: that's what maintainers do. So please could you tone it down a bit, and rather than excoriate John for whatever you perceive his mistakes or whatever to be, focus on helpful suggestions. I apologize for the tone: I am *very* frustrated by this situation. now, I suggested how to improve the situation in the email as well. I talk as both a member of the gtk
RE: pixbuf-cairo_surface_t conversion
Sorry this may be a very inept question: How will this effect integration with OpenGL. I know we use a lot of get/sets on pixels buffers; off screen rendering, textured (especial animated) and tricks. You want and need that raw data access. taking it way I think would also break GTKGLExt if I am not mistaken? As I have come to understand, most GL windows have a completely different context than the windowing system itself. Is cairo going to play nice? I mean with this: http://www.opengl.org/sdk/docs/man4/xhtml/glReadPixels.xml and this: http://www.songho.ca/opengl/gl_pbo.html Date: Fri, 3 Sep 2010 09:52:22 -0400 Subject: Re: pixbuf-cairo_surface_t conversion From: matthias.cla...@gmail.com To: sandm...@daimi.au.dk CC: gtk-devel-list@gnome.org; h...@pobox.com On Fri, Sep 3, 2010 at 3:22 AM, Soeren Sandmann sandm...@daimi.au.dk wrote: Not that it matters that much, but if you use cairo_mask() with the pixbuf data as both source and mask, the source as RGB24 and the mask as ARGB32, you could make cairo do the conversion from pixbuf to surface. That would likely hit an SSE2 or ARM NEON optimized code path in pixman. Interesting. But how would that deal with the fixed-endianness of pixbuf data vs the native endianness of cairo ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Gtk-OSX
You tell'm John I think the key point here is: The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The GTK+ site clearly advertises the product as a cross-platform toolkit. http://www.gtk.org/features.html OS X is listed as one of three platforms. I have said this before and I will say it again, every time a thread like this comes up. There should be a table with (fully supported, % complete, or not function) per platform, right on the features page. So saps like me don't go believing Santa Claus is going to shoot down my chimney with a Red Ryder BB Gun. :) From: jra...@ceridwen.us Subject: Re: Gtk-OSX Date: Tue, 31 Aug 2010 09:56:12 -0700 To: mar...@lanedo.com CC: gtk-devel-list@gnome.org On Aug 31, 2010, at 6:56 AM, Martyn Russell wrote: On 27/08/10 17:48, Matthias Clasen wrote: As long as the people working on GTK-OSX do it with a us-vs-them attitude (like you display here by talking about the GTK developers in third person), things are not going to change. If you start considering yourself part of the team and actively engage, things can and will change. After reading the thread, I have a few thoughts on the matter. 1. I agree with Matthias, I did get the feeling there is an us vs them in the thread. 2. Equally I agree, when something new comes along, Win32/OSX are often an after thought (that's just my perception). I have spent time building packages for proprietary apps to run on Windows in the past and I know how this can be disconcerting. BUT, GTK+ is targeted mostly with X11 in mind we should not forget that. X11 has the larger use base. I think that people that maintain backends really need to get involved more in meetings, planning, designing, etc if they want to change either of the above issues. About having ONE sanctioned package (for Windows or MAC) I think Yes, we should be doing that, as an app developer before I was more involved in the community, there was no right this is the distributed package we should be using, I had to download it myself and build it myself. Why not channel the work used to make the Pidgin/GIMP downloads with GTK+ into a useful package hosted on gtk.org? Ultimately, having GTK+ packaged *with* each app also has its benefits, like stability on Windows when others GTK+ versions exist/get upgraded for GIMP/Pidgin/etc. Additionally, one of the MAJOR features we boasted when selling our apps was that we could guarantee it worked on ALL versions of Windows (though that later changed) without needing to download .NET for that version of Windows or because something got deprecated. About having Mac on the gtk.org site, I think this does make sense. As a *user* of GTK+ porting my app to these operating systems, I don't have confidence in GTK+ when a port of it is hosted off site. I haven't checked, but I am pretty sure QT doesn't do this. Generally, we should be presenting a more united front for application developers looking to invest time in GTK+. Perhaps this is where we should be focusing some of the GNOME foundation's money if resources are short? Qt is a bit of a strawman: Its sole reason for existing is to provide a cross-platform toolkit. It's also a commercial product, maintained by a huge corporation; it would indeed be strange if some of its functionality were developed outside. WxWidgets might be a better comparison, except that it, too, is solely a cross-platform toolkit. AFAIK, Qt doesn't ship a feature until it's working on all supported OSes. OTOH, they also don't let outsiders see their VCS repos. Wx strives for the same ploicy, but being a volunteer project doesn't always make the goal. They've been struggling for a couple of years with switching their primary Mac port from Carbon to Cocoa. None of which has much of anything to do with Gtk+: As is abundantly clear from this thread, Gtk+ is primarily a backend for the Gnome desktop on Linux, which happens to support most of its basic features on Win32 and Quartz. The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The warnings on the Gtk-OSX website that have sparked this long and vituperative thread merely point out to developers that if they want to write an application that they can distribute to the majority platforms (sorry, that most certainly does *not* include X11) should look elsewhere. I don't know why Gtk-OSX isn't on Gnome.org. (Gtk.org is just a PR website; all of the development resources are provided by Gnome.org.) The project was originated by Richard Hult, who had AFAICT full privs on Gnome for project creation both in VCS and on Bugzilla, but he chose to use Github for VCS and to
RE: Gtk-OSX
1) The code does contain a fair amount of FIXME comments. Note that a couple of those are for either deprecated functionality (that will be removed in the future and is only really needed by legacy applications) or for things that are very X11-specific and will not work natively on the Mac. -- http://live.gnome.org/GTK%2B/OSX Now that statement IMVHO, the following statement is misleading at best : Originally GTK+ was developed for X Windows but it has grown over the years to include backend support for other well known windowing systems. Today you can use GTK+ on: GNU/Linux and UnixWindowsMac OS X--http://www.gtk.org/features.html In the fullness of truth you would put an little asterisk next to the Mac OS X in that list, IN RED, telling people to read the caveat in the first part. Why? Simple, we started on Linux, and migrated to OS X with the idea that we could, the number of issues that I have run into, are far greater than what I would consider a complete product on OS X (or toolkit, if we are playing semantic games). There was a time when the website clearly stated that this was RAW and in Development, but most of those warnings have gone the way of the ghost, and chiding John R for warning people that there are serious issues, and a really task to get this all going on OS X should NOT be considered a us vs. them attitude. It is a we would like to counted too attitude. If there is funding being put into developing GTK, and that funding is with the idea that this is NOT just a Linux GUI, but a fully crossplatformable one, that those resourses spending time on coding, should be held accountable for breaking things, or pushing forward the development of a single platform, at the cost of others. Unfortunately, there is a BIG difference between a toolkit that works, in the most minimum sense of the world, and a toolkit that provide a complete set of widgets to get a job done. 2) Writing that table, agreed. I should stop talking about it and do it. I wish I knew how. As re-focus on the GTK part of our app I'll see if I can put something together. as a point: bash-3.2$ pwd /Users/shawn/gtk/source/gtk+-2.18.2/gdk bash-3.2$ cd win32/ bash-3.2$ grep -R FIXME * | wc -l 16 bash-3.2$ cd ../x11/ bash-3.2$ grep -R FIXME * | wc -l 15 bash-3.2$ cd ../quartz/ bash-3.2$ grep -R FIXME * | wc -l 125 We have 10 times more fixes to make to the just the gdk backend compared to windows or X11, So when you ask Is anything of what I said false at all? If that's the case, how is it untrue? No non of it is false, but it is also not the truth, the full truth. Which seems to be the way of things these days, as long is it is not false, than it must be true, and that simply is not the case, unless you are a computer. The website gives a false impression, that it does. Date: Wed, 1 Sep 2010 18:17:07 +0100 Subject: Re: Gtk-OSX From: ar...@gnome.org To: shashan...@hotmail.com CC: gtk-devel-list@gnome.org Hello Shawn, 2010/9/1 Shawn Bakhtiar shashan...@hotmail.com: You tell'm John I think the key point here is: The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The GTK+ site clearly advertises the product as a cross-platform toolkit. http://www.gtk.org/features.html Product? This is a project not a product. And it is cross platform. You _can_ run it on Windows, you can run it on Mac OS X, you can run it on Intel hardware, ARM hardware, SPARC, you can run it on Linux, Solaris, FreeBSD. Is anything of what I said false at all? If that's the case, how is it untrue? OS X is listed as one of three platforms. I have said this before and I will say it again, every time a thread like this comes up. There should be a table with (fully supported, % complete, or not function) per platform, right on the features page. So saps like me don't go believing Santa Claus is going to shoot down my chimney with a Red Ryder BB Gun. :) Maybe, instead of saying it again and again, you should come up with that table, you should actually write that web page? From: jra...@ceridwen.us Subject: Re: Gtk-OSX Date: Tue, 31 Aug 2010 09:56:12 -0700 To: mar...@lanedo.com CC: gtk-devel-list@gnome.org On Aug 31, 2010, at 6:56 AM, Martyn Russell wrote: On 27/08/10 17:48, Matthias Clasen wrote: As long as the people working on GTK-OSX do it with a us-vs-them attitude (like you display here by talking about the GTK developers in third person), things are not going to change. If you start considering yourself part of the team and actively engage, things can and will change. After reading the thread, I have a few thoughts on the matter. 1. I agree with Matthias, I did get the feeling there is an us vs them in the thread. 2. Equally I agree, when something
RE: Gtk-OSX (was: Website proposal for usability)
I am just a humble user of GTK, I have yet to develop the skills to contribute, but half way through the development of our app, we moved to OS X, from linux. Reason: Faster, better looking interface, much better looking chassis. You tell'm John, and thanks for all the hard work to you and Kris. I was using GTK on Linux, because there is nothing else. really. I have mentioned this before, GTK is a linux GUI, with SOME cross platform abilities (not for the faint of heart). It only looks good native on Linux, because it is designed to be used with GNOME. It does not look good on Windows or OS X. I have sat days with users, applying all kinds of themes (half of which don't work), only to get the same block-ish look, on Windows and OS X. There is a HUGE gap, between what is being touted on GTK's website, versus reality. GTK+, or the GIMP Toolkit, is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. http://eboyjr.homelinux.org:8081/ The only platform that has a complete implementation is Linux. Windows has a lot of issues, and in OS X most of the imp are TODO TODO TODO. Without the help of GTK-OSX, I don't even know where I would be! So I would certainly be supporting the work, not chiding them for telling the truth. If the point is indeed to be multi-platform offering a complete set of widgets, I would certainly be spending a great deal of effort looking at Quartz and some of the functionality it touts, and applying them backwardly to windowing systems that don't. I would also spend a good amount of time on another project that needs to be brought into the fold. GTKGLExt. Most of the OS X interface uses OpenGL now. I would also make sure to point user to some place where they can quickly see a chart of widgets and functions, and what platforms they are complete, in progress, or TODO. This way, (as the archives will show) hapless programmers like me, will not leap to far before they get the truth. WidgetOS X WindowsLinux GtkWindow60%99% 100% GtkButton ... ... Date: Fri, 27 Aug 2010 10:46:55 +0200 Subject: Re: Gtk-OSX (was: Website proposal for usability) From: k...@gtk.org To: jra...@ceridwen.us CC: gtk-devel-list@gnome.org; cottr...@wfu.edu On Fri, Aug 27, 2010 at 6:35 AM, John Ralls jra...@ceridwen.us wrote: I don't know how many people share these views, but if I'm not totally out on a limb I would be willing to draft a page along the lines I'm talking about (recruiting help from those who are more knowledgeable). I'd also be willing to try making a runtime package if I can get some time on OS X -- though I suspect others are better qualified than I for that job. The R guys have some packages at http://r.research.att.com/libs/ and maybe one of them would be willing to do an official build. For a GTK+ runtime package (GTK+ Framework), I think you should check out what has been done in the past. It is by no means an easy task. The latest code and instructions for this are at the GTK-OSX website if I am not mistaken. You might not like the warnings about the quality of Gtk+ Quartz, but when I wrote them a year ago, no one had touched the quartz backend for 8 months. Since then, one developer (Kristian Reitveld) has fixed many of the outstanding bugs, and some of the other Gtk devs have become a lot more receptive to minor patches... but the general attitude remains that it's OK to implement (or rewrite) features in Linux, and if it breaks Win32 and Quartz, oh well. There's a list of features that aren't yet implemented, or aren't implemented completely, at http://live.gnome.org/GTK%2B/OSX/. I would say the quality has been slowly increasing, though there's enough left to do. I do try to track the latest developments in GTK+ master and adapt the Quartz backend wherever necessary so it does not break. This is also pretty time consuming, but did result in a Quartz backend that continued to work when the XI2 and rendering-cleanup branches where merged into the master branch. There's some more backend work planned I think, that will hopefully affect the Quartz backend to a lesser extent. In the meantime I will continue with reviewing patches/implementing missing features to end up with a feature-complete backend some day :) regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: How to change color of GtkCellRendererProgress ?
Sorry this is a bad answer. Of course you can do this!! and that is no reason not to use GTK. You can use the themes, or if you need individual progress bars to be different colors, you can easily derive a GtkCellRenderProgressFooBar class from the GtkCellRendererProgress, which does this, and if it is useful enough, maybe the rest of us will use it in our app, and submit it for inclusion. I'm surprised it is not in the default functionality, but there are a lot of ways you can do this. From: kcc1...@gmail.com Date: Mon, 2 Aug 2010 10:21:31 +0800 Subject: Re: How to change color of GtkCellRendererProgress ? To: jardas...@gmail.com CC: gtk-app-devel-list@gnome.org On Mon, Aug 2, 2010 at 2:46 AM, Jaroslav Šmíd jardas...@gmail.com wrote: You can't. The only way to change this is to modify theme you use. That's bad news to me. I were planned to use it for a simple histogram application but color is required feature ... Thanks anyway. Regards KC On Sat, Jul 31, 2010 at 6:33 AM, Kuang-Chun Cheng kcch...@linuxdaq-labs.com wrote: Hi, As subject said, how to change color of GtkCellRendererProgress ? Either color of text or bar is OK. This looks like a simple question, but I can't find anything from Google yet. Thanks a lot. Regards, KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Jaroslav Šmíd ___ 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 ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: GDK_NATIVE_WINDOWS not working under Windows
I think what he is saying is that GTK can not do it, using Windows, and last I experienced it can not do it on OS X either. In fact it fails in almost the exact same way you wrote (the GL window takes over the entire top level). This indeed may very well be due to the problems you mentioned, mainly that GTK only use native windows at the top level, and does not use ei a native button (but instead relies on its own implementation of a button). If this is the case, and given that 3D widgetry is becoming more and more prominent in user requests. I think your point, and bug, should be given some priority. To be fare, GLExt is not part of GTK, but it should be. ALL major platforms are using GL to do more and more desktop rendering and IMHO GTK should have a native support at the drawable level. In reading some of the documentation on how Quartz NSOpenGLView is implemented, there is definitely something special about a GL window. I believe it has to do with the GPU needed direct access to the memory, and the ability of modern windowing systems to have multiple rendering pipelines that merge on screen. For example: The OpenGL specification does not provide a windowing layer of its own. It relies on functions defined by Mac OS X to integrate OpenGL drawing with the windowing system. Your application creates a Mac OS X OpenGL rendering context and attaches a rendering target to it (known as a drawable object). The rendering context manages OpenGL state changes and objects created by calls to the OpenGL API. The drawable object is the final destination for OpenGL drawing commands and is typically associated with a Cocoa window or view. -- http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html In fact in OS X has NSOpenGLView (which is derived from NSView) which transparently takes care of this functionality (as GTKGLExt is suppose to do). But in playing around with drawing OpenGL off and on screen, trying to create a transparent / borderless 3d object on screen, there are marked differences between the two object. For example, you can NOT have a transparent NSOpenGLView, you have to draw off-screen, and copy with transparency set to the background color of the off-screen buffer. This clearly shows that the GLView is different than a standard NSView. That is you can set the transparency for an NSView window and draw to have only what you draw appear, in an NSOpenGLview the background is always cleared to black (it does not have access to the screen buffer). I know this does not solve the problem but perhaps it will light some fires :) Date: Mon, 2 Aug 2010 16:31:58 +0100 Subject: Re: GDK_NATIVE_WINDOWS not working under Windows From: michael.goffi...@gmail.com To: eba...@gmail.com CC: gtk-devel-list@gnome.org On Mon, Aug 2, 2010 at 3:51 PM, Emmanuele Bassi eba...@gmail.com wrote: ... specifically: no, it's not possible in Window. Are you sure about that? Quick trials with PyQt4 under Windows show no problem in having regular widgets on top of the OpenGL widget. this is not a Qt development list, though; so, as hint for the future don't try to compare functionality. :-) I was just commenting your statement that it's not possible under Windows. What I'm trying to achieve *is* possible, because Qt can do it. I'm trying to figure out a way to achieve it with GTK+-2.16 (it seems I'm stuck at that version for OpenGL support under Windows). I think GtkGLExt allows placing gtk+ widgets on top of the GL drawing surface; at least, I'm pretty sure I've seen that happen. I'll give it another try. I'd just love to see a working example :-) Michael; ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why is GCompletion deprecated
From and outsiders perspective I too would absolutely LOVE this feature. Not just in GTK, but in OS X as well. the OS X NSSearchField however (to my shock!) does not implement this functionality either. Apple has exposed this in the NSTextView (with spell check et al...) which is akin to GTKTextView. I suppose one could create a single line text view. In any case it seems like this would be a GREAT end user tool to be included in an application. I am surprised to read there is not that much use of it. As for the word deprecated (http://en.wikipedia.org/wiki/Deprecated) when I see this word anywhere it makes me RUN. I know that sooner or later that feature is NOT going to be there no matter how much I want it to be. So I can certainly (as a user of the library) understand why one would assume that deprecated also means DON'T work on it any more. I try to choose long lived objects, could it be that its use has been limited by placing a status of deprecated on it? My users are constantly looking up customer information. I want to give the CEO a tool by which he can pull up snapshots of customers by simply put in a word like color in the text field, and have all possible customers with that word color in their name appear. This seems to me like a must have for people at his level as they have 0 typing skills, and do not know any of the customer account numbers, and since 99% of all business do deal with some number of customers, and invariably have CEO who still pigeon pick at the keyboard, this type of functionality is not just useful, but gets us big pats on the back. At the end of the day, I can certainly do it programmaticly, but is the point of a library NOT to have to app developers re-writing the same type of code? Of course this is beyond what is offered on the base platforms themselves. Thanks for reading my rant, Shawn Subject: Re: Why is GCompletion deprecated From: eba...@gmail.com To: gtk-devel-list@gnome.org Date: Mon, 28 Jun 2010 17:59:47 +0100 On Mon, 2010-06-28 at 18:43 +0200, Christian Dywan wrote: and, again, there is this false impression that deprecation is akin to removal. [...] you can either #undef G_DISABLE_DEPRECATED for the files that use these particular data structures, or copy gcompletion.[ch] in your project; since these files haven't been really changed in a while, the maintenance burden for projects is not heavy. One has to wonder where this false impression is coming from. Is it by any chance because there are loads of bugs and wiki pages about using G_DISABLE_FOOBAR and not relying on deprecated code? it's a maintainer's choice to make your application rely on deprecated code; all the bugs and wiki pages in the world are there in an informational capacity only: I cannot get on your repository and just rip code out of your application. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: New widget proposal: GtkLiveSearch
Cocoa AppKit (OS X) has a controller object called NSSearchField, sounds very much the same. Perhaps a similar concept could be implemented? I agree that I would like to be able to control the actual equality used for search and / or sort. http://developer.apple.com/mac/library/documentation/cocoa/reference/ApplicationKit/Classes/NSSearchField_Class/Reference/Reference.html Subject: Re: New widget proposal: GtkLiveSearch From: csaave...@gnome.org To: gtk-devel-list@gnome.org Date: Mon, 14 Jun 2010 14:23:18 +0300 On Mon, 2010-06-14 at 10:27 +0200, Christian Dywan wrote: I would suggest if somebody has a non-tree view use case it makes a lot more sense to consider it. Also to confirm that it actually is convenient to use with other widgets. It is quite convenient to use it, for instance, with a GtkIconView. Look at the mediaplayer in the N900 for a use case. Claudio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: [Gtk-osx-users] Print dialog hangs for several seconds before activating
Thanks Guys! This looks like it solved my problem. I had to apply the patch manually (GTK 2.18 on OS X 10.6.3 using jhbuild). No more hangs in the print dialog... my users will be singing your blessing. So the patch works, and from the bug it is has already been committed since 2.22. If it works, don't add more layers. Shawn Date: Thu, 10 Jun 2010 10:11:41 +0200 From: four...@gmail.com To: gtk-devel-list@gnome.org; gtk-osx-us...@lists.sourceforge.net CC: david...@mit.edu; al...@redhat.com Subject: Re: [Gtk-osx-users] Print dialog hangs for several seconds before activating On Thu, Jun 10, 2010 at 9:38 AM, Alexander Larsson al...@redhat.com wrote: On Wed, 2010-06-09 at 20:20 -0400, David A Benjamin wrote: I've run into this issue (and have been poking at it recently). The core problem appears to be that, although GTK+ is using CUPS and setting things like httpBlocking off, the CUPS non-blocking API isn't. See conversations with CUPS developers at [1,2,3]. Yeah, it seems like threads are the way to go. Dunno if this is related, but there is also bug 614581 that may help as well: https://bugzilla.gnome.org/show_bug.cgi?id=614581 which was committed as http://git.gnome.org/browse/gtk+/commit/?id=33097d65 HTH, Olivier. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Gtk-osx-users mailing list gtk-osx-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-osx-users _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Print dialog hangs for several seconds before activating
For some reason the Print dialog hangs for several seconds before fully activating. During this period I am unable to push any buttons and on my OS X 10.6.3, I get the little color wheel. After a few seconds, The dialog pops bigger, with several added tabs show up at the top (printer info). jhbuild info Name: gtk-i386 Module Set: gtk-osx-universal Type: autogen Install-date: not installed URL: http://ftp.gnome.org/gtk+/2.16/gtk+-2.18.2.tar.bz2 Version: 2.18.2 Tree-ID: 2.18.2-d41d8cd98f00b204e9800998ecf8427e Required-by: meta-gtk-universal Name: glib Module Set: gtk-osx Type: autogen Install-date: 2010-03-22 16:31:17 URL: http://ftp.gnome.org/pub/GNOME/sources/glib/2.22/glib-2.22.2.tar.bz2 Version: 2.22.2 Tree-ID: 2.22.2-d41d8cd98f00b204e9800998ecf8427e Required-by: glibmm, gnome-mime-data, pango, enchant, shared-mime-info, libsoup, atk After: meta-gtk-osx-bootstrap, gtk-doc Before: loudmouth, gstreamer . According to google, there seems to be a bug everyone is working arround, I have as of yet to implement correctly on my machine. https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/475845 https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/475845/comments/29 https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/359975 http://serverfault.com/questions/104935/authinforequired-cups-overwrites Has anyone run into this problem, and is there a fix I am not aware of? Thanks in advance, Shawn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Multi-platform dbus (was: Ige-mac-integration: New version with Cocoa interface available)
Sorry for my naivete
But I have been building some of our application tool sets in native Cocoa (the
printing industry is exclusively MAC, with little room for anything else).
The question being, in the standard Cocoa application framework you never
actually derive the NSApplication class, but instead you derive the
NSApplicationDelegate. Would this not be more appropriate for this discussion.
It receive all the signals for each interface object whos IBoutlet is set to
this class, and all the functionality for the toolbar, menu, etc, is exposed in
it.
IE this class actually receives the signal for the NSSearchField object, and
process it. So should GTKApplication.c not really be GTKApplicationDelegate.c,
or perhaps both.
Last I recall of the MFC, there was something similar where you had a
CCmdTarget which did a lot of what I guess GTKApplication.C is todo, but seems
more inline with NSApplicationDelegate than NSApplication.
I've noticed a lot of stuff like GTKTreeView implement its own displays, why is
it not derived from NSTableView using NSDataSource for GTKTreeStore and
GTKListStore? Or is the point to also make it all look alike?
-- MY APP DELIGATIONS
@interface isiod2AppDelegate : NSObject NSApplicationDelegate {
/*Views */
NSWindow *window;
AnalyzerView *view;
SimpleCView *scView;
/* Fields */
NSSearchField *searchField;
NSTextField *startDate;
NSTextField * endDate;
/* Tables */
NSTableView *shippingTable;
NSTableView *receivingTable;
NSTableView *batchesTable;
NSTableView *usageTable;
/* Data sources */
isilistDataSource *shippingDS;
isilistDataSource *receivingDS;
isilistDataSource *batchesDS;
isilistDataSource *usageDS;
/* Internal objects */
IsiComponent *component;
IsiDatabase *db;
}
/* Views */
@property (assign) IBOutlet NSWindow *window;
@property (assign) IBOutlet AnalyzerView *view;
@property (assign) IBOutlet SimpleCView *scView;
/* Fields */
@property (assign) IBOutlet NSSearchField *searchField;
@property (assign) IBOutlet NSTextField * startDate;
@property (assign) IBOutlet NSTextField * endDate;
/* Tables */
@property (assign) IBOutlet NSTableView *shippingTable;
@property (assign) IBOutlet NSTableView *receivingTable;
@property (assign) IBOutlet NSTableView *batchesTable;
@property (assign) IBOutlet NSTableView *usageTable;
/* Actions */
- (IBAction)filterSearch:(id)sender;
@end
Subject: Re: Multi-platform dbus (was: Ige-mac-integration: New version with
Cocoa interface available)
From: jra...@ceridwen.us
Date: Tue, 18 May 2010 14:10:22 -0700
To: p...@linuxaudiosystems.com
CC: gtk-devel-l...@gnome.org
On May 18, 2010, at 1:36 PM, Paul Davis wrote:
On Tue, May 18, 2010 at 4:12 PM, John Ralls jra...@ceridwen.us wrote:
Sure. But dbus provides services which are provided by notifications and
AppleEvents on OSX. If a supposedly cross-platform application supports
only the dbus way, it turns out to be pretty autistic on OSX. I don't think
that it's all that common for OSX users (aside from the few Fink and
MacPorts users who are trying to replicate an entire Linux environement) to
run more than one or two dbus-using apps, and they aren't able to
communicate with other OSX application or OSX itself unless those channels
are separately implemented.
So maybe g_dbus isn't the right place for the abstraction layer; it could
be one of the implementation layers.
i think that is precisely what is being proposed:
GApplication/GtkApplication as the abstaction that covers notifications
etc, and an implementation for a given platform. the linux/X11/FD.org one
would use DBus. apps that choose to use DBus directly will be assumed to
want something specific that DBus offers, and not a generic
platform-agnostic application abstraction.
OK.
I don't think that GApplication is a good name for it, though. The fact that
some notifications (became active, quit, etc.) are directed at the
application object doesn't mean that all of them should be.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-l...@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
_
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: different data types between clist and mysql.
Ran into same problem.
I use a structure like
_IsiField {
int type,
int pos,
int
}
Then create my own list with
_IsiList {
GList Fields;
GList rows;
}
Every time retrieve a set of values, I have a routing which sets type to a
G_TYPE, which corresponds to the MYSQL_TYPE
Here is what I do:
GList *
isi_database_fetch_fields(IsiDatabase *self)
{
MYSQL_FIELD *field;
IsiFields *l;
GList *gl = NULL;
guint column = 0;
/* Sanity Check */
g_return_val_if_fail(self != NULL, NULL);
g_return_val_if_fail(self-priv != NULL, NULL);
g_return_val_if_fail(self-priv-dispose_has_run != TRUE, NULL);
g_return_val_if_fail(self-priv-res != NULL, NULL);
/* Rewind the feild set */
mysql_field_seek(self-priv-res,0L);
while((field = mysql_fetch_field(self-priv-res)))
{
/* Initialize a new IsiFields structure */
//l = (IsiFields*) g_new0(IsiFields, 1);
l = g_new0(IsiFields, 1);
/* Set the values */
l-alias = g_strdup(field-name);
l-name = g_strdup(field-org_name);
l-length = field-length;
/* always make fields visable */
l-hidden = FALSE;
l-sortable = FALSE;
l-pos = column++;
switch (field-type){
/* Integer types */
case MYSQL_TYPE_TINY:
case MYSQL_TYPE_SHORT:
case MYSQL_TYPE_INT24:
/* Check for signage */
if (field-flags UNSIGNED_FLAG)
l-type = G_TYPE_UINT;
else
l-type = G_TYPE_INT;
break;
/* Long types */
case MYSQL_TYPE_LONG:
case MYSQL_TYPE_LONGLONG:
/* Check for signage */
if (field-flags UNSIGNED_FLAG)
l-type = G_TYPE_ULONG;
else
l-type = G_TYPE_LONG;
break;
/* Decimal types */
case MYSQL_TYPE_DECIMAL:
case MYSQL_TYPE_NEWDECIMAL:
case MYSQL_TYPE_FLOAT:
case MYSQL_TYPE_DOUBLE:
l-type = G_TYPE_DOUBLE;
break;
/* Bit types */
case MYSQL_TYPE_BIT:
l-type = G_TYPE_BOOLEAN;
break;
/* ENUM types */
case MYSQL_TYPE_ENUM:
l-type = G_TYPE_ENUM;
break;
/* All other types */
default:
case MYSQL_TYPE_STRING:
case MYSQL_TYPE_VAR_STRING:
case MYSQL_TYPE_BLOB:
case MYSQL_TYPE_SET:
case MYSQL_TYPE_TIMESTAMP:
case MYSQL_TYPE_DATE:
case MYSQL_TYPE_TIME:
case MYSQL_TYPE_DATETIME:
case MYSQL_TYPE_YEAR:
case MYSQL_TYPE_GEOMETRY:
case MYSQL_TYPE_NULL:
if(l-length = 1){
l-type = G_TYPE_CHAR;
}else{
l-type = G_TYPE_STRING;
}
break;
}
/*DEBUG*/
//g_print(%s %d %d \n, l-alias,l-type,l-length);
/* Save pointer to list */
gl = g_list_append(gl,(gpointer)l);
}
return gl;}
now convert the row data to a GList and you have two GLists in your one lists,
one with the field header info, the other with the data.
and create the liststore like this:
GtkTreeModel *
isi_display_liststore_create(IsiDisplay *self, GList *fields)
{
guint num_fields, i;
IsiFields *l;
GtkTreeModel *model;
GType *types;
guint search_col_adj = 0;
/* Sanity Check */
g_return_val_if_fail(self != NULL, NULL);
g_return_val_if_fail(self-priv != NULL, NULL);
g_return_val_if_fail(self-priv-dispose_has_run != TRUE, NULL);
/* Get the number of fields */
if(fields != NULL){
num_fields = g_list_length(fields);
/* Initialize values based on number of columns */
types = (GType*) g_new0( GType, num_fields);
for(i=0;inum_fields;i++){
l = (IsiFields*)g_list_nth_data(fields,i);
types[i] = l-type;
}
/* create the model store for data input */
model = (GtkTreeModel*) gtk_list_store_newv(num_fields,types);
g_free(types);
for(i=0;inum_fields;i++){
l = (IsiFields*)g_list_nth_data(fields,i);
/* Setup sorting functions for the modle */
switch(l-type){
case G_TYPE_INT:
l-sortable=TRUE;
gtk_tree_sortable_set_sort_func(GTK_TREE_SORTABLE(model),
l-pos, sort_by_int,(gpointer) l-pos, NULL);
break;
case G_TYPE_UINT:
l-sortable=TRUE;
gtk_tree_sortable_set_sort_func(GTK_TREE_SORTABLE(model),
l-pos, sort_by_uint,(gpointer) l-pos, NULL);
break;
case G_TYPE_LONG:
l-sortable=TRUE;
gtk_tree_sortable_set_sort_func(GTK_TREE_SORTABLE(model),
l-pos, sort_by_long,(gpointer) l-pos, NULL);
break;
case G_TYPE_ULONG:
l-sortable=TRUE;
RE: GdkOffscreenWindow and texture_from_pixmap extension
Juan, Let me know if you find a good way to do this with GtkGLExt, it is something I need to do on the OS X platform. I think this will help you, here is where I first came across on the apple devnet: http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_offscreen/opengl_offscreen.html#//apple_ref/doc/uid/TP40001987-CH403-SW2 and here is the actual opengl reference to it: http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt You can use OpenGL Extensions to create buffers (original was only for texture maps apparently), render to them, and place them in scene as texture, or pictures, or even video, the best thing is there is a whole set of utils to take the buffer, and render directly to objects, and can be done so in a single context, of your choosing. This is how OS X does its fancy iChat AV In general rendering to offscreen will be much slower then rendering directly to a video framebuffer. EMAILING FOR THE GREATER GOOD Join me Date: Thu, 1 Apr 2010 20:25:11 -0700 Subject: GdkOffscreenWindow and texture_from_pixmap extension From: juanpablouga...@gmail.com To: gtk-app-devel-list@gnome.org Hello everyone. I want to do some OpenGL widget compositing using GtkGLExt and GdkOffscreenWindow. I implemented a offscreen widget as the ones in gtk-demo to be able to use the offscreen GdkPixmap as the source for a texture. But I am having some problems while trying to bind the GdkPixmap to the texture So does anyone know how to ge a Pixmap, as returned by XcompositeNameWindowPixmap(), from a GdkOffscreenWindow in order to use it in glxCreatePixmap()? thanks Juan Pablo ___ 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: displaying a number on screen
Try retreiving the cairo context for the widget you want to draw in and try this: /* Create the default Layout */ layout = pango_cairo_create_layout(cr); /* Atach the font descriptor */ font_description = pango_font_description_new(); /* Setup Fonts and color and other layout attributes*/ pango_font_description_set_family(font_description,Helvetica); cairo_set_source_rgba(cr, 0.3, 0.3, 0.3, 1.0); pango_font_description_set_absolute_size(font_description, 0.28 * PANGO_SCALE); pango_font_description_set_weight(font_description,PANGO_WEIGHT_BOLD); pango_layout_set_font_description(layout,font_description); gchar * l1 = g_strdup_printf(%s-%d,label-aid,label-nid); cairo_move_to(cr, 0.05 * xmultip, 0.00 * ymultip); pango_layout_set_text(layout,l1,-1); pango_cairo_show_layout(cr,layout); You can also use pango_layout_set_markup(layout,l1,-1); using Pango markup to change text style. EMAILING FOR THE GREATER GOOD Join me Date: Sat, 27 Mar 2010 23:58:15 +0530 Subject: displaying a number on screen From: rao.nisc...@gmail.com To: gtk-app-devel-list@gnome.org Hi, I am sorry if this is not the right mailing list. For given x and y co-ordinates is it possible to display a particular number at that position? or in other words, is it possible to paint a number or character on the screen at a given point? Thanks in advance. -- regards, Nischal E Rao blogs.sun.com/nischal Join RVCE OSUM at http://osum.sun.com/group/rvceosum ___ 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: how to draw something on GtkDrawingArea when I click a button?
As a matter of fact. I would suggest using Cairo. Which will allow you to then
draw in any context (IE Printer, PDF, etc...)
/* Local Variables */
cairo_t *cr;/* Rendering context derived from widget */
/* Get the context to which we need to draw */
cr = gdk_cairo_create(widget-window);
/* Printer context would be:
cr = gtk_print_context_get_cairo_context(context)
where context is a GtkPrinterContext* */
/* If we have a valid context draw valid object */
if (cr != NULL){
/* Boarder rectangle */
cairo_rectangle(cr, 0.00, 0.00, 20.0 , 40.0 );
cairo_stroke(cr);
cairo_set_line_width(cr,line_width / 60);
/* Virtical Seporation lines */
cairo_move_to(cr, 20.0 , 40.0 );
cairo_line_to(cr, 40.0, 40.0);
cairo_stroke(cr);
/* Distroy the context we created */
cairo_destroy(cr);
}
EMAILING FOR THE GREATER GOOD
Join me
Subject: Re: how to draw something on GtkDrawingArea when I click a button?
From: csaave...@gnome.org
To: gtk-app-devel-list@gnome.org
Date: Fri, 19 Mar 2010 08:46:33 +0200
El vie, 19-03-2010 a las 13:34 +0800, Tolic Ma escribió:
Hi,everyone!
I want to draw something on GtkDrawingArea when I click a GtkButton,but I
don't know how to do this...
this is my code(it doesn't work...):
*void click_button(void){
gdk_draw_line(drawing_area,drawing_area-style-white_gc,x,y,width+x,height+y);
}
You shouldn't draw directly in your callback for the button. Instead,
you should call gtk_widget_queue_draw() to tell GTK+ to schedule a paint
of the widget.
How will the widget be painted? GTK+ will tell your code that the widget
needs to be painted by emitting the GtkWidget::expose-event signal.
Then, you should connect to that signal and paint in your callback.
Last but no least, don't forget to paint to the GdkWindow of the drawing
area, since that's the drawable.
More or less (untested code, just for clarity):
*void
click_button(GtkButton *button, gpointer data)
{
button_clicked = TRUE;
gtk_widget_queue_draw (drawing_area);
...
}
gboolean
expose_drawing_area (GtkWidget *area,
GdkExposureEvent *event,
gpointer data)
{
...
if (button_clicked) {
gdk_draw_line(drawing_area-window,
drawing_area-style-white_gc,x,y,width+x,height+y);
}
...
}
int main(int argc,char *argv[]){
...
g_signal_connect(button,clicked,G_CALLBACK(click_button),NULL);
g_signal_connect(drawing_area,expose-event,G_CALLBACK(expose_drawing_area),NULL);
...
}
Claudio
--
Claudio Saavedra csaave...@gnome.org
___
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: GTK+ at the UX Hackfest
Frankly Thomas has given the best opinion on this. The idea behind the widget set should be to provide the MINIMAL REQUIRED functionality to address the mundane job of programming you own interface. HOWEVER, IMHO, if you want the library to do everything for you, then it will become bloated (frankly I'm already loosing track off all the the new widgets). I'm sure if you ask around especially in this list, you can drum up thousands of widget requests (where individual programmers will want specif widget most of which will be only STYLISTICALLY different). Whatever the theme engine can not handle, you can certainly override the expose event, motion / button press events to create your own derived widget. IE. Use a button box, override methods with your own specific methods. You can use the same process of adding and deleting buttons, etc but draw them yourself in the exact way you want. EMAILING FOR THE GREATER GOOD Join me Subject: Re: GTK+ at the UX Hackfest From: t...@gnome.org To: carl...@gnome.org Date: Wed, 3 Mar 2010 11:45:33 + CC: jim...@novell.com; usabil...@gnome.org; gtk-devel-list@gnome.org; wwal...@gnome.org; brats...@gnome.org; hylkeb...@gmail.com On Wed, 2010-03-03 at 12:20 +0100, Carlos Garnacho wrote: Hi!, On mié, 2010-03-03 at 00:03 +0100, Filippo Argiolas wrote: On Tue, Mar 2, 2010 at 11:55 PM, Filippo Argiolas fargio...@gnome.org wrote: [cut] Well it's not actually the radio functionality that I really care, that's easily implementable. It's more the custom container that can be themed to visually merge together several buttons. Once that's done, the buttons could behave like simple buttons (probably useless), toggle buttons or radio buttons. They would be just the usual buttons into a special container probably. Look at Carlos post about theming hackfest too[1]. Point 3 really seems to be exactly what I'm talking about. 1. http://blogs.gnome.org/carlosg/2009/02/20/dublin-theming-hackfest/ The idea there is that current widgets/containers would be able to tell theme engines how do painted items visually connect each other. There would be no need for special containers or buttons, nor hacks in theme engines such as peeping into the parent widget GType. I'm really not sure this is a good idea; it's really not expressive enough to just say this button is somehow related to this one and let themes decide what to do with it. Some themes might ignore it, some themes might do what you expect and some themes may want to do something completely different. If two buttons are supposed to be connected because of some interaction design, then this should be reflected in a widget explicitly designed to cater for that situation. Regards, Thomas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: gtk+-2.18, win32, and OpenGL
FYI --- The same thing happens on the OS X version using the Native GTK (NON X Windows). No mater where the widget. It always takes up the entire windows, and does not respond to mouse input. Could it be that the issue is not platform specific? EMAILING FOR THE GREATER GOOD Join me Subject: Re: gtk+-2.18, win32, and OpenGL From: al...@redhat.com To: t.ev...@aranz.com Date: Mon, 15 Feb 2010 10:21:01 +0100 CC: gtk-devel-l...@gnome.org On Mon, 2010-02-15 at 12:07 +1300, Tim Evans wrote: Previous with GTK+ 2.14 I had some custom code that would let me draw with OpenGL into a widget under win32. After updating GTK+ 2.18 this code doesn't work properly any more, it turns the entire toplevel window into an OpenGL area instead. I've gotten part way to having it work by calling gdk_window_ensure_native() on the window behind my OpenGL area widget, but some things are still broken: Hmmm, ideally that should not be needed. Its not on the X11 version of client side windows. There the gdk_x11_drawable_get_xid() call will automatically create a native window if you call it on a client-side window. Win32 should do the same. However, the win32 port of client side windows does not really seem fully done. Unfortunately I don't personally have time to work on it at the moment. 1. I've found I need to call SetWindowPos manually to resize the native window when the widget is allocated. Is this the expected behaviour? No, this is likely another bug in win32 csw support. 2. Mouse events seem to be screwed up. After clicking on my OpenGL area widget, other widgets will not receive enter-notify-event until I click again outside the widget, making buttons and other widgets not work. Is there a way to fix this? same here. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a world-famous shark-wrestling househusband on his last day in the job. She's a bloodthirsty punk bounty hunter from a different time and place. They fight crime! ___ gtk-devel-list mailing list gtk-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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: gtk+-2.18, win32, and OpenGL
FYI --- The same thing happens on the OS X version using the Native GTK (NON X Windows). No mater where the widget. It always takes up the entire windows, and does not respond to mouse input. Could it be that the issue is not platform specific? EMAILING FOR THE GREATER GOOD Join me Subject: Re: gtk+-2.18, win32, and OpenGL From: al...@redhat.com To: t.ev...@aranz.com Date: Mon, 15 Feb 2010 10:21:01 +0100 CC: gtk-devel-list@gnome.org On Mon, 2010-02-15 at 12:07 +1300, Tim Evans wrote: Previous with GTK+ 2.14 I had some custom code that would let me draw with OpenGL into a widget under win32. After updating GTK+ 2.18 this code doesn't work properly any more, it turns the entire toplevel window into an OpenGL area instead. I've gotten part way to having it work by calling gdk_window_ensure_native() on the window behind my OpenGL area widget, but some things are still broken: Hmmm, ideally that should not be needed. Its not on the X11 version of client side windows. There the gdk_x11_drawable_get_xid() call will automatically create a native window if you call it on a client-side window. Win32 should do the same. However, the win32 port of client side windows does not really seem fully done. Unfortunately I don't personally have time to work on it at the moment. 1. I've found I need to call SetWindowPos manually to resize the native window when the widget is allocated. Is this the expected behaviour? No, this is likely another bug in win32 csw support. 2. Mouse events seem to be screwed up. After clicking on my OpenGL area widget, other widgets will not receive enter-notify-event until I click again outside the widget, making buttons and other widgets not work. Is there a way to fix this? same here. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a world-famous shark-wrestling househusband on his last day in the job. She's a bloodthirsty punk bounty hunter from a different time and place. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: How I can do Double Buffer without OpenGL Ext?
Well in the good old days, when we did have all these fancy smancy libraries ( :P ) we use to double buffer graphics by drawing to an off screen bitmap or any compatible context (to that of the screen) and then simply copy that context to the screen. I.E. 1) Create a new GtkBitmap, 2) Draw everything to the bitmap 3) copy the bits to screen EMAILING FOR THE GREATER GOOD Join me Date: Thu, 11 Feb 2010 11:41:47 -0300 Subject: How I can do Double Buffer without OpenGL Ext? From: grojas@gmail.com To: gtk-app-devel-list@gnome.org Hi, I'm working in avoid the flicker when i paint my widget draw area. Then my questions are the following: How i can to do double buffer?, but without GL Ext, using just gtk draw area and pixbuf or pixmap. And If it is posible or only can I to work double buffer with GL Ext???. Any idea? Regards. Gustavo Rojas ___ 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: How I can do Double Buffer whether OpenGl Ext?
From the logo example:
/*
* Configure OpenGL-capable visual.
*/
/* Try double-buffered visual */
glconfig = gdk_gl_config_new_by_mode (GDK_GL_MODE_RGB|
GDK_GL_MODE_DEPTH |
GDK_GL_MODE_DOUBLE);
if (glconfig == NULL)
{
g_print (*** Cannot find the double-buffered visual.\n);
g_print (*** Trying single-buffered visual.\n);
/* Try single-buffered visual */
glconfig = gdk_gl_config_new_by_mode (GDK_GL_MODE_RGB |
GDK_GL_MODE_DEPTH);
if (glconfig == NULL)
{
g_print (*** No appropriate OpenGL-capable visual found.\n);
exit (1);
}
}
..
/* Set OpenGL-capability to the widget. */
gtk_widget_set_gl_capability (drawing_area,
glconfig,
NULL,
TRUE,
GDK_GL_RGBA_TYPE);
This function first tries to create a glconfig using double buffered, if fails,
uses single buffer). This works on OS X 10.6 Snow Leopard.
EMAILING FOR THE GREATER GOOD
Join me
Date: Tue, 9 Feb 2010 04:41:12 -0300
Subject: How I can do Double Buffer whether OpenGl Ext?
From: grojas@gmail.com
To: gtk-app-devel-list@gnome.org
Hi,
I'm trying to do a double buffer with pixbuf and draw area, whether to use
OpenGL Ext, but i don't know if it is posible or not.
Any idea?
Thanks.
Gustavo R.
___
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
Random crashes when printing on OS X
I am using the GtkPrint* functions to print. However at what seems to be random
occurrences the application crashes with the following error:
Gdk:ERROR:gdkeventloop-quartz.c:559:select_thread_collect_poll: assertion
failed: (ufds[i].fd == current_pollfds[i].fd)
Abort trap
When the user clicks on the print button a signal is generated and the
application comand function executes based on the following case statement:
...
case ISI_PERM_MENU_COMPONENT_FORMULA_PRINT:
if( isi_app_check_permission(prev_self,
ISI_PERM_MENU_COMPONENT_FORMULA_PRINT) prev_self-component != NULL){
isi_display_page_setup( prev_self-display,
prev_self-component,FALSE);
isi_display_print(prev_self-display);
} else {
isi_user_message(NULL,Not Allowed,You do not have
permission to print formulas.,0);
}
break;
...
void isi_display_print(IsiDisplay *self){
GtkPrintOperation *print = NULL;
GtkPrintSettings *printer_settings = NULL;
GtkPageSetup *page_setup = NULL;
GtkPaperSize *paper_size = NULL;
guint ctype;
/* Sanity Check */
g_return_if_fail(self != NULL);
g_return_if_fail(ISI_IS_DISPLAY(self) != FALSE);
g_return_if_fail(self-priv != NULL);
g_return_if_fail(self-priv-dispose_has_run != TRUE);
/* Create a new print operation */
print = gtk_print_operation_new();
/* Create new page setup and paper size */
page_setup = gtk_page_setup_new();
paper_size = gtk_paper_size_new(GTK_PAPER_NAME_LETTER);
gtk_page_setup_set_paper_size(page_setup,paper_size);
/* Set the default to the new page setup */
gtk_print_operation_set_default_page_setup(print,page_setup);
/* Make sure we always do full page printing*/
gtk_print_operation_set_unit(print,GTK_UNIT_INCH);
gtk_print_operation_set_use_full_page(print,TRUE);
gtk_print_operation_set_n_pages (print, self-priv-page_count);
g_signal_connect(print, draw-page,
G_CALLBACK(isi_display_print_event),(gpointer)self);
/* SOMEWHERE IN THIS FUNCTION THE DIALOG BLOWS UP!! */
gtk_print_operation_run(print,GTK_PRINT_OPERATION_ACTION_PRINT_DIALOG,NULL,NULL);
return;}
Any help would be greatly appreciated.
The problem is pervasive will most printer types, but is exacerbated with the
HP CP3525 Color Laserjet printer.
Shawn
EMAILING FOR THE GREATER GOOD
Join me
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Random crashes when printing on OS X
I am now also getting this when I print, after having added a cairo_clip() to bound my drawings into a (0,0),(1,1) region. But I do not get it when I am displaying to screen, only printing, and I use the same function for both, one simply gets the cairo_t from the drawing area, the other retrieves it from the printer. Any ideas? Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199]
RE: Random crashes when printing on OS X
I am now also getting this when I print, after having added a cairo_clip() to bound my drawings into a (0,0),(1,1) region. But I do not get it when I am displaying to screen, only printing, and I use the same function for both, one simply gets the cairo_t from the drawing area, the other retrieves it from the printer. Any ideas? Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetRGBFillColor: invalid context 0x0 Thu Feb 4 17:04:16 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextShowGlyphsAtPoint: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFont: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetFontSize: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextSetTextMatrix: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199] Error: CGContextClearRect: invalid context 0x0 Thu Feb 4 17:04:18 Shawn-Bakhtiars-iMac.local orderdesk[39199]
RE: [GtkGLExt] Window size issue
I know someone brought this up before. I don't recall if there was a resolution
to it or not.
I have successfully patched and compiled the latest from the GtkGLExt git repo
and running on OS X Snow Leopard (10.6), although I am use the 10.5 building to
the 368 architecture.
However, any application (including the examples), that uses the library, takes
over the entire window, overlapping all other widgets.
Any ideas how I should trace this down?
The code is straight out of the example (which does the same thing),
gtk_gl_init() has already been called in main, and the container is main_hbox,
which then has other widgets added to it later in the code.
glconfig = gdk_gl_config_new_by_mode (GDK_GL_MODE_RGB|
GDK_GL_MODE_DEPTH |
GDK_GL_MODE_DOUBLE);
if(glconfig != NULL){
GtkWidget * drawing_area = gtk_drawing_area_new ();
gtk_widget_set_size_request (drawing_area, 200, 200);
/* Set OpenGL-capability to the widget. */
gtk_widget_set_gl_capability (drawing_area,
glconfig,
NULL,
TRUE,
GDK_GL_RGBA_TYPE);
gtk_widget_add_events (drawing_area,
GDK_BUTTON1_MOTION_MASK|
GDK_BUTTON2_MOTION_MASK|
GDK_BUTTON_PRESS_MASK |
GDK_VISIBILITY_NOTIFY_MASK);
g_signal_connect_after (G_OBJECT (drawing_area), realize,
G_CALLBACK (realize), NULL);
g_signal_connect (G_OBJECT (drawing_area), configure_event,
G_CALLBACK (configure_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), expose_event,
G_CALLBACK (expose_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), button_press_event,
G_CALLBACK (button_press_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), motion_notify_event,
G_CALLBACK (motion_notify_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), map_event,
G_CALLBACK (map_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), unmap_event,
G_CALLBACK (unmap_event), NULL);
g_signal_connect (G_OBJECT (drawing_area), visibility_notify_event,
G_CALLBACK (visibility_notify_event), NULL);
g_signal_connect_swapped (G_OBJECT (main_window), key_press_event,
G_CALLBACK (key_press_event), drawing_area);
gtk_box_pack_start (GTK_BOX (main_hbox), drawing_area, TRUE, TRUE, 0);
gtk_widget_show (drawing_area);
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Random memory allocation error
At what appears to be random locations in a program which runs thought 24000 components, and breaking out the formulas in to there raw material components (formulations table of about 200,000 formulation lines, I see this error message: malloc: *** error for object 0xe41074: incorrect checksum for freed object - object was probably modified after being freed.*** set a breakpoint in malloc_error_break to debug so far I have only found some obscure references, and this is happening randomly: IE #0 0x95f95072 in malloc_error_break ()#1 0x95f96218 in szone_error ()#2 0x95f9638b in free_list_checksum_botch ()#3 0x95ea2985 in tiny_malloc_from_free_list ()#4 0x95ea1b03 in szone_malloc_should_clear ()#5 0x95ea1988 in malloc_zone_malloc ()#6 0x95e9fa58 in malloc ()#7 0x00c2a799 in g_malloc ()#8 0x00ba774d in g_object_newv ()#9 0x00ba7ef7 in g_object_new_valist ()#10 0x00ba758f in g_object_new ()#11 0x000a8468 in isi_database_get_component_simple (self=0x101c000, aid=0x2008030 ZH, nid=90005) at isidatabase.c:4296 but it has run through the same piece of code with no problems for 30 times before it hits this. continue, and it will go past this part and break , #0 0x95f95072 in malloc_error_break ()#1 0x95f96218 in szone_error ()#2 0x95f9638b in free_list_checksum_botch ()#3 0x95ea2985 in tiny_malloc_from_free_list ()#4 0x95ea1b03 in szone_malloc_should_clear ()#5 0x95ea386b in malloc_zone_calloc ()#6 0x95ea37fa in calloc ()#7 0x00c2a82a in g_malloc0 ()#8 0x00053030 in isi_list_instance_init (instance=0x185f190, g_class=0xe1a850) at isilist.c:96#9 0x00bc196c in g_type_create_instance ()#10 0x00ba832a in g_object_constructor ()#11 0x00ba7726 in g_object_newv ()#12 0x00ba7ef7 in g_object_new_valist ()#13 0x00ba758f in g_object_new ()#14 0x0005b647 in isi_component_instance_init (instance=0x180e020, g_class=0x13a12070) at isicomponent.c:156#15 0x00bc196c in g_type_create_instance ()#16 0x00ba832a in g_object_constructor ()#17 0x00ba7a5e in g_object_newv ()#18 0x00ba7ef7 in g_object_new_valist ()#19 0x00ba758f in g_object_new ()#20 0x000a8468 in isi_database_get_component_simple (self=0x101c000, aid=0x20081b0 ZH, nid=90004) at isidatabase.c:4296#21 0xcd36 in isi_util_normalize_formuals (theApp=0x1016010, prompt=1) at isiutil.c:368#22 0xd67f in main (argc=1, argv=0xbfffe848) at isiutil.c:764 EMAILING FOR THE GREATER GOOD Join me ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Random memory allocation error
Nailed it on the head. bad programing. I forgot how wonderful valgrind is, thanks. EMAILING FOR THE GREATER GOOD Join me Date: Sat, 26 Dec 2009 13:52:06 -0500 From: cottr...@wfu.edu To: shashan...@hotmail.com CC: gtk-app-devel-list@gnome.org; gtk-osx-us...@lists.sourceforge.net Subject: Re: Random memory allocation error On Sat, 26 Dec 2009, Shawn Bakhtiar wrote: At what appears to be random locations in a program which runs thought 24000 components, and breaking out the formulas in to there raw material components (formulations table of about 200,000 formulation lines, I see this error message: malloc: *** error for object 0xe41074: incorrect checksum for freed object - object was probably modified after being freed.*** Your code is buggy. Run it under valgrind and you'll see where the bugs are. Allin Cottrell ___ 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)
Well... this seems to turn on a few flames... so let me put some of this to rest. For anyone to say OpenGL is niche, and does not apply to everyday apps, I again remind you of iChat and the OS X Panel. Granted it has only recently found prominence in the desktop but it is quickly making way as OGL hardware acceleration becomes standardize (has been for some time). To look back at the past decade and say look desktops are all 2D, not realizing it has to do with memory and CPU/GPU issues, which are no longer issues is simply wrong. The next decade of desktops, more importantly GUI (Graphical USER -- hello!!! Interfaces) WILL have a blinding array of 3D widgets which will be like eye candy to most users, and as they see it they will want it more and more. I do NOT work at a facility which requires 3D visualization to accomplish its tasks, but users are starting to ask and want. Can I do a walkthrough of our warehouse to see how much material I have?, Can we have a little computerized white box, with a virtualized pallet to do color matching in? This has NOTHING to do with scientific engineering or niche market. It has to do with the future of interface design. I work in a ink manufacturing plant, and by that argument, we should mix it all by hand, since that is how they did it 5000 years ago! 2D is NOT the end of all GUIs. It simply is not! R2 space can not hold as much date/widgets/whatever as R3 even if the axis were infinite! they (users) want 3D buttons that pop, role, jump, and wink at them too. They want there pictures to start bending, bouncing, and getting all organic on them. To say that GTK does NOT need OGL, is to say they sun is not going to rise in the morning. To say that GTKGLext (a great tool to be sure) is good enough, is to slap a hand in the face of all of use who see where this is going. The greatest problem with the linux community (one I myself am having to learn about) is this indelible ego that the data and function has to be correct and nothing else. Sorry if the user can not visually keep up or understand what you present, it won't make a difference how good the app works in the back, it IS the eye candy that gets the user to use it. GtkTreeview in 3D? I can thing of a dozen categorization applications in seconds. FYI - OS X is a FreeBSD engin, with NextStep as its windowing system. It uses OGL IN the windowing system (quartz / composer), and it is the hottest desktop on the market. No one, and I mean no one, has even come close! And lets not forget all the work that is being done on Compiz why? For the masochism of it?!? No! Because that is where the future of desktop are, in 3D space! IMMHO, if Gtk is to keep up, as the cross platform interface it promises to be, it will need OGL to be fully modularized or integrated somehow. I don't even think GtkGLExt is that far, other than the OS X side of it, which with demand will certainly improve. P.S.the comment: Ah. You are such a loser. Go away., has no business on this forum, the point is a good one, and your minimization of it, a poor show of understanding. EMAILING FOR THE GREATER GOOD Join me Date: Sat, 5 Dec 2009 19:48:06 +0100 From: y...@physics.muni.cz To: jose.carlos.pere...@ist.utl.pt Subject: Re: GtkGLExt (was Re: Gtk 3.0) CC: gtk-app-devel-list@gnome.org On Sat, Dec 05, 2009 at 04:22:36PM +, Carlos Pereira wrote: We must atract more scientifc/engineering applications for Linux and GTK, because this is exactly the kind of stuff that enterprises and universities are demanding. If we have fantastic operating systems and desktop environments in the free software world, but most of the scientific/engineering aplications only run in Windows/Mac OS X, people will be forced to use them, even if they would rather prefer to use Linux/BSD... I have many friends in this situation... I'm afraid you explain it from your viewpoint. But looking at your reasoning from the `desktop' viewpoint there are troubles. 1) Objective. There will never ever be a scientific `killer app'. Every little branch of science, or even an individual scientific problem, has specific needs. Hence the applications are inherently scattered and each individual app is used only by a small group of people. Even the `universal' commerical tools such as Matlab are far from being universally used [among scientists]. This makes hard to see sci/eng apps matter *at all*. 2) Subjective. Do your graphs have round corners and include the user's IM status? Can your data acquistion software synchronize the data with an iPod? Are your reports summarized to 140 characters and sent to Twitter? No? Does your app help people with some difficult to understand and much more difficult to solve problems instead of facilitating idle chit-chat while consuming power for visual effects? Ah. You are such a loser. Go away. Regards, Yeti
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: differences between Glade and GtkBuilder
Yes. They are all set to visible. I'll change them in the GUI and see if that makes a difference. I still think something in the process has changes, at least from the user perspective. 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) 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? 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? EMAILING FOR THE GREATER GOOD Join me Subject: Re: From: sc...@asofyet.org Date: Wed, 2 Dec 2009 13:37:42 -0500 To: shashan...@hotmail.com On Dec 1, 2009, at 1:01 PM, Shawn Bakhtiar wrote: 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. Should this not work like glade did before, where you would load the file, then call the objects you wanted to be displayed? Do you have the visible property set for all of the windows in the buildable xml? 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.) -- 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. -- Dave Hodgkinson, on london.pm ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Gtk-OSX Frameworks (was: Why are developers...)
For building an application... I couldn't agree more, about the framework vs.
jhbuild and autotools. You definitely want the latter. I like XCode's editor.
when looking at source code (the colors man the
colors). It also has a lot of nice features such as collapsible
sections, an intuitive way of knowing if you {} are correct, as well as
a jump to function feature that list all functions in the current file
in a drop down menu. However, you can use the editor, and build in shell
(jhbuild shell). In any case, gdb is a much better debugger to boot.
But yeah.. just try to build mysql with it, or even use it in a build. Good
luck!!
Also using the ige-mac-bundler, users now simple drag and drop the latest
package (application) to their application folder, and they are done,
especially if you adhere to the XDG file system.
I don't know what all the complaint is about... I have been using the jhbuild
scripts with little to no problems. I have had a few dependency issues but
nothing that can not be figured out with a little reading of the script itself
and attention to what I am doing. In any case, anything that is missing, simple
download to source directory, and build inside the jhbuild shell, your done!
Like I said, I'm not too good with the back-end stuff, but it looks like I will
be getting my own Snow Leopard today, I can re-run the jhbuild stuff from
scratch, and see if I can't get a framework out. Would this help?
EMAILING FOR THE GREATER GOOD
Join me
From: jra...@ceridwen.us
Subject: Re: Gtk-OSX Frameworks (was: Why are developers...)
Date: Tue, 10 Nov 2009 07:10:09 -0800
To: gtk-devel-list@gnome.org
On Nov 10, 2009, at 4:16 AM, Paul Davis wrote:
On Mon, Nov 9, 2009 at 1:10 PM, Jack Skellington dac...@gmail.com
wrote:
Also if a native Gtk+ OS X framework were available people who are
maintaining Gtk+ apps would have the option to extend their user base
to OS X quite quickly.
All it requires to use it is to build the GTK stack yourself using the
instructions provided (i wish the instructions had not been moved away
from gnome.org, but they are still easy to find). I should put all
in quotes because if you choose to follow bleeding edge GTK then you
will find that maintaining your built version can be quite a lot of
work in the face of breakages and changes in many different parts of
the stack. This is not true (or at least, it is MUCH less true) if you
use a recent release version (there are instructions on how to do that
included in the gtk osx build info).
I do not believe that using a pre-built GTK OS X framework is
desirable for users or developers. Include GTK as part of your app
bundle. Its not hard to do and gives you complete control over which
version of GTK is used by your app. We do this for Ardour (and now
Mixbus) (screenshots at http://ardour.org/ and
http://mixbus.harrisonconsoles.com/). Users download a single app, and
run it. No framework installation or maintainance.
I haven't built and made available updated frameworks because the
approach Richard used to create the first one (still hanging around on
gtk-osx.org
, as previously noted elsewhere) didn't produce a result that I think
I can support. I have in mind a modification of ige-mac-bundler which
I think will provide better results, but other tasks have higher
priority at the moment.
Some others, including me, have done some work on the gtk-osx-
frameworks, and the network graph at github shows that my tree
(http://github.com/jralls/gtk-osx-framework
) is current with all of them . Do be aware that there are 3 branches,
of which master is probably the only one which will get you close
enough to use.
I also agree with Paul here: The Apple Framework idiom doesn't make
sense for cross-platform development. It uses special #include syntax
and special linking. It doesn't play well with pkg-config. Yes, those
are solvable problems, but why? The regular gnu autotools work very
well indeed on OSX, and one needs to use it anyway for building on
Linux. Why deal with another build chain just for the dubious benefit
of using XCode instead of emacs or vim?
Add to that that it's hard to build a non-trivial application using
only gtk+. You're going to need a bunch of other libraries, either
from gnome, gnu, or freedesktop. They're not going to be in
Frameworks, so you're going to have to integrate them the autotools
way, so what do you gain from having gtk+ in a set of frameworks?
There is one exception to which I'm quite sympathetic: PyGtk. At
present building a downloadable PyGtk app bundle is a royal pain, and
a PyGtk framework *might* be part of the solution.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Gtk-OSX Frameworks (was: Why are developers...)
in isi_app_initialize_default_interface
(self=0x10201b000) at isiapp.c:6204
#2 0x0001ae0a in main (argc=1, argv=0x7fff5fbfec08) at isimain.c:53
I am going to try an do what Jralls suggest and perhaps re-build with both -g
and see if I can not trace this better, also try to build the library as 32bit
and see what happens than. But this application has been running great using
this technique on the 32 bit interface with no problems what so ever! I can't
figure out why I have all kinds of bad memory references.
I just noticed the there seems to be 32bit memory addresses intermingled with
64bit? IE in the above output self is 32bit but the address lookup is 64bit ??
Is that right? Same with the code??
Do I need to post this to gtk-app or is this something wrong in the backend
(perhaps I am compiling with wrong options ??)
HELP :S :'S :S :S
EMAILING FOR THE GREATER GOOD
Join me
Subject: Re: Gtk-OSX Frameworks (was: Why are developers...)
From: ja...@juvul.com
Date: Tue, 10 Nov 2009 18:20:26 +0100
CC: gtk-devel-list@gnome.org
To: shashan...@hotmail.com
On Nov 10, 2009, at 4:46 PM, Shawn Bakhtiar wrote:For building an
application... I couldn't agree more, about the framework vs. jhbuild and
autotools. You definitely want the latter. I like XCode's editor. when looking
at source code (the colors man the colors). It also has a lot of nice features
such as collapsible sections, an intuitive way of knowing if you {} are
correct, as well as a jump to function feature that list all functions in the
current file in a drop down menu. However, you can use the editor, and build in
shell (jhbuild shell). In any case, gdb is a much better debugger to boot.
But yeah.. just try to build mysql with it, or even use it in a build. Good
luck!!
Also using the ige-mac-bundler, users now simple drag and drop the latest
package (application) to their application folder, and they are done,
especially if you adhere to the XDG file system.
I don't know what all the complaint is about... I have been using the jhbuild
scripts with little to no problems. I have had a few dependency issues but
nothing that can not be figured out with a little reading of the script itself
and attention to what I am doing. In any case, anything that is missing, simple
download to source directory, and build inside the jhbuild shell, your done!
Like I said, I'm not too good with the back-end stuff, but it looks like I will
be getting my own Snow Leopard today, I can re-run the jhbuild stuff from
scratch, and see if I can't get a framework out. Would this help?
That would be great!I've been trying to build it on Snow Leopard, butI i'm
stuck now with jhbuild meta-gtk-osx-core failing to build ige-mac-integration:
*** Building ige-mac-integration *** [10/11]make make all-recursiveMaking all
in srcif /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
-I.. -I.. -Wall -Wunused -Wchar-subscripts -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -std=c99
-Wno-sign-compare -Wno-pointer-sign -Werror -I/Users/dacobi/gtk/inst/include
-I/Users/dacobi/gtk/inst/include/gtk-2.0
-I/Users/dacobi/gtk/inst/lib/gtk-2.0/include
-I/Users/dacobi/gtk/inst/include/atk-1.0 -I/Users/dacobi/gtk/inst/include/cairo
-I/Users/dacobi/gtk/inst/include/pango-1.0
-I/Users/dacobi/gtk/inst/include/glib-2.0
-I/Users/dacobi/gtk/inst/lib/glib-2.0/include
-I/Users/dacobi/gtk/inst/include/pixman-1
-I/Users/dacobi/gtk/inst/include/freetype2
-I/Users/dacobi/gtk/inst/include/libpng12 -xobjective-c -g -O2 -MT
libigemacintegration_la-ige-mac-menu.lo -MD -MP -MF
.deps/libigemacintegration_la-ige-mac-menu.Tpo -c -o
libigemacintegration_la-ige-mac-menu.lo `test -f 'ige-mac-menu.c' || echo
'./'`ige-mac-menu.c; \ then mv -f
.deps/libigemacintegration_la-ige-mac-menu.Tpo
.deps/libigemacintegration_la-ige-mac-menu.Plo; else rm -f
.deps/libigemacintegration_la-ige-mac-menu.Tpo; exit 1; filibtool: compile:
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -Wall -Wunused -Wchar-subscripts
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith
-Wcast-align -std=c99 -Wno-sign-compare -Wno-pointer-sign -Werror
-I/Users/dacobi/gtk/inst/include -I/Users/dacobi/gtk/inst/include/gtk-2.0
-I/Users/dacobi/gtk/inst/lib/gtk-2.0/include
-I/Users/dacobi/gtk/inst/include/atk-1.0 -I/Users/dacobi/gtk/inst/include/cairo
-I/Users/dacobi/gtk/inst/include/pango-1.0
-I/Users/dacobi/gtk/inst/include/glib-2.0
-I/Users/dacobi/gtk/inst/lib/glib-2.0/include
-I/Users/dacobi/gtk/inst/include/pixman-1
-I/Users/dacobi/gtk/inst/include/freetype2
-I/Users/dacobi/gtk/inst/include/libpng12 -xobjective-c -g -O2 -MT
libigemacintegration_la-ige-mac-menu.lo -MD -MP -MF
.deps/libigemacintegration_la-ige-mac-menu.Tpo -c ige-mac-menu.c -fno-common
-DPIC -o .libs/libigemacintegration_la-ige-mac-menu.occ1obj: warnings being
treated as errorsige-mac-menu.c: In function
RE: Why are no developers completing/maintaining native Gtk+ for OS X?
On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it. Well, let me be the first to thank you for all you efforts Kris, you have been extremely helpful to me, and I am actively developing a ERP (Ordering, purchasing, Inventory, CRM) for the company I work for. The work you and John Ralls et al. have done has made it possible for me to do my work. So keep up the good work. Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. http://gtk-osx.sourceforge.net/ I have successfully used this on OS X Leopard (build the framework and app using jhbuild, with ige-mac-integration), and have been able to build the framework on SN (but my application crashes out, I think because of libglade which I really need to move away from, fix it for GtkBuilder). I to wish it was more complete (window transparency and shaping, is what I'm looking for), but I do not have a good enough grasp of Cocoa and Carbon (Not very familiar with Next Step windowing system) to be of any use, but I will certainly try to help were I can. Two years moving from Windows to Linux, and now OS X, V1 to be deployed in 010110. I'm not quite sure what you mean (Jacob) when you say native implementation, if you look at the quartz backend it looks pretty close to me, again with a lot of FIXME's in non-essential areas such as (window shaping), but that is not at all important for our functionality. It works, and it works well on OS X, just follow the jhbuild procedures form the above link. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Why are no developers completing/maintaining native Gtk+ for OS X?
To build the latest framework: 1) Get the latest using jhbuild and build 2) http://github.com/jralls/gtk-osx-framework/tree/master/framework/ I think I was able to build the frameworks and compile against them using the Xcode IDE, but I prefer using make and the command line myself. Actually machine has a couple of versions of framework / dependencies and builds, so I don't know if I just got lucky. Like I said, in 52 days I will have more time to play :) Subject: Re: Why are no developers completing/maintaining native Gtk+ for OS X? From: ja...@juvul.com Date: Tue, 10 Nov 2009 00:35:44 +0100 To: k...@gtk.org CC: gtk-devel-list@gnome.org On Nov 9, 2009, at 8:23 PM, Kristian Rietveld wrote: On Nov 9, 2009, at 7:10 PM, Jack Skellington wrote: Hello All I'm currently in charge of the development of a cross-platform OpenGL app which uses GTk+ for it's interface. The app runs on both *nix/X.org and win32 but when I started looking into OS X I found that the Quartz OS X version of Gtk+ is neither complete nor being actively developed. No, it is not fully complete, but getting close. Recently, I have been working on reviewing outstanding patches, fixing up the last few kinks remaining after the transition to client side windows and implemented proper and complete multi monitor support. I do have plans on how to continue my work on the backend. Development of the Mac port is actually pretty active. I only have very ample spare time to work on this and I do not get paid for this at all. Saying that the OS X port is not being actively developed is actually close to insulting to me; I have been trying my best to pick it up after the previous maintainer stopped working on it I can't tell you how happy reading this makes me. I love Gtk+ and have been using it in projects for like a decade, mostly on *nix, but lately cross-platform. As for the insult part, it was never my intention, I was merely relaying the present information thats available on the Gtk+ OS X sourceforge site. Keep up the good work! If I had money, I'd pay you ;) Also if a native Gtk+ OS X framework were available people who are maintaining Gtk+ apps would have the option to extend their user base to OS X quite quickly. The basics for this have been worked out in the past and are available for everybody to pick up. John Ralls co have been doing a good job at making GTK+ easy to build and looking into scripts for simplifying the creation of application bundles for GTK+ applications and a framework. A framework as in the Gtk.framework folder you add to the Xcode project and then build? Ever since I started developing in OS X I've found this approach quite beautiful in its simplicity. I will seriously consider looking into this myself if/when I have the time, Thanks again! Jacob Juul Kolding Juvul Tech -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: error building git head GTK on OS X ... IM symbols missing etc.
On clean copy of SL (upgraded) Xcode 3.2: downloaded and ran: prompt sh gtk-osx-build-setup.shprompt export PATH=$PATH:/Users/sbakhtiar/.local/binprompt jhbuild bootstrapprompt jhbuild build meta-gtk-osx-bootstrapprompt jhbuild build meta-gtk-osx-core libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=\GLib\ -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED -DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include -DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo -MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC -o .libs/gatomic.o /var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s:103:Incorrect register `%rdx' used with `l' suffixmake[4]: *** [gatomic.lo] Error 1make[3]: *** [all-recursive] Error 1make[2]: *** [all] Error 2make[1]: *** [all-recursive] Error 1make: *** [all] Error 2*** Error during phase build of glib: ## Error running make *** [2/11] Any ideas? EMAILING FOR THE GREATER GOOD Join me Subject: Re: error building git head GTK on OS X ... IM symbols missing etc. From: jra...@ceridwen.us Date: Mon, 26 Oct 2009 22:30:54 -0700 To: p...@linuxaudiosystems.com CC: gtk-devel-list@gnome.org On Oct 26, 2009, at 4:50 PM, Paul Davis wrote: just tried a jhbuild of gtk on OS X (tiger). things went well until it got to the link stage in the input methods code. i got a large number of messages of this form, one for each (every?) IM module: Cannot load module /Users/paul/gtk/source/gtk+/modules/input/im-am-et.la: dlopen(/Users/paul/gtk/source/gtk+/modules/input/.libs/im-am-et.so, 10): Symbol not found: _res_9_init Referenced from: /Users/paul/gtk/inst/lib/libgio-2.0.0.dylib Expected in: flat namespace does anybody have any clues what this might be? the missing symbol is always _res_9_init Found it, after a bit of searching. It's defined in /usr/include/ resolv.h, included from gio/gionetworkingprivate.h It doesn't show up in my SL build from today. I can't see from configure why it would pick it up for your build but not for mine. Search for lresolv in configure and config.log; maybe you can see why it's getting picked up on yours. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: error building git head GTK on OS X ... IM symbols missing etc.
Yep. That fixed it. For some reason I still had to download and install libiconv before I can run phase 2 of the meta-gtk-osx-core, when building glib it complains using header without any libraries present? Also, the script crashes out on the freetype module. gzip complains about a bad file. I downloaded the same version from the website, but now it won't compile with do not know how to make start. I don't have any more time for this today... but I will keep cranking and reporting here. Thanks for all the help. EMAILING FOR THE GREATER GOOD Join me Subject: Re: error building git head GTK on OS X ... IM symbols missing etc. From: k...@gtk.org Date: Tue, 27 Oct 2009 17:31:03 +0100 CC: jra...@ceridwen.us; gtk-devel-list@gnome.org To: shashan...@hotmail.com On Oct 27, 2009, at 5:25 PM, Shawn Bakhtiar wrote: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN= \GLib\ -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include - DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo - MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC - o .libs/gatomic.o /var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s: 103:Incorrect register `%rdx' used with `l' suffix Ah yes, I think I have stumbled on this as well. This is probably caused because the default jhbuildrc for the Mac forces a build for the 486: # When building on intel, force build to be 486, since glib won't # enable asm atomic operations otherwise. # try: _f = os.popen(uname -p) if _f.read().startswith(i386): append_autogenargs(glib, --build=i486-apple-darwin) I changed the last line to: append_autogenargs(glib, --build=x86_64-apple-darwin) And that fixed it for me. (If you have a Mac with a Core2 processor, the user land will be in 64-bit in Snow Leopard). regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: error building git head GTK on OS X ... IM symbols missing etc.
rm -rf the freetype-2.3.11 files from both gtk/source/pkgs and /gtk/source re-run jhbuild build meta-gtk-osx-core its working. EMAILING FOR THE GREATER GOOD Join me From: shashan...@hotmail.com To: k...@gtk.org Subject: RE: error building git head GTK on OS X ... IM symbols missing etc. Date: Tue, 27 Oct 2009 13:40:40 -0400 CC: gtk-devel-list@gnome.org Yep. That fixed it. For some reason I still had to download and install libiconv before I can run phase 2 of the meta-gtk-osx-core, when building glib it complains using header without any libraries present? Also, the script crashes out on the freetype module. gzip complains about a bad file. I downloaded the same version from the website, but now it won't compile with do not know how to make start. I don't have any more time for this today... but I will keep cranking and reporting here. Thanks for all the help. EMAILING FOR THE GREATER GOOD Join me Subject: Re: error building git head GTK on OS X ... IM symbols missing etc. From: k...@gtk.org Date: Tue, 27 Oct 2009 17:31:03 +0100 CC: jra...@ceridwen.us; gtk-devel-list@gnome.org To: shashan...@hotmail.com On Oct 27, 2009, at 5:25 PM, Shawn Bakhtiar wrote: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN= \GLib\ -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include - DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo - MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC - o .libs/gatomic.o /var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s: 103:Incorrect register `%rdx' used with `l' suffix Ah yes, I think I have stumbled on this as well. This is probably caused because the default jhbuildrc for the Mac forces a build for the 486: # When building on intel, force build to be 486, since glib won't # enable asm atomic operations otherwise. # try: _f = os.popen(uname -p) if _f.read().startswith(i386): append_autogenargs(glib, --build=i486-apple-darwin) I changed the last line to: append_autogenargs(glib, --build=x86_64-apple-darwin) And that fixed it for me. (If you have a Mac with a Core2 processor, the user land will be in 64-bit in Snow Leopard). regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: error building git head GTK on OS X ... IM symbols missing etc.
Success! I had to manually edit the ige-mac-integration's Makefile in the src directory and delete -Werror. I still have to build libglade and mysql before I can build my app and test. EMAILING FOR THE GREATER GOOD Join me From: shashan...@hotmail.com To: k...@gtk.org Subject: RE: error building git head GTK on OS X ... IM symbols missing etc. Date: Tue, 27 Oct 2009 15:52:02 -0400 CC: gtk-devel-list@gnome.org rm -rf the freetype-2.3.11 files from both gtk/source/pkgs and /gtk/source re-run jhbuild build meta-gtk-osx-core its working. EMAILING FOR THE GREATER GOOD Join me From: shashan...@hotmail.com To: k...@gtk.org Subject: RE: error building git head GTK on OS X ... IM symbols missing etc. Date: Tue, 27 Oct 2009 13:40:40 -0400 CC: gtk-devel-list@gnome.org Yep. That fixed it. For some reason I still had to download and install libiconv before I can run phase 2 of the meta-gtk-osx-core, when building glib it complains using header without any libraries present? Also, the script crashes out on the freetype module. gzip complains about a bad file. I downloaded the same version from the website, but now it won't compile with do not know how to make start. I don't have any more time for this today... but I will keep cranking and reporting here. Thanks for all the help. EMAILING FOR THE GREATER GOOD Join me Subject: Re: error building git head GTK on OS X ... IM symbols missing etc. From: k...@gtk.org Date: Tue, 27 Oct 2009 17:31:03 +0100 CC: jra...@ceridwen.us; gtk-devel-list@gnome.org To: shashan...@hotmail.com On Oct 27, 2009, at 5:25 PM, Shawn Bakhtiar wrote: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN= \GLib\ -DG_DISABLE_CAST_CHECKS -DG_DISABLE_DEPRECATED - DGLIB_COMPILATION -DPCRE_STATIC -I/Users/sbakhtiar/gtk/inst/include - DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -g -O2 -Wall -MT gatomic.lo - MD -MP -MF .deps/gatomic.Tpo -c gatomic.c -fno-common -DPIC - o .libs/gatomic.o /var/folders/8i/8iPY4ZafEpezLgvmjxSKSU+++TY/-Tmp-//ccNq7o6P.s: 103:Incorrect register `%rdx' used with `l' suffix Ah yes, I think I have stumbled on this as well. This is probably caused because the default jhbuildrc for the Mac forces a build for the 486: # When building on intel, force build to be 486, since glib won't # enable asm atomic operations otherwise. # try: _f = os.popen(uname -p) if _f.read().startswith(i386): append_autogenargs(glib, --build=i486-apple-darwin) I changed the last line to: append_autogenargs(glib, --build=x86_64-apple-darwin) And that fixed it for me. (If you have a Mac with a Core2 processor, the user land will be in 64-bit in Snow Leopard). regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Building Gtk-OSX (was: Intricate changes to Quartz/OSX backend)
Very Sweet guys Last I tried Snow Leopard I was not able to get past the bootstrap / build process (a couple of a months ago). I am going to spend the rest of the day re-building the environment, and our application to see if this is all works on OS X 10.6 Snow Kitty (SL). I don't have dual monitor but I will see if I can find one and test. EMAILING FOR THE GREATER GOOD Join me Date: Mon, 26 Oct 2009 15:46:54 -0400 Subject: Re: Building Gtk-OSX (was: Intricate changes to Quartz/OSX backend) From: p...@linuxaudiosystems.com To: jra...@ceridwen.us CC: gtk-devel-list@gnome.org On Mon, Oct 26, 2009 at 3:22 PM, John Ralls jra...@ceridwen.us wrote: Um, how long ago did you last run jhbuild bootstrap? The m4 module was added to bootstrap.modules last December, with version 1.4.11. more than bootstrap - fixing this required an entirely new version of jhbuild. there is also possibly some interaction going on because i have at least two GTK builds managed by jhbuild on this system. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Thumbnailing service project; opinions, suggestions?
[ CUT ] Sorry to keep chiming in, but regrading the statement: you just don't seem to get the point. I need to build something from the ground up (making uml, class diagrams and such).. and based on that i need to make the actual program. Tumbler is existing already! i would be making those diagrams based on the current inner working which is not the way to go. [CUT] I think everyone understands what you are doing, I think your the one missing the point; from what I gather, many on this very list, have given you some very good constructive advice on what to do, if you want to do this from the ground up. So be it. They are also very prudently advising you that this is not needed, and would ONLY serve as a class project, so: Can i get the: - Git - gnome sub domain - blog for this project on planet gnome and/or gtk No one is bashing anything, but despite the many who agree, that this project is NOT a requirement for GNOME or GTK (and since it is only for school, a place that rots the brain) I would be shocked... SHOCKED... if they provided you with a GIT, a gnome sub domain, and a blog. My friend, understanding is a two way street, and I'm not sure if any one on this list will convince you of any other path, than the one you are on. But don't expect them to hold your hand in this process as well. You want to do this do it: Put up your own GIT repo. Use a domain name off of your own schools website. and create your own blog for the project. I doubt any of this will effect your grade. Frankly it simply sounds like your trying to get your name on the site, which will help with other prospects. I would LOVE to be attached to such a project, many would. Open source is not about having many choices of software that do the same thing, it is about having many people working together in a cooperative (operative word here) to create something for the people, by the people, that will benefit the people, and in the process have some fun doing what we love. Open source is about freedom to do as you will, without the fear of big bro slamming you. Open source has never NEVER been about quantity, and has everything EVERYTHING to do with quality. IMHO shawn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Question about the default title of a GTK window
Hey pals, I am a new comer on GTK things.
I have some questions about it, would any one have time taking me over it?
Here is it:
1, What is the default title of a GTK window? I mean, if there is no string
was assigned to title of a GTK window, what will be exposed in the title bar
of said window?
I got curious so I looked. All three implementation Win32, X11, and my
favorite Quartz (Next Step, just cause that's what I'm working on now)
implements gdk_window_new based on the underlying platform and are somewhat
different. From what I can gather this is the part that gets the title and use
the implementation specific library functions to set the actual title, with the
text coming from this tidbit of code based on glib:
in gdk_window_new_internal(){
(implementation specific code)
if (attributes_mask GDK_WA_TITLE)
title = attributes-title;
else
title = get_default_title ();
(implementation specific code)..
}
with the function get_default_title defined as:
static const gchar *
get_default_title (void)
{
const char *title;
title = g_get_application_name ();
if (!title)
title = g_get_prgname ();
return title;
}
in all implementation, thus the answer being, the executable name.
2, Whether there is another interface for developers on setting title on GTK
window except gtk_window_set_title?
I suppose you could use g_set_prgname() look at
http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Functions.html
3, More specifications, will GTK framework take application name from
anywhere and set it as title into any untitled window in the application?
That all. Thanks alot.
Take application name from anywhere? Huh? I can't say the function below is
straight forward, I can only imaging its convolution is do the WIN32, but from
what I can gather g_prgname is a global variable within the file, and as as
mentioned initialized in gdk_init. Actually it comes from
g_option_context_parse() in goption.c.
Basically the function (very compiler depended) finds the program name and sets
it, which intern becomes your very changeable window title.
**
* g_get_prgname:
*
* Gets the name of the program. This name should emphasisnot/emphasis
* be localized, contrast with g_get_application_name().
* (If you are using GDK or GTK+ the program name is set in gdk_init(),
* which is called by gtk_init(). The program name is found by taking
* the last component of literalargv[0]/literal.)
*
* Returns: the name of the program. The returned string belongs
* to GLib and must not be modified or freed.
*/
gchar*
g_get_prgname (void)
{
gchar* retval;
G_LOCK (g_prgname);
#ifdef G_OS_WIN32
if (g_prgname == NULL)
{
static gboolean beenhere = FALSE;
if (!beenhere)
{
gchar *utf8_buf = NULL;
wchar_t buf[MAX_PATH+1];
beenhere = TRUE;
if (GetModuleFileNameW (GetModuleHandle (NULL),
buf, G_N_ELEMENTS (buf)) 0)
utf8_buf = g_utf16_to_utf8 (buf, -1, NULL, NULL, NULL);
if (utf8_buf)
{
g_prgname = g_path_get_basename (utf8_buf);
g_free (utf8_buf);
}
}
}
#endif
retval = g_prgname;
G_UNLOCK (g_prgname);
return retval;
}
I hope this answers your question. It sure helped me to answer it :)
EMAILING FOR THE GREATER GOOD
Join me
Date: Mon, 19 Oct 2009 08:30:56 -0700
From: zheng.easy...@gmail.com
To: gtk-devel-list@gnome.org
Subject: Question about the default title of a GTK window
Hey pals, I am a new comer on GTK things.
I have some questions about it, would any one have time taking me over it?
Here is it:
1, What is the default title of a GTK window? I mean, if there is no string
was assigned to title of a GTK window, what will be exposed in the title bar
of said window?
2, Whether there is another interface for developers on setting title on GTK
window except gtk_window_set_title?
3, More specifications, will GTK framework take application name from
anywhere and set it as title into any untitled window in the application?
That all. Thanks alot.
--
View this message in context:
http://www.nabble.com/Question-about-the-default-title-of-a-GTK-window-tp25960347p25960347.html
Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[no subject]
Hi all, I have been working on developing an in-house ERPish application. I am using GTK as the front end, and with much scope creep, two years later, we are about to go production. We started on the Linux desktops but they lost out to the IMAC (all back end is still Linux). while researching whether Metacity themes work on OS X (perhaps I'm doing this part a bit late), In came across this link: http://markmail.org/message/wq35kgkjds37g5mv#query:gtk%20os%20x%20John%20Ralls+page:1+mid:iticcxa5wo4ce4nh+state:results Without the work that jraills has inherited (please let me know how I can help) I would be lost. I have mostly relied on what the OS X project has done to make this thing run. I am building the entire framework using jhbuildd I am able to create a fully self sustained bundle, drag and drop. But I must reflect jraills concern, if there is no work being done on the back-end, and at some point, my applications interface is going to be problematic... well yikes... I can't have that. There is not much longer before we put this thing on the desktop and it starts generating orders, PO's etc it is already the main inventory application. I have never done anything like this but I see all the FIXME in the gdkwindow-quartz.c , a functionality I was hoping to use that does not exists. I guess my question is, where did the rest of that mail chain go? Who is going to fix these? If the answer is no one, how do we get involved? Just fix it and submit patches? concerned GTK OS X user. EMAILING FOR THE GREATER GOOD Join me___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
