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
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.