1 < ebassi> as usual, the agenda is at: http://live.gnome.org/GTK%2B/Meetings
   2 < ebassi> • how to deal with gtk-requiring libraries, with regards to the API/ABI break
   3 < ebassi> • GApplication and GtkApplication
   4 < ebassi> • review GBinding
   5 < ebassi> • review GController/GObject::thaw-notify
   6 < ebassi> • Editable label: sub-class or class feature+ABI break?
   7 < ebassi> • get rid of GtkProgress
   8 < ebassi> • deprecation of gtk_quit_add_full() to remove GtkArg
   9 < ebassi> other items?
  10  * mclasen had one
  11  * mclasen thingks
  12 < mclasen> ah right
  13 < mclasen> fixing up distcheck
  14 < mclasen> I was trying to get a release out today, but got stuck on that old 'someone else committed during my distcheck'
  15 < mclasen> so I want to finally figure out how to make distcheck not touch any files under source control
  16 < walters> (cd ..; git clone gtk+ gtk-distcheck; cd gtk-distcheck; make distcheck) ?
  17 < walters> really, tarballs should be built automatically on gnome servers, and not from developer machines
  18 < leio> as long as said gnome servers don't have broken intltool versions on them like various maintainers do have a lot
  19 < walters> (and eventually turned off once operating system builders have better version control based tools)
  20  * jjardon thinks that the new admin will have a lot of work to do
  21 < mclasen> walters: the problem is that currently make distcheck touches files that I have to commit to get a tag on the tarball contents
  22 < walters> mclasen: yeah, my first command suggestion would work around that
  23 < mclasen> walters: I don't know how
  24 < walters> er...wait maybe not
  25 < walters> nevermind =)
  26 < mclasen> it doesn't address the 'get the tag on the contents' part
  27 < mclasen> the only alternative would be to create a small branch for each release
  28 < mclasen> and merge it back afterwards
  29 < mclasen> but then the tag sits on that branch, not on master
  30 < mclasen> so fixing distcheck would be better, I think
  31 < mclasen> not much to discuss here, though. I just need to figure out file-by-file why it is touched
  32 < chpe> the biggest problem is that it updates the po files, isn't it? intltool's Makefile.in.in used to have that problem too, but it was fixed not to
  33 < mclasen> the biggest headache is the old copy of po/Makefile.in.in that we have
  34 < mclasen> which has an update-po in make dist
  35 < mclasen> for I don't know what reason
  36 < mclasen> thats all tangled up with glib-gettextize vs upstream gettext and has a long histroy
  37 < jjardon> someone suggest that we should switch to upstream gettext, instead glib-gettextize, but maybe this is OT
  38 < mclasen> proposing that is easy
  39 < mclasen> someone needs to do the work...
  40  * mclasen attends to his other meeting for a minute
  41 < ebassi> it would be good to have at least a list of requirements; I might give it a go
  42 < jjardon> ebassi, I think the proper solution is port glib-gettextize to upstream gettext
  43 < jjardon> as lots of projects are using  glib-gettextize now
  44 < ebassi> I'm afraid I'm going to get saddled with gettext itself :-/
  45 < ebassi> but it would also be good to see if glib-gettext can be fixed not to make our lives miserable by default - since we control it
  46 < mclasen> anyway, lets move on; I'll work on fixing up distcheck for the release I still want to do today
  47 < ebassi> okay; second point: how to deal with libraries depending on gtk
  48 < ebassi> so, as a maintainer of a library indirectly depending on gtk+ -- what happens with gdk-pixbuf in gtk 3.0?
  49 < ebassi> has it been renamed to gdk-pixbuf-3.0?
  50 < mitch> it becomes gdk-pixbuf-3.0
  51 < mitch> it must, there is no other way
  52 < mclasen> it has been renamed, yeah
  53 < ebassi> okay, so we'll need clutter to depend on that
  54 < ebassi> no problem
  55 < mclasen> alternatives would have been to move it out or to radically rewrite it on top of cairo (like some people want)
  56 < leio> moving it out would be nice for some wanting to use the librsvg gdk-pixbuf module without gtk+ on a server setup. We've had such a request
  57 < ebassi> move it out would make my life much easier
  58 < walters> the libraries-depending-on-gtk+ seems to subdivide into libraries which expose GTK+ APIs publicly versus those that don't
  59 < walters> clutter is the latter right now
  60 < ebassi> yep
  61 < mitch> ebassi: clutter also needs a new library name then, or everything will break
  62 < ebassi> clutter-gtk will bump up to gtk+ 3.0
  63 < ebassi> mitch: ugh
  64 < mitch> it doesn't matter if it's exposing api or not, it *must* be a new library
  65 < mitch> or you get distros into hell
  66 < mclasen> the problem is linking, not api
  67 < mitch> exactly
  68 < jjardon> ebassi, clutter-gtk3 ?
  69 < walters> maybe the best thing with gdk-pixbuf is to keep it as is and have any radical rewrite use new symbols
  70 < ebassi> jjardon: no, clutter-gtk 1.0
  71 < ebassi> walters: we might move it to an internal copy
  72 < jjardon> ebassi, the new name, I mean
  73 < mclasen> do we have a volunteer to work on standalone gdk-pixbuf ?
  74 < ebassi> jjardon: no, the new name would be clutter-gtk 1.0 :-)
  75 < jjardon> okis ;)
  76 < ebassi> mclasen: I'll talk with my manager and see if I can get team time to work on it (and fix it, while we're at it)
  77 < ebassi> it's something we wanted to do anyway
  78 < mclasen> nice, thanks
  79 < mclasen> but even with gdk-pixbuf out of the way, there's still plenty of libraries that will have to do the abi jump with us
  80 < jjardon> we can say in the minutes that It's planned, if someone makes the work
  81 < jjardon> maybe someone more is interesed in working on it
  82 < ebassi> mclasen: we need to communicate this on desktop-devel or desktop-announce
  83 < mclasen> yes
  84 < mclasen> rpm -q --whatrequires "libgtk-x11-2.0.so.0()(64bit)" | grep "^lib" | wc -l
  85 < mclasen> -> 26
  86 < mitch> we knew that from the start, so let the whining begin :P
  87 < mclasen> right, its nothing new
  88 < mclasen> just something to remind people of
  89 < mclasen> of those 26 I found, some 5-6 are obsolescent anyway
  90 < walters> mclasen: you probably want to use repoquery --whatrequires libgtk-x11-2.0.so.0 | grep '^lib' since the former will only list things you have installed, right?
  91 < walters> (61 here on f13)
  92 < mclasen> walters: yeah, but my install is not minimal by any measure...
  93 < jjardon> maybe a good GnomeGoal?
  94 < mclasen> not really, I don't think
  95 < ebassi> jjardon: no
  96 < ebassi> it's limited in size, but not limited to the GNOME platform
  97 < jjardon> well, we can make the GnomeGoal for GNOME. Other libraries can take a look to the GnomeGoal for help about the transition
  98 < jjardon> or we can create a GtkGoal instead :P
  99 < jjardon> the idea is to have a list to track the progress of the most important libraries. And to have all the info in the same place
 100 < mclasen> the right decision for each library may be different
 101 < mclasen> for some it maybe best to just leave them in gtk2.x land
 102 < mclasen> and port apps away to newer gtk apis
 103 < mclasen> anyway, I'll draft a mail on this topic for gtk-devel-list/desktop-announce-list
 104 < mclasen> should we move on?
 105 < ebassi> sure
 106 < ebassi> GApplication and GtkApplication
 107 < walters> so they were merged, but there's still work to do, which i am doing as we speak
 108  * davidz sent some feedback to walters and mclasen in private
 109 < mclasen> I merged them now since I didn't get much feedback on the list last week
 110 < walters> the biggest outstanding thing is still a prototype win32 or os X backend, but there is some debate about how that should work nwo
 111 < mclasen> and promptly got a lot of feedback in bugzilla 
 112 < ebassi> yup; I also have a proposal for multi-windows applications; will open a bug with a patch
 113 < mclasen> so thats good, on some level, I guess
 114 < davidz> in particular I'm concerned that about the scope - it sounds like it's only intended for Gtk and Mx
 115 < mclasen> ebassi: have you seen what I added last week, add_window ?
 116 < davidz> in which case GApplication shouldn't be instantiable e.g.
 117 < walters> well...if we made dbus work in the legacy unix contexts it could be useful
 118 < ebassi> mclasen: yes; I still think that we should allow overriding create_window()
 119 < walters> primarily in ssh
 120 < walters> ebassi: no objections to that
 121 < ebassi> mclasen: well get_window() → get_default_window(), add create_window()
 122 < ebassi> the first window added using add_window() will become the default one
 123 < mclasen> davidz: one concern is that you don't expect commandline stuff or daemons to show up in your application menu
 124 < mclasen> but I guess, since they are never 'active' in a shell sense, that wouldn't happen anyway
 125 < davidz> mclasen: hah! - that's a cheapshot...
 126 < davidz> one question I asked is whether GApplication should be used for, say, gnome-user-share
 127 < davidz> e.g. a session-based headless daemon
 128 < davidz> we don't have to decide on that right here right now
 129 < davidz> but the docs should be very clear about this
 130 < davidz> also
 131 < davidz> the failure mode should be brutal if people are doing it wrong
 132 < davidz> e.g. maybe it's fine that GApllication is only useful for UI apps... in which case the failure mode should be that we abort() if there's no UI server (e.g. no X server)
 133 < davidz> in which case making GApplication instantiable is not a good idea
 134 < davidz> anyway
 135 < davidz> I felt a want for design docs on that level
 136 < davidz> when I looked at it
 137 < davidz> it's not at all clear to me how and when GApplication should be used
 138 < walters> if you don't know, don't use it?
 139 < davidz> that's not a very compelling answer
 140 < walters> the main problem is inability to guarantee any kind of semantics
 141 < walters> mainly because of the concept of linux distributions
 142 < davidz> that's not really the point
 143 < leio> How does it all interact with the same program being ran on the same computer, but locally and over remote X (ssh forwarding), in particular can applications decide if they want it to be X client unique, or X server unique
 144 < davidz> you can make it as narrow or as wide as you want - but please just make it apparent when reading the docs
 145 < walters> okay, i'll add something to the docs
 146 < walters> anything else?
 147 < davidz> thanks
 148 < davidz> well, there are some other practical issues in my mail
 149 < davidz> I'll just file that in bugzilla
 150 < mclasen> biggest concern from my side is that we still lack implementations for win32 or os x
 151 < walters> yeah
 152 < mclasen> and, from looking at http://live.gnome.org/TwoPointThirtyone/PortabilityMatrix
 153 < walters> there are two parts - i know we can do uniqueness and arg passing on both
 154 < mclasen> just merging it is no guarantee of an implementation showing up
 155 < walters> the question mark is _add_action
 156 < ebassi> walters: I've followed the discussion with chpe 
 157 < mclasen> secondary concern is figuring out some of the scope questions that david raised, e.g. do we want/need session management in GtkApplication 
 158 < walters> which?
 159 < ebassi> walters: the one on bugzilla
 160 < walters> david was only talking about GApplication
 161 < walters> ebassi: there were several =)
 162 < mclasen> oh right
 163 < ebassi> walters: bug #620957
 164 < ebassi> I think the biggest question about the action support is that we need some design on the interaction model
 165 < ebassi> what can and cannot be done
 166 < ebassi> apart from the wiki page for gnome-shell, I haven't seen much
 167 < davidz> mclasen: well, there are really two concerns here
 168 < davidz> mclasen: first, both headless and UI programs often need several "Application Services".. such as inhibiting the screensaver or the PM and so on.. it would be nice to at least be able to add it to something like GApplication at some point in the future... I don't know
 169 < davidz> mclasen: the second is that of documentation and failure modes... we've learned the very hard way what disasters can happen if people use D-Bus-using libraries in the wrong way
 170 < davidz> mclasen: here I'm talking about GIO/gvfs
 171 < davidz> and the auto-spawning of session bus instances and all that
 172 < davidz> and the auto-spawning of session bus instances and all that
 173 < jjardon> about session managment: hp said: https://bugzilla.gnome.org/show_bug.cgi?id=79285#c26
 174 < davidz> so from a practical point of view it would be nice to have a story for developers
 175 < davidz> so they know what APIs to use and when to use it
 176 < davidz> instead of undocumented APIs leaving people to guess whether to use it or not
 177 < mclasen> since gdbus doesn't do autolaunching, we're safe for now, right ?
 178 < walters> this is the second time you've mentioned that
 179 < walters> i will again mention i will add something to the docs
 180 < mclasen> undocumented is a bit harsh, anyway
 181 < davidz> mclasen: gdbus will probably need to do autolaunching
 182 < walters> ebassi: so...what can and cannot be done from the perspective of an app author?
 183 < davidz> sorry if I'm being too harsh
 184 < ebassi> walters: multiple action groups? what is the smallest subset of features that can be reasonably portable?
 185 < ebassi> walters: also, how does this map to the main menu that a quartz GtkApplication would support?
 186 < ebassi> walters: does the gnome-shell decide what to put in the application menu, or applications are supposed to tag the actions that should go in it, on the gnome platform?
 187 < walters> ebassi: quartz - i believe they have an API that just exports a GtkMenu; we could just export that under #ifdef GDK_WINDOWING_QUARTZ as gtk_application_set_menu() i guess
 188 < walters> ebassi: the basic idea is apps have an action group with their app-global stuff and we export that as best we can everywhere
 189 < jjardon> Here the code of ige-mac-integration: http://github.com/jralls/ige-mac-integration/tree
 190 < mclasen> exporting widgets like that is just icky, I don't like it at all
 191 < ebassi> walters: sounds reasonable; though I expect people will start asking for that API on linux as well, for embedding the app menu somewhere else
 192 < ebassi> anyway, we can worry about that when we start receiving odd patches ;-)
 193 < leio> silence, next topic?
 194 < ebassi> right, if nothing's left for application, there's gbinding
 195 < ebassi> (exo-like binding between object properties, for people that don't follow twitter)
 196 < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=348080
 197 < mclasen> I don't follow twitter - what are concrete uses for this facility ?
 198 < ebassi> mclasen: evo and other apps are already using copy-and-paste API similar to it
 199 < ebassi> evo and gedit and seahorse, according to the bug
 200 < ebassi> it's also similar to the GSettings binding API
 201 < ebassi> it can be used to link two widgets for sensitivity, or two adjustments with a conversion function
 202 < mitch> gimp has that for 5 years or so ;)
 203 < mitch> ehm
 204 < mitch> it should clearly become part of gobject
 205  * mclasen has not looked at the patch in detail
 206 < mclasen> but it seems fairly obvious; we have several users, we have a working patch, it has docs, and tests
 207 < ebassi> the latest patch moves it from gio to gobject, and adds documentation
 208 < mclasen> docs still say "since GIO 2.26" in places
 209 < ebassi> ugh, right - will fix that
 210 < mclasen> so, I think this should go in; any other opinions ?
 211 < ebassi> seems not :-)
 212 < mclasen> is there ever a case where you want to bind multiple properties at the same time ?
 213 < bratsche> Wouldn't you want to do that for linking properties in a compound widget or something?
 214 < ebassi> mclasen: you can create multiple bindings
 215 < bratsche> Or maybe the child widgets would be reflecting the property of the container widget, I dunno.
 216 < mclasen> yeah, I guess having them in on binding would just be a minor optimization
 217 < ebassi> but since property notification is expensive, we're down to the next item -- add GObject::thaw-notify signal, to allow bulk notification :-)
 218 < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=617446
 219 < mclasen> I'm not 100% clear on how that avoids the overhead
 220 < mclasen> thaw-notify is only emitted if there's more than one  notify queued up, right ?
 221 < ebassi> mclasen: you get a single signal instead of N
 222 < mclasen> so how do you catch the individual updates that might also happen to properties you are interested in ?
 223 < mclasen> don't you have to listen for notify after all, anyway ?
 224 < ebassi> mclasen: it is emitted - in the current incarnation - whenever the notification queue is thawed last
 225 < mitch> i was just wondering the same
 226 < ebassi> mclasen: the idea is that you don't listen to ::notify if you're interested in many properties
 227 < mitch> so you simply want GObject::dispatch_properties_changed() to be a signal?
 228 < mclasen> but then you loose ::notify emissions that are not batched ?
 229 < ebassi> mclasen: no, you still get those even when n_pspecs == 1
 230 < ebassi> mitch: yes, thaw-notify is essentially the signal form of dispatch_properties_changed()
 231 < mclasen> oh, I see
 232 < mitch> that makes sense
 233 < mclasen> the  name mislead me into thinking it was only emitted for freeze/thaw pairs
 234 < mclasen> bad name...
 235 < ebassi> yeah, I realize that :-)
 236 < mitch> why not simply "properties-changed"?
 237 < ebassi> mitch: that might work
 238 < mclasen> actually, rays comment is in that vein too
 239 < mclasen> just the implementation ends up working differently
 240 < mitch> or *actually* a signal emission on the topmost freeze/thaw pair might be useful too
 241 < mitch> listeners might want to stop doing stuff on freeze() and resume on thaw()
 242 < mitch> theoretically speaking, i have no real use case in mind, given everything is within one call tree here
 243 < mclasen> that sounds like adding more overhead, instead of avoiding overhead...,
 244 < mitch> yeah maybe ;)
 245 < mitch> the problem here might be that sometimes the order of properties matters, but that's up to the listener then
 246 < mitch> they can choose to connect to notify anyway
 247 < mitch> hm no ignore me, thaw fucks up the order anyway
 248 < ebassi> well, the order would be the same as the one you get ::notify emissions
 249 < mitch> really?
 250 < mitch> um
 251 < ebassi> mitch: if you exclude the duplicates
 252 < mitch> sure
 253 < ebassi> the reasoning behing bulk notification is for libraries that use a lot of properties that change in block - like clutter :-)
 254 < ebassi> but since the only way to get bulk notification is to override dispatch_properties_changed, it can only be done in sub-classes of GObject
 255 < mitch> we do that in gimp a lot
 256 < mitch> well s/a lot/in one or two places/ ;)
 257 < jjardon> ebassi, just curious, Did you do any performance test?
 258 < ebassi> yeah; allocation in Actor notifies 5 properties in the worst case; animations are pretty bad as well
 259 < mitch> GtkAdjustment does that too now
 260 < ebassi> jjardon: we did profiling and if you start animating, you can see it on sysprof
 261 < mclasen> ebassi: and that (requiring subclassing) is the motivation for this signal addition?
 262 < ebassi> jjardon: no micro-benchmarking for stress-testing
 263 < ebassi> mclasen: yes, mostly; we don't have a GtkObject at the bottom of our class hierarchy
 264 < mitch> would that signal get the same array of properties as dispatch_properties_changed()?
 265 < ebassi> mitch: yes
 266 < ebassi> it's a concentrated notify emission
 267 < mitch> the longer i thnk about it the more often i have worked around exactly that problem using dispatch_properties_changed() in a subclass
 268 < mitch> i think that signal makes sense, given that signals with no listeners are essentially nops
 269 < mclasen> are they ?
 270 < mitch> iirc they are
 271 < mitch> aren't they? :)
 272 < mitch> timj to the rescue
 273 < mclasen> I believe various patches to that effect were rejected as micro-optimization
 274 < mitch> heh
 275 < mitch> so if this new signals involves yet another motex lock/unlock we should indeed maybe think twice
 276 < mitch> mutex*
 277 < mitch> gah
 278 < mclasen> the patch looks like context->dispatcher really wants to be the default handler for thaw-notify
 279 < mclasen> but I'm sure there's complications that prevent that...
 280 < tadeboro> http://git.gnome.org/browse/glib/tree/gobject/gsignal.c#n2879
 281 < tadeboro> Looks like there are some optimizations inside signal emission machinery.
 282 < mitch> doesn't look like a nop to me
 283 < mclasen> still a lock there, though
 284 < mitch> yeah
 285 < mclasen> hard to avoid though
 286 < mitch> unavoidable for looking up the signal i guess
 287 < ebassi> the unlocks are all over the place
 288 < mclasen> we do lockless lookup of interfaces now, though ?
 289 < ebassi> yep
 290 < mclasen> any other topics ?
 291 < ebassi> editable label: sub-class or not?
 292 < ebassi> the sub-class idea was due to the "we can't break ABI and we're out of slots on LabelClass"
 293 < ebassi> I guess now we can simply extend that
 294 < mclasen> I must admit I never fully grokked the idea of an editable label as a widget
 295 < mitch> haha i agree
 296 < mclasen> isn't that just a notebook with a label and an entry ?
 297 < mitch> it's a WTF
 298 < ebassi> well, nautilus has them to rename files :-)
 299 < ebassi> it's a bit ad hoc, though
 300 < mitch> ebassi: aren't these tree rows?
 301 < ebassi> no
 302 < ebassi> in icon view
 303 < ebassi> not in list view
 304  * mclasen has done a lot of label + editable widget in a notebook in the accountsdialog
 305 < jjardon> It's needed to replace EelEditableLabel: Its one of the items of ProjectRidley: http://live.gnome.org/ProjectRidley
 306 < mclasen> it can be tricky sometimes to get focus handling right
 307 < ebassi> jjardon: yep, EelEditableLabel is what nautilus is using (in tree)
 308 < jjardon> bug here: https://bugzilla.gnome.org/show_bug.cgi?id=310693
 309 < ebassi> dunno if there are other projects using it, though
 310 < mclasen> I would invite anybody to study the accountsdialog set of label-that-turns-into-entry, label-that=turns-into-button, label-that-turns-into-combo
 311 < jjardon> cosimoc offered to make a patch if an implementation was decided here
 312 < jjardon> mclasen, yeah It's pretty cool ;)
 313 < mclasen> so, I'd be more interested in investigating if there is a more general pattern of editable-uneditable widget that we can  support, instead of just copying eeleditablelabel
 314 < garnacho> I wonder if it doesn't make more sense to make it the other way around, a non-editable entry that looks like a label
 315 < mclasen> the thing is that label and entry have distinct feature sets
 316 < mclasen> there's a big overlap, certainly
 317 < mclasen> but there is also a difference
 318 < garnacho> I see, should check the use cases
 319 < mclasen> labels do urls, they can or cannot be selectable, they can wrap,..
 320 < mclasen> entries can be invisible, they can show icons, they can not wrap, etc etc
 321 < garnacho> a GtkLabel subclass makes sense then
 322 < mclasen> what will that class do ? reimplement gtkentry ?
 323 < ebassi> and in case of word wrapping, does it become a text area? :-)
 324 < jjardon> There is already a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=310693#c10
 325  * mclasen will put his thoughts in that bug
 326 < leio> the agenda topic seemed to be whether the feature should be in a sub-class, or directly inside GtkLabel with an ABI break (due to GtkLabelClass being out of padding)
 327 < mclasen> any other topics ?
 328 < leio> <ebassi> • get rid of GtkProgress
 329 < leio> <ebassi> • deprecation of gtk_quit_add_full() to remove GtkArg
 330 < mclasen> right, gtkprogress
 331 < mclasen> I wrote a patch one evening last week that strips out GtkProgress
 332 < jjardon> bug and patch here: https://bugzilla.gnome.org/show_bug.cgi?id=620618
 333 < mclasen> and moves enough pieces into GtkProgressBar to make the non-deprecated functionality work
 334 < mclasen> took a few hours, but wasn't as hard as I thought
 335 < mclasen> it is obviously not abi compatible
 336 < mclasen> but other than that, it works fine
 337 < mclasen> I just wondered what people's thoughts are on that ? should I just commit it ?
 338 < ebassi> ship it, it's done :-)
 339 < leio> so no sharing with GtkEntry progress stuff?
 340 < leio> (interface)
 341 < jjardon> well, It's for GTK+3, is abi compatibily required?
 342 < mclasen> leio: there was never any sharing with the entry progress stuff, api wise
 343 < ebassi> leio: there's no real common interface anyway - unless you want to a) add a GtkProgressable interface b) deprecate the whole overlapping GtkProgressbar and GtkEntry API and c) implement the interface
 344 < mclasen> the drawing is shared, of course
 345 < ebassi> which would be still fill odd anyway
 346 < leio> feels similar to GtkOrientable, sort of
 347 < bratsche> I think right now if there is no text in the GtkProgressbar it's still full-height.. I'd kind of like to change it so that it's shorter/thinner when there is no text in it.
 348 < bratsche> (at least, I think this is how it works right now)
 349 < leio> GtkProgressBar is a non-editable GtkEntry with no text in it *grin*
 350 < mclasen> it is shorter/thinner
 351 < leio> except there is a label. Anyway, considered, decided, then GtkProgress is not useful if not serving an interface
 352 < mclasen> ok, cool
 353 < bratsche> Oh, then I'm just smoking crack I guess.
 354 < mclasen> deprecation of quit_add_full - last point
 355 < jjardon> yeah, I asked murray about it. He commented in the bug
 356 < jjardon> pygtk uses that function, but GI based bindings no
 357 < mclasen> in an essential way, or easily avoidable ?
 358 < mclasen> I would assume the essential point is that bindings need a destroynotify
 359 < jjardon> murray words: <murrayc> jjardon: *_full() functions are generally needed to maintain state, by associating user_data with a callback function. Bindings and well-written apps do need that, yes.
 360  * mclasen needs to run out
 361 < mclasen> your conclusions on a postcard...
 362 < mclasen> later
 363 < ebassi> ugh
 364  * ebassi just saw GtkArg for the first time
 365 < jjardon> ebassi, Do you know anything about the perl case?
 366 < jjardon> :)
 367 < jjardon> I saw that current perl bindings use that functions one time. But the GI based no
 368 < jjardon> oh, here is the bug with the murray comment: https://bugzilla.gnome.org/show_bug.cgi?id=619671
 369 < ebassi> jjardon: perl-Gtk2 binds it
 370 < ebassi> but we don't use it in code
 371 < ebassi> so, since perl-Gtk2 binds gtk+-2.0, it's not a big deal
 372 < ebassi> and as soon as we switch over to GI, it's not going to be a problem ever again
 373 < jjardon> indeed, It's only used here: http://git.gnome.org/browse/perl-Gtk2/tree/xs/Gtk2.xs#n491
 374 < jjardon> and here in gtkmm: http://git.gnome.org/browse/gtkmm/tree/gtk/src/main.ccg#n252
 375 < jjardon> the problem is that gtkmm bindings are  not GI based (for now)
 376 < ebassi> so, dunno; at this point, should we rename the function? break it without pity since it's fairly unused?
 377 < ebassi> jjardon: gtkmm will have to bump up anyway
 378 < jjardon> yeah, or maybe use GCallback instead GtkCallbackMarshal
 379 < jjardon> in these functions
 380 < jjardon> as murray suggest in the bug report
 381 < ebassi> sounds reasonable to switch to GCallback and let GtkCallbackMarshal die a painful death
 382  * tadeboro rather goes directly to hell that being listed on ebassi's deprecation list ...
 383 < ebassi> right, so we can adjurn the meeting
 384 < jjardon> ok, Is there time for leio concerns about performance?
 385 < ebassi> oh, right
 386 < ebassi> though we have hit the 2:30hrs mark
 387 < leio> I'm not personally prepared to argue any counter arguments, so some "unofficial" chatter is fine
 388 < ebassi> okay; I can still put it in the minutes - it's up to you
 389 < leio> jjardon should have a link to some March meeting about function calls vs direct access stuff with some options on how to proceed. Trying to find the right place
 390 < leio> http://live.gnome.org/GTK%2B/Meetings?action=AttachFile&do=view&target=20100323.txt
 391 < jjardon> one moment, let me check
 392 < leio> 21:50
 393 < leio> in the raw log
 394 < leio> so, basically I'm saying what desrt said there. I see no reason to go with slower (doing accessor function calls for things that are available internally directly)
 395 < leio> just put the private structures in a foo-private.h header instead of on the top of the *.c and don't install it
 396 < ebassi> one of the options was: add a macro that expands to a direct access when GTK_COMPILATION is defined, and to a function if not
 397 < ebassi> though, obviously, it would be good to have numbers before making the build even more hacktacular than it is
 398 < ebassi> (not that I don't doubt that function call + argument type checking > direct access
 399 < ebassi> in terms of time, obviously)
 400 < leio> argument type checking is quite expensive, for example gstreamer is going out of its way to do direct casts when it knows it's correct, saving tens of percentage of instructions in the process
 401 < ebassi> still, internally, the compiler could do tricks; and we could have the cross-file boundary inlining at some point
 402 < leio> is GTK+ already using function calls internally, or that is one of jjardon's gsoc projects?
 403 < ebassi> leio: for things that are exposed publicly, we use the public accessor internally as well
 404 < leio> because if it isn't already using function calls internally, it's probably easier to spread some ->priv around rather than converting to public accessors
 405 < jjardon> I added some internal functions functions, but without type checking
 406 < leio> I'm not sure what build hacks would be involved here
 407 < ebassi> right - internal functions should not have type checking
 408 < ebassi> the idea is that if you take out some code from gtk+ it won't blow up in your face; and even internally, the code won't become a tangled mess of direct accesses to private structures
 409 < ebassi> which is the biggest risk as soon as you start making Private data structure project-wide
 410 < leio> I've never heard or read about the GTK_COMPILATION idea before, but it sounds neat, albeit probably can be considered a build hack
 411 < ebassi> leio: it might probably rate lower on the build hacks scale than, say, the aliasing stuff ;-)
 412 < ebassi> anyway, it's a good discussion that should be brought up on the mailing list
 413 < leio> I do not have the time resource right now to do any concrete measuring of how much slower it is, I think this should definitely have been done BEFORE making it obviously slower - measure if it's not measurable
 414 < jjardon> yeah, but thinking more on this, waht id the advantage of _gtk_accesible_set_widget (a, w) over a->priv->widget = w ?
 415 < leio> yeah, jjardon suggested in a meeting :P
 416 < ebassi> leio: since people have gone offline, and since we probably need more bandwidth, the mailing list is usually the next step
 417 < ebassi> leio: it's much appreciated, though
 418 < leio> agreed
 419 < jjardon> <jjardon> leio, I already ported some widgets. I'd suggest you to sent a mail to gtk-devel-list if you can't attend :P
 420 < ebassi> we've had this discussion on IRC, in various shapes and forms
 421 < leio> gtk-2-90 is in master now?
 422 < jjardon> leio, I'm pushing my work here: http://gitorious.org/gtk3/gtk/commits/refactor
 423 < ebassi> leio: yes
 424 < jjardon> leio, gtk-2-90 is obsolete now
 425 < jjardon> It was merged in master some time ago
 426 < leio> looks like even GtkWidget code itself internally does gtk_widget_get_realized function calls with type checking all over the place
 427 < ebassi> leio: yep
 428 < leio> anyway, I think this is not for the meeting channel anymore
 429 < leio> as we didn't have time :)
 430 < ebassi> okay; leio: thanks for the patience :-)
 431 < ebassi> next meeting in two weeks
 432 < ebassi> good night everyone; will send the minutes soon