• figure out how to make distcheck not touch any files under source control - distchecking gtk takes so long commits might happen in between - usually, translator commits - the distcheck phase touches files under revision control, named *.po - the Makefile.in.in from glib-gettext is the culprit - might be good to finally move glib-gettext to upstream gettext and switch to that - needs a list of requirements - at least, find a way for glib-gettext to not make our lives miserable by default
• how to deal with gtk-requiring libraries, with regards to the API/ABI break - libraries will have to do an ABI bump to match the ABI bump in gtk - we need to communicate this on the various venues and remind the maintainers ACTION: mclasen to draft a mail for gtk-devel-list/desktop-announce • GApplication and GtkApplication - merged GApplication in glib - merged GtkApplication in gtk+ - feedback is coming through Bugzilla - identified issues: + portability (win32 and quartz backend are missing) + headless applications + platform support (inhibit idle, session management) + documentation should be improved (esp. failure conditions) • review GBinding - https://bugzilla.gnome.org/show_bug.cgi?id=348080 - binds two object properties, uni or bi-directionally + optionally with a transformation function - API idea coming from libexo - similar implementations in: gimp, evolution, gedit, seahorse - GObject functionality • review GObject::thaw-notify - property notification can be expensive - when N properties change it requires N signal emissions - bulk notification can be implemented only by overriding dispatch_properties_changed, which is not always possible - ::thaw-notify is emitted when the notification queue is thawed for the last time, and it emits a bulk notification of all the properties in the queue + thaw-notify is the signal form of ::dispatch_properties_changed() - naming is not really descriptive - needs more thought/work • Editable label: sub-class or class feature+ABI break? - replaces EelEditableLabel - a sub-class of GtkLabel was needed to preserve ABI - gtk+ 3.0 is breaking ABI anyway, so can we fold that into GtkLabel itself? - more importantly: do we really, really need them? - feature sets between labels and entries do not match - worth investigating the pattern of editable/uneditable widgets • get rid of GtkProgress - patch wrote by mclasen at: https://bugzilla.gnome.org/show_bug.cgi?id=620618 - not as hard as thought - not ABI compatile (for obvious reasons) - works fine • deprecation of gtk_quit_add_full() to remove GtkArg - GtkArg is only used by GtkCallbackMarshal - GtkCallbackMarshal is only used by one function - should really be replaced by GCallback • potential cost of direct access vs. function calls - sealing means moving away from direct access to public accessor and modifier functions even from within gtk+ - public accessors have type and argument checking - the cost has not been fully benchmarked - there are possible scenarios for enabling direct access from within the gtk+ code base without breaking all the work done with the sealing - measurement, or even a definition of measurement, should be done first ACTION: discuss on the mailing list next meeting: 2010-06-22 ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list