Re: [g-a-devel] No module anymore & perfect zoom feature
Le 01/03/2018 à 21:27, Emmanuele Bassi a écrit : Thanks. I was not claiming that the Shell’s zoom is perfect; I’m saying that the Shell is where things need to be fixed, as it’s where things are implemented already. The shell does not currently ask the toolkit to render an area at a different scaling factor, but it could. The shell can also change the rendering pipeline to apply an effect like color inversion. Do you mean you can change the scaling factor during a session? Visual-impaired, including me, use the zoom in/zoom out shortcut all the time, they don't stay on the same zoom level. When a colleague wants to work with me, I change the zoom, enable it, disable it each minutes to make our collaboration easier. The zoom in/zoom out shortcut seems instant on the screen. Best regards and thanks for your feedback on this important subjects to make GTK usable for all, Alex ARNAUD. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [g-a-devel] No module anymore & perfect zoom feature
Le 01/03/2018 à 16:32, Emmanuele Bassi a écrit : that the current GNOME Shell already has logic for zoom, color inversion, and other effects, it’s perfectly capable of dealing with these requirements. You can enable the GNOME Shell zoom feature, zoom to the factor 10 and tell me if it works without blurry effects. I'm visual-impaired with a vision of 1/10 and I see embarrassing blurry effect. You can try the ZoomText magnifier on Windows, it provides trial version and you'll see a real perfect zoom. Best regards, Alex ARNAUD. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A bug no one talks about: g_object_new: assert
Hi ! On 09/26/2017 10:24 PM, psp...@mail.bg wrote: > (Notification Project.exe:27780): GLib-GObject-CRITICAL **: g_object_new: > assertion 'G_TYPE_IS_OBJECT (object_type)' failed What it means is that, during a call to g_object_new (https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-object-new), a type was checked with G_TYPE_IS_OBJECT (https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#G-TYPE-IS-OBJECT:CAPS). The code expected to see a GObject type, but it didn't, hence the assertion failure. The most, most likely error here is from the library caller (aka you): you must be passing wrong pointers. You say you're using g_application_send_notification (), so have a look at the manual here: https://developer.gnome.org/gio/stable/GApplication.html#g-application-send-notification Look closely at the types GApplication and GNotification (section Object Hierarchy): they're both objects derived from a GObject. So when you invoke g_application_send_notification (), you can be sure that the implementation will validate the pointers here and there, and ensure they're GObject pointers. While I can't solve your error, I can advice you to double-check the pointers you're passing. Are you sure it's not NULL pointers ? Are you sure they're initialized ? How did you obtain these pointers ? Hope this helps, good luck ! Arnaud ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: CSS documentation and non-breakable hyphens
> Wondering if there's a better way to do that.
Well, it seems that the most common answer for that problem is to use a
element with the 'white-space' property set to 'nowrap'.
HTML:i-dont-want-to-be-broken
CSS:span.nobr { white-space: nowrap; }
And this is now how it translates in our GTK XML documentation. We can
use the element along with the 'role' attribute. Example with a
table entry from the file css-properties.xml.
-gtk-outline-bottom-left-radius
In the generated HTML, it translates to:
-gtk-outline-bottom-left-radius
Once this is done, the only thing left to do is to tweak the
'style.css', and add this snippet.
span.nobr { white-space: nowrap; }
It does the job, and would allow to remove every non-breaking spaces and
hyphens. The only detail here is that it requires to modify 'style.css'
file, which belongs to gtk-doc-tools, and is not shipped with gtk.
Anyway, there may be better solution, I'm not a web developer, you
shouldn't trust me too much on that ;)
Cheers.
References:
- DOCBOOK: Non breaking spaces or "ties"?
<https://lists.oasis-open.org/archives/docbook/200103/msg00118.html>
- Using CSS to style HTML
<http://www.sagehill.net/docbookxsl/UsingCSS.html#CustomClass>
- White-space property
<https://developer.mozilla.org/en/docs/Web/CSS/white-space?v=control>
On 05/30/2017 05:51 PM, Arnaud wrote:
> Hey there,
>
> While browsing the GTK+ CSS documentation lately in my web browser, I
> noticed a weird phenomenon. If you do a research on 'font-' (for
> example), most of the 'font-' strings are left out of the search results.
>
> You can try it easily. Go on this page, and do a research on 'font-'.
> https://developer.gnome.org/gtk3/stable/chap-css-properties.html
>
> The truth behind is that the page uses 'non-breaking hyphens' (U+2011)
> instead of 'normal hyphens'. I suppose it works great for formatting,
> but it kind of breaks the search function in the browser.
>
> If you're curious about that on your console, browse the GTK+ source
> code. And do something like that.
>
> cd docs/references
> grep -rl $'\xe2\x80\x91' .
> grep $'\xe2\x80\x91' ./gtk/css-overview.xml
>
> I've been even more curious and tried to replace all these non-breaking
> hyphens with normal hyphens.
>
> sed -i 's:\xe2\x80\x91:-:g' css-*.xml
>
> The result is not that bad, but it's true that some property names in
> first column of the tables get split in two lines.
>
> Wondering if there's a better way to do that.
>
> Cheers,
> Arnaud
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
CSS documentation and non-breakable hyphens
Hey there, While browsing the GTK+ CSS documentation lately in my web browser, I noticed a weird phenomenon. If you do a research on 'font-' (for example), most of the 'font-' strings are left out of the search results. You can try it easily. Go on this page, and do a research on 'font-'. https://developer.gnome.org/gtk3/stable/chap-css-properties.html The truth behind is that the page uses 'non-breaking hyphens' (U+2011) instead of 'normal hyphens'. I suppose it works great for formatting, but it kind of breaks the search function in the browser. If you're curious about that on your console, browse the GTK+ source code. And do something like that. cd docs/references grep -rl $'\xe2\x80\x91' . grep $'\xe2\x80\x91' ./gtk/css-overview.xml I've been even more curious and tried to replace all these non-breaking hyphens with normal hyphens. sed -i 's:\xe2\x80\x91:-:g' css-*.xml The result is not that bad, but it's true that some property names in first column of the tables get split in two lines. Wondering if there's a better way to do that. Cheers, Arnaud ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Recoloring of symbolic icons
Dear Gtk+,
just following up with myself. I struggled and struggled, until finally
giving up on recoloring images using the 'color' CSS property. This
attribute seems to be ignored in most cases, so I guess it's just not
supposed to be used the way I wanted to use it.
In the end, the only case where I managed to re-color my icons using the
CSS property 'color' is when I loaded them using
'gtk_image_new_from_icon_name()' with png files. Later on I switched to
'gtk_image_new_from_resource()', and I lost the re-coloring forever.
My solution right now is to color my icons manually, and therefore have
different set of files for different colors. It work just as good, but
it's less elegant.
It's still unclear to me if I was abusing the 'color' attribute (so it's
OK that I failed to use it), or if I was using it in a legitimate way
(and therefore, why so much pain ?).
Cheers guy, have a nice day !
Arnaud
On 05/23/2017 09:32 AM, El Boulangero wrote:
> Hi Gtk+,
>
> Short story:
>
> In my application, I have use custom symbolic icons, and I want to
> recolor them with the css.
>
> What I observe right now is that, as long as my icons are loaded from a
> svg file, they are not recolored and remain grey. However, if I render
> my icons to png with 'gtk-encode-symbolic-svg', these png files are
> loaded instead, and recolored.
>
> I'm wondering if this behavior is expected, as I couldn't find any
> information on that matter.
>
>
>
> Long story:
>
> I'm building an application in which I have dice buttons. Depending if
> the button is clicked or not, I want to change the color of the
> background of the dices, and also the color of the dots on the dices.
>
> I'm trying to implement that by using symbolic icons. I have svg dice
> icons, and typically a dot looks like that in the svg file:
>
> style="display:inline;fill:#bebebe;fill-opacity:1;stroke:none"/>
>
> My icon is named 'dice-1-symbolic.svg', I load it with a call like this one:
>
> Gtk.Image.new_from_icon_name('dice-1-symbolic', size)
>
> I have a css that looks like that for my dicebutton.
>
> .dicebutton {
> color: #ff;
> background-color: #6199ff; }
>
> The idea is to recolor the dices by changing the css attributes.
>
> - What works: recoloring the background (aka changing 'background-color').
> - What doesn't work: recoloring the icon (aka changing 'color' has no
> effect).
>
> I tried again and again, and what I observe at the moment is that:
> - as long as I use a svg file as the source, the icon is not recolored
> - if, however, I render my svg to png using 'gtk-encode-symbolic-svg',
> the png is picked up instead of the svg, and the icon is then recolored
> according to the CSS.
>
> That's a bit puzzling to me. Moreover, my naive understanding was that a
> SVG was trivial to recolor (since it's just about changing the colors
> definitions in the file), while PNG was harder to recolor, since it's
> binary data. So, I thought that SVG were recolored first, then rendered
> to PNG with the right color.
>
> But it looks like it doesn't work like that, especially since I
> discovered that the icon theme on my system is full of '.symbolic.png'
> files, which makes me wonder, what's the point with the svg files in the
> end ? Are they used at all by Gtk ?
>
> So, I'm wondering if anyone could enlighten me a bit about how gtk
> handles this re-coloring. I didn't find the right piece of information yet.
>
> In the end, should I always render my svg to png ? Or is there a way to
> have my svg recolorized by the css ?
>
> Any advice welcome !
>
> Cheers,
> Arnaud
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Glib on Windows for Windows Stroe apps
Hello, I was wondering if Glib could work on Windows 8 embedded in a Windows store application. As far as I understood, there are some limitations in using Windows CRT APIs when building a Store app as defined in this link: http://msdn.microsoft.com/en-us/library/windows/apps/jj606124.aspx Glib (and surely gio, gobject) are using some CRT calls, and some of them are not allowed, or even do not work. Is there any plan to make it compatible with Windows store apps? (if this is technically possible ...) Thanks in advance for your answer. Best regards, Arnaud Collard NB: I am writing on this mailing list because it seems the most suitable for Glib, but we would like to use glib in the scope of Gstreamer to give you a little bit more background. So perhaps we don't need all Glib APIs to be ported if used with Gstreamer. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
Things to test are: everything related to menu behaviour (rich in grabs), everything involving press-and-hold-down mouse button behaviour, checking that the right things prelight as you move between windows and widgets. However, this is also more of a call for feedback about places where the current Gtk 2.24 code fails for you on windows. I'd like to know so i can try fixing it. See https://bugzilla.gnome.org/show_bug.cgi?id=646930 for an example of a regression in 2.24 wrt grabs. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
See https://bugzilla.gnome.org/show_bug.cgi?id=646930 for an example of a regression in 2.24 wrt grabs. I replied to this bug, it should be fixed already on the branch. Great, thanks for having a look! BTW, what's your estimate on looking at Gtk+ 3.x? Since 3.2 is now out, it would be great to have a stable 3.2 Gtk+ under Windows. Do you know about the status of 3.2 under Windows these days? Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ win32 fixes, please test
I want to make sure 2.24 works well first, then I will look at porting the fixes to master (and then back to 3.2 branch which should be trivial). The forward port should be mostly mechanic and not a lot of work, as there has not been a lot of conceptual changes to the gdk code. Makes sense, sounds promising. The one problematic thing for 3.x is the windows theme. That requires a completely different approach (to integrate with the css) which will require some new work. I see. Good to know, since the Windows theme is really a must have to have nicely integrated Gtk+ apps under Windows in our (AdaCore) experience. Thanks again for your work on this, much appreciated! Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: new gtk-fortran binding
I also had to add the 2.24 and 3.x columns in there so I have continued the previous status from all other bindings. If anyone out there sees their binding is out of date, please let me know and I can update it accordingly: http://www.gtk.org/language-bindings.html 2.24 is also partially supported by the Ada (GtkAda) binding. Work is underway to support it fully, as well as 3.0. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Language Bindings Update for Website
GtkAda (Ada binding) supports 2.22 (and below). What do you mean by supports? Can I access to new API added in GTK+ 2.18 ( like GtkSpinner ) from a Ada program? To be more precise: current GtkAda binds everything in Gtk+ 2.16 and below, and is compatible with gtk+ up to 2.22 (we've found Gtk+ bugs in the process FWIW, see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=633089). Work is also under way to support more recent APIs, such as GtkSpinner. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Language Bindings Update for Website
For anyone else wanting to update their language binding support listed on the site, please let me know so we can update them accordingly. ¹ http://www.gtk.org/language-bindings.html GtkAda (Ada binding) supports 2.22 (and below). Thanks! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: handling of keyboard under darwin (quartz)
That's great news, thanks! I had been planning on doing that at some point, my plan was to keep the old code for 10.4 and conditionally use TIS. Right, some conditionalization is probably needed to keep compatibility with 10.4 Please file a bug and attach the patch and we can discuss the details in bugzilla. Thanks for the quick feedback, I'll do that. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: handling of keyboard under darwin (quartz)
Please file a bug and attach the patch and we can discuss the details in bugzilla. Done: http://bugzilla.gnome.org/show_bug.cgi?id=558586 Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.16.2 released
Blogged! http://blogs.gnome.org/gtk/2008/04/02/glib-2162-released/ Well, the tarballs are still not available as of today though :-) http://download.gnome.org/sources/glib/2.16/ lists 2.16.1 as the latest, and no 2.16.2 in sight. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.16.2 released
What do you mean? This was fixed last night (although some files took a bit longer).. would've been earlier if someone mentioned the install-module error message to a sysadmin. I can see them in my browser. Perhaps just a browser-cache-thing. OK, today was indeed a browser cache issue (unlike yesterday where I tried several times to get the file), sorry for the confusion. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
http://library.gnome.org/developers/gtk/ is a page listing available versions of the documentation; do you believe a latest symlink would be useful ? As well as a stable symlink ? Yes, that would be useful indeed. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
Sorry, I overlooked this message until now and just found your latest patch. I will review this patch really soon, and if it looks okay I'll get it committed to svn. Thanks a lot! BTW, did you see my message (and the follow up) on http://bugzilla.gnome.org/show_bug.cgi?id=399253 ? Comment #9 from charlet act-europe fr (points: 11) 2007-04-19 10:31 UTC [reply] There's still a memory leak in the case of e.g. Windows Classic style, fixed by the following patch: --- msw_style.c.old +++ msw_style.c @@ -2541,6 +2548,9 @@ draw_extension (GtkStyle * style, HDC dc; gint32 aPosition; + if (real_gap_side == GTK_POS_BOTTOM) + g_object_unref (pixmap); + dc = get_window_dc(style, window, state_type, x, y, width, height, rect); if (real_gap_side == GTK_POS_TOP) Could someone apply it ? Arno Comment #10 from Daniel Atallah (reporter, points: 8) 2007-04-19 14:29 UTC [reply] The fix for comment #9, and an additional fix for the LEFT/RIGHT tabs is in Bug #403470. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
I committed a similar patch yesterday. It was bug #403470. Indeed, that was part of the text I quoted: The fix for comment #9, and an additional fix for the LEFT/RIGHT tabs is in Bug #403470. Thanks. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
My patch is still against revision 17429. Maybe someone can test it, and if My base is 2.10.11, on which the patch does not apply, so I cannot test it easily. If you have a patch for 2.10, I'd be glad to test it. Cheers, Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
When the tabs are on the left, right, or bottom then the results are worse. Right, that's the main issue with this patch. Strange that I get not so good results even with top tabs. The bug #399253 is, I think, a separate issue.. that happens when the notebook receives expose events or something. As it is right now (without your patch), the tabs look pretty decent when they're first drawn or when the entire widget exposes.. but when it receives partial expose events it gets really screwed up. I tried looking into that, but didn't put much time into it. In the mean time, I've reverted the draw_extension function in msw_style.c to what it was in Gtk+ 2.8.20 to avoid this very annoying (to us) glitch, seems to be good enough for now, and certainly better than having bad redraws. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
Instead of doing that, can you test this patch and see if it solves these problems for you? Sure. Let me know if you have any problems. If not I'll try to commit this to svn soon. This indeed solves the issue nicely for me as well, and is clearly better than reverting to the 2.8.20 implementation (the tabs are properly highlighted for instance). Thanks! Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
I made a patch for the windows theme engine, that adjusts the clip rectangle of the notebook buttons a bit. Now it resambles the native windows look more closely, and it fixes the gap between the left edge of the page and the left edge of the button, when the leftmost page is selected. I do not really get the same effect applying your patch locally: instead I see the tab displayed one pixel too high. Also, your patch makes the situation worse when tabs are put at the bottom (instead of top), see related PR: http://bugzilla.gnome.org/show_bug.cgi?id=399253 Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
change of ABI in Gtk+ 2.10 on Win32
I see lots of changes like that in Gtk+ 2.10.7: #ifdef G_OS_WIN32 /* Reserve old names for DLL ABI backward compatibility */ #define gtk_accel_map_load gtk_accel_map_load_utf8 #define gtk_accel_map_save gtk_accel_map_save_utf8 #endif Which causes a huge number of undefined symbols when binding Gtk+ in another language (in my case, GtkAda). What's the proper approach here ? Where are the old symbols (without _utf8) defined ? I cannot change all these names, because that would mean having to maintain two very different list of symbols and files for unix and win32, so I find this change very intrusive and very incompatible. Can we do something to improve the situation ? Thanks in advance, Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bugs regarding late g_thread_init() calls
* It does appear that we are pulling in pthread in any case for a standard GTK+ application these days, so perhaps it would be worth at least considering whether we wanted to make that a hard dependency; considerations: - What simplifications could we achieve with such a hard dependency? - The only use for libgthread is to avoid a hard pthread dependency; if we added such a dependency, would it make sense to make libgthread an empty dummy library? (it can't be quite empty on windows, since g_thread_init() has to stay in the same DLL) - Could g_thread_init() be removed entirely, by making the different subsystems lazily initialize themselves? What's the performance impact of the necessary GOnce usage for this? - What is the performance degradation when you link to -pthread? On many unix systems, linking with -lpthread will replace many libc calls (e.g. read, write, ...) by thread-safe versions, which are heavier (extra use of locks). Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Win32 - handling mainloop while showing modal comon controls
FWIW,
We've solved a similar issue when using e.g. the standard open file/save
file Windows dialog in a different way.
This is also not ideal but works fine in practice, and is not bound to
any specific dialog.
Here it is attached (this is a patch against 2.8.17 sources).
Arno
* gdk/win32/gdkevents-win32.c: Force an update when paint message
is received, otherwise windows in background are not immediately
refreshed when moving a modal window on top of them.
Add handling of WM_NCPAINT message to refresh some areas when a window
from another application is moved on top of the current app.
--- gdk/win32/gdkevents-win32.c.old 2006-02-21 10:02:58.0 +0100
+++ gdk/win32/gdkevents-win32.c 2006-02-21 10:08:22.0 +0100
@@ -2125,6 +2125,12 @@ handle_wm_paint (MSG*msg,
_gdk_window_process_expose (window, update_region);
gdk_region_destroy (update_region);
+ /* Force a process_updates to refresh visible windows
+ * when receiving a paint message. */
+
+ if (!GDK_WINDOW_DESTROYED (window) gdk_window_is_visible (window))
+gdk_window_process_updates (window, FALSE);
+
DeleteObject (hrgn);
}
@@ -2964,6 +2970,35 @@ gdk_event_translate (MSG *msg,
*ret_valp = 1;
break;
+case WM_NCPAINT:
+ if (msg-wParam 1)
+ break;
+
+ {
+ HRGN hrgn;
+
+ hrgn = CreateRectRgn (0, 0, 0, 0);
+ if (GetUpdateRgn (msg-hwnd, hrgn, FALSE) == ERROR)
+ {
+ WIN32_GDI_FAILED (GetUpdateRgn);
+ break;
+ }
+
+ {
+ GdkRegion *update_region = _gdk_win32_hrgn_to_region (hrgn);
+
+ _gdk_windowing_window_get_offsets (window, xoffset, yoffset);
+ gdk_region_offset (update_region, xoffset, yoffset);
+
+ _gdk_window_process_expose (window, update_region);
+ gdk_region_destroy (update_region);
+
+ DeleteObject (hrgn);
+ return_val = FALSE;
+ }
+ }
+ break;
+
case WM_PAINT:
handle_wm_paint (msg, window, FALSE, NULL);
break;
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
