Visible flicker when changing model
Hi, changing the model property of a CellRendererCombo in its editing-started signal handler is visible as a slight flicker when opening the pop-up. Any way around that? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Dynamic change of styles...
Hi, i'm working on a GTK based raw image development application which has an initial dark scheme pretty low contrast of UI elements to not distract the view of the image... But in some circumstance where light conditions are bad for this theme it's pretty hard to distinct the ui elements and i want to add a contrast functionality to the application, which gives the user an oppertunity to boost contrast for elemens in such bad light condition... What i want to be able to do is to take an rc style, and recompute the colors, dark get slighter darker and light slighter lighter.. what is the way to do this ? I need the color change to be applied in realtime! /Henrik ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Wrapping Box Container
On Mon, 2010-08-30 at 22:07 -0400, Havoc Pennington wrote: While I'm making trivial comments about wrap box - there's START/END in several other enums, rather than BEGIN/END (just look through gtkenums.h, wrap box is the only BEGIN) @GTK_WRAP_BOX_SPREAD_EVEN description says evenly distributed between children which I think means as spacing between children but I read it several times thinking it meant the children got the space (as in EXPAND) Thanks a lot for your comments Havoc :) I'll make the change for BEGIN-START to be more consistent with other apis... good point. SPREAD_EVEN is exactly that.. adding extra space between the children as spacing, and there is SPREAD_EXPAND for the other (not sure if that could be better explained). Regarding your other mail in this thread... I agree the _insert_child() api has alot of arguments, my original idea was to simply reuse GtkAttachOptions enum (except I'm not sure exactly what to do with GTK_SHRINK). What would we prefer here ? A single AttachOptions type which can be used amongst many containers or a custom enumeration ? also, there's a lot of trailing whitespace showing up red in my emacs ;-) I'll give a look into that... Cheers, -Tristan Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_container_new_child (was Re: Wrapping Box Container)
On Tue, 2010-08-31 at 18:32 -0400, Havoc Pennington wrote: Hi, On Mon, Aug 30, 2010 at 9:51 PM, Havoc Pennington h...@pobox.com wrote: With my proposed padding cleanup though that issue goes away: child = g_object_new(TYPE_MYCHILD, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); insert_child(layout, child, 2, GTK_WRAP_BOX_PACK_Y_EXPAND); Really great would be: gtk_container_add_with_properties(layout, child, position, 2, y-expand, TRUE, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); which would work if we made gtk_container_set() and friends fall back to props on the child if not finding a child prop on the container. Kind of magic, but also really handy and results in very readable code. I like this idea alot and as its a trivial patch I might write one up tonight or tomorrow ... The patch is kind of a pain because gtkcontainer.c relies on weird gobject internals (seriously, #include gobject/gobjectnotifyqueue.c ?) and stealing part of g_object_set() with public GObject API basically isn't possible. However, either a bit of a hack in here or a quick API addition to libgobject would make this a simple feature to accomplish. EVEN MORE AWESOME would be: child = gtk_container_new_child(layout, MY_TYPE_WHATEVER, position, 2, y-expand, TRUE, padding, 5, h-align, GTK_ALIGN_FILL_HORIZONTAL, NULL); sweet! even construct-only properties could be set here. I can see how that can reduce some lines of code when building UIs directly with code (not GtkBuilder)... although I think it would be best to avoid as it throws property and packing property names into the same namespace (so if ever packing properties and object properties share the same name, this api will be a little ambiguous as to which will be assigned, or one or the other would be prioritized...). Thoughts ? Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wrapping Box Container
Hi, On Wed, Sep 1, 2010 at 6:37 AM, Tristan Van Berkom trista...@openismus.com wrote: SPREAD_EVEN is exactly that.. adding extra space between the children as spacing, and there is SPREAD_EXPAND for the other (not sure if that could be better explained). that's what I was saying, just that the docs could use a small wording tweak. (because distributing extra space between children could mean either among the children - what I read the first few times - or in between them as spacing) What would we prefer here ? A single AttachOptions type which can be used amongst many containers or a custom enumeration ? I think AttachOptions is just broken, personally (though it beats booleans for readability). FILL should be in an enum with start, end, center since it is logically exclusive with those. SHRINK is just broken (widgets should never get less than their min size). So only EXPAND is a valid flag. Obviously the main gist of my comments would be most useful if actually fixing up FILL and padding to be props of widget instead of props of containers. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Gtk-OSX
You tell'm John I think the key point here is: The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The GTK+ site clearly advertises the product as a cross-platform toolkit. http://www.gtk.org/features.html OS X is listed as one of three platforms. I have said this before and I will say it again, every time a thread like this comes up. There should be a table with (fully supported, % complete, or not function) per platform, right on the features page. So saps like me don't go believing Santa Claus is going to shoot down my chimney with a Red Ryder BB Gun. :) From: jra...@ceridwen.us Subject: Re: Gtk-OSX Date: Tue, 31 Aug 2010 09:56:12 -0700 To: mar...@lanedo.com CC: gtk-devel-list@gnome.org On Aug 31, 2010, at 6:56 AM, Martyn Russell wrote: On 27/08/10 17:48, Matthias Clasen wrote: As long as the people working on GTK-OSX do it with a us-vs-them attitude (like you display here by talking about the GTK developers in third person), things are not going to change. If you start considering yourself part of the team and actively engage, things can and will change. After reading the thread, I have a few thoughts on the matter. 1. I agree with Matthias, I did get the feeling there is an us vs them in the thread. 2. Equally I agree, when something new comes along, Win32/OSX are often an after thought (that's just my perception). I have spent time building packages for proprietary apps to run on Windows in the past and I know how this can be disconcerting. BUT, GTK+ is targeted mostly with X11 in mind we should not forget that. X11 has the larger use base. I think that people that maintain backends really need to get involved more in meetings, planning, designing, etc if they want to change either of the above issues. About having ONE sanctioned package (for Windows or MAC) I think Yes, we should be doing that, as an app developer before I was more involved in the community, there was no right this is the distributed package we should be using, I had to download it myself and build it myself. Why not channel the work used to make the Pidgin/GIMP downloads with GTK+ into a useful package hosted on gtk.org? Ultimately, having GTK+ packaged *with* each app also has its benefits, like stability on Windows when others GTK+ versions exist/get upgraded for GIMP/Pidgin/etc. Additionally, one of the MAJOR features we boasted when selling our apps was that we could guarantee it worked on ALL versions of Windows (though that later changed) without needing to download .NET for that version of Windows or because something got deprecated. About having Mac on the gtk.org site, I think this does make sense. As a *user* of GTK+ porting my app to these operating systems, I don't have confidence in GTK+ when a port of it is hosted off site. I haven't checked, but I am pretty sure QT doesn't do this. Generally, we should be presenting a more united front for application developers looking to invest time in GTK+. Perhaps this is where we should be focusing some of the GNOME foundation's money if resources are short? Qt is a bit of a strawman: Its sole reason for existing is to provide a cross-platform toolkit. It's also a commercial product, maintained by a huge corporation; it would indeed be strange if some of its functionality were developed outside. WxWidgets might be a better comparison, except that it, too, is solely a cross-platform toolkit. AFAIK, Qt doesn't ship a feature until it's working on all supported OSes. OTOH, they also don't let outsiders see their VCS repos. Wx strives for the same ploicy, but being a volunteer project doesn't always make the goal. They've been struggling for a couple of years with switching their primary Mac port from Carbon to Cocoa. None of which has much of anything to do with Gtk+: As is abundantly clear from this thread, Gtk+ is primarily a backend for the Gnome desktop on Linux, which happens to support most of its basic features on Win32 and Quartz. The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The warnings on the Gtk-OSX website that have sparked this long and vituperative thread merely point out to developers that if they want to write an application that they can distribute to the majority platforms (sorry, that most certainly does *not* include X11) should look elsewhere. I don't know why Gtk-OSX isn't on Gnome.org. (Gtk.org is just a PR website; all of the development resources are provided by Gnome.org.) The project was originated by Richard Hult, who had AFAICT full privs on Gnome for project creation both in VCS and on Bugzilla, but he chose to use Github for VCS and to
Re: padding cleanup
On Sun, 2010-08-29 at 19:02 -0400, Havoc Pennington wrote: Hi, Matthias's mention of padding props got me thinking about how this could be mopped up (based shamelessly on what we did in HippoCanvas and then BigBox) I'm attaching a patch that I haven't even tried to compile (my jhbuild setup is kinda hosed, don't ask) illustrating what I might like to see if starting from scratch. In brief it adds to GtkWidget: h-align, v-align = FILL, CENTER, START, END padding-left,padding-right,padding-top, padding-bottom = int16 Would it be better to have padding-start and padding-end, rather than -left and -right, and have it do the right thing in RTL locales? I've often wished CSS did it that way, and GTK+ does do most things with start and end already. -- Shaun McCance http://syllogist.net/ ___ 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 shashan...@hotmail.com: You tell'm John I think the key point here is: The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The GTK+ site clearly advertises the product as a cross-platform toolkit. http://www.gtk.org/features.html Product? This is a project not a product. And it is cross platform. You _can_ run it on Windows, you can run it on Mac OS X, you can run it on Intel hardware, ARM hardware, SPARC, you can run it on Linux, Solaris, FreeBSD. Is anything of what I said false at all? If that's the case, how is it untrue? OS X is listed as one of three platforms. I have said this before and I will say it again, every time a thread like this comes up. There should be a table with (fully supported, % complete, or not function) per platform, right on the features page. So saps like me don't go believing Santa Claus is going to shoot down my chimney with a Red Ryder BB Gun. :) Maybe, instead of saying it again and again, you should come up with that table, you should actually write that web page? From: jra...@ceridwen.us Subject: Re: Gtk-OSX Date: Tue, 31 Aug 2010 09:56:12 -0700 To: mar...@lanedo.com CC: gtk-devel-list@gnome.org On Aug 31, 2010, at 6:56 AM, Martyn Russell wrote: On 27/08/10 17:48, Matthias Clasen wrote: As long as the people working on GTK-OSX do it with a us-vs-them attitude (like you display here by talking about the GTK developers in third person), things are not going to change. If you start considering yourself part of the team and actively engage, things can and will change. After reading the thread, I have a few thoughts on the matter. 1. I agree with Matthias, I did get the feeling there is an us vs them in the thread. 2. Equally I agree, when something 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
Re: padding cleanup
Hi, On Wed, Sep 1, 2010 at 12:24 PM, Shaun McCance sha...@gnome.org wrote: Would it be better to have padding-start and padding-end, rather than -left and -right, and have it do the right thing in RTL locales? I've often wished CSS did it that way, and GTK+ does do most things with start and end already. Hmm. does GTK usually do that or does it just name them left and right and then flip left and right in RTL? Problem with start and end is it doesn't convey vertical vs. horizontal. I guess you could do hpadding-start hpadding-end. Still isn't the RTL support based on the app developer just thinking LTR and then GTK inverting everything? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk-OSX
On 01/09/10 18:17, Alberto Ruiz wrote: Hello Shawn, 2010/9/1 Shawn Bakhtiarshashan...@hotmail.com: You tell'm John I think the key point here is: The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The GTK+ site clearly advertises the product as a cross-platform toolkit. http://www.gtk.org/features.html Product? This is a project not a product. And it is cross platform. You _can_ run it on Windows, you can run it on Mac OS X, you can run it on Intel hardware, ARM hardware, SPARC, you can run it on Linux, Solaris, FreeBSD. Is anything of what I said false at all? If that's the case, how is it untrue? 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
1) The code does contain a fair amount of FIXME comments. Note that a couple of those are for either deprecated functionality (that will be removed in the future and is only really needed by legacy applications) or for things that are very X11-specific and will not work natively on the Mac. -- http://live.gnome.org/GTK%2B/OSX Now that statement IMVHO, the following statement is misleading at best : Originally GTK+ was developed for X Windows but it has grown over the years to include backend support for other well known windowing systems. Today you can use GTK+ on: GNU/Linux and UnixWindowsMac OS X--http://www.gtk.org/features.html In the fullness of truth you would put an little asterisk next to the Mac OS X in that list, IN RED, telling people to read the caveat in the first part. Why? Simple, we started on Linux, and migrated to OS X with the idea that we could, the number of issues that I have run into, are far greater than what I would consider a complete product on OS X (or toolkit, if we are playing semantic games). There was a time when the website clearly stated that this was RAW and in Development, but most of those warnings have gone the way of the ghost, and chiding John R for warning people that there are serious issues, and a really task to get this all going on OS X should NOT be considered a us vs. them attitude. It is a we would like to counted too attitude. If there is funding being put into developing GTK, and that funding is with the idea that this is NOT just a Linux GUI, but a fully crossplatformable one, that those resourses spending time on coding, should be held accountable for breaking things, or pushing forward the development of a single platform, at the cost of others. Unfortunately, there is a BIG difference between a toolkit that works, in the most minimum sense of the world, and a toolkit that provide a complete set of widgets to get a job done. 2) Writing that table, agreed. I should stop talking about it and do it. I wish I knew how. As re-focus on the GTK part of our app I'll see if I can put something together. as a point: bash-3.2$ pwd /Users/shawn/gtk/source/gtk+-2.18.2/gdk bash-3.2$ cd win32/ bash-3.2$ grep -R FIXME * | wc -l 16 bash-3.2$ cd ../x11/ bash-3.2$ grep -R FIXME * | wc -l 15 bash-3.2$ cd ../quartz/ bash-3.2$ grep -R FIXME * | wc -l 125 We have 10 times more fixes to make to the just the gdk backend compared to windows or X11, So when you ask Is anything of what I said false at all? If that's the case, how is it untrue? No non of it is false, but it is also not the truth, the full truth. Which seems to be the way of things these days, as long is it is not false, than it must be true, and that simply is not the case, unless you are a computer. The website gives a false impression, that it does. Date: Wed, 1 Sep 2010 18:17:07 +0100 Subject: Re: Gtk-OSX From: ar...@gnome.org To: shashan...@hotmail.com CC: gtk-devel-list@gnome.org Hello Shawn, 2010/9/1 Shawn Bakhtiar shashan...@hotmail.com: You tell'm John I think the key point here is: The reason that this thread (and similar ones in the past) get going is largely because of false advertising: Gtk+ claims to be a cross-platform toolkit. The GTK+ site clearly advertises the product as a cross-platform toolkit. http://www.gtk.org/features.html Product? This is a project not a product. And it is cross platform. You _can_ run it on Windows, you can run it on Mac OS X, you can run it on Intel hardware, ARM hardware, SPARC, you can run it on Linux, Solaris, FreeBSD. Is anything of what I said false at all? If that's the case, how is it untrue? OS X is listed as one of three platforms. I have said this before and I will say it again, every time a thread like this comes up. There should be a table with (fully supported, % complete, or not function) per platform, right on the features page. So saps like me don't go believing Santa Claus is going to shoot down my chimney with a Red Ryder BB Gun. :) Maybe, instead of saying it again and again, you should come up with that table, you should actually write that web page? From: jra...@ceridwen.us Subject: Re: Gtk-OSX Date: Tue, 31 Aug 2010 09:56:12 -0700 To: mar...@lanedo.com CC: gtk-devel-list@gnome.org On Aug 31, 2010, at 6:56 AM, Martyn Russell wrote: On 27/08/10 17:48, Matthias Clasen wrote: As long as the people working on GTK-OSX do it with a us-vs-them attitude (like you display here by talking about the GTK developers in third person), things are not going to change. If you start considering yourself part of the team and actively engage, things can and will change. After reading the thread, I have a few thoughts on the matter. 1. I agree with Matthias, I did get the feeling there is an us vs them in the thread. 2. Equally I agree, when something
Re: Gtk-OSX
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: padding cleanup
Hi, On Wed, Sep 1, 2010 at 2:03 PM, Shaun McCance sha...@gnome.org wrote: Well, all of the packing functions use start and end, but I guess that's just to make the term orientation-neutral. Looking through the docs, I do see properties like left-attach, left-margin, and left-padding. So it doesn't make sense to use start and end unless we switch all terminology. That's probably just pointless API churn. Side note: browsers are starting to provide properties using start and end: http://help.dottoro.com/lcedmdkb.php Well, what does GtkAlignment do already with its padding? I think the question is, does GTK just flip left and right, or does GTK let you choose to force left/right regardless of text direction and then also let you virtualize with start/end. I'd guess the browsers are not comfortable / unable to just flip all lefts and rights so they are adding new props for auto-flipping padding. The problem is if you have something called left or right which does NOT auto-flip, people will use it, and then be broken in RTL. I'd almost be inclined to have foo-left, foo-right which flip and then _if there's a use-case_ foo-left-in-all-text-directions and foo-right-in-all-text-directions which don't flip. But I don't know much about it, honestly. However it works, the obvious, default thing app developers will do probably ought to work by default in RTL. I kind of suspect padding-left and padding-right are the obvious default thing app devs will use. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: padding cleanup
On Wed, Sep 1, 2010 at 2:52 PM, Havoc Pennington h...@pobox.com wrote: Hi, On Wed, Sep 1, 2010 at 2:03 PM, Shaun McCance sha...@gnome.org wrote: Well, all of the packing functions use start and end, but I guess that's just to make the term orientation-neutral. Looking through the docs, I do see properties like left-attach, left-margin, and left-padding. So it doesn't make sense to use start and end unless we switch all terminology. That's probably just pointless API churn. Side note: browsers are starting to provide properties using start and end: http://help.dottoro.com/lcedmdkb.php Well, what does GtkAlignment do already with its padding? I think the question is, does GTK just flip left and right, or does GTK let you choose to force left/right regardless of text direction and then also let you virtualize with start/end. I'd guess the browsers are not comfortable / unable to just flip all lefts and rights so they are adding new props for auto-flipping padding. The problem is if you have something called left or right which does NOT auto-flip, people will use it, and then be broken in RTL. I'd almost be inclined to have foo-left, foo-right which flip and then _if there's a use-case_ foo-left-in-all-text-directions and foo-right-in-all-text-directions which don't flip. But I don't know much about it, honestly. However it works, the obvious, default thing app developers will do probably ought to work by default in RTL. I kind of suspect padding-left and padding-right are the obvious default thing app devs will use. Right. We generally don't have a choice between follow-text-direction and hardcoded-left, anywhere currently. We just 'flip where it makes sense'. And that works okayish. Except for a few things where it really depends on the context. E.g you can have an GTK_ARROW_LEFT arrow that says: The beginning of the paragraph is there... or you can have have one that says please turn your head left. For the first one, you want flipping, for second one, you don't, since even in RTL-locales, left is still left... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup Part 2
On Mon, 2010-08-30 at 00:50 +0200, Benjamin Otte wrote: On Mon, Aug 30, 2010 at 12:03 AM, Peter Clifton pc...@cam.ac.uk wrote: Is there any plans to drop the gdk_color_parse() API? Our circuit board design app (gEDA/PCB) uses that for processing configured colour values to RGB values. AUUI, it can also translate X colour names into RGB values. It would be a shame to have to re-invent / copy all this code into the application for use with GTK3. The GdkColor struct is so far unchanged in my branch. There are plans to make it work better with Cairo, like giving it a value for the alpha channel or using doubles instead of shorts for the values. So everything might look a little different with GTK3. But I definitely do not intend to drop any of the functionality provided with GdkColor. So things like the color parsing or to_string() will definitely stay. Cool, thanks for the clarification. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ 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: introspection status
Update: the branch has been merged. I'm happy to finally deliver (somewhat) on the promise of giving useful feedback. Some example warnings, with my comments: gtkmain.h:93: warning: Gtk: gtk_get_option_group: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip) In this case, the right thing is probably to just (skip). Binding apps probably aren't going to dive into lowlevel argument processing (and GTK shouldn't have arguments to begin with, but that's another bug). Alternatively, we could continue with the pattern of registering boxed types for GLib in GObject. gtkmain.h:169: warning: Gtk: gtk_get_current_event_device: return value: Missing (transfer) annotation Simply missing a (transfer full). gtkprintoperation.h:200: warning: Gtk: gtk_print_run_page_setup_dialog_async: argument done_cb: Missing (scope) annotation for callback without GDestroyNotify (valid: call, async) This one looks like it's (scope async). gtktoolshell.h:75: warning: Gtk: ToolShell: Virtual function 'get_icon_size' has no known invoker This one actually looks like a scanner bug... =) Um...here's a different virtual-invoker-missing one that looks like a GTK+ bug: gtkrecentchooser.h:70: warning: Gtk: RecentChooser: Virtual function 'get_recent_manager' has no known invoker For anyone interested in GObject static analysis, this is a useful place to dive in: http://git.gnome.org/browse/gobject-introspection/tree/giscanner/introspectablepass.py Help in getting GTK3 fully introspectable is appreciated! ___ 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
[help]gir-repository compilation error?
Hello, I grabbed gobject-introspection and gir-repository a few hour ago, and failed to compile gir-repository? I am using building on Ubuntu 10.04 with latest glib/gtk 2.0 etc. packages. error log: /home/test/Install/bin/g-ir-scanner -v --namespace Soup --nsversion=2.4 \ --add-include-path=. --add-include-path=. \ --include=Gio-2.0 \ --library=soup-2.4 \ --libtool=/bin/bash ../libtool \ --output Soup-2.4.gir \ --pkg libsoup-2.4 \ ./Soup-custom.c \ /usr/include/libsoup-2.4/libsoup/soup-address.h /usr/include/libsoup-2.4/libsoup/soup-auth-domain-basic.h /usr/include/libsoup-2.4/libsoup/soup-auth-domain-digest.h /usr/include/libsoup-2.4/libsoup/soup-auth-domain.h /usr/include/libsoup-2.4/libsoup/soup-auth.h /usr/include/libsoup-2.4/libsoup/soup-content-decoder.h /usr/include/libsoup-2.4/libsoup/soup-content-sniffer.h /usr/include/libsoup-2.4/libsoup/soup-cookie.h /usr/include/libsoup-2.4/libsoup/soup-cookie-jar.h /usr/include/libsoup-2.4/libsoup/soup-cookie-jar-text.h /usr/include/libsoup-2.4/libsoup/soup-date.h /usr/include/libsoup-2.4/libsoup/soup-enum-types.h /usr/include/libsoup-2.4/libsoup/soup-form.h /usr/include/libsoup-2.4/libsoup/soup.h /usr/include/libsoup-2.4/libsoup/soup-headers.h /usr/include/libsoup-2.4/libsoup/soup-logger.h /usr/include/libsoup-2.4/libsoup/soup-message-body.h /usr/include/libsoup-2.4/libsoup/soup-message.h /usr/include/libsoup-2.4/libsoup/soup-message-headers.h /usr/include/libsoup-2.4/libsoup/soup-method.h /usr/include/libsoup-2.4/libsoup/soup-misc.h /usr/include/libsoup-2.4/libsoup/soup-multipart.h /usr/include/libsoup-2.4/libsoup/soup-password-manager.h /usr/include/libsoup-2.4/libsoup/soup-portability.h /usr/include/libsoup-2.4/libsoup/soup-proxy-resolver.h /usr/include/libsoup-2.4/libsoup/soup-proxy-uri-resolver.h /usr/include/libsoup-2.4/libsoup/soup-server.h /usr/include/libsoup-2.4/libsoup/soup-session-async.h /usr/include/libsoup-2.4/libsoup/soup-session-feature.h /usr/include/libsoup-2.4/libsoup/soup-session.h /usr/include/libsoup-2.4/libsoup/soup-session-sync.h /usr/include/libsoup-2.4/libsoup/soup-socket.h /usr/include/libsoup-2.4/libsoup/soup-status.h /usr/include/libsoup-2.4/libsoup/soup-types.h /usr/include/libsoup-2.4/libsoup/soup-uri.h /usr/include/libsoup-2.4/libsoup/soup-value-utils.h /usr/include/libsoup-2.4/libsoup/soup-xmlrpc.h g-ir-scanner: compile: gcc -Wall -pthread -I/home/test/Install/include/gobject-introspection-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gio-unix-2.0/ -c -o /home/test/temp/gir-repository/gir/tmp-introspectZ3rMNG/Soup-2.4.o /home/test/temp/gir-repository/gir/tmp-introspectZ3rMNG/Soup-2.4.c g-ir-scanner: link: /bin/bash ../libtool --mode=link --tag=CC --silent gcc -o /home/test/temp/gir-repository/gir/tmp-introspectZ3rMNG/Soup-2.4 -L. -Wl,--export-dynamic -pthread -L/home/test/Install/lib -lgirepository-1.0 -lgobject-2.0 -lgmodule-2.0 -lffi -lgthread-2.0 -lrt -lglib-2.0 -lsoup-2.4 -pthread -Wl,--export-dynamic -L/home/test/Install/lib -lgio-2.0 -lgirepository-1.0 -lgobject-2.0 -lgmodule-2.0 -lffi -lgthread-2.0 -lrt -lglib-2.0 /home/test/temp/gir-repository/gir/tmp-introspectZ3rMNG/Soup-2.4.o Traceback (most recent call last): File /home/test/Install/bin/g-ir-scanner, line 44, in module sys.exit(scanner_main(sys.argv)) File /home/test/Install/lib/gobject-introspection/giscanner/scannermain.py, line 327, in scanner_main main.transform() File /home/test/Install/lib/gobject-introspection/giscanner/maintransformer.py, line 67, in transform self._namespace.walk(self._pass_read_annotations) File /home/test/Install/lib/gobject-introspection/giscanner/ast.py, line 405, in walk node.walk(callback, []) File /home/test/Install/lib/gobject-introspection/giscanner/ast.py, line 484, in walk res = callback(self, chain) File /home/test/Install/lib/gobject-introspection/giscanner/maintransformer.py, line 160, in _pass_read_annotations self._apply_annotations_function(node, chain) File /home/test/Install/lib/gobject-introspection/giscanner/maintransformer.py, line 144, in _apply_annotations_function self._apply_annotations_callable(node, chain, block) File /home/test/Install/lib/gobject-introspection/giscanner/maintransformer.py, line 532, in _apply_annotations_callable self._apply_annotations_params(node, node.parameters, block) File /home/test/Install/lib/gobject-introspection/giscanner/maintransformer.py, line 528, in _apply_annotations_params self._apply_annotations_param(parent, param, tag) File /home/test/Install/lib/gobject-introspection/giscanner/maintransformer.py, line 513, in _apply_annotations_param
