Re: Gtk-OSX
On Tue, 2010-09-07 at 14:21 -0400, Colin Walters wrote: > I think it makes sense to put gtk-doc.m4 inside glib (and the same for > introspection.m4). Shouldn't you be able to get away with the same hack that we use in GIMP ? http://git.gnome.org/browse/gimp/commit/?id=4f14da539118f7a4017c271b202c6c6ea304672b Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
I think it makes sense to put gtk-doc.m4 inside glib (and the same for introspection.m4). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On 06/09/10 21:39, John Ralls wrote:
On Sep 6, 2010, at 12:13 PM, Stefan Kost wrote:
I think I heard somewhere that you have a kind of dummy gtk-doc to
satisfy the build deps. I wonder if we can fix this somehow better.
Can you either ping me in #gtkdoc (gimpnet-irc), write to gtk-doc
mailing list or even to me in person and describe the problem. Also
let me know where I can look at the dummy package that you are
using.
The dummy gtk-doc I used a while back was stolen from Tor's work to get
Evolution going on Windows:
http://www.go-evolution.org/Building_Evolution_on_Windows#Fake_gtk-doc
No, it's gnome-doc-utils that's faked to satisfy the build deps,
along with a package of DocBook DTDs (that the real gnome-doc-utils
would provide if it wasn't faked). I thought that it had to do with
not wanting to deal with scrollkeeper, but that doesn't seem to have
anything to do with gnome-doc-utils. At this point, I don't really
know why it's there; perhaps one of the Lanedo folks still here knows
or can find out from Richard Hult. I'll experiment with just using
the real gnome-doc-utils instead.
As I recall (and this is from my Windows building GTK+ experience a
while back now), the reason was because autogen.sh / configure.{ac|in}
include gtk-doc m4 macros and so you have to have gtk-doc installed in
some capacity to actually get the build working.
Personally, I hate this. I have always thought that gtk-doc should be
build time optional and not in the sense that you disable building
project documentation but rather that you don't need any part of gtk-doc
to actually make your build work.
If I am out of date on any of these matters, then I will happily accept
corrections :)
If it works, then
gnome-doc-utils-fake and gtk-osx-docbook can go away. If it doesn't,
then when time permits I'll see about fixing it. It doesn't look like
either gnome-doc-utils-fake or gtk-osx-docbook should migrate to
gnome.org.
I would rather fix gtk-doc.
--
Regards,
Martyn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Sep 6, 2010, at 12:13 PM, Stefan Kost wrote: > > I think I heard somewhere that you have a kind of dummy gtk-doc to satisfy the > build deps. I wonder if we can fix this somehow better. Can you either ping me > in #gtkdoc (gimpnet-irc), write to gtk-doc mailing list or even to me in > person > and describe the problem. Also let me know where I can look at the dummy > package > that you are using. No, it's gnome-doc-utils that's faked to satisfy the build deps, along with a package of DocBook DTDs (that the real gnome-doc-utils would provide if it wasn't faked). I thought that it had to do with not wanting to deal with scrollkeeper, but that doesn't seem to have anything to do with gnome-doc-utils. At this point, I don't really know why it's there; perhaps one of the Lanedo folks still here knows or can find out from Richard Hult. I'll experiment with just using the real gnome-doc-utils instead. If it works, then gnome-doc-utils-fake and gtk-osx-docbook can go away. If it doesn't, then when time permits I'll see about fixing it. It doesn't look like either gnome-doc-utils-fake or gtk-osx-docbook should migrate to gnome.org. Gtk-doc works fine and is a supported module. I even used it to write the documentation for GtkOSXApplication. The code is at http://github.com/jralls/gnome-doc-utils-fake, but I doubt that you'll find it interesting. 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
Am 03.09.2010 02:48, schrieb John Ralls: > > On Sep 1, 2010, at 7:53 PM, John Ralls wrote: > >> >> On Sep 1, 2010, at 12:38 PM, Olav Vitters wrote: >> >>> On Tue, Aug 31, 2010 at 09:56:12AM -0700, John Ralls wrote: It's now on Sourceforge because when Richard decided with his partner wind up Imendio and to withdraw from Gtk+, he asked on his forum for someone to take over maintaining the build system. I bit, and after some probing discovered that he'd not been successful in getting anyone to take over *any* of the components; he had some hope that one or more of his former Imendio employees who were still involved with Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered that it would take some time and a lot of work to get a project started at Gnome.org. It took a week at Sourceforge, and only that long because I did a hostile takeover of a moribund project that was a fork of Gtk 1 whose name I wanted. >>> >>> If you want a Git account so you can commit to Gtk+, it should be pretty >>> easy. Three steps basically: >>> 1. For the person requesting it: follow http://live.gnome.org/NewAccounts >>> 2. A gtk+ maintainer: approving the Git account >>> 3. Accounts team: setting it up >>> >>> This can all be done very quickly. >>> >>> If for some reason there is a delay in above process, feel free to >>> send me a message. >> >> It seems likely that no. 2 will be the rub: I don't have a long track record >> compared to others who don't have git commit priv (Paul Davis comes to >> mind)... but maybe they never asked. So I just did. We'll see what happens, >> eh? > > > Well, much to my surprise, my Git account was approved in short order. > > So now the question is which pieces belong where? > > Gtk-quartz-engine already has a repo, so that's obvious. The > GtkOSXApplication half of ige-mac-integration can go in gtk+/gtk, and its > Python bindings to PyGtk if the devs over there are willing. > > But what about the build stuff and the proxy packages for docbook and > gtk-doc-utils? I think I heard somewhere that you have a kind of dummy gtk-doc to satisfy the build deps. I wonder if we can fix this somehow better. Can you either ping me in #gtkdoc (gimpnet-irc), write to gtk-doc mailing list or even to me in person and describe the problem. Also let me know where I can look at the dummy package that you are using. Stefan > Is there a logical home for them, should they have a new project on Gnome, or > should they stay on SourceForge? > > 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: Gtk-OSX
On Sep 3, 2010, at 4:30 PM, John Stowers wrote: >> its Python bindings to PyGtk if the devs over there are willing. > > Yip, that would be fine in theory (PyGtk). Could you please point me to > where the PyGtk code for this lives? I presume you are talking about > just the ige-mac-integration GtkOSXApplication bindings in GitHub? > > PyGtk will not see updates into the gtk+-3.0 series, so the code will > likely need to be annotated for gobject-introspection and then some > effort made into making sure all that stuff works on OSX, but based on > the current trend that will be a while away. > > Anyway, my goal is to make PyGtk feature complete (with the whole gtk > +-2.0), useful and stable before it enters maintenance mode with gtk > +-2.0. Yes, the code on Github. As for introspection, that won't work right now: https://bugzilla.gnome.org/show_bug.cgi?id=626995 I haven't yet made time to understand the scanner well enough to offer a patch (or to use it for the GtkOSXApplication bindings for that matter). As far as I'm concerned, there's no problem leaving the binding code on Github until PyGtk is ready to assimilate it -- or forever, for that matter. I think that having code on Github encourages potential contributors to have a go. 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
> its Python bindings to PyGtk if the devs over there are willing. Yip, that would be fine in theory (PyGtk). Could you please point me to where the PyGtk code for this lives? I presume you are talking about just the ige-mac-integration GtkOSXApplication bindings in GitHub? PyGtk will not see updates into the gtk+-3.0 series, so the code will likely need to be annotated for gobject-introspection and then some effort made into making sure all that stuff works on OSX, but based on the current trend that will be a while away. Anyway, my goal is to make PyGtk feature complete (with the whole gtk +-2.0), useful and stable before it enters maintenance mode with gtk +-2.0. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Sep 1, 2010, at 7:53 PM, John Ralls wrote: > > On Sep 1, 2010, at 12:38 PM, Olav Vitters wrote: > >> On Tue, Aug 31, 2010 at 09:56:12AM -0700, John Ralls wrote: >>> It's now on Sourceforge because when Richard decided with his partner >>> wind up Imendio and to withdraw from Gtk+, he asked on his forum for >>> someone to take over maintaining the build system. I bit, and after >>> some probing discovered that he'd not been successful in getting >>> anyone to take over *any* of the components; he had some hope that one >>> or more of his former Imendio employees who were still involved with >>> Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered >>> that it would take some time and a lot of work to get a project >>> started at Gnome.org. It took a week at Sourceforge, and only that >>> long because I did a hostile takeover of a moribund project that was a >>> fork of Gtk 1 whose name I wanted. >> >> If you want a Git account so you can commit to Gtk+, it should be pretty >> easy. Three steps basically: >> 1. For the person requesting it: follow http://live.gnome.org/NewAccounts >> 2. A gtk+ maintainer: approving the Git account >> 3. Accounts team: setting it up >> >> This can all be done very quickly. >> >> If for some reason there is a delay in above process, feel free to >> send me a message. > > It seems likely that no. 2 will be the rub: I don't have a long track record > compared to others who don't have git commit priv (Paul Davis comes to > mind)... but maybe they never asked. So I just did. We'll see what happens, > eh? Well, much to my surprise, my Git account was approved in short order. So now the question is which pieces belong where? Gtk-quartz-engine already has a repo, so that's obvious. The GtkOSXApplication half of ige-mac-integration can go in gtk+/gtk, and its Python bindings to PyGtk if the devs over there are willing. But what about the build stuff and the proxy packages for docbook and gtk-doc-utils? Is there a logical home for them, should they have a new project on Gnome, or should they stay on SourceForge? 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
On Wed, Sep 1, 2010 at 10:53 PM, John Ralls wrote: > It seems likely that no. 2 will be the rub: I don't have a long track record > compared to others who don't have git commit priv (Paul Davis comes to > mind)... but maybe they never asked. So I just did. We'll see what happens, > eh? just for correctness: i do have it. but i'm an old fart and i don't trust myself with git, so i have yet to use it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Sep 1, 2010, at 12:38 PM, Olav Vitters wrote: > On Tue, Aug 31, 2010 at 09:56:12AM -0700, John Ralls wrote: >> It's now on Sourceforge because when Richard decided with his partner >> wind up Imendio and to withdraw from Gtk+, he asked on his forum for >> someone to take over maintaining the build system. I bit, and after >> some probing discovered that he'd not been successful in getting >> anyone to take over *any* of the components; he had some hope that one >> or more of his former Imendio employees who were still involved with >> Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered >> that it would take some time and a lot of work to get a project >> started at Gnome.org. It took a week at Sourceforge, and only that >> long because I did a hostile takeover of a moribund project that was a >> fork of Gtk 1 whose name I wanted. > > If you want a Git account so you can commit to Gtk+, it should be pretty > easy. Three steps basically: > 1. For the person requesting it: follow http://live.gnome.org/NewAccounts > 2. A gtk+ maintainer: approving the Git account > 3. Accounts team: setting it up > > This can all be done very quickly. > > If for some reason there is a delay in above process, feel free to > send me a message. It seems likely that no. 2 will be the rub: I don't have a long track record compared to others who don't have git commit priv (Paul Davis comes to mind)... but maybe they never asked. So I just did. We'll see what happens, eh? 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
On Tue, Aug 31, 2010 at 09:56:12AM -0700, John Ralls wrote: > It's now on Sourceforge because when Richard decided with his partner > wind up Imendio and to withdraw from Gtk+, he asked on his forum for > someone to take over maintaining the build system. I bit, and after > some probing discovered that he'd not been successful in getting > anyone to take over *any* of the components; he had some hope that one > or more of his former Imendio employees who were still involved with > Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered > that it would take some time and a lot of work to get a project > started at Gnome.org. It took a week at Sourceforge, and only that > long because I did a hostile takeover of a moribund project that was a > fork of Gtk 1 whose name I wanted. If you want a Git account so you can commit to Gtk+, it should be pretty easy. Three steps basically: 1. For the person requesting it: follow http://live.gnome.org/NewAccounts 2. A gtk+ maintainer: approving the Git account 3. Accounts team: setting it up This can all be done very quickly. If for some reason there is a delay in above process, feel free to send me a message. If you think it is better to have other resources (mailing list), just file a bug at Bugzilla, for details see http://live.gnome.org/NewListRequest. Best to get started with the Git account first. Above and other infrastructure procedures are documented at: http://live.gnome.org/Infrastructure Note that I don't see a Gtk+ OSX backend as any different from Gtk+. IMO you could use a branch in gtk+ or commit directly. However, I'm not a maintainer, talk to them. If you need anything Bugzilla related, file a bug in the bugzilla.gnome.org product. Need permissions? Contact Bugsquad. In all above cases (except Gtk+ maintainership ;), if you need assistance, feel free to contact me. -- Regards, Olav (GNOME sysadmin, bugzilla maintainer) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Sep 1, 2010, at 8:15 PM, Shawn Bakhtiar wrote: > 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 FYI, this is absolutely not a sound way of judging software quality. Some developers add a lot of FIXME comments when they are writing the code, some don't, some only do when they feel like it. So counting FIXMEs says *nothing* at all. To put it into more perspective: > 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 A lot of these FIXMEs are for deprecated functionality or very X11-specific things. You will see a lot of FIXMEs disappear in the GTK+ 3 branch. Again, it says nothing about the actual quality. -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Wed, 1 Sep 2010, Martyn Russell wrote: > Alberto++ :) Me too. > If GTK+ *runs* on [various] platforms, then why shouldn't we > include the support details on gtk.org? > > Again, to iterate my point, the end user developing their project would > rather see supported ports of the toolkit on one website than as > sub-projects somewhere else, regardless of the % of feature complete > widgets. Martyn++; > You do make one important point, perhaps we should be detailing the > level of feature completeness on Windows and MAC? Yes. And in regard to OS X we also should explain that the X11 version of GTK+ works fine. X11 != Linux && Linux != Gnome. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 : > > 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-the
Re: Gtk-OSX
On 01/09/10 18:17, Alberto Ruiz wrote: Hello Shawn, 2010/9/1 Shawn Bakhtiar: 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? Alberto++ :) If GTK+ *runs* on these platforms, then why shouldn't we include the support details on gtk.org? Again, to iterate my point, the end user developing their project would rather see supported ports of the toolkit on one website than as sub-projects somewhere else, regardless of the % of feature complete widgets. You do make one important point, perhaps we should be detailing the level of feature completeness on Windows and MAC? -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
Hello Shawn, 2010/9/1 Shawn Bakhtiar : > 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 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 wo
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 w
Re: Gtk-OSX
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 provide PR, documentation, and support on his former company's (Imendio.AB) website, and downloads at a private domain (www.gtk-macosx.org). It's now on Sourceforge because when Richard decided with his partner wind up Imendio and to withdraw from Gtk+, he asked on his forum for someone to take over maintaining the build system. I bit, and after some probing discovered that he'd not been successful in getting anyone to take over *any* of the components; he had some hope that one or more of his former Imendio employees who were still involved with Gtk+ would take over maintaining the Gtk+ parts. I quickly discovered that it would take some time and a lot of work to get a project started at Gnome.org. It took a week at Sourceforge, and only that long because I did a hostile takeover of a moribund project that was a fork of Gtk 1 whose na
Re: Gtk-OSX
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? -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On Mon, Aug 30, 2010 at 11:46 PM, Michael Torrie wrote: > This is only partially true. Some apps ship as an .mpkg installer, > which is really a bunch of separate, dependant packages that install > together. But under the hood they are installed as separate packages > with dependency resolution. That's true, I did ignore mpkg's. I'm not sure what the split is between apps that distribute as a .app or a .mpkg ... > As for users not expecting to have to install some dependency, on app in > common use, MacFusion, requires that the MacFuse .pkg be installed. This is an exception that proves the rule. > Also Office 2008 requires the Rosetta .pkg package to be installed, but > helpfully offers to install it for you. Actually, this appears to just be just laziness on the part of MS. Rosetta seems not to be needed: http://forums.mactalk.com.au/11/72330-install-microsoft-office-2008-snow-leopard-without-rosetta.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On 08/30/2010 08:51 AM, Paul Davis wrote: > The logic is that despite its "*nix-type" infrastructure, this is how > Apple has intended ISV's to distribute software, and as a result, its > what users expect. You will rarely (if ever) see an OS X application > that has a list of prequisites other than a particular version of OS X > and perhaps some hardware. The notion that "too use this app, you also > need to have the FOO framework installed" just isn't something that > exists in the OS X user culture. This is only partially true. Some apps ship as an .mpkg installer, which is really a bunch of separate, dependant packages that install together. But under the hood they are installed as separate packages with dependency resolution. As for users not expecting to have to install some dependency, on app in common use, MacFusion, requires that the MacFuse .pkg be installed. Also Office 2008 requires the Rosetta .pkg package to be installed, but helpfully offers to install it for you. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Mon, 30 Aug 2010, Paul Davis wrote: > On Mon, Aug 30, 2010 at 9:47 AM, Allin Cottrell wrote: > > On Mon, 30 Aug 2010, Tor Lillqvist wrote: > > > >> > It has certainly been explained that that is the situation on > >> > Windows, and I fully accept it. It's less clear that it should be > >> > the situation on OS X, with its *nix-type substructure. > >> > >> You have it backwards. It was from the GTK-on-OS-X people (well, at > >> least those that I have heard from) that this convention originated. > >> Only a bit later did the GTK+-on-Windows people (well, many of us, not > >> all) realize the same. > > > > I was interested in the logic rather than the history, > > The logic is that despite its "*nix-type" infrastructure, this is how > Apple has intended ISV's to distribute software, and as a result, its > what users expect... OK, you make a good case for this. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Mon, Aug 30, 2010 at 9:47 AM, Allin Cottrell wrote: > On Mon, 30 Aug 2010, Tor Lillqvist wrote: > >> > It has certainly been explained that that is the situation on >> > Windows, and I fully accept it. It's less clear that it should be >> > the situation on OS X, with its *nix-type substructure. >> >> You have it backwards. It was from the GTK-on-OS-X people (well, at >> least those that I have heard from) that this convention originated. >> Only a bit later did the GTK+-on-Windows people (well, many of us, not >> all) realize the same. > > I was interested in the logic rather than the history, The logic is that despite its "*nix-type" infrastructure, this is how Apple has intended ISV's to distribute software, and as a result, its what users expect. You will rarely (if ever) see an OS X application that has a list of prequisites other than a particular version of OS X and perhaps some hardware. The notion that "too use this app, you also need to have the FOO framework installed" just isn't something that exists in the OS X user culture. People shipping apps for OS X package up everything their app needs that isn't part of OS X itself. And yes, this causes all kinds of potential security issues and all the rest that Linux distributions hate about things like AppImage, but for better or for worse, that is the way Apple wants things to be. It is hard for it be otherwise without the kind of centralized repositories that most linux distributions use, and faced with DLL hell as the alternative, I guess Apple felt that the all-in-one package was the best option. Regardless of whether it is or isn't, its what people have come to expect. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Mon, 30 Aug 2010, Tor Lillqvist wrote: > > It has certainly been explained that that is the situation on > > Windows, and I fully accept it. It's less clear that it should be > > the situation on OS X, with its *nix-type substructure. > > You have it backwards. It was from the GTK-on-OS-X people (well, at > least those that I have heard from) that this convention originated. > Only a bit later did the GTK+-on-Windows people (well, many of us, not > all) realize the same. I was interested in the logic rather than the history, and I don't think I had that backwards. But anyway, I'm OK with assuming that a common user-runtime for GTK is not on. > > I don't think that invalidates the idea that it would be very > > useful for app developers to have a GTK runtime package > > available, as we do for Windows. > > As usual, people seem to be constantly jumping between talking about > "packages" for developers, and "packages" for end-users. There is no > "officially sanctioned" GTK end-user runtime package for Windows > available, in the sense that it would be something that could/should > be installed as such on end-user systems. It's the developer and/or > packager that is expected to pick out those files his application > actually needs at run-time from the run-time zip archives on > ftp.gnome.org (or from the "bundle" which just combines all the > run-time and developer zip archives for the GTK+ stack). This is not > the same set of files for all applications. Maybe "runtime package" was the wrong choice of words, but I didn't intend anything thst contradicts what you're saying. As an app developer I'm happy to select what I need from the run-time zip archives for Windows. You have done us a major service by making those archives available. I'd like to be able to do the same for OS X (if a common runtime package for users is deemed infeasible or undesirable). Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
> It has certainly been explained that that is the situation on > Windows, and I fully accept it. It's less clear that it should be > the situation on OS X, with its *nix-type substructure. You have it backwards. It was from the GTK-on-OS-X people (well, at least those that I have heard from) that this convention originated. Only a bit later did the GTK+-on-Windows people (well, many of us, not all) realize the same. > I don't think that > invalidates the idea that it would be very useful for app > developers to have a GTK runtime package available, as we do for > Windows. As usual, people seem to be constantly jumping between talking about "packages" for developers, and "packages" for end-users. There is no "officially sanctioned" GTK end-user runtime package for Windows available, in the sense that it would be something that could/should be installed as such on end-user systems. It's the developer and/or packager that is expected to pick out those files his application actually needs at run-time from the run-time zip archives on ftp.gnome.org (or from the "bundle" which just combines all the run-time and developer zip archives for the GTK+ stack). This is not the same set of files for all applications. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Sun, 29 Aug 2010, Paul Davis wrote:
> On Fri, Aug 27, 2010 at 4:17 PM, Allin Cottrell wrote:
> > On Fri, 27 Aug 2010, Kristian Rietveld wrote:
> >
> >> 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.
> >
> > I'm aware it's not an easy task. That's why I'm requesting that
> > such a runtime package be made available as a download via gtk.org
> > (and offering to help in building one to the extent I'm able).
>
> its been explained quite a few times before that applications that use
> GTK and ship a bundle for OS X will almost certainly include GTK
> *inside* the bundle. providing standalone GTK frameworks is almost
> useless for users.
It has certainly been explained that that is the situation on
Windows, and I fully accept it. It's less clear that it should be
the situation on OS X, with its *nix-type substructure.
But even if we suppose that the best way to distribute a GTK app
for OS X is with GTK bundled internally, I don't think that
invalidates the idea that it would be very useful for app
developers to have a GTK runtime package available, as we do for
Windows. As things stand, rolling your own GTK for OS X is a
significant hurdle, and one that doesn't really have to be there.
Allin Cottrell
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Mon, Aug 30, 2010 at 5:43 AM, Alberto Ruiz wrote: > Hello Paul, > > 2010/8/30 Paul Davis : >>> 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. >> >> this is pretty obnoxious. > >> i don't know how tor manages to keep his temper with the windows port, > > This is a resources issue, most of the existing developers are focused > on Linux, and they have no resources/time to focus on Windows > development. > I have contributed several improvements to improve the Windows support > and I have felt more than welcome to do so. I wasn't disputing the resource issue. But there are (at least) two approaches to the resource issue. One is to say "well, we don't have enough (or the right) person-hours to implement this for all backends, but we will go ahead and do it anyway; the backends will catch up when someone does the work there". Another would be to say "well, we don't have enough (or the right) person-hours to implement this for all backends, and because its going to break/change the semantics/stop compilation on some of them, and because GTK is trying to be a cross-platform toolkit, we won't actually push this change until we can figure out how to get it in place for all the backends". Now there is clearly a perfectly good rationale for choosing the first approach - most GTK developers and most GTK users are on X11 platforms, and yes, viewed from that perspective, it doesn't make sense to hold up the development of GTK because of a lack of human resources for other backends. But then if that is the decision, it also doesn't make sense to claim that the sense of "other backends don't really count" is so clearly wrong. Let me give you a recent example, although I am wary of doing so because I don't want to make it appear that I'm being critical of the design decisions of process that was involved. There is work going on for GTK+3 to add a GApplication object to Glib and probably a GtkApplication object to GTK. I've had quite a few discussions on IRC about what this might need to look like to be useful on OS X, and I think that because of this, the result will not be too hard to "port" to OS X (and probably Windows too). But ... the clearly overriding goal for this object has been to provide some functionality for a GNOME/X11 platform, functionality that is already present on OS X and Windows c/o the OS. So although other platforms are loosely taken into account by the design process of this potentially central part of Glib/GTK, the actual reality is that it will provide almost no functionality for apps on other platforms, and will instead be a way to get some specific (very useful) things done within the context of GNOME and DBus. To stress again, there is NOTHING WRONG WITH THIS. I don't have any disagreement with the way things have happened, but I also know that it reinforces *my* personal feeling that for most of the core GTK development team, GTK is an X11/GNOME toolkit that happens to run on other platfoms to some extent, rather than a cross-platform toolkit that happens to have some specific support for GNOME. Its therefore no suprise that John and perhaps some others should feel a little "edge-dweller-ish" in their efforts to get GTK fully implemented on OS X. > So yeah, I totally support Matthias here, if you want a better > situation, feel free to JFDI. Everytime I've needed something in the OS X backend, I've had to JFDI and have. I've made numerous improvements to the OS X backend, and will continue to do so on as-needed basis because I already have a full time job as a developer of an app that is actually *using* GTK. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
Hello Paul, 2010/8/30 Paul Davis : >> 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. > > this is pretty obnoxious. > i don't know how tor manages to keep his temper with the windows port, This is a resources issue, most of the existing developers are focused on Linux, and they have no resources/time to focus on Windows development. I have contributed several improvements to improve the Windows support and I have felt more than welcome to do so. So this is not obnoxious at all, if the people with the focus and time actually helped, the situation would be a lot better, what you can't ask is that the development of Gtk+ to be stalled until someone shows up and helps with the Windows or Mac OS X port to make a given change. So yeah, I totally support Matthias here, if you want a better situation, feel free to JFDI. -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Fri, Aug 27, 2010 at 12:48 PM, Matthias Clasen wrote: > On Fri, Aug 27, 2010 at 12:35 AM, John Ralls wrote: > >> 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/. > > 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. this is pretty obnoxious. i don't know how tor manages to keep his temper with the windows port, but the truth is as john stated it: the core GTK development team has *consistently* demonstrated that its considered fine to implement something/change something for the linux port with the expectation that other backends will just follow along. i have lots of IRC quotes to support this claim, quite apart from the history provided by git. the people working on gtk-osx (which at this point is pretty much kristian plus a few occasional patch providers) do not consider *themselves* to be in an us-vs-them situation IMHO. instead, the attitude consistently displayed on IRC and this channel supports a view of the world in which the core parts of GTK are developed for the linux/gnome platform and then the rest of the world might, at some point, follow along. the very idea of trying to implement major new functionality on all supported backends before its committed to git (or certainly before its released) seems like an anathema to the development process. ***which of course is fine*** as long as you then don't go and get upset when people whose major focus is a backend other than the the linux/X11 one feel distinctly edge-dweller-like when yet another change to GTK is done without much consideration of their chosen platform. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Fri, Aug 27, 2010 at 4:17 PM, Allin Cottrell wrote:
> On Fri, 27 Aug 2010, Kristian Rietveld wrote:
>
>> 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.
>
> I'm aware it's not an easy task. That's why I'm requesting that
> such a runtime package be made available as a download via gtk.org
> (and offering to help in building one to the extent I'm able).
its been explained quite a few times before that applications that use
GTK and ship a bundle for OS X will almost certainly include GTK
*inside* the bundle. providing standalone GTK frameworks is almost
useless for users.
> GTK-OSX is focused on a native Quartz build but I'm talking about
> an X11 build (taking at face value the statement on GTK-OSX that
> the Quartz port is still immature).
the extent to which is it immature has been overstated in this thread.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Fri, 27 Aug 2010, Kristian Rietveld wrote:
> 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.
I'm aware it's not an easy task. That's why I'm requesting that
such a runtime package be made available as a download via gtk.org
(and offering to help in building one to the extent I'm able).
GTK-OSX is focused on a native Quartz build but I'm talking about
an X11 build (taking at face value the statement on GTK-OSX that
the Quartz port is still immature). Building GTK+ for Windows is
not an easy task either, and it's _very_ helpful that app
developers are able to download a well-built runtime.
Allin Cottrell
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Thu, 26 Aug 2010, John Ralls wrote: [ in response to http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00244.html ] > Gtk-OSX is *not* part of Gtk+. Well, perhaps that's the problem right there. I've got nothing "personal" against Gtk-OSX but it seems that the main GTK site should not be sending people who are interested in GTK on OS X directly to http://gtk-osx.sourceforge.net/ . There should be a link, obviously, but it should be subsidiary to a more general account of GTK on OS X, which -- as things stand right now -- is probably going to mean GTK-X11 for most uses. > Building Gtk-Xll on OSX isn't Gtk-OSX's department. OK, I understand that, but I think it should be GTK's department. > Try http://www.macports.org/ and http://www.finkproject.org/ for > that. You can install GTK via Fink, but that's not what I'm talking about. It's much too complicated for most users. I'm talking about a pre-built GTK Framework bundle that you can install by simple point-and-click. As I mentioned, the R project people have such an installer, and IMO the same should be available from the main GTK site. > My experience with Gnucash is that there are few Mac users who > even know what X11 is, and even fewer who want to deal with it. Since Leopard, at least, Mac users don't have to know anything about X11 to use it as a means of running GTK apps. They just install two bundles, the GTK one and the app one (or they could even be combined). The bundled app contains the "magic" for starting X11 on demand. The only downside is that the GTK app is a little "foreign" in some ways, but if the app is useful enough people can get over that pretty quickly. I've used my GTK statistical app with my students, both PC and Mac users, and the Mac users don't seem to have any special difficulty with using it. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Fri, Aug 27, 2010 at 12:35 AM, John Ralls wrote: > 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/. 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 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: Gtk-OSX (was: Website proposal for usability)
On Fri, Aug 27, 2010 at 6:35 AM, John Ralls 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
Re: Gtk-OSX (was: Website proposal for usability)
Hi John, 2010/8/27 John Ralls : > > Gtk-OSX is *not* part of Gtk+. Maybe that's something we should fix? Resources around Gtk+ are already way too fragmented. -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX (was: Website proposal for usability)
On Aug 26, 2010, at 8:08 PM, Allin Cottrell wrote: > On Thu, 26 Aug 2010, Devin Samarin wrote: > >> I moved the URL from >> >> http://eboyjr.homelinux.org:8080/gtk/ >> to >> http://eboyjr.homelinux.org:8081/ > > This looks good to me. But given that the website is getting a lot > of attention, I'd like to suggest one area where the content needs > to be changed: the material relating to GTK on OS X. > > The new draft site basically does what the old one does, namely > hands off to http://gtk-osx.sourceforge.net/ for everything to do > with OS X. But that site has some serious problems. It has an > old-fashioned, clunky look. Worse, the author(s) spell the name of > the target operating system incorrectly: Apple's OS X is > consistently referred to as "OSX". Much worse still, it gives an > overall impression of pessimism and disarray. To quote: > > "The native Quartz display is handled by libgdk-quartz and > libgtk-quartz... Unfortunately, these libraries are not yet > feature-complete. What's more, while most other Gnome > functionality can be made to work on OSX, few if any of the > developers have any interest [sic] cross-platform compatibility. > Developers considering GTK+ as a cross-platform environment for > new work are advised to evaluate other toolkits carefully before > committing to GTK if they consider OSX an important market." > > A nice advertisement -- not! > > It may be that the Quartz port of GTK is stalled. (It looks that > way, though I'm not an expert on the topic.) But if that's so, I > can think of a good reason why it might be: Apple ships a decent > X11 implementation with current OS X, and installs it by default, > so that GTK apps work well on the Mac without GtkQuartz. Sure, it > would be nice to have totally native GTK apps on the Mac, but > that's a luxury and I can imagine why working on it might not > motivate many people all that strongly. > > IMO, the site for GTK on OS X should "accentuate the positive" > (i.e. GTK-X11 works well) while also talking about the Quartz port > objectively and (if this makes sense) encouraging developers who > are fans of both GTK and OS X to contribute. > > One more thing: the site should offer a downloadable binary > runtime package for X11-based GTK on the Mac. Many GTK app > developers, I suspect, develop on Linux but wish to offer Windows > and Mac versions. We don't necessarily have time, opportunity or > interest to build the whole GTK stack for the target OS. > (Cross-compilation is of course not trivial.) We can download a > Windows GTK runtime to distribute, and that's great. It would be a > big step forward if we could also download a Mac runtime. > > 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. > Gtk-OSX is *not* part of Gtk+. Sorry you don't like the website. It isn't intended to be flashy or an advertisement. It's intended to show developers who want to port their Gtk+ applications to native Quartz and make a shippable bundle that Mac users will actually try out. 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/. Building Gtk-Xll on OSX isn't Gtk-OSX's department. Try http://www.macports.org/ and http://www.finkproject.org/ for that. My experience with Gnucash is that there are few Mac users who even know what X11 is, and even fewer who want to deal with it. For the most part they want a draggable app bundle, though they'll put up with an installer bundle if they have to. They certainly don't want to go through the pain of building Fink or Macports only to have the whole thing fail because the packager of x requires a newer version of foo than the packager of x's dependency y, and upgrading foo deletes y. (Yes, that happens. Often.) (In case you're wondering, I do this because there are a couple of Gtk+ applications that I want to use, and I don't want to have to deal with X11, or put up with the version-hell that plagues Fink and Macports.) Regards, John Ralls ___
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 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
Re: Gtk-OSX Frameworks (was: Why are developers...)
On Nov 10, 2009, at 8:32 PM, Jon Cruz wrote: On Nov 10, 2009, at 5:44 PM, John Ralls wrote: For those who prefer a web forum, we have one of those, too, at http://sourceforge.net/apps.sourceforge.net/phpbb/gtk-osx/ You need to sign up for a sourceforge userid to post to it. 404 on that forum link Sorry, that's an old link. I'll have to update the Support page, too. The correct link is: http://sourceforge.net/apps/phpbb/gtk-osx/ Thanks for pointing it out. 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...)
On Nov 10, 2009, at 5:44 PM, John Ralls wrote: > For those who prefer a web forum, we have one of those, too, at > http://sourceforge.net/apps.sourceforge.net/phpbb/gtk-osx/ > You need to sign up for a sourceforge userid to post to it. 404 on that forum link ___ 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...)
On Nov 10, 2009, at 4:57 PM, Shawn Bakhtiar wrote: Re-build using jhbuild today: Let's not clutter up this list with support requests for Gtk-OSX. Gtk- OSX has its own support mailing list at gtk-osx-us...@lists.sourceforge.net ; you can subscribe at http://lists.sourceforge.net/lists/listinfo/gtk-osx-users/subscribe For those who prefer a web forum, we have one of those, too, at http://sourceforge.net/apps.sourceforge.net/phpbb/gtk-osx/ You need to sign up for a sourceforge userid to post to it. 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...)
_ADDRESS at address: 0x018639f8
0x00010001a3c6 in isi_app_setup_menu (self=0x10201b000) at isiapp.c:2583
2583if(self->priv->user_perms != NULL && self->priv->user_perms->rows
!= NULL){
(gdb) bt
#0 0x00010001a3c6 in isi_app_setup_menu (self=0x10201b000) at isiapp.c:2583
#1 0x00010001b816 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
Re: Gtk-OSX Frameworks (was: Why are developers...)
On Nov 10, 2009, at 7:32 PM, John Ralls wrote: On Nov 10, 2009, at 9:20 AM, Jacob Juul Kolding wrote: 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: Please rerun gtk-osx-build-install.sh to get the most recent jhbuildrc. You'll have to build 32-bit to use ige-mac-integration (it uses Carbon), but the latest jhbuildrc skips it for you if you build for 64-bit. (For now, you can just abandon the module; everything else is built.) But how do I build the framework or other apps without the ige stuff? Jacob Kolding dac...@juvul.com Regards, John Ralls smime.p7s Description: S/MIME cryptographic signature ___ 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...)
On Nov 10, 2009, at 9:20 AM, Jacob Juul Kolding wrote: 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: Please rerun gtk-osx-build-install.sh to get the most recent jhbuildrc. You'll have to build 32-bit to use ige-mac-integration (it uses Carbon), but the latest jhbuildrc skips it for you if you build for 64-bit. (For now, you can just abandon the module; everything else is built.) 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...)
tributes’ ige-mac-menu.c:337: warning: nested extern declaration of ‘ChangeMenuItemAttributes’ ige-mac-menu.c: In function ‘carbon_menu_item_update_active’: ige-mac-menu.c:347: warning: implicit declaration of function ‘CheckMenuItem’ ige-mac-menu.c:347: warning: nested extern declaration of ‘CheckMenuItem’ ige-mac-menu.c: In function ‘carbon_menu_item_update_submenu’: ige-mac-menu.c:361: warning: implicit declaration of function ‘SetMenuItemHierarchicalMenu’ ige-mac-menu.c:361: warning: nested extern declaration of ‘SetMenuItemHierarchicalMenu’ ige-mac-menu.c:367: warning: implicit declaration of function ‘CreateNewMenu’ ige-mac-menu.c:367: warning: nested extern declaration of ‘CreateNewMenu’ ige-mac-menu.c:373: warning: implicit declaration of function ‘SetMenuTitleWithCFString’ ige-mac-menu.c:373: warning: nested extern declaration of ‘SetMenuTitleWithCFString’ ige-mac-menu.c: In function ‘carbon_menu_item_update_label’: ige-mac-menu.c:394: warning: implicit declaration of function ‘SetMenuItemTextWithCFString’ ige-mac-menu.c:394: warning: nested extern declaration of ‘SetMenuItemTextWithCFString’ ige-mac-menu.c: In function ‘carbon_menu_item_update_accelerator’: ige-mac-menu.c:417: warning: implicit declaration of function ‘SetMenuItemModifiers’ ige-mac-menu.c:417: warning: nested extern declaration of ‘SetMenuItemModifiers’ ige-mac-menu.c:423: warning: implicit declaration of function ‘SetMenuItemCommandKey’ ige-mac-menu.c:423: warning: nested extern declaration of ‘SetMenuItemCommandKey’ ige-mac-menu.c: In function ‘carbon_menu_item_create’: ige-mac-menu.c:588: warning: implicit declaration of function ‘InsertMenuItemTextWithCFString’ ige-mac-menu.c:588: warning: nested extern declaration of ‘InsertMenuItemTextWithCFString’ ige-mac-menu.c:592: warning: implicit declaration of function ‘SetMenuItemProperty’ ige-mac-menu.c:592: warning: nested extern declaration of ‘SetMenuItemProperty’ ige-mac-menu.c: In function ‘nsevent_handle_menu_key’: ige-mac-menu.c:724: warning: implicit declaration of function ‘IsMenuKeyEvent’ ige-mac-menu.c:724: warning: nested extern declaration of ‘IsMenuKeyEvent’ ige-mac-menu.c:727: warning: implicit declaration of function ‘GetMenuItemCommandID’ ige-mac-menu.c:727: warning: nested extern declaration of ‘GetMenuItemCommandID’ ige-mac-menu.c:740: warning: implicit declaration of function ‘GetMenuID’ ige-mac-menu.c:740: warning: nested extern declaration of ‘GetMenuID’ ige-mac-menu.c:742: warning: implicit declaration of function ‘GetMenuEventTarget’ ige-mac-menu.c:742: warning: nested extern declaration of ‘GetMenuEventTarget’ ige-mac-menu.c:742: warning: passing argument 2 of ‘SendEventToEventTarget’ makes pointer from integer without a cast ige-mac-menu.c: In function ‘sync_menu_shell’: ige-mac-menu.c:921: warning: implicit declaration of function ‘GetMenuAttributes’ ige-mac-menu.c:921: warning: nested extern declaration of ‘GetMenuAttributes’ ige-mac-menu.c:927: warning: implicit declaration of function ‘ChangeMenuAttributes’ ige-mac-menu.c:927: warning: nested extern declaration of ‘ChangeMenuAttributes’ ige-mac-menu.c: In function ‘parent_set_emission_hook_remove’: ige-mac-menu.c:988: warning: implicit declaration of function ‘ClearMenuBar’ ige-mac-menu.c:988: warning: nested extern declaration of ‘ClearMenuBar’ ige-mac-menu.c:989: warning: implicit declaration of function ‘DeleteMenu’ ige-mac-menu.c:989: warning: nested extern declaration of ‘DeleteMenu’ ige-mac-menu.c: In function ‘window_focus’: ige-mac-menu.c:1001: warning: implicit declaration of function ‘SetRootMenu’ ige-mac-menu.c:1001: warning: nested extern declaration of ‘SetRootMenu’ ige-mac-menu.c: In function ‘ige_mac_menu_set_quit_menu_item’: ige-mac-menu.c:1068: warning: implicit declaration of function ‘GetIndMenuItemWithCommandID’ ige-mac-menu.c:1068: warning: nested extern declaration of ‘GetIndMenuItemWithCommandID’ ige-mac-menu.c:1071: warning: implicit declaration of function ‘SetMenuItemCommandID’ ige-mac-menu.c:1071: warning: nested extern declaration of ‘SetMenuItemCommandID’ make[2]: *** [libigemacintegration_la-ige-mac-menu.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 *** Error during phase build of ige-mac-integration: ## Error running make *** [10/11] Anyone? /Jacob 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 > > 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
Re: Gtk-OSX Frameworks (was: Why are developers...)
On Nov 10, 2009, at 7:46 AM, Shawn Bakhtiar wrote: 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! On Nov 10, 2009, at 7:54 AM, Tristan Van Berkom wrote: On Tue, Nov 10, 2009 at 1:10 PM, John Ralls wrote: Guys, I just wanted to take this ridiculously appropriate opportunity to congratulate you on the great improvements on the OSX build I've seen this year. I by chance had a contract that involved building a GTK+/GStreamer application that primarily had to run on OSX; two very notable results: a.) I started doing osx builds of Glade, and even did the ige-mac-integration thing, just because it was so damn easy to do, that says alot because I've really had next to no time this year for hacking Glade. b.) I started to appreciate jhbuild for the first time, actually now I just stay on osx and do anything GTK+ related on osx, just because damn it builds so easy on osx, easier than on ubuntu (hell I even built nbtk on my MacBook last week just for the hell of it, I only had to hack the clipboard code and run an unstable clutter). So thanks for making my job so easy, and thanks for making Glade and other GNOME apps easily available on OS X ;-) Cheers, -Tristan Thanks. 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...)
On Tue, Nov 10, 2009 at 1:10 PM, John Ralls wrote: > > On Nov 10, 2009, at 4:16 AM, Paul Davis wrote: > >> On Mon, Nov 9, 2009 at 1:10 PM, Jack Skellington wrote: >> Guys, I just wanted to take this ridiculously appropriate opportunity to congratulate you on the great improvements on the OSX build I've seen this year. I by chance had a contract that involved building a GTK+/GStreamer application that primarily had to run on OSX; two very notable results: a.) I started doing osx builds of Glade, and even did the ige-mac-integration thing, just because it was so damn easy to do, that says alot because I've really had next to no time this year for hacking Glade. b.) I started to appreciate jhbuild for the first time, actually now I just stay on osx and do anything GTK+ related on osx, just because damn it builds so easy on osx, easier than on ubuntu (hell I even built nbtk on my MacBook last week just for the hell of it, I only had to hack the clipboard code and run an unstable clutter). So thanks for making my job so easy, and thanks for making Glade and other GNOME apps easily available on OS X ;-) Cheers, -Tristan >>> 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 > ___ 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
> > 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?
>
Re: Gtk-OSX Frameworks (was: Why are developers...)
On Nov 10, 2009, at 4:16 AM, Paul Davis wrote: On Mon, Nov 9, 2009 at 1:10 PM, Jack Skellington 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
Sorry im a fool, i assume these distros are the same, it did meantion of overwriting the normal X11 ? I was hoping of a way to compile gtk and run gtk apps without X11 hence my waste of time on 10.3.9 On 08/02/2006, at 9:21 PM, Goran Rakić wrote: You can use Apple X11 (X11.app from developer tools on install cd) and gtk+ from Fink project... On 08.02.2006., at 09.59, electroteque wrote: Yeh i prob missed that one, so it does need the Quartz stuff, i just wasted my time :D Im looking now @ Xdarwin instead :D On 08/02/2006, at 7:33 PM, Richard Hult wrote: ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk + OSX
You can use Apple X11 (X11.app from developer tools on install cd) and gtk+ from Fink project... On 08.02.2006., at 09.59, electroteque wrote: Yeh i prob missed that one, so it does need the Quartz stuff, i just wasted my time :D Im looking now @ Xdarwin instead :D On 08/02/2006, at 7:33 PM, Richard Hult wrote: ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk + OSX
Yeh i prob missed that one, so it does need the Quartz stuff, i just wasted my time :D Im looking now @ Xdarwin instead :D On 08/02/2006, at 7:33 PM, Richard Hult wrote: Hi, electroteque wrote: In file included from GdkQuartzView.c:22: GdkQuartzView.h:21:26: Quartz/Quartz.h: No such file or directory In file included from GdkQuartzView.c:22: GdkQuartzView.h:26: error: cannot find interface declaration for `NSView', superclass of `GdkQuartzView' make[4]: *** [GdkQuartzView.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Are you by any chance running 10.3 or older? As the build instructions say, you currently need 10.4 or newer. /Richard -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk + OSX
Hi, electroteque wrote: > > In file included from GdkQuartzView.c:22: > GdkQuartzView.h:21:26: Quartz/Quartz.h: No such file or directory > In file included from GdkQuartzView.c:22: > GdkQuartzView.h:26: error: cannot find interface declaration for > `NSView', superclass of `GdkQuartzView' > make[4]: *** [GdkQuartzView.lo] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 Are you by any chance running 10.3 or older? As the build instructions say, you currently need 10.4 or newer. /Richard -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk + OSX
On Wed, 2006-02-08 at 12:15 +1100, electroteque wrote: > What is Quartz.h and where would it be ? locate Quartz.h doesnt tell > me anything. It's an OS X-supplied header file most likely. I have no idea where you'd get ahold of it. The appropriate place to ask, though, would be on the darwin mailing list (http://lists.apple.com/mailman/listinfo/darwin-dev) or the opendarwin list (see www.opendarwin.org). 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
