1 < ebassi> meeting time
   2 < desrt> agenda url?
   3 < ebassi> http://live.gnome.org/GTK+/Meetings -- agenda
   4 < ebassi> pretty long so I won't paste it here :-)
   5 < ebassi> Company wanted to go first because he has to go before 21:00 UTC, AFAIR
   6 < desrt> Company: poke
   7 < ebassi> so: 1. rendering-cleanup branch/gtk_widget_draw
   8 < desrt> AWOL?
   9 < desrt> let's wait 5 mins?
  10  * Company almost there
  11 < mclasen> girlfriend come home early ?
  12 < Company> 1 minute
  13 < desrt> k
  14 < Company> ok
  15 < Company> did someone try to summon alex?
  16  * mclasen tries
  17 < mclasen> its late for him, though
  18 < Company> lets just start
  19 < mclasen> I'd say lets go ahead without him
  20 < Company> i'll summarize: rendering-cleanup part 1 has hit master and gtk-2-22 and (almost) everyone is busy porting their apps and reporting great success
  21 < Company> part 2 (that is GdkPixmap removal + switching theme engines to cope) is in preparation and from my view well received
  22 < Company> though i have no idea how easy we can make a gtk2 => gtk3 transition for that
  23 < Company> and part 3 (fixing GdkWindow) is hotly contested on the list atm
  24 < mclasen> that'll affect anybody calling a gtk_paint function ?
  25 < Company> no
  26 < mclasen> part 2, I meant ?
  27 < Company> still no :)
  28 < Company> i think you can probably make part 2 work with deprecations + ugly hacks in gtk2 if you wanted to
  29 < mclasen> who is affected, then ?
  30 < Company> everything that uses GdkPixmap for anything is affected
  31 < Company> that's mostly dnd and code that buffers or does special tricks for drawing
  32 < ebassi> Company: what happens for GdkOffscreenWindow.get_pixmap()?
  33 < Company> "code that buffers" == keeping a pixmap for easy blitting later
  34 < mclasen> do you have a grep of the tree, or one of fredp's fantastic pages for that ?
  35 < Company> ebassi: oh right: and offscreen windows :)
  36 < ebassi> Company: because clutter-gtk uses that to do the texture-from-pixmap embedding of gtk widgets
  37 < Company> yeah, it's a tricky thing
  38 < Company> we could just store the pixmap's cairo surface and return that in a offscreen.get_surface()
  39 < Company> but that's the hacky part
  40 < mclasen> I think we want to have a good idea of the porting effort / compat story before landing part 2
  41 < Company> i agree
  42 < mclasen> of course, we don't have a huge window for the parts that need to land in 2.22
  43 < Company> but i suppose i'll need to finish it before having an idea what to do about it
  44 < ebassi> fredp's git grep results should help
  45 < Company> mclasen: i'm pretty sure landing it in 2.22 would be bad
  46 < mclasen> isn't there a deprecation component here ?
  47 < mclasen> for gdkpixmap, at least ?
  48 < Company> i think landing gdkpixmap cleanup work would require a 2.24 gtk, with even more deprecations and helper APIs
  49 < Company> and it would require some apps inside gnome to not compile with DISABLE_DEPRECATED
  50 < Company> unless we'd really want to be hacky with themes
  51 < Company> as theme engines are outside of our control and they can only render to windows or pixmaps
  52 < Company> and with pixmaps gone, that is some sort of problem...
  53 < desrt> 2.22, 2.24, 3.0?
  54 < desrt> all before the end of the year?
  55 < Company> (you could invent clever ways to render to an offscreen window, then get the surface from it, then use that, but ugh)
  56 < mclasen> well, 2.22 was supposed to be parallel with 3
  57 < mclasen> since 3 moved back, we have a tiny window to squeeze in a 2.24 if we think thats absolutely necessary
  58 < Company> desrt: i think it's not a lot of work to backport useful APIs and add deprecation markers around existing ones
  59 < ebassi> the window to port from 2.24 to 3.0 is still going to be 3 months between gtk+ 3.0 and gnome 3.0
  60 < Company> desrt: it's just a lot of work if you keep the "must recompile to gtk3 without changes" idea
  61 < mclasen> Company: I think we've waffled a bit on this already, with part1
  62 < Company> mclasen: mostly with cairo_region_t - i dont think part 1 violated that
  63 < Company> actually, i'm pretty sure it didn't
  64 < mclasen> true, cairo_region is what I meant
  65 < Company> the reason for 2.24 for me would be to provide an update path for app developers: mkae it work with: 2.22, 2.24, 3.0 - in that order
  66 < Company> or something like that
  67 < mclasen> how do others feel about this ?
  68 < desrt> so basically it's a bodge of new 3.0 bling without breaking the old 2.x stuff
  69 < Company> yeah
  70 < Company> something like gtk_drag_set_icon_surface()
  71 < Company> (not sure how to do that with gtk2 though - probably with a copy to a pixmap ;))
  72 < Company> and some really useful convenience APIs - like the gdk_window_create_similar_surface() that I only realize are useful while hcking on this stuff
  73 < tristan> Company, I would have liked to do that for SizeRequest (backport it and let us remove more cruft) but from what I understand it cant be dont 100% portabley
  74 < mclasen> ebassi: will clutter-gtk have a chance to work with the pixmap removal at all ? in that timeframe ?
  75 < tristan> s/dont/done
  76 < Company> fwiw, i suspect more weirdnesses to come up during 3.0 development where we'd wish we had deprecated APIs in GTK2 so we could remove them for 3.0
  77 < tristan> it still technically breaks at least inkscape and maybe still gimps wrapping box
  78 < Company> outside of the rendering-cleanup
  79 < ebassi> mclasen: well. clutter-gtk 1.0 will depend on gtk 3.0 anyway; I have to do a clutter-gtk 0.12 that depends on gtk+ 2.x with the widgets embedding for evolution (and meego), but I can use #undef GTK_DISABLE_DEPRECATED if push come to shove
  80  * desrt eyes GtkAction
  81 < ebassi> mclasen: if I have to get a X11 Pixmap from a cairo surface or from a GdkPixmap, I don't particularly care
  82 < mclasen> ebassi: well, I guess the question is: will clutter-gtk 1.0 work ok without pixmaps, or are you going to be in trouble ?
  83 < mclasen> ah, ok
  84 < ebassi> mclasen: I'm going to be in trouble if I don't have a Pixmap XID
  85  * herzi_ too
  86 < ebassi> otherwise, it's just API calls
  87 < Company> mclasen: everything will work fine, pixmaps break nothing but function names really
  88 < Company> *pixmaps removal
  89 < mclasen> ok
  90 < Company> a cairo xlib surface has the same API basically
  91 < mclasen> so, is this an agreeable plan: pixmaps stay in 2.22, we'll extend 2.x with a short release that nukes them ?
  92 < desrt> by 'nuke' you mean deprecate
  93 < mclasen> plus whatever additional deprecations we find necessary 
  94 < Company> (and whatever else comes up!)
  95 < ebassi> Company: so I guess we can get gdk_window_get_similar_surface() take into account offscreen windows
  96  * Company doesn't want to be the only one responsible for 2.24 ;)
  97 < ebassi> Company: too late
  98 < ebassi> ;-)
  99 < Company> ebassi: what do you mean "take into account"?
 100 < ebassi> Company: I mean, make sure that a GdkOffscreenWindow will return the surface wrapping the backing pixmap
 101 < mclasen> Company: plus we'll make you fix all of the desktops rendering, so you'll be responsible for gnome3 too
 102 < mclasen> well, you already claimed the gnome3 slip anyway :-)
 103 < Company> yeah
 104 < Company> i don't want people to hate me when gnome 3 gets delayed to next september...
 105 < ebassi> we'll make sure it doesn
 106 < ebassi> 't
 107  * ebassi prepares the whip
 108 < mclasen> anything else on rendering cleanup ?
 109 < Company> oh, also there's a part 2.5: I intend to make GdkColormap die
 110 < mclasen> I guess we all agree that part 3 is pretty much up in the air still
 111 < Company> colormaps are just confusing these days and the only use case is setting translucency on windows
 112 < Company> and we can do that better with visuals
 113 < Company> that would be 2.24 material again
 114 < mclasen> yep
 115 < ebassi> okay, the point on releases and dates is pretty much sorted already: 2.22 for GNOME 2.32, 2.24 with 3.0
 116 < mclasen> so, 2.22 in september, 2.24+3 endofyear
 117 < ebassi> yup
 118 < Company> but yeah, summary: part 1 landed, part 2 in preparation, part 3 in flux and not really necessary, part 4 probably easy with part 2 and without part 3 even
 119 < mclasen> part4 is what again ?
 120 < mclasen> the theme stuff ?
 121 < Company> expose_event => draw
 122 < krh> yeah, what was the parts again?
 123 < Company> part 1: removal of gc, image etc
 124 < krh> (sorry if it was pasted earlier, joined late)
 125 < Company> part 2: getting rid of GdkPixmap (requires themeing changes or huge hacks) and GdkColormap
 126 < Company> part 3: reorg of GdkWindow
 127 < Company> part 4: expose_event => gtk_widget_draw()
 128 < mclasen> krh: is any of this important for your wayland backend ?
 129 < krh> mclasen: it all makes it easier
 130 < krh> the longer Company hacks on gtk+, the less I have to do :)
 131 < Company> considering all the code does cairo_create (); draw(); cairo_destroy() already, it should all more or less work in wayland
 132 < mclasen> he gets all the blame, and you get all the fame :-)
 133 < krh> and all I have to do is wait :)
 134 < Company> "it's impressive how much you can get done if you don't care who gets the glory"
 135 < mclasen> I guess the more interesting parts in the wayland backend are input related anyway ?
 136 < mclasen> but lets move on, I think
 137 < krh> yeah
 138 < ebassi> desrt: I guess glib 2.26 is still on for GNOME 2.32 and we'll also do a 2.28 for gtk+ 3.0 (dec '10) or do we delay until GNOME 3.0 (march '11)
 139 < Company> krh: you redo input for GdkWindow!
 140 < ebassi> desrt: I'm just trying to get the full picture
 141 < desrt> i'd like a glib release to go with 2.24/3.0
 142 < desrt> i'm sure there's a thing or two that will come up
 143 < ebassi> okay
 144 < mclasen> sounds reasonable to me, too
 145 < krh> Company: the new GdkDevice goes a long way towards what I need, actually
 146 < Company> we should plan for a glib release, we can still omit it if nothing comes up
 147 < ebassi> did whatever danw was working on actually got reviewed/landed or do we wait for the next cycle?
 148 < mclasen> we've pushed a lot of new stuff in this cycle, so there's probably going to be some additions required as people adopt it
 149 < mclasen> danw was working on at least two things
 150 < mclasen> some tls / ssh /whatever networking
 151 < Company> ebassi: whaddaya mean? the caching, the TLS sockets or proxies?
 152 < ebassi> proxies
 153 < mclasen> and some unix stream improvement
 154 < Company> i _think_ proxies landed
 155  * Company looks it up
 156 < mclasen> we also didn't land the datetime work yet
 157 < ebassi> I think TLS sockets were already punted, but proxy support was requiring a final review
 158 < ebassi> mclasen: I did a review again, but stuff still is missing
 159 < ebassi> I think I'll JFDI myself
 160 < mclasen> thats the spirit
 161 < mclasen> so it looks like we'll have things to land in a 2.28 glib release anyway
 162 < Company> hrm no
 163 < mclasen> who is next ? refactoring branch (jjardon) or gapplication (desrt) ?
 164 < Company> the proxy bug is still open
 165 < mclasen> since jjardon is not here, desrt wins, I guess
 166 < desrt> good times
 167 < desrt> i'm landing my changes for gaction today
 168 < mclasen> might be good to give a brief summary for people who haven't followed our discussion the other day ?
 169 < desrt> network is going to shit here :(
 170 < desrt> okay.  so basically: i'm introducing a new abstract class called a GActionGroup
 171 < Company> proxy stuff: <danw> Company: last i knew the plan was still to get it in. stormer is working on it and very close to done
 172 < desrt> it represnts a group of named actions.  each action has a parameter type so the Activate() signal takes this parameter
 173 < desrt> it's a GVariant*
 174 < desrt> so you can have parameters that are tuples if you want to support multiple parameters
 175 < desrt> there is a simple implementation of this -- GSimpleActionGroup
 176 < desrt> it's just a hash table (by name) of another new class being introduced: GAction
 177 < desrt> that's just one named action
 178 < desrt> the idea is to make GtkAction a subclass of GAction
 179 < stormer> sorry was way, code have had severa review now and is ready now
 180 < desrt> load a bunch of GtkActions up into a GActionGroup
 181 < desrt> and throw that into your GApplication
 182 < mclasen> stormer: thanks for the update
 183 < ebassi> mostly similar to what MxApplication does, so I approve :-)
 184 < desrt> (GApplication itself will be a GActionGroup, so you can invoke the actions on the Gapplication and they will either be delivered to the internal actiongroup (master process) or transmitted over the bus (remote process)
 185 < mclasen> those actions don't have descriptions anymore, though
 186 < ebassi> desrt: is-a?
 187 < mclasen> just names
 188 < desrt> right.
 189 < desrt> ebassi: gapplication subclasses gactiongroup
 190 < ebassi> mmh
 191 < ebassi> I'd rather go with a proxy instead of a direct inheritance
 192 < desrt> it sort of is a proxy
 193 < desrt> it's an actiongroup that you add other actiongroups to
 194 < desrt> (possibly more than one)
 195 < desrt> that's where the actions go in the primary instance case...
 196 < desrt> if the gapplication finds out that it's remote then it just drops its reference on all the (local) actions that you gave it
 197 < desrt> a couple of things worth noting that are different/improved vs. GtkAction
 198 < desrt> 1) there's a unified mechanism by which actions can be stateful.  an action has a GVariantType* that is the type of the 'state'
 199 < desrt> (if NULL then no state)
 200 < desrt> this is how we do things like toggleactions -- the state type would be boolean in this case
 201 < desrt> 2) as mclasen mentioned, no descriptions are included in GAction.  also no tooltips, labels, icons, display hints, visibility, anything like that
 202 < desrt> only 'enabled' (which more or less is the same as 'sensitive')
 203 < mclasen> so we'll have to have some presentation layer on top, I assume
 204 < desrt> right
 205 < desrt> GtkAction will subclass GAction and it will have all that info inside of it
 206 < ebassi> fair enough
 207 < desrt> 3) actions can be in more than one GActionGroup
 208 < desrt> also: a GtkAction can be in a GtkActionGroup and several GActionGroup at the same time
 209 < desrt> a GActionGroup doesn't impact the GAction in any way (sensitivity sharing, etc)
 210 < desrt> also: GtkActionGroup and GActionGroup are not related
 211 < desrt> 4) GActionGroup has change notification signals for when items are added, removed, or when an item has its 'enabled' status or state changed
 212 < desrt> that means that we can export a dbus API properly
 213 < desrt> 5) i plan to add a GtkRadioGroup that is a subclass of GAction that works like this:
 214 < desrt>   - you add GtkRadioAction or GtkRadioButton to it
 215 < desrt>   - each button you add is given a (string) name
 216 < desrt>   - the 'state' of the action is the name of the currently selected button
 217 < mclasen> is there any provision for platforms that may not allow fully general parameterized actions ?
 218 < desrt>   - begin gsettings binding bliss
 219 < desrt> mclasen: they can't call them.
 220 < mclasen> or rather, how is the platform abstraction handled in this rewrite ?
 221 < desrt> mclasen: our concern for other platforms ends at the ability to integrate menus
 222 < desrt> menu items can't have parameters anyway
 223 < desrt> if you want the scripting interface then clearly you'll need dbus
 224 < mclasen> will we stil have a dbus implementation and a placeholder where other platform implementatoins can be fit in ?
 225 < desrt> heh.  yes. :)
 226 < desrt> i have no particular desire or plans to investigate the other platforms :/
 227 < mclasen> a little unfortunate that the os x guys haven't shown much enthusiasm yet to make their stuff fit in here
 228 < desrt> las (on #gtk+) indicated that he has some interest to do so...
 229 < desrt> but not enough time at the moment
 230 < mclasen> your rework might make it easier for them, I assume
 231 < desrt> it's worth noting, btw, that i just got my email back from tedg
 232 < mclasen> they had quite some issues with colins initial scope
 233 < desrt> and he's willing to make really substantial changes to dbusmenu to fit our separated actions/menu design
 234 < aruiz> \o/
 235 < desrt> who are 'the mac guys'?
 236 < desrt> las, for example?
 237 < garnacho> I'd talk with kris as well
 238 < mclasen> las and I don't know john ralls irc nic
 239 < desrt> las seems pretty much very positive with almost everything that i have proposed
 240 < desrt> so i take that to be a good sign
 241 < mclasen> I don't think dbusmenu will be very relevant per se here ? except as an example of prior art, I guess
 242 < desrt> well
 243 < desrt> dbusmenu has several existing implementations
 244 < desrt> truth be told, from a technical standpoint, it's my opinion that it's simply not what we want
 245 < desrt> i listed my problems with it to ted and said "i doubt you want to change it this much, so it looks like we end up going our own way"
 246 < desrt> he replied:
 247 < desrt> Honestly, I'd rather fix dbusmenu to address everyone's concerns than
 248 < desrt> develop something new on either front.  I think the only thing that's
 249 < desrt> radically different is the concept of the dual set of properties.
 250 < desrt> Everything else seems evolutionary.
 251 < desrt> ("dual set of properties" => how he understood my description of action/menu separation)
 252 < desrt> i'll keep in touch with him in any case
 253 < mclasen> sure
 254 < desrt> none of this speaks to GtkApplication yet
 255 < aruiz> he should be attending this meetings though
 256 < aruiz> but anyway
 257 < aruiz> :-)
 258 < desrt> ebassi: i'm interested in what you might have to say about that
 259 < aruiz> these*
 260 < ebassi> desrt: as I said, I generally agree with the design; I looked at the earlier commits and they look fine
 261 < desrt> okay
 262 < desrt> i had a few questions about the existing code
 263 < desrt> it does some really random things
 264 < ebassi> desrt: I still have some reservation on GApplicationGroup being an actual ancestor of GApplication, but nothing much
 265 < desrt> like looking at some weird environment variables in order to find a .desktop file to open to determine the default title that application windows get
 266 < desrt> that seems so broken
 267 < desrt> ebassi: i'd like to chat with you after the meeting, then
 268 < mclasen> desrt: that was just a performance hack
 269 < ebassi> desrt: there is no uniform way of getting a .desktop file without cooperation from the thing that sets up the execution environment
 270 < mclasen> if we launch it from a desktop file, no need to go over all desktop files to find it again on the other side
 271 < ebassi> desrt: unless we rename all .desktop file using the unique application id
 272 < mclasen> born out of colins desire to have a single place for app information
 273 < desrt> why does the app want to find its own desktop file?
 274 < ebassi> desrt: because we're going to put more state into it
 275 < desrt> interesting
 276 < ebassi> and remember remote instances
 277 < desrt> so one thing that comes to mind is that the environment variable approach is going to end up being insufficient, i think
 278 < ebassi> if I want to control rhythmbox by using a GApplication proxy I want to extract meta-data from the .desktop file of rhythmbox
 279 < desrt> if we want to talk about using dbus to launch apps...
 280 < desrt> we can shove something into platform-data i guess......
 281 < ebassi> desrt: using the platform data would be the non-hacky version
 282 < desrt> much better we do it properly, though, and somehow make it possible to go from appid to desktop file efficiently
 283 < ebassi> desrt: one way is to create a desktop-file-cache, similar to the icon-cache, to make it easy to index stuff efficiently
 284 < desrt> yes.  that's sort of along the lines of what i was thinking, i guess
 285 < mclasen> yeah, having a real app db would be nice
 286 < desrt> alternatively: investigating changing desktop file filenames or appid strings to be the same thing
 287 < ebassi> but that would require a gtk-update-applications binary executed post-install
 288 < mclasen> we already run update-desktop-database
 289 < mclasen> and update-mime-database
 290 < mclasen> and gtk-update-icon-cache
 291 < ebassi> mclasen: right
 292 < mclasen> ...
 293 < desrt> don't forget glib-compile-schemas =)
 294 < mclasen> oh, and glib-compile-schemas
 295 < mclasen> jinx
 296 < desrt> thx.
 297 < desrt> okay.  small technical detail.
 298 < ebassi> desrt: we're getting pushback for changing application names - changing application files will take ages. and I *already* know that OO.o and Eclipse will take at least 2 years to notice ;-p
 299 < desrt> one more point i think is worth dragging into this discussion (and it's on the agenda anyway): gtk_init
 300  * mclasen put 'drop cmdline args' on the agenda further down...
 301 < Company> do it automatically when the so is loaded!
 302  * Company hides again
 303 < desrt> right.  i'm pulling it up. :)
 304 < ebassi> heh
 305 < ebassi> Havoc's old pet peeve
 306 < desrt> on .so load is very obviously wrong
 307  * mclasen doesn't remember havoc having a prominent position on this ?
 308 < desrt> anyway... i don't care too much about the fact that you have to call gtk_init()
 309 < desrt> i care that it wants to eat your commandline args
 310 < ebassi> mclasen: he tried to get clutter to get rid of it :-)
 311 < mclasen> of the init or of the cmdline args ?
 312 < ebassi> mclasen: the init in itself
 313 < desrt> ebassi: i think having explicit init is very helpful just because initing gtk is a big deal
 314 < desrt> connection to X server opens up, etc
 315 < desrt> also: your app can be killed if that fails...
 316 < Company> desrt: why would you link against ligtk but not call gtk_init()?
 317 < ebassi> desrt: I'd like either a gtk_init() with no args and a gtk_parse_args() that takes my option entries/groups and parses everything
 318 < ebassi> or only gtk_parse_args()
 319 < desrt> Company: take the GApplication case -- no reason for the remote instance to connect to X
 320 < desrt> ebassi: i'm actually advocating that Gtk have no commandline arguments at all, ever
 321 < Company> desrt: hrm
 322 < Company> no command line args, ever!
 323 < ebassi> desrt: so a gtk_init() with no args
 324 < Company> no lib should take commandline args
 325 < desrt> yes.  and no parse_args() functions.
 326 < mclasen> desrt: its too late, for ever, but we can discuss removing them from gtk3
 327 < desrt> gtk should use environment variables if it wants options
 328  * Company <3 that gtk3 has GTK2_RC_FILES
 329 < desrt> mclasen: right.  'ever, after 3.0' :)
 330 < desrt> we have a compatibility concern, of course
 331 < desrt> people who want to have gtk2 and gtk3 apps without lots of #ifdef
 332  * mclasen wonders if there is a envvar variant of --sync
 333 < desrt> anything that lacks an environment variable can gain one if there is demand
 334 < mclasen> doesn't look like it, but can be easily added, of course
 335 < Company> mclasen: not in xlib, no
 336 < mclasen> desrt: the one concern with env vars is that they leak
 337 < mclasen> unless you are careful when launching 
 338 < desrt> mclasen: i think we're long past that point, though
 339 < Company> mclasen: isn't that usually what you want?
 340 < desrt> consider our current situation: an assortment of options to gtk: some are commandline, some are environment
 341 < desrt> we already have the leak problem
 342 < mclasen> yeah, its not a huge concern
 343 < mclasen> just pointing it out
 344 < desrt> anyway... are we brave enough to do gtk_init(void)
 345 < mclasen> and we do care to clean some things out of the environment already, like the startup notification stuff
 346 < desrt> or should we rather tell people to always do gtk_init(NULL,NULL);?
 347 < desrt> (and maybe give g_warning() if they do not)
 348 < Company> and you add the env vars to 2.24?
 349 < desrt> yes.  of course.
 350 < Company> dunno
 351 < desrt> see?  now you're not the only one :)
 352 < Company> i like the "add env vars to 2.24 and give a warning if non-NULL"
 353 < Company> but i don't like the "keep 2 NULL args in gtk 3"
 354 < desrt> ya...
 355 < desrt> lemme see something
 356 < desrt> hmm
 357 < desrt> #define gtk_init(...) gtk_init();
 358 < desrt> so this works
 359 < desrt> er.  no ;, obviously
 360 < mclasen> but then you can also call gtk_init (1, 2, 3), I guess
 361 < bratsche> desrt: Why no commandline args ever?  --sync is a useful one.
 362 < Company> and it breaks compat
 363 < desrt> if you fancy....
 364 < desrt> Company: it keeps source compat, no?
 365 < desrt> bratsche: we're going to add an environment variable for that
 366 < Company> bratsche: then let your app provide it
 367 < Company> bratsche: GTK_SYNC=1 app otherwise
 368 < bratsche> Ah, okay.
 369 < bratsche> I'm not up to speed on stuff then.  Carry on. :)
 370 < Company> desrt: yes, but not binary - or did you want to do that for gtk3
 371 < Company> ?
 372 < desrt> Company: gtk3 only
 373 < Company> ugh
 374 < desrt> btw: it would also keep binary compat :)
 375 < desrt> oh.  interesting.
 376 < Company> let's not start putting hacks into gtk3
 377 < bratsche> What about glib commandline arg parsing?  Like --g-fatal-warnings and such?
 378 < mclasen> it obviously has cost in invalidating all the cmdlines that people might have stored in desktop files, shell scripts, .Xclients, etc
 379 < Company> bratsche: G_DEBUG=fatal-warnings
 380 < desrt> so you're proposing that we do the hack in 2.24
 381 < desrt> and just have straight (void) in 3
 382 < bratsche> Okay, cool.
 383 < Company> desrt: yes, it's trivial to fix apps and i'd rather have apps look sane
 384 < mclasen> bratsche: that one is wierd, because it is actually a gtk option...
 385 < Company> desrt: ideally i'd have a different name, but i suppose that's a bad idea for init
 386 < desrt> okay... so we'd keep source compat
 387 < desrt> and we're keep binary compat, too, actually
 388 < desrt> since the new function would just ignore its arguments
 389 < bratsche> mclasen: I didn't even realize that. :)
 390 < mclasen> desrt: the idea is still that gtkapplication will call gtk_init, right ?
 391 < Company> desrt: the hack in gtk2 doesn't work
 392 < desrt> yes.
 393 < Company> because you'll fail to parse cmdlines
 394 < mclasen> so that our 'ideal' application will not ever run into this
 395 < desrt> Company: you want commandline arg parsing to continue to work?
 396 < Company> desrt: during 2.x, yes
 397 < desrt> okay.  that's fair.
 398 < Company> desrt: otherwise you break ABI
 399 < Company> is there a global arc/argv defined in libc?
 400 < desrt> right.  old ABI is that gtk_init() was a function that removed instances of "--sync" from the strv you passed
 401 < desrt> no.  i think not.
 402 < desrt> we could just have a new function name....
 403 < Company> that'd be a nice workaround
 404 < desrt> gtk_start
 405 < Company> but everyone and their dog names init functions init
 406 < desrt> or we could have it be implicit
 407 < ebassi> gtk_setup()
 408 < desrt> ya.  _init() is certainly the correct name
 409 < ebassi> gtk_ready_set_go()
 410 < desrt> the other alternative is that we can expect people to #ifdef
 411 < desrt> or............
 412 < desrt> we make some #define gtk_ready_set_go() gtk_init(NULL, NULL) in 2.x
 413 < desrt> and #define gtk_ready_set_go() gtk_init() in 3
 414 < desrt> so you can use gtk_ready_set_go() if you want to target both
 415 < desrt> that's a very very small weight to carry in 3.x going forward
 416 < Company> it's all ugly, no matter what you invent
 417 < mclasen> I think gtk_init (NULL, NULL) is also a small weight
 418 < desrt> and eventually the assumption is that people will only care for 3
 419 < Company> the best thing you can probably do is make gtk_init (...); in gtk 3
 420 < desrt> mclasen: it's an uglier one
 421 < mclasen> in particular if you hide it behind gtkapplicaiton
 422 < Company> and ignore all passed args
 423 < mclasen> ok, should we move on ?
 424 < ebassi> yes
 425 < mclasen> or are we out of time ?
 426 < ebassi> I guess we still have 25 minutes
 427 < aruiz> :-)
 428 < desrt> soname?
 429 < ebassi> then we get to 2hrs
 430 < mclasen> ok soname
 431 < desrt> is this the -x11 issue?
 432 < mclasen> owen pointed out to me that libs we ship in 2.90 have absurd versions
 433 < mclasen> libgtk-x11-3.0.so.0.9005.0
 434 < mclasen> because I forgot to update the configure.in hackery that generates them
 435 < mclasen> so, the idea we came up with is to change the soname to
 436 < mclasen> libgtk-x11-3.so.0.0.0 when we get to 3.0
 437 < ebassi> sounds good to me
 438 < Company> is libgtk-x11-3.0.so.1 so bad?
 439 < mclasen> since we've already 'wasted' the 3.0 name
 440 < mclasen> oh, you mean go to libgtk-x11-3.0.so.1.0.0 ?
 441 < desrt> i'm not sure what the benefit here is
 442 < Company> yeah
 443 < desrt> either way, you require a recompile when 3.0 hits the street
 444 < stormer> also 3.1 should not break ABI
 445 < mclasen> not sure it makes a difference
 446 < mclasen> and yeah, it implies that we'll require a recompile going from 2.90.x -> 3
 447 < stormer> well 3.1 would ship with libgtk-x11-3.0.so.X
 448 < Company> stormer: current libgtk is libgtk-x11-3.0.so.0.2000.x
 449 < desrt> if we need the recompile anyway, why not just keep the 3.0 name?
 450 < mclasen> desrt: because then we're stuck with absurd high versions ?
 451  * Company doesn't care
 452 < desrt> just bump it back down to the bottom again
 453 < Company> desrt: no!
 454 < desrt> either way it's the same: stuff already compiled will stop working
 455 < mclasen> I don't think the linker will take that gracefully
 456 < Company> desrt: then my package manager will do the wrong thing
 457 < Company> desrt: it'll link to an old lib because it's newer
 458 < desrt> it'll link to whatever the .so file points to....
 459 < Company> desrt: libgtk-x11-3.0.so.0 will be linked to libgtk-x11-3.0.so.0.9050.0 instead of libgtk-x11-3.0.so.0.0.0
 460 < Company> desrt: on make install at least, probably when installing packages, too
 461 < mclasen> ldconfig will get confused, at least
 462 < desrt> hmm
 463 < desrt> is it even possibel to have gtk2.90 and 3.0 packages parallel installed?
 464 < mclasen> if you just make install, certainly
 465 < Company> desrt: it is on my devel box, i'm sure :)
 466 < desrt> i don't see widespread pain and panic here :)
 467 < mclasen> no, just a detail to get right
 468 < Company> i'd just bump to so.1 and be happy
 469 < mclasen> to avoid localized pain and anger
 470 < mclasen> ok, I'll consider that
 471 < desrt> having the soname vaguely resemble the pkgconfig name is kinda nice...
 472  * Company notices his girlfriend is 40 minutes late
 473 < desrt> isn't there a phil collins song about this?
 474 < mclasen> next, I have some small patches that I just wanted to run by this crowd before landing them
 475 < mclasen> first http://bugzilla.gnome.org/show_bug.cgi?id=84188 - an oldie
 476 < mclasen> it is about making buttonboxes not fully homogeneous
 477 < mclasen> but instead let 'outliers' have their own width
 478 < mclasen> I wrote the patch because it is somewhat required for the lockbutton widget that I want to land in gtk3 (and forgot to put on the agenda)
 479 < desrt> an outlier is what?  more than 1.5x the average or something?
 480 < mclasen> exactly
 481 < mclasen> of course, the details can be tweaked
 482 < mclasen> I have put some more ideas in the bug
 483 < mclasen> we could also add a way to explicitly mark children as non-homogeneous
 484 < desrt> seems like a pretty reasonable idea
 485 < desrt> mclasen: i think we want to avoid that
 486 < desrt> mclasen: for the i18n reason mentioned in the bug
 487 < desrt> people might feel like they're being helpful, but actually end up causing more harm
 488 < mclasen> I know, but there may be situations where you know a child is going to be different
 489  * desrt reads that last statement in a total context vacuum, laughs.
 490 < aruiz> desrt, I did the same
 491 < mclasen> ok, I'd appreciate comments in the bug
 492 < desrt> right.  non-text content, i guess
 493 < mclasen> moving on, draw-border removal
 494 < desrt> as long as we mark the API docs very clearly "don't call this"
 495 < mclasen> http://bugzilla.gnome.org/show_bug.cgi?id=426924
 496 < mclasen> we have this experimental style-property to add a 'draw border' around widgets
 497 < Company> mclasen: remove it
 498 < mclasen> which came out of krh+owens experiments with cairo theming long ago
 499 < mclasen> nobody ever used it
 500 < mclasen> except at some point we used it as a hacky fix for a problem with mnmemonic underlines in labels
 501 < Company> we might want it back later when we actually use it, but we'll do it properly then
 502 < mclasen> and it has some performance overhead
 503 < desrt> from the minimal understanding i have, my gut agrees with Company 
 504 < ebassi> I'm all for nuking it
 505 < mclasen> so, if there is no disagreement, I'll deprecate in 2.x and remove in 3
 506 < Company> yes
 507 < Company> i didn't even know it existed :o
 508 < desrt> mclasen: i think you have rather strong agreement, in fact
 509 < mclasen> last patch I have is about stock icon names
 510 < Company> and it breaks widgets with real windows
 511 < mclasen> http://bugzilla.gnome.org/show_bug.cgi?id=626474
 512 < Company> and i bet it doesn't work with csw
 513 < Company> :)
 514 < mclasen> who knows ?
 515 < mclasen> and now we'll never find out...
 516 < Company> i don't wanna know :)
 517 < mclasen> so, stock icon lookup falls back to icon themes
 518 < mclasen> and looks up the stock id in the icon theme
 519 < mclasen> and then we have these symlink forests in our icon themes to map stock ids to existing icons
 520 < mclasen> the patch I put in that bug moves the map from the filesystem into gtk
 521 < desrt> with some extra syscalls to go with, it seems?
 522 < mclasen> so we can use 'standard' icon themes without any symlink uglyness
 523 < mclasen> syscalls ?
 524 < desrt> or is this all benefiting from the icon cache?
 525 < mclasen> yes, it all goes through the icon cache
 526 < desrt> ya.  you mention trying stuff, falling back...
 527 < mclasen> the symlinks were reflected in the cache, too
 528 < desrt> with the icon cache, that's not so bad
 529 < Company> mclasen: reminds me: can we eprecate either stock ids or icon names?
 530 < Company> (and remove in gtk3)
 531 < mclasen> well, gtkstock has its own mechanisms to associate icons with ids
 532 < Company> or is there notable differences?
 533 < desrt> stock has text too
 534 < mclasen> which can be set from gtkrc files, and whatnot
 535 < desrt> and a mnemonic, i think?
 536 < mclasen> I think stock items are sufficiently different that we can't really get rid of them entirely on short notice
 537 < Company> ok
 538 < mclasen> this is just a small step in that direction
 539 < Company> they seemed very similar to me, but i only looked at drawwing them ;)
 540 < mclasen> I'm bringing it up here, because I like to commit this change to 2.x as well
 541 < mclasen> since we'd otherwise be stuck with the symlink forests anyway
 542 < mclasen> until gtk2 dies
 543 < ebassi> mclasen: since I'm the one getting an earful from hbons every time we go to the pub, I wholly approve :-)
 544 < mclasen> it will add a bunch of strings to libgtk
 545 < mclasen> so make it a bit larger, and some relocations
 546 < mclasen> but not a huge deal, I think
 547 < mclasen> and .... I think we've used up our time now
 548 < desrt> :(
 549 < mclasen> chpe: unless you want to squeeze in your boxed type
 550 < chpe> I do
 551 < mclasen> ok, 5 min
 552 < chpe> https://bugzilla.gnome.org/show_bug.cgi?id=449565
 553 < chpe> patch was adapted to all of timj's demands, and just lacks a final approval
 554 < ebassi> chpe: 1/2, as far as I'm concerned
 555 < mclasen> sure, lets get this in. I agree
 556 < mclasen> in particular since it will actually save code in gio
 557  * desrt looks for things to box
 558 < chpe> http://bugzilla-attachments.gnome.org/attachment.cgi?id=165043 is a patch that makes all of glib use it
 559 < chpe>  7 files changed, 50 insertions(+), 263 deletions(-)
 560 < desrt> anything to stop chpe from pushing this now?
 561 < ebassi> sounds like a nice day's worth of work :-)
 562 < mclasen> small potatoes, compared to Company, but I like it
 563 < Company> haha
 564 < desrt> meh.
 565 < desrt> chpe's work lets other people erase code from their own programs
 566 < desrt> that's the true indicator of a good library :)
 567 < mclasen> chpe: so, go ahead, I think. Everybody agrees
 568 < desrt> Company's work only erases our own :p
 569 < chpe> ok, thanks :)
 570 < mclasen> desrt: any hackfest news before we part ?
 571 < desrt> sign up!
 572 < ebassi> oh, oh: one thing for desrt - https://bugzilla.gnome.org/show_bug.cgi?id=626919
 573 < desrt> the wiki looks very empty
 574 < desrt> and i know many more people will be coming than are listed
 575 < ebassi> desrt: I shall have a confirmation on friday at most
 576 < desrt> ehm
 577 < desrt> why are you filling this array of paramspecs?
 578 < mclasen> to avoid a hash table lookup later on
 579 < ebassi> desrt: because calling g_object_notify_by_pspec() cuts the ::notify call time by 10/15%
 580 < desrt> oh.  i didn't know that.
 581 < ebassi> and we emit *a metric fuckton* of ::notify
 582 < desrt> i don't like it for a very simple reason: it forces you to write PROP_FOO twice
 583 < ebassi> yeah, ideally we should get away from attaching a uint to the GParamSpec to do what an array does better
 584  * mclasen needs to run out now
 585 < mclasen> next meeting in 2-3 weeks ?
 586 < ebassi> mclasen: sure
 587 < mclasen> we should probably have at least one more before the hackfest, to work on the hackfest agenda
 588 < desrt> i guess we'll easily have 2 or 3 before the hackfest
 589 < ebassi> desrt: we can discuss it on #gtk+ or on gtk-devel-list
 590 < desrt> bye everyone :)
 591 < ebassi> thanks for attending
 592 < stormer> bye bye
 593 < ebassi> as usual, minutes and log ASAP
 594 < aruiz> bye bye