• 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
