Minutes of the gtk+ team IRC meeting - 2010-06-08

[Emmanuele Bassi <ebassi gmail com>]

• 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