1 < desrt> greetings friends and loved ones
   2 < mclasen> excellent, a new talk show host
   3 < bilboed> all rise for the honorable...
   4 < mclasen> so, do we have an agenda ?
   5 < bratsche> http://live.gnome.org/GTK%2B/Meetings
   6 < desrt> mclasen: i think that's what priests say before weddings :)
   7 < bratsche> I'm probably not going to stick around long today, but I wanted to ask about schedules for post-2.20
   8 < bratsche> As in, what's next?  Is there a 2.22 or will it go directly to 3.0?  And either way, if there is any idea what the timetable is.
   9 < mitch> or before funerals?
  10 < mclasen> ok, lets do that first, then
  11 < bratsche> Just for the purpose of scheduling things with my manager at work.
  12 < desrt> mitch: i hope not :)
  13 < mclasen> I think we should aim for 3.0 next, provided the sealing business is in good shape in 2.20
  14 < mitch> which reminds me i need to add about 10 sealings
  15 < mitch> so gimp builds
  16 < mclasen> but thats just my opinion, I don't foresee having a ton of time to push things that way...
  17 < danni_> there are still a bunch of outstanding feature branches (resolution-indep., extended layout) are we going to wait until 3.0 to push these?
  18 < mclasen> I think thats on the agenda as the next point...
  19 < ebassi> at some point we'll have to stop cramming stuff in 2.x :-)
  20 < Company> there's also a lot of features people would like to get rid of, refactor etc
  21 < danni_> mclasen: so it is!
  22 < bratsche> Yeah.
  23 < mitch> we should compile a list to *remove* fo 3.0 rather than to add
  24 < bratsche> Is there any rough idea of how many months after 2.20 before we want 3.0 to be released?
  25 < danni_> Company: yeah
  26 < bratsche> Or is that going to be depending on Gnome 3.0's release schedule?
  27 < danni_> Company: yeah
  28 < bratsche> Or is that going to be depending on Gnome 3.0's release schedule?
  29 < mclasen> mitch: a good idea, but most things to be removed in 3.0 ought to be deprecated in 2.20, I think
  30 < mitch> mclasen: some things cannot be deprecated, like signals
  31 < mitch> but generally, yes
  32 < mclasen> mitch: they can always be documented as deprecated
  33 < danni_> ooher, can we invent a way to deprecate set-scroll-adjustments ?
  34 < mitch> right
  35 < mclasen> you may not be able to make the build break if they are used...
  36 < mitch> but we could warn
  37 < mitch> don't signals have flags?
  38 < mclasen> danni_: someone had a patch for a scrollable interface in bugzilla at some point
  39 < mclasen> was that you ?
  40 < danni_> mitch: python style, yeah
  41 < danni_> mclasen: that was not me
  42 < jpetersen> i have a patch to add a GtkScrollable interface
  43 < mitch> like GtkContainer::add ::remove (the signals, not the vfuncs)
  44 < kalikiana> we have a diagnostic mode in the plan to take care of signal and prop deprecations :)
  45 < kalikiana> ^^ mitch
  46 < jpetersen> https://bugzilla.gnome.org/show_bug.cgi?id=468689
  47 < mitch> mclasen: we also have a list of things that need to go into gobject for 2.20 to happen
  48 < danni_> but a Python style g_warning in some Deprecation domain, could be useful here
  49 < mitch> like class private data
  50 < mitch> deprecation flags for signals
  51 < mclasen> kalikiana: is that mode something thats going to be ready for 2.20 ?
  52 < kris> mitch: and all the performance stuff is on that list as well ...
  53 < mitch> kris: yeah
  54 < kalikiana> mclasen, not sure, so far it's mostly planning, hardly code
  55 < kalikiana> would you think that's preferrable?
  56 < mitch> deep derivability of fundamental types
  57 < mclasen> kalikiana: better late than never, but if the diagnostic mode is supposed to be useful in preparation for porting things to 3.0, it better show up in  a 2.x release, no ?
  58 < mitch> yes
  59 < mclasen> so, it sounds like we would be better off making a list of things that need to happen for 2.20 
  60 < kalikiana> yes of course. Just asking if we should try to get it in 2.20 as opposed to 2.22
  61 < kris> the main issue with the "diagnostic mode" is that there is nothing concrete ...
  62 < Company> somewhat related question: how would we handle switching GdkPixbuf from RGBA to CAIRO_FORMAT_ARGB32?
  63 < Company> assuming I wanted to write a patch for that
  64 < kris> Company: doesn't that break the publicly exposed pixels pointer?
  65 < mitch> Company: that's hardly possible i think :/
  66 < danni_> could it be added as another colourspace ?
  67 < Company> kris: yes it does
  68 < mitch> for the reason kris gave
  69 < jjardon> mclasen, I think you can use http://live.gnome.org/JavierJardon/GTKRoadmap for that list (move the page to other place if you want)
  70 < ebassi> another colorspace would be interesting
  71 < mclasen> danni_: thats 'formally api compat', but hardly in practical terms
  72 < kalikiana> so the current one would have to be deprecated
  73 < kalikiana> not impossible, just ugly
  74 < mclasen> because nobody ever checks colorspaces
  75 < danni_> mclasen: well, you'd make it so that people had to explicitly request that colourspace
  76 < kris> you can add another colorspace, but you cannot set the other colorspace as default
  77 < mclasen> jjardon: I was actually less interested in writing that list myself...
  78 < danni_> mclasen: rather than make it the default
  79 < danni_> but mention it in the docs
  80 < Company> i think something like that would only be doable for 3.0, which is why i'm asking
  81 < danni_> it would make a lot of people's lives easier
  82 < danni_> even if it wasn't the default
  83 < mclasen> yeah, adding a non-default cairo colorspace might be doable for 3.0
  84 < Company> if the consensus is that it's not possible/shouldn't be done, then i'll look at a complete replacement more
  85 < danni_> on this note, I've been trying to think how to have a gtktreemodel API that uses quarks
  86 < danni_> so we can have named columns
  87 < danni_> but I think this would have to break API
  88 < Company> danni_: treemodel api should be broken anyway
  89 < Company> danni_: because get_value is so slow
  90 < desrt> *ahem* libmodel
  91 < Company> desrt: do you have a treeview widget for it already? :)
  92 < desrt> listview only
  93 < desrt> treeview in development
  94 < desrt> but targetting clutter, not gtk :)
  95 < Company> cool
  96 < Company> not that cool then
  97 < desrt> gave a quick demo in boston
  98 < ebassi> desrt: cool :-)
  99 < danni_> desrt: do you use quarks for columns?
 100 < desrt> not sure if anyone who was there is here... except maybe ebassi?
 101 < desrt> danni_: no.  strings.
 102 < ebassi> desrt: I either missed it or was completely asleep
 103 < desrt> danni_: and they're not columns
 104  * mclasen missed it too
 105 < desrt> mclasen: it was on the last day :(
 106 < danni_> desrt: strings are fine too, I suppose
 107  * danni_ wishes she could have been in Boston
 108 < desrt> mind if i talk about it briefly?
 109 < ebassi> desrt: I think the meeting is going to take some time
 110 < desrt> i'm ok with waiting until next time then
 111 < kris> i dont see how quarks solve anything
 112 < Company> did i mention i'd like to see GQuark deprecated and replaced by interend strings?
 113 < desrt> Company: that's an exceptionally reasonable proposal
 114 < kris> Company: I think breaking get_value() like that is on the same line as suddenly changing the pixel format of GdkPixbuf
 115 < danni_> kris: really it's the named columns I want
 116 < kris> Company: I don't think we have envisioned such breakage initially, we have always promised a smooth migration
 117 < danni_> kris: however they're looked up is an implementation detail for me
 118 < Company> kris: yeah
 119 < mclasen> Company: quarks give you interned strings today
 120 < mclasen> or do I miss something ?
 121 < kris> danni_: ah, named columns instead of numbers?
 122 < desrt> mclasen: but they also give you a new namespace
 123 < Company> mclasen: yes, it's just the ugly API
 124 < danni_> kris: right
 125 < kris> danni_: aah right
 126 < danni_> kris: because numbers suck in GtkBuilder
 127 < danni_> and in the bindings
 128 < mclasen> Company: you can just ignore the quark api and use g_intern_string ?
 129 < kris> danni_: in C code as well, unless you create an enum
 130 < danni_> kris: yeah
 131 < Company> mclasen: yeah, that's what everyone should do
 132 < desrt> danni_: https://desrt.ca/gitweb/?p=model;a=blob;f=model/model.vala;h=e30d580c5a111e9170a8186a15e0d89f061fdea7;hb=HEAD
 133 < Company> mclasen: and then you deprecate the quarks api so you can get rid of loads of public API \o/
 134 < bilboed> Company, by which you mean you wouldn't have to explicetely create the quark, but just have some kind of decorator ?
 135 < mclasen> Company: ok, I can buy that; except for cases where you really want to have an int as a identifier
 136 < danni_> kris: basically I've always felt that named columns would fix so much up
 137 < ebassi> can I ask to get things under a little bit more of control?
 138 < desrt> danni_: references, lists, dictionaries.  i'll bring it up at the next gtk meeting.
 139 < kalikiana> Company, quarks are glib, won't help to deprecate them :-/
 140 < Company> mclasen: where would that be?
 141 < Company> kalikiana: not yet ;)
 142 < mclasen> Company: dunno, you brought this topic up, so I am not prepared...
 143 < Company> bilboed: you use g_intern_string() which gives you a unique gchar *
 144 < Company> mclasen: ok, then i'll just assume there's no such case for now :)
 145 < kris> maybe we can move all the new topics to the next meeting?
 146 < kris> since I thin kthe list for this meeting was already long
 147 < desrt> kris: a fine idea!
 148 < mclasen> ebassi is right, we should get some order here
 149 < mitch> yea we don't discuss the agenda here :)
 150 < ebassi> I doubt an IRC meeting is going to solve the "future stuff" agenda point
 151 < bilboed> kris, agreed
 152 < Company> mclasen: you can use GPONTER_TO_SIZE() on the interened string if you want a number anyway
 153 < kris> not that I don't want to discuss it :)
 154 < mclasen> so, the question bratsche wanted answered ( and he needs to go soon)
 155 < ebassi> so, can I ask everyone that has a proposal to send it to the mailing list and/or open a page under bugzilla (bug references are welcome)?
 156 < mclasen> was when we target the release after 2.20
 157 < ebassi> mclasen: thanks :-)
 158 < ebassi> mclasen: I think it depends on when the release-team decides to spin GNOME 3.0 at this point
 159 < ebassi> if GNOME 3.0 is going to depend on gtk+ 3.0
 160 < mclasen> yeah, thats the one thing
 161 < mitch> they said they don't need to
 162 < kris> we need to have a plan at least
 163 < jjardon> From Gnome people Feb 22: http://live.gnome.org/TwoPointTwentynine
 164 < mitch> and would be willing to break abi in 3.2
 165 < kris> if they "like" the plan, they might base gnome 3.0 on gtk+ 2.current and have gtk+ 3.0 for gnome 3.2
 166 < mclasen> the other is what amount of feature branches we decide to pull in after 2.20
 167 < danw> from talk in boston it sounded like people are expecting this spring to be GNOME 2.30, not 3.0
 168 < desrt> mclasen: on that point, i'd like to have the floor for a few moments after this conversation :)
 169 < desrt> danw: that's officially not decided yet
 170 < kalikiana> ^^ why not keep "follow up" topics for after the official agenda, and see who can stay longer :)
 171 < kalikiana> otherwise we keep disrupting the topic
 172 < danw> desrt: no, but we probably shouldn't *assume* 3.0 will happen this spring
 173 < mclasen> so, it looks like we will have a hard time making a solid plan here; from what I can see, our best bet is to ensure that we land all the '3.0-readiness
 174 < desrt> danw: actually, i argue that's exactly what we *should* assume :)
 175 < mclasen> ' things in 2.20
 176 < kalikiana> I'd think if we are prepared, it's good. And if we're prepared but GNOME 3.0 isn't happening, no problem
 177 < mitch> leaving out the possibility of not being prepared? :)
 178 < ebassi> mclasen: agree
 179 < kalikiana> mitch, I think the timeframe is doable, if we don't insist on getting everything, milk and ponies into 2.9 ;)
 180 < mclasen> and to make sure we have all the 3.0 readiness items covered, we should collect them on the wiki page that jjardon has volunteered
 181 < mitch> yes please
 182 < mitch> like, we still have no plan on how to seal class structures
 183 < desrt> jjardon: can you move that page to some semi-official place before we all try to edit it? :)
 184 < kalikiana> mitch, question: who can take charge of class privates?
 185 < ebassi> jjardon: under GTK+/Roadmap
 186 < jjardon> ok
 187 < kalikiana> maybe it would help to get that a bit going
 188 < mitch> kalikiana: timj
 189 < kalikiana> mitch, Let me reword: is timj available right now, to do that?
 190 < kris> again, on the class private patch
 191 < mitch> it's not a big change
 192 < kris> I have "pre-reviewed" it
 193 < kris> it makes fully sense
 194 < kris> together with the reporter I found another bug that has been fixed
 195 < mitch> yes it does, i looked at it too
 196 < kalikiana> Maybe it's not big, I'm just saying it would be good to get it done sooner than later
 197 < kris> it can't be more than 30 mins work for a gobject maintainer to accept it
 198 < Company> then just commit it
 199 < Company> there is no gobject maintainer right now :o
 200 < bilboed> where is that branch located ?
 201 < jjardon> done: http://live.gnome.org/GTK+/GTKRoadmap
 202 < Company> bilboed: it's a patch in bugzilla i believe
 203 < mclasen> kris: I'd tend to agree with Company here. Commit it, and invite timj to review it in-tree
 204  * kalikiana thinks Company forgot his pink glasses today :P
 205 < mitch> mclasen: which brings up the agenda point of glib branching?
 206 < Company> kalikiana: no, i'm just fed up with everyone blocking on timj
 207  * bilboed seconds Company's point-of-view
 208 < ebassi> kalikiana: if two people like kris and mitch reviewed it, then I think we can commit it :-)
 209 < Company> kalikiana: but i'll elaborate on that when we hit the gobject-performance agenda point
 210 < mclasen> mitch: I did create a glib-2-22 branch, I believe
 211 < kalikiana> The situation is annoying alright, but nobody other than Company seems to be eager to accept that :)
 212 < mitch> cool
 213 < mitch> back to agenda :)
 214 < mitch> what is git surgery?
 215 < kris> i have been wondering about that one as well
 216 < mitch> fixing the 2.90 branch name?
 217 < kalikiana> git surgery is cutting up an idiot I presume
 218 < mclasen> volunteers ?
 219 < bilboed> what needs to be done for that ?
 220 < mitch> mclasen: you? ;)
 221 < desrt> i'll do it if we agree
 222 < desrt> you don't need surgery
 223 < ebassi> mitch: 2.90 branch name and gtk-2.16
 224 < desrt> just need to push an empty ref to the branch
 225 < ebassi> or what jjardon added to the wiki :-)
 226 < Company> git push origin :gtk-2.16
 227 < Company> bye bye
 228 < desrt> yup
 229 < desrt> then just push thte 2.90 branch as 2-90 and do the same thing for 2.90
 230 < desrt> the 'how' is less important than the 'why' and 'should'
 231 < mclasen> ok, sounds like desrt has the necessary expertise to handle this comfortably
 232 < kalikiana> ++
 233 < mclasen> the why is easy: both were misnamed by accident
 234 < mclasen> and the 2.16 branch is just an accident altogether
 235 < mitch> let's do it
 236 < desrt> ok.  i'll do it
 237 < ebassi> desrt: thanks :-)
 238 < kalikiana> customer happy, neeeext point
 239 < desrt> gvariant/gsettings/gdbus/etc, plz?
 240 < ebassi> desrt: did you put those on the agenda? :-P
 241 < bilboed> desrt, not on agenda
 242 < desrt> no.  but it's on jjardon's lovely list
 243 < desrt> i suppose i have to wait until next week?
 244 < ebassi> desrt: it can go in miscellaneous
 245 < ebassi> if we cut some corners to save time :-)
 246 < Company> desrt: it's a wiki page, edit it!
 247 < desrt> i'm okay with deferring
 248 < bilboed> Company, gaaaah, shaddap
 249 < desrt> davidz and i are still hammering some small details down
 250 < kalikiana> Company, editing during the meeting is cheating :P
 251 < desrt> i'll make sure it's on the schedule for next week
 252 < ebassi> I've seen garnacho's email on gtk-deve-list
 253 < davidz> desrt: for the gdbus stuff we probably want alexl to review it - he's gone for the next week and a half (clone()/fork() in his family)
 254 < kalikiana> (maybe we should consider a metting next instead of after next week, since we have many topics)
 255 < desrt> i'm gonna skip out now.  just one note:
 256 < ebassi> for xi2
 257 < davidz> desrt: (e.g. he had a son)
 258 < desrt> when you're discussing the abstract application base class stuff, consider under the assumption that you'll be able to use DBus from GTK
 259 < desrt> davidz: a boy?  nice.
 260 < kris> with all the dbus stuff i am still wondering how that will work for cross platform stuff
 261 < mclasen> desrt: sure, unique-app + session-client is the two main gtk-level motivations for doing the dbus stuff in the first place
 262 < kalikiana> hopefully not like gvfs, ie half done
 263 < desrt> kris: i'll have an agenda item for next week
 264 < Company> kris: i bet desrt will write a COM equivalent for windows
 265 < kris> i think we should either fully support it, or not at all, but not half done
 266 < danw> kris: the actually d-bussy APIs will depend on win32 dbus. the higher-level apis (unique app, session client) will not use dbus on win32
 267 < kris> as i fully understand the motivation from a gtk+/gnome standpoint to have it, and I don't want to hold that back
 268 < kris> danw: oh, interesting
 269  * desrt out.
 270 < davidz> libdbus-1 for win32 exists - it's just not in the mainline fd.o libdbus repo (it's a fork - fd.o dbus wants to merge it, it's not a lot of work but no-one qualified has stepped up... if we merge gdbus into glib someone should just step up and do the work)
 271 < davidz> anyway, we can cover that next week
 272 < davidz> everyone is aware of the problem and there's a way to solve it
 273 < mclasen> so, back to the agenda item of 'interesting topic branches' ?
 274 < jjardon> xi2 seems to be ready: https://bugzilla.gnome.org/show_bug.cgi?id=596725
 275 < mclasen> I have poked murrayc/tbf last week, and they made noises that sounded like they would get the extended layout work revived
 276 < ebassi> as mitch pointed out on #gtk+, xi2 should be tested with gimp to check its readiness
 277 < tbf> oink. oink.
 278 < ebassi> if it hasn't already
 279 < mclasen> without having looked at the branch at all, xi2 strikes me as the one topic that would be most interesting to get squeezed into 2.x still
 280 < mitch> mclasen: agreed
 281 < ebassi> yup
 282 < mclasen> unfortunately, I am crazy short on time for GTK+ stuff in the near future
 283 < mclasen> so, if we could muster some additional review power, that would be cool
 284 < jjardon> RI branch seems to be ready too, I think only testing is needed: http://bugzilla.gnome.org/show_bug.cgi?id=546711
 285 < kalikiana> ^^ more review power would so rock
 286 < bilboed> no excuses now with splinter
 287 < ebassi> jjardon: davidz said in boston that some more testing with complex non-gtk apps like openoffice, eclipse and firefox should be in order for RI review
 288 < danni_> I think it also needs a bit more forward porting
 289 < danni_> from when I last worked on it
 290 < kalikiana> mclasen being a machine and all that, but he deserves some relief
 291 < danni_> it also needs some integration with settings
 292 < danni_> since it doesn't have any atm
 293 < davidz> yeah, there's a separate task of figuring out the gnome ui for configuring this
 294 < davidz> and then ensure that the apis we want (in particular GtkSettings) work with that
 295 < danni_> I've never really had inspiration for how it might be configured
 296 < danni_> or how the settings should look
 297 < davidz> right, we just need a high-level idea so we are sure that the api supports what we want
 298 < danni_> mmm
 299 < danni_> maybe we need to punt this to a designer ?
 300 < danni_> get some ideas
 301 < ebassi> danni_: yes
 302 < davidz> danni_: yeah, something like that would be great
 303 < ebassi> I can probably ask Nick Richards on my team
 304 < mclasen> s/punt to/consult with/
 305 < kalikiana> mclasen, maybe you could just write down a list of people you consider able, otherwise it could take years to sort that out
 306 < danni_> ebassi: neat
 307 < kalikiana> and just see who also has time
 308 < ebassi> because if the configuration involves a ruler then I think we failed already :-)
 309 < mclasen> kalikiana: I think I promised something like that last time, didn't i ?
 310 < danni_> ebassi: yeah, I think we all agree there
 311 < danni_> ebassi: tbh, I'm not sure that most people will want that much RI
 312 < danni_> and certainly not multimonitor RI
 313 < danni_> (although that's where the configuration nightmare starts)
 314 < kalikiana> mclasen, I just remember it was supposed to be sorted out after the meeting, and so far nothing looks sorted =)
 315 < davidz> so I think with RI it's like: 1. figure out high-level story for configuration; 2. review API changes (mostly GtkSize and GtkSettings multi-monitor changes) in the patch; 3. go through all of gtk+ and do s/12/GTK_SIZE_ONE_TWELFTH_EM(1.0)/ where appropriate
 316 < davidz> (maybe find a shorter macro name too!) ;-)
 317 < danni_> davidz: right
 318 < ebassi> GTK_DEFAULT_SPACING :-)
 319 < danni_> I did a lot of (3) when I was using the work
 320 < davidz> then 4. test on lots of apps / desktop sessions; 5. merge it
 321 < danni_> but still needed (1) and (2)
 322 < davidz> right
 323 < danni_> there were a few other things I'd been meaning to fix
 324 < danni_> like the signal on GtkSettings.. seemed a little nutty
 325 < danni_> possibly belonged on GdkScreen, etc.
 326 < davidz> yeah
 327 < davidz> anyway 3. and 4. can happen in parallel so ideally more than one person can work on them
 328 < danni_> yeah
 329 < davidz> but for 1. and 2. it's mostly a one-man job
 330 < danni_> I had a script to track down 3 somewhere
 331 < danni_> it had a list of API calls that take a size
 332 < davidz> cool
 333 < danni_> I wonder what I did with it
 334 < danni_> (although I never delete anything, this doesn't mean those things are easy to find)
 335  * mclasen peeks at the next topic
 336 < mclasen> deprecations...
 337 < mitch> please!
 338 < mitch> these classes have bevome entirely useless
 339 < mitch> and we can simply keep gtk_hbox_new() etc. as utility functions
 340 < mitch> instead of gtk_box_new(GTK_ORIENTATION_FOO);
 341 < mclasen> well, we still can't instantiate the flippable ones...
 342 < mitch> i know
 343 < mitch> i wanted to have them instantiatable
 344  * mclasen too
 345 < mitch> and i still didn't get what exactly we should change with default values
 346 < mitch> apart from e.g. gtk box to pack shrinking by dwfault, not expanding
 347 < ebassi> didn't the wiki page about that already listed the changes?
 348 < ebassi> for the properties, I mean
 349 < mclasen> so, should we reconsider that 'defaults block !absract
 350 < mclasen> ' decision from long ago
 351 < mclasen>  ?
 352 < mitch> we should go over the list again i think, but yes
 353 < mitch> timj wanted to e.g. make these widgets visible by default
 354 < mclasen> tangentially related: we should fix the orientation properties to have correct declared initial values
 355 < mitch> but that's something that should be done for all widgets imho
 356 < jjardon> davidz, I've created this, if it's useful :http://live.gnome.org/GTK%2B/RI
 357 < mitch> mclasen: initial values?
 358 < Company> mclasen, mitch: related to that, would a g_param_spec_copy_with_new_default (const GValue *default) make sense?
 359 < Company> so that subclasses could override default values?
 360 < mclasen> yeah, if you can figure out how to do it 
 361 < mclasen> the last time I looked at teaching the paramspecredirect to change defaults
 362 < mclasen> I couldn't figure it out
 363 < mitch> you mean *just* the default value?
 364 < davidz> jjardon: cool, thanks
 365 < mclasen> I guess if you just copy, then that'll work
 366 < kalikiana> yes, without re-creating it entirely
 367 < Company> mitch: yeah, so HBox and VBox can have a different default orientation
 368 < mitch> yea 
 369 < mitch> Company: i'm rather for killing these classes
 370 < danni_> mclasen: you could make it not a redirect
 371 < Company> ya, it was just an example
 372  * danni_ did something similar to that very recently
 373 < Company> it's useful elsewhere
 374 < danni_> it just proxied cmp, and validate
 375 < mitch> problem is that they would also all have to become CONSTRUCT properties
 376 < mitch> for overridden defaults i mean
 377 < Company> mitch: you'd have to do that in instance_init, too
 378 < Company> for non-construct ones
 379 < mitch> Company: not if they are construct
 380 < mitch> yea
 381 < mclasen> we already do it in instance_init, no ?
 382 < Company> mclasen: yes
 383 < mitch> that's error prone ;)
 384 < Company> mclasen: but it confuses apps like glade
 385 < mclasen> I know, thats why I want the declared default fixed
 386 < mitch> aaah
 387 < Company> i suggested to tristan that he should write a test that instantiates all widgets and compares their property values with the defaults
 388 < Company> just to see how many cases we have where they don't match
 389 < mclasen> Company: like gtk/tests/defaultvalue.c ?
 390 < Company> don't think he ever did
 391 < mitch> Company: such a test is already there
 392 < Company> oh :)
 393 < mclasen> Company: that one blacklists all the properties where its broken...
 394 < mitch> heh
 395  * Company HAS A LOOK
 396 < mclasen> well, in some cases its unfixable, like object-valued properties
 397 < Company> /cas-lock
 398 < jjardon> For the record, this is the code of GtkHBoxButton after remove deprecated code: http://git.gnome.org/cgit/gtk+/tree/gtk/gtkhbbox.c?h=gtk-2.90
 399 < mitch> fixing that for next stable is also a good goal
 400 < kalikiana> Company, so you like unit tests but never looked at gtk's tests? tsts ;)
 401 < mitch> jjardon: looks like hbox, hruler, hscale etc ;)
 402 < Company> kalikiana: that's mostly becaue they're not taken serious enough
 403 < kalikiana> I guess they are just too chaotic
 404 < jjardon> mitch, yeah: see GtkVBoxButton: http://git.gnome.org/cgit/gtk+/tree/gtk/gtkvbbox.c?h=gtk-2.90
 405 < Company> kalikiana: and not run often enough
 406 < mclasen> mitch: so, clearly, before we can even talk about deprecating h/v variants, we have to solve the abstractness issue
 407 < Company> kalikiana: and you're not shamed publically if you break them
 408 < kalikiana> Company, yeah, we need a bot to IRC and email breakes
 409 < kalikiana> that would be cool
 410 < mitch> mclasen: all classes i hacked up just work totally fine when you remove ABSTRACT
 411 < mclasen> the thing is, they don't break that often
 412 < mclasen> ...lack of coverage...
 413 < mclasen> mitch: no doubt
 414 < bilboed> did I hear buildslaves ?
 415 < mclasen> the holdup here is entirely about default values
 416 < mitch> yea...
 417 < mclasen> but we cannot really change the defaults in 2.x. Or can we ?
 418 < mitch> mclasen: only if somebody instantiates a gtkbox directly,
 419 < mitch> mclasen: i'm just not totally sure about the how
 420 < mclasen> well, then you gotta give all derived classes the old default back
 421 < mclasen> how are you going to do that for out-of-tree stuff ?
 422 < mitch> void
 423 < mitch> _gtk_box_set_old_defaults (GtkBox *box)
 424 < mitch> {
 425 < mitch>   GtkBoxPrivate *private;
 426 < mitch>   g_return_if_fail (GTK_IS_BOX (box));
 427 < mitch>   private = GTK_BOX_GET_PRIVATE (box);
 428 < mitch>   private->default_expand = TRUE;
 429 < mitch> }
 430 < mitch> that's how we do it now, as an example
 431 < mitch> um, good point
 432 < mitch> maybe we should simply got for GTK_IS_VBOX() || GTK_IS_HBOX() here
 433 < mitch> ugly but works
 434 < mitch> and will go away as soon as we remove te deprecated hbox and vboxed
 435 < mitch> vboxes*
 436 < kalikiana> mclasen, wouldn't out-of-tree classes inherit the subclasses defaults?
 437 < kalikiana> if we fix them that is
 438 < mitch> yes, right actually
 439 < mclasen> kalikiana: if we change the default for boxes to visible= true, we can fix hbox/vbox to be !visible still
 440 < mitch> as long as they derive from the old subclasses they inherit their hacks too
 441 < mclasen> but some gimpbox thats directly derived from gtkbox is going to be visible by default, then
 442 < kalikiana> does it actually inheit gtkbox?
 443 < kalikiana> is that allowed yet?
 444 < mitch> mclasen: and it will know that, because it derives from gtkbox!
 445 < kalikiana> s/allowed/allowed by gobject
 446 < mitch> kalikiana: deriving is allowed of course
 447 < kalikiana> Hm.. ok. Wasn't sure if it was protected somehow
 448 < Company> kalikiana: yes
 449 < jjardon> Related bug about properties: https://bugzilla.gnome.org/show_bug.cgi?id=587256
 450 < mclasen> one can perhaps play horrible games to figure out at construct time whether its a box or a subclass...
 451 < mclasen> ...but the pain involved is certainly considerable...
 452 < mitch> you can do that in init()
 453 < mclasen> the thing is, you need to do it in a box function, not in a function of the derived class
 454 < mitch> it's a simple == but you can't use the type definition macros any longer :(
 455 < jjardon> (that bugs makes glade unusable for some people)
 456 < mclasen> we probably need a worked out example of that...
 457  * mclasen looks at the rest of the deprecation list
 458 < mclasen> those look easier...
 459 < mitch> what list?
 460 < mclasen> notebook tab packing, gtkcurve, multihead
 461 < mitch> oh, yea, the usual stuff :)
 462 < mclasen> so, I don't think we need to discuss gtkcurve really
 463 < mitch> die die die
 464 < ebassi> and the tab packing on Notebook either
 465 < ebassi> evilness
 466 < Company> but i want my help tab on the right!
 467 < mclasen> looking at gtkcurve, theres some more in the too-specialized departement
 468 < mclasen> gtkruler and its ilk
 469 < mitch> ruler is used in many apps though
 470 < ebassi> Company: :-P
 471 < mclasen> mitch: oh, in that case, we should move it out of the 'too-specialized' section in the docs
 472 < mitch> mclasen: well actually gimp has gimpruler now, so... ;)
 473 < ebassi> if I had to implement a ruler nowadays I'd probably reach for cairo and DrawingArea
 474 < mclasen> mitch: cool ruler features you are holding back ?!
 475 < Company> did anyone review all the APIs we have for "too specialized"?
 476 < mitch> haha :)
 477 < Company> stuff like GtkLabel::pattern?
 478 < mitch> mclasen: but yes indeed ;)
 479 < mitch> Company: wtf is that?
 480 < kalikiana> Company, I doubt so. It would be a good idea, though
 481 < mclasen> Company: nobody did, as far as I know
 482 < ebassi> mitch: underscore a label's contents using a pattern
 483 < mclasen> so, we have agreement to deprecate gtkcurve and notebook tab packing
 484 < mclasen> what about !multihead-safe api
 485  * mclasen is a bit torn on that 
 486 < mitch> please
 487 < ebassi> mclasen: for that I kinda agree with your comment on the bug
 488 < mitch> i know owen's argument of simplicity here, but it just sucks to have these legacy apis :/
 489 < mitch> bug #?
 490 < mclasen> https://bugzilla.gnome.org/show_bug.cgi?id=547920
 491  * mclasen rereads his own comment
 492 < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=547920#c24
 493 < desrt> btw
 494 < desrt>  - [deleted]         gtk-2.16
 495 < desrt>  * [new branch]      gtk-2.90 -> gtk-2-90
 496 < desrt>  - [deleted]         gtk-2.90
 497 < desrt> bye :)
 498 < mclasen> thanks, desrt
 499 < mitch> mclasen: how it multihead dying?
 500 < mitch> i'm not totally up-to-date on that front
 501 < mclasen> mitch: you don't have multiple screens anymore
 502 < mitch> is*
 503 < mclasen> you have a single screen, with multiple monitors 
 504 < mitch> oh heh
 505 < mclasen> since nobody does the b/w + color monitor workstation setup from the 80ies anymore
 506 < bilboed> and even so it would be handled at the X level
 507 < kalikiana> what about remote?
 508 < danni_> remote is a separate Display, rather than a separate Screen
 509 < mitch> does any app apart from emacs and gimp support opening another display?
 510 < mitch> danni_: so it is a separate screen too
 511 < danni_> mitch: ok, valid
 512 < kalikiana> danni_, I just mean sth like running an app over ssh so it has a different gtk-settings :)
 513 < danni_> mitch: I guess though, since you're connected to a new Display, you'll get the default Screen for that Display
 514 < mclasen> so, I kinda see the point that this is a nice amount of api to get rid off
 515 < mclasen> do we know if gtk builds with multihead-safe turned on ?
 516 < danni_> can you hold connections to two separate Displays in X? I guess you could... I've never tried
 517 < Company> danni_: gstreamer-cairo holds roughly 50
 518 < mitch> danni_: you can, try that sick hack in gimp ;)
 519 < Company> danni_: so the stuff can pass thread boundaries (it's X Displays, not gdk displays though)
 520  * kalikiana ponders saving that gimp quote as a universal excuse for new api
 521 < mitch> heh
 522 < Company> next item?
 523 < kalikiana> eeeeebassi
 524 < Company> hilight fail
 525 < Company> ebassi: next item!
 526 < mclasen> night item is 290 branch for glib
 527 < mitch> freudian slip?
 528 < mitch> i'm tired at least ;)
 529 < kalikiana> freudian gstring
 530 < ebassi> heh
 531 < mclasen> nah, I just omitted the .
 532 < mclasen> so, do we need one ? if so, what for ?
 533 < bilboed> ebassi, what would that entail ?
 534 < ebassi> bilboed: I do not know -- jjardon added it :-)
 535 < kalikiana> as far as I realize glib 2.9 was voted down quite loudly
 536 < kalikiana> since it's not worth it
 537 < ebassi> I guess it revolves around the "what do we do with glib" question
 538 < mitch> we don't have much to do there apart from remove deprecated stuff
 539 < mitch> not worth a 3.0, or?
 540 < ebassi> kalikiana: pretty much, though people have been asking for all sorts of crazy stuff to land in the next 3 months without testing and review ;-)
 541 < bilboed> crazy as in additions ? or crazy as in fixing tons of little stuff nobody's ready to review ?
 542 < ebassi> crazy as in additions
 543 < kalikiana> ebassi, crazy but painful is better than pain without gain :P
 544 < Company> desrt and davidz is a recipe for crazy
 545 < Company> and i mean that as a compliment
 546 < kalikiana> or typos
 547 < ebassi> like the usual 
 548 < ebassi> ""collection API"
 549 < ebassi> request
 550 < Company> ...
 551 < mitch> treemodel into glib!!1!1!!
 552 < Company> is anyone using libgee outside of vala?
 553 < ebassi> doubt it
 554 < kalikiana> gee, nobody does
 555 < mitch> are we idling?
 556 < bilboed> ebassi, seems like a moo point
 557 < ebassi> yep
 558 < bilboed> ebassi, if stuff is reviewed... why put it in another branch ?
 559 < mitch> gobject-performance?
 560 < mitch> ok we're back on the last point :)
 561 < bilboed> just waiting for ebassi to close the previous topic :)
 562 < ebassi> as for the "application class" point, I'd say we wait until the D-Bus stuff lands :-)
 563 < mclasen> yeah, that should wait until then
 564 < Company> i'd like to have a schedule for gobject-performance
 565 < ebassi> bilboed: nothing much to close :-)
 566 < Company> because i'm kinda afraid noone will be looking at it and then it's too late to land
 567 < bilboed> right
 568 < Company> and then the gstreamer guys will keep ranting about glib maintainers being idiots
 569 < bilboed> which maintainers ? :)
 570 < Company> and then it'll all be my fault again
 571 < mclasen> Company: you live in the same town, no ? you could just casually 'meet' timj somewhere...
 572 < Company> mclasen: he's big and scary
 573 < mitch> yea bring some chains to bind him to the table
 574 < mclasen> but you have performance-enhancing branches
 575  * bilboed was worried this topic would go haywire
 576 < bilboed> mclasen, yes, gobject-performance on glib, and some others on fdo
 577 < bilboed> mclasen, the point is ... merging them
 578 < kalikiana> "some others" sounds like it must be very well organized
 579 < mclasen> Company: so, I would love to get serious about the gobject-performance stuff when alex comes back in a few weeks
 580 < Company> i'd just like to avoid everyone blocking on timj
 581 < Company> just like with class data
 582 < bilboed> kalikiana, you'd prefer me to pollute git.g.o with 500 branches ?
 583 < mclasen> and at that point, I'll try to reroute review around timj and get stuff unblocked
 584 < kalikiana> bilboed, Hm.. you realize you don't *have* to branch only because it's git :P
 585 < mclasen> does that sound fair ?
 586 < bilboed> kalikiana, agreed, I should just commit to master
 587 < Company> mclasen: yeah
 588 < mclasen> ok, cool
 589 < mitch> mclasen: it sounds like something nobody can object against
 590 < Company> mclasen: as long as it makes next stable glib, i'm happy :)
 591 < bilboed> same here
 592 < mclasen> almost at the 2 hour mark, should we defer remaining issues until ...when ?
 593 < mclasen> next week ?
 594 < mitch> yes please
 595 < Company> aren't we done?
 596 < mclasen> there's misc, and I would have brought up some tooltips revamp I'm doing right now
 597 < mitch> there is misc on the agenda :P
 598 < mclasen> but I'll table that for today
 599 < mitch> mclasen: yet another revamp?
 600 < ebassi> so next meeting in two weeks?
 601 < ebassi> November 3rd
 602 < ebassi> ?
 603 < mclasen> mitch: just a facelift 
 604 < mitch> next week?
 605 < mclasen> rounded corners, that kind of stuff
 606 < mitch> mclasen: neat :)
 607 < mclasen> and maybe better positioning
 608 < Company> ebassi: didn't someone suggest next week?
 609 < ebassi> or next week
 610  * Company doesn't mind
 611 < bilboed> fine by me
 612 < mclasen> there was some motion to meet earlier, because we have stuff on the agenda
 613 < ebassi> either is fine by me - I just need the date for the wiki (and for the reminder)
 614 < mitch> since we don't have infinite time i'd say next week
 615 < mclasen> so make it next week, then
 616 < ebassi> okay, next week, October 27th
 617 < ebassi> thanks everyone
 618 < bilboed> thx