Re: www.gtk.org now updated but no news!
On 03/06/11 20:40, Devin Samarin wrote: I have hopefully fixed this problem (I can't test with older versions of PHP, but I have tested the new function by itself, and in theory it will work.) Patch is located here: https://bugzilla.gnome.org/show_bug.cgi?id=651807 I also cleaned up some code used during development of the website. Thank you for the patches Devin, however, at the moment, it seems the last few commits from me and Javier Jardón have not yet made it through to the website. I suspect there is something larger going wrong here and I don't have access to the server to fix it. Shawn, any chance you can assist here? -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: www.gtk.org now updated but no news!
Everyone, It looks like all the committed changes are being updated fine. Except the changes on the features page were editing code that was not visible. They were editing the code for the old features slider instead of the current page (which is hidden in a PHP if-statement). I have removed the old features slider and moved the changes over. https://bugzilla.gnome.org/show_bug.cgi?id=651834 On Sat, Jun 4, 2011 at 2:04 AM, Martyn Russell wrote: > On 03/06/11 20:40, Devin Samarin wrote: >> >> I have hopefully fixed this problem (I can't test with older versions >> of PHP, but I have tested the new function by itself, and in theory it >> will work.) >> >> Patch is located here: https://bugzilla.gnome.org/show_bug.cgi?id=651807 >> >> I also cleaned up some code used during development of the website. > > Thank you for the patches Devin, however, at the moment, it seems the last > few commits from me and Javier Jardón have not yet made it through to the > website. I suspect there is something larger going wrong here and I don't > have access to the server to fix it. > > Shawn, any chance you can assist here? > > -- > Regards, > Martyn > -- Regards, Devin Samarin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gail next steps (was Re: GTK and ATK)
On 06/03/2011 06:01 PM, Matthias Clasen wrote: On Wed, Jun 1, 2011 at 7:48 PM, Piñeiro wrote: On 05/10/2011 04:28 PM, Benjamin Otte wrote: In fact, IMHO, some of the issues pointed by Benjamin would be solved by this [2] and the gail migration, but lets not talk about it. As I said, those are long term tasks, and the fact is that the current accessibility status needs to be improved also in the short and medium term. I also planned to define those short-medium tasks, but after reading again some mails, Matthias already did it in this mail [3], so I will not repeat that. I will just include that as task 1.5 I would include refactoring gailtreeview, one of the big problems related to performance that prevents having a11y enabled as default [5] For making things work better in the short/medium term (ie before we land a complete refactoring/rewrite of gail), I think two things are essential: 1. Define the atk interfaces to a testable level. One example that I have run in recently is the 'name' property of AtkObject - it is not really defined at all what this is supposed to contain, and how it is supposed to be used. It turns out a change that I committed last September made menu accessibles not have names - it turns out that that breaks ATs which expected those names to be taken out of the labels contained in the menuitems. This needs to be specified somewhere, so that we can then About this specific case it is about improve the documention: http://developer.gnome.org/atk/stable/AtkObject.html#AtkObject--accessible-name Or something else? You could also try to create a bug to debate it, or include it as a item on the a11y weekly. Anyway, I thought that the first step here was to migrate the current gail (with their virtues and drawbacks) to gtk. And although things would be easier with a good atk documentation, Im not sure if this is a blocking here. 2. Test that the accessible implementations actually follow that spec. I want to be able to have a unit test in the GTK+ repository that instantiates a widget, gets the corresponding accessible, and then verifies that it has the expected properties. If we had such testcases, it would not have taken 9 months from me committing the breaking change to me committing the fix. On the other hand, the fact that nobody filed a bug maybe tells us something about the amount of real-life usage that the gnome3 accessibility stack currently gets... Real-life usage is mostly done by users. GNOME 3 is not accessible, or at least was announced as not accessible. In general most of the tests done by the users were mostly a disappointment (ie: [1][2][3][4]). In summary: there is no real-life usage of the gnome3 accessibility stack. For the moment GNOME 3 accessibility stack is mostly developers tested. BR [1] https://mail.gnome.org/archives/orca-list/2011-May/msg00307.html [2] https://mail.gnome.org/archives/orca-list/2011-May/msg00165.html [3] https://mail.gnome.org/archives/orca-list/2011-May/msg00048.html [4] https://mail.gnome.org/archives/orca-list/2011-May/msg00143.html -- Alejandro Piñeiro Iglesias (API) (apinhe...@igalia.com) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.29.6
GLib 2.29.6 is now available for download at: ftp://ftp.gtk.org/pub/glib/2.29/ http://download.gnome.org/sources/glib/2.29/ d6218380f33f0ad48471cd8b245fbbc20aabd542b1a5221708c19a4e72860fa7 glib-2.29.6.tar.bz2 2ad525fc0aa2381594c51569e38824d820b1f551b825dbc9219defaa7e90c329 glib-2.29.6.tar.xz The is another development snapshot of the 2.29 series. Overview of changes from GLib 2.29.4 to 2.29.6 == * Atomic operations have been rewritten from scratch to make use of gcc builtins where possible. As a side-effect of this, calls to g_atomic_ API with explicit casts may now be problematic; if that happens to you, try first to remove the casts. Another side-effect of the rewrite is that g_atomic_int_exchange_and_add has been deprecated in favor of g_atomic_int_add. * A full set of atomic operations on pointers has been added, including bit locks in pointer-size locations. * Access to quarks is now lockless * GObject data scalability has been greatly improved * g_data_time_format now supports alternative digits and padding * Introspection improvements: - Add a boxed type for GVariantBuilder - Annotation fixes in GDBus, GVariant, g_base64_ * Bugs fixed: 502560 g_rand_double_range returns 'inf' 612729 g_mkdir_with_parents can fail if the directory already exists 617491 g_once() implementation is inefficient 619418 Add a performance test for UTF-8 decoding functions 619435 Make g_utf8_to_ucs4_fast() yet faster 626549 G_STATIC_ASSERT_EXPR 631231 bitlock: Fix detection and usage of futexes with Bionic 632294 g_queue_remove() should return a boolean 640518 GMainLoop has quadratic complexity when all pollfd's... 642026 Race condition in g_static_private_free 646635 Fix introspection of GLib 648678 g_date_time_format(): support %O flags for localized numbers 649480 Use MSG_CMSG_CLOEXEC in recvmsg in gio/gsocket.c 649506 GTestFunc et al lacking Since tag 649657 Don't return gboolean for functions that throw 649775 glib-gio-gdbuscodegen-Makefile.patch 649915 gsettings accepts unquoted strings longer than two characters 649973 gthread: build unix tests only on unix 649988 gdbus-codegen: Drop dependency on argparse 650078 forkbomb building glib/tests/protocol 650211 Optimization in key file parsing 650236 Application over DBus implements action state incorrectly 650345 g_key_file_has_key_full: New function to fix... 650458 reduce overhead in g_object_set/get_data 650459 hash table consistency while calling destroy notify funcs 650688 enforce rules about hash table modification 650823 expand the set of atomic ops 650874 codegen chokes on docs 650882 use stdout instead of stderr for informational messages 650884 fix compilation with gcc2 650885 implement glib credentials on OpenBSD (hackish) 650935 G_GNUC_MAY_ALIAS and atomic ops 651009 minor documentation fix 651034 Regarding g_cond_wait after g_thread_pool_push in gthreaded... 651133 race condition in GDBusConnection's emit_signal_instance_in_... 651141 hashtable infinite loop 651219 fix path to true(1) on OpenBSD 651223 Fix some compile warnings on OpenBSD 651327 Minor fixes for the gsocket API 651467 Add pointer sized bitlocks 651650 gdbus: Avoid busy wait loop 651725 gmain: Cleanups and a new test case 651745 Switch to _ prefixing rather than G_GNUC_INTERNAL * Updated translations: Catalan (Valencian) Esperanto Hebrew Hungarian Russian Spanish Thanks to all contributors Chun-wei Fan Colin Walters Dan Winship David Zeuthen Ray Strode Ryan Lortie Martin Pitt Giovanni Campagna Maarten Bosmans Benjamin Otte Philip Withnall Javier Jardón Emmanuele Bassi John Lindgren Jasper Lievisse Adriaanse Antoine Jacoutot Marc-André Lureau Richard Hughes David Schleef Simon McVittie Neil Roberts Alexander Larsson Matthew Barnes Mikhail Zabaluev Paolo Bonzini June 4, 2011 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
