< ebassi> meeting time < desrt> agenda url? < ebassi> http://live.gnome.org/GTK+/Meetings -- agenda < ebassi> pretty long so I won't paste it here :-) < ebassi> Company wanted to go first because he has to go before 21:00 UTC, AFAIR < desrt> Company: poke < ebassi> so: 1. rendering-cleanup branch/gtk_widget_draw < desrt> AWOL? < desrt> let's wait 5 mins? * Company almost there < mclasen> girlfriend come home early ? < Company> 1 minute < desrt> k < Company> ok < Company> did someone try to summon alex? * mclasen tries < mclasen> its late for him, though < Company> lets just start < mclasen> I'd say lets go ahead without him < 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 < Company> part 2 (that is GdkPixmap removal + switching theme engines to cope) is in preparation and from my view well received < Company> though i have no idea how easy we can make a gtk2 => gtk3 transition for that < Company> and part 3 (fixing GdkWindow) is hotly contested on the list atm < mclasen> that'll affect anybody calling a gtk_paint function ? < Company> no < mclasen> part 2, I meant ? < Company> still no :) < Company> i think you can probably make part 2 work with deprecations + ugly hacks in gtk2 if you wanted to < mclasen> who is affected, then ? < Company> everything that uses GdkPixmap for anything is affected < Company> that's mostly dnd and code that buffers or does special tricks for drawing < ebassi> Company: what happens for GdkOffscreenWindow.get_pixmap()? < Company> "code that buffers" == keeping a pixmap for easy blitting later < mclasen> do you have a grep of the tree, or one of fredp's fantastic pages for that ? < Company> ebassi: oh right: and offscreen windows :) < ebassi> Company: because clutter-gtk uses that to do the texture-from-pixmap embedding of gtk widgets < Company> yeah, it's a tricky thing < Company> we could just store the pixmap's cairo surface and return that in a offscreen.get_surface() < Company> but that's the hacky part < mclasen> I think we want to have a good idea of the porting effort / compat story before landing part 2 < Company> i agree < mclasen> of course, we don't have a huge window for the parts that need to land in 2.22 < Company> but i suppose i'll need to finish it before having an idea what to do about it < ebassi> fredp's git grep results should help < Company> mclasen: i'm pretty sure landing it in 2.22 would be bad < mclasen> isn't there a deprecation component here ? < mclasen> for gdkpixmap, at least ? < Company> i think landing gdkpixmap cleanup work would require a 2.24 gtk, with even more deprecations and helper APIs < Company> and it would require some apps inside gnome to not compile with DISABLE_DEPRECATED < Company> unless we'd really want to be hacky with themes < Company> as theme engines are outside of our control and they can only render to windows or pixmaps < Company> and with pixmaps gone, that is some sort of problem... < desrt> 2.22, 2.24, 3.0? < desrt> all before the end of the year? < Company> (you could invent clever ways to render to an offscreen window, then get the surface from it, then use that, but ugh) < mclasen> well, 2.22 was supposed to be parallel with 3 < mclasen> since 3 moved back, we have a tiny window to squeeze in a 2.24 if we think thats absolutely necessary < Company> desrt: i think it's not a lot of work to backport useful APIs and add deprecation markers around existing ones < 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 < Company> desrt: it's just a lot of work if you keep the "must recompile to gtk3 without changes" idea < mclasen> Company: I think we've waffled a bit on this already, with part1 < Company> mclasen: mostly with cairo_region_t - i dont think part 1 violated that < Company> actually, i'm pretty sure it didn't < mclasen> true, cairo_region is what I meant < 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 < Company> or something like that < mclasen> how do others feel about this ? < desrt> so basically it's a bodge of new 3.0 bling without breaking the old 2.x stuff < Company> yeah < Company> something like gtk_drag_set_icon_surface() < Company> (not sure how to do that with gtk2 though - probably with a copy to a pixmap ;)) < 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 < 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 < mclasen> ebassi: will clutter-gtk have a chance to work with the pixmap removal at all ? in that timeframe ? < tristan> s/dont/done < 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 < tristan> it still technically breaks at least inkscape and maybe still gimps wrapping box < Company> outside of the rendering-cleanup < 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 * desrt eyes GtkAction < ebassi> mclasen: if I have to get a X11 Pixmap from a cairo surface or from a GdkPixmap, I don't particularly care < 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 ? < mclasen> ah, ok < ebassi> mclasen: I'm going to be in trouble if I don't have a Pixmap XID * herzi_ too < ebassi> otherwise, it's just API calls < Company> mclasen: everything will work fine, pixmaps break nothing but function names really < Company> *pixmaps removal < mclasen> ok < Company> a cairo xlib surface has the same API basically < mclasen> so, is this an agreeable plan: pixmaps stay in 2.22, we'll extend 2.x with a short release that nukes them ? < desrt> by 'nuke' you mean deprecate < mclasen> plus whatever additional deprecations we find necessary < Company> (and whatever else comes up!) < ebassi> Company: so I guess we can get gdk_window_get_similar_surface() take into account offscreen windows * Company doesn't want to be the only one responsible for 2.24 ;) < ebassi> Company: too late < ebassi> ;-) < Company> ebassi: what do you mean "take into account"? < ebassi> Company: I mean, make sure that a GdkOffscreenWindow will return the surface wrapping the backing pixmap < mclasen> Company: plus we'll make you fix all of the desktops rendering, so you'll be responsible for gnome3 too < mclasen> well, you already claimed the gnome3 slip anyway :-) < Company> yeah < Company> i don't want people to hate me when gnome 3 gets delayed to next september... < ebassi> we'll make sure it doesn < ebassi> 't * ebassi prepares the whip < mclasen> anything else on rendering cleanup ? < Company> oh, also there's a part 2.5: I intend to make GdkColormap die < mclasen> I guess we all agree that part 3 is pretty much up in the air still < Company> colormaps are just confusing these days and the only use case is setting translucency on windows < Company> and we can do that better with visuals < Company> that would be 2.24 material again < mclasen> yep < ebassi> okay, the point on releases and dates is pretty much sorted already: 2.22 for GNOME 2.32, 2.24 with 3.0 < mclasen> so, 2.22 in september, 2.24+3 endofyear < ebassi> yup < 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 < mclasen> part4 is what again ? < mclasen> the theme stuff ? < Company> expose_event => draw < krh> yeah, what was the parts again? < Company> part 1: removal of gc, image etc < krh> (sorry if it was pasted earlier, joined late) < Company> part 2: getting rid of GdkPixmap (requires themeing changes or huge hacks) and GdkColormap < Company> part 3: reorg of GdkWindow < Company> part 4: expose_event => gtk_widget_draw() < mclasen> krh: is any of this important for your wayland backend ? < krh> mclasen: it all makes it easier < krh> the longer Company hacks on gtk+, the less I have to do :) < Company> considering all the code does cairo_create (); draw(); cairo_destroy() already, it should all more or less work in wayland < mclasen> he gets all the blame, and you get all the fame :-) < krh> and all I have to do is wait :) < Company> "it's impressive how much you can get done if you don't care who gets the glory" < mclasen> I guess the more interesting parts in the wayland backend are input related anyway ? < mclasen> but lets move on, I think < krh> yeah < 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) < Company> krh: you redo input for GdkWindow! < ebassi> desrt: I'm just trying to get the full picture < desrt> i'd like a glib release to go with 2.24/3.0 < desrt> i'm sure there's a thing or two that will come up < ebassi> okay < mclasen> sounds reasonable to me, too < krh> Company: the new GdkDevice goes a long way towards what I need, actually < Company> we should plan for a glib release, we can still omit it if nothing comes up < ebassi> did whatever danw was working on actually got reviewed/landed or do we wait for the next cycle? < 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 < mclasen> danw was working on at least two things < mclasen> some tls / ssh /whatever networking < Company> ebassi: whaddaya mean? the caching, the TLS sockets or proxies? < ebassi> proxies < mclasen> and some unix stream improvement < Company> i _think_ proxies landed * Company looks it up < mclasen> we also didn't land the datetime work yet < ebassi> I think TLS sockets were already punted, but proxy support was requiring a final review < ebassi> mclasen: I did a review again, but stuff still is missing < ebassi> I think I'll JFDI myself < mclasen> thats the spirit < mclasen> so it looks like we'll have things to land in a 2.28 glib release anyway < Company> hrm no < mclasen> who is next ? refactoring branch (jjardon) or gapplication (desrt) ? < Company> the proxy bug is still open < mclasen> since jjardon is not here, desrt wins, I guess < desrt> good times < desrt> i'm landing my changes for gaction today < mclasen> might be good to give a brief summary for people who haven't followed our discussion the other day ? < desrt> network is going to shit here :( < desrt> okay. so basically: i'm introducing a new abstract class called a GActionGroup < Company> proxy stuff: Company: last i knew the plan was still to get it in. stormer is working on it and very close to done < desrt> it represnts a group of named actions. each action has a parameter type so the Activate() signal takes this parameter < desrt> it's a GVariant* < desrt> so you can have parameters that are tuples if you want to support multiple parameters < desrt> there is a simple implementation of this -- GSimpleActionGroup < desrt> it's just a hash table (by name) of another new class being introduced: GAction < desrt> that's just one named action < desrt> the idea is to make GtkAction a subclass of GAction < stormer> sorry was way, code have had severa review now and is ready now < desrt> load a bunch of GtkActions up into a GActionGroup < desrt> and throw that into your GApplication < mclasen> stormer: thanks for the update < ebassi> mostly similar to what MxApplication does, so I approve :-) < 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) < mclasen> those actions don't have descriptions anymore, though < ebassi> desrt: is-a? < mclasen> just names < desrt> right. < desrt> ebassi: gapplication subclasses gactiongroup < ebassi> mmh < ebassi> I'd rather go with a proxy instead of a direct inheritance < desrt> it sort of is a proxy < desrt> it's an actiongroup that you add other actiongroups to < desrt> (possibly more than one) < desrt> that's where the actions go in the primary instance case... < 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 < desrt> a couple of things worth noting that are different/improved vs. GtkAction < 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' < desrt> (if NULL then no state) < desrt> this is how we do things like toggleactions -- the state type would be boolean in this case < desrt> 2) as mclasen mentioned, no descriptions are included in GAction. also no tooltips, labels, icons, display hints, visibility, anything like that < desrt> only 'enabled' (which more or less is the same as 'sensitive') < mclasen> so we'll have to have some presentation layer on top, I assume < desrt> right < desrt> GtkAction will subclass GAction and it will have all that info inside of it < ebassi> fair enough < desrt> 3) actions can be in more than one GActionGroup < desrt> also: a GtkAction can be in a GtkActionGroup and several GActionGroup at the same time < desrt> a GActionGroup doesn't impact the GAction in any way (sensitivity sharing, etc) < desrt> also: GtkActionGroup and GActionGroup are not related < desrt> 4) GActionGroup has change notification signals for when items are added, removed, or when an item has its 'enabled' status or state changed < desrt> that means that we can export a dbus API properly < desrt> 5) i plan to add a GtkRadioGroup that is a subclass of GAction that works like this: < desrt> - you add GtkRadioAction or GtkRadioButton to it < desrt> - each button you add is given a (string) name < desrt> - the 'state' of the action is the name of the currently selected button < mclasen> is there any provision for platforms that may not allow fully general parameterized actions ? < desrt> - begin gsettings binding bliss < desrt> mclasen: they can't call them. < mclasen> or rather, how is the platform abstraction handled in this rewrite ? < desrt> mclasen: our concern for other platforms ends at the ability to integrate menus < desrt> menu items can't have parameters anyway < desrt> if you want the scripting interface then clearly you'll need dbus < mclasen> will we stil have a dbus implementation and a placeholder where other platform implementatoins can be fit in ? < desrt> heh. yes. :) < desrt> i have no particular desire or plans to investigate the other platforms :/ < mclasen> a little unfortunate that the os x guys haven't shown much enthusiasm yet to make their stuff fit in here < desrt> las (on #gtk+) indicated that he has some interest to do so... < desrt> but not enough time at the moment < mclasen> your rework might make it easier for them, I assume < desrt> it's worth noting, btw, that i just got my email back from tedg < mclasen> they had quite some issues with colins initial scope < desrt> and he's willing to make really substantial changes to dbusmenu to fit our separated actions/menu design < aruiz> \o/ < desrt> who are 'the mac guys'? < desrt> las, for example? < garnacho> I'd talk with kris as well < mclasen> las and I don't know john ralls irc nic < desrt> las seems pretty much very positive with almost everything that i have proposed < desrt> so i take that to be a good sign < mclasen> I don't think dbusmenu will be very relevant per se here ? except as an example of prior art, I guess < desrt> well < desrt> dbusmenu has several existing implementations < desrt> truth be told, from a technical standpoint, it's my opinion that it's simply not what we want < 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" < desrt> he replied: < desrt> Honestly, I'd rather fix dbusmenu to address everyone's concerns than < desrt> develop something new on either front. I think the only thing that's < desrt> radically different is the concept of the dual set of properties. < desrt> Everything else seems evolutionary. < desrt> ("dual set of properties" => how he understood my description of action/menu separation) < desrt> i'll keep in touch with him in any case < mclasen> sure < desrt> none of this speaks to GtkApplication yet < aruiz> he should be attending this meetings though < aruiz> but anyway < aruiz> :-) < desrt> ebassi: i'm interested in what you might have to say about that < aruiz> these* < ebassi> desrt: as I said, I generally agree with the design; I looked at the earlier commits and they look fine < desrt> okay < desrt> i had a few questions about the existing code < desrt> it does some really random things < ebassi> desrt: I still have some reservation on GApplicationGroup being an actual ancestor of GApplication, but nothing much < 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 < desrt> that seems so broken < desrt> ebassi: i'd like to chat with you after the meeting, then < mclasen> desrt: that was just a performance hack < ebassi> desrt: there is no uniform way of getting a .desktop file without cooperation from the thing that sets up the execution environment < 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 < ebassi> desrt: unless we rename all .desktop file using the unique application id < mclasen> born out of colins desire to have a single place for app information < desrt> why does the app want to find its own desktop file? < ebassi> desrt: because we're going to put more state into it < desrt> interesting < ebassi> and remember remote instances < desrt> so one thing that comes to mind is that the environment variable approach is going to end up being insufficient, i think < ebassi> if I want to control rhythmbox by using a GApplication proxy I want to extract meta-data from the .desktop file of rhythmbox < desrt> if we want to talk about using dbus to launch apps... < desrt> we can shove something into platform-data i guess...... < ebassi> desrt: using the platform data would be the non-hacky version < desrt> much better we do it properly, though, and somehow make it possible to go from appid to desktop file efficiently < ebassi> desrt: one way is to create a desktop-file-cache, similar to the icon-cache, to make it easy to index stuff efficiently < desrt> yes. that's sort of along the lines of what i was thinking, i guess < mclasen> yeah, having a real app db would be nice < desrt> alternatively: investigating changing desktop file filenames or appid strings to be the same thing < ebassi> but that would require a gtk-update-applications binary executed post-install < mclasen> we already run update-desktop-database < mclasen> and update-mime-database < mclasen> and gtk-update-icon-cache < ebassi> mclasen: right < mclasen> ... < desrt> don't forget glib-compile-schemas =) < mclasen> oh, and glib-compile-schemas < mclasen> jinx < desrt> thx. < desrt> okay. small technical detail. < 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 < desrt> one more point i think is worth dragging into this discussion (and it's on the agenda anyway): gtk_init * mclasen put 'drop cmdline args' on the agenda further down... < Company> do it automatically when the so is loaded! * Company hides again < desrt> right. i'm pulling it up. :) < ebassi> heh < ebassi> Havoc's old pet peeve < desrt> on .so load is very obviously wrong * mclasen doesn't remember havoc having a prominent position on this ? < desrt> anyway... i don't care too much about the fact that you have to call gtk_init() < desrt> i care that it wants to eat your commandline args < ebassi> mclasen: he tried to get clutter to get rid of it :-) < mclasen> of the init or of the cmdline args ? < ebassi> mclasen: the init in itself < desrt> ebassi: i think having explicit init is very helpful just because initing gtk is a big deal < desrt> connection to X server opens up, etc < desrt> also: your app can be killed if that fails... < Company> desrt: why would you link against ligtk but not call gtk_init()? < 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 < ebassi> or only gtk_parse_args() < desrt> Company: take the GApplication case -- no reason for the remote instance to connect to X < desrt> ebassi: i'm actually advocating that Gtk have no commandline arguments at all, ever < Company> desrt: hrm < Company> no command line args, ever! < ebassi> desrt: so a gtk_init() with no args < Company> no lib should take commandline args < desrt> yes. and no parse_args() functions. < mclasen> desrt: its too late, for ever, but we can discuss removing them from gtk3 < desrt> gtk should use environment variables if it wants options * Company <3 that gtk3 has GTK2_RC_FILES < desrt> mclasen: right. 'ever, after 3.0' :) < desrt> we have a compatibility concern, of course < desrt> people who want to have gtk2 and gtk3 apps without lots of #ifdef * mclasen wonders if there is a envvar variant of --sync < desrt> anything that lacks an environment variable can gain one if there is demand < mclasen> doesn't look like it, but can be easily added, of course < Company> mclasen: not in xlib, no < mclasen> desrt: the one concern with env vars is that they leak < mclasen> unless you are careful when launching < desrt> mclasen: i think we're long past that point, though < Company> mclasen: isn't that usually what you want? < desrt> consider our current situation: an assortment of options to gtk: some are commandline, some are environment < desrt> we already have the leak problem < mclasen> yeah, its not a huge concern < mclasen> just pointing it out < desrt> anyway... are we brave enough to do gtk_init(void) < mclasen> and we do care to clean some things out of the environment already, like the startup notification stuff < desrt> or should we rather tell people to always do gtk_init(NULL,NULL);? < desrt> (and maybe give g_warning() if they do not) < Company> and you add the env vars to 2.24? < desrt> yes. of course. < Company> dunno < desrt> see? now you're not the only one :) < Company> i like the "add env vars to 2.24 and give a warning if non-NULL" < Company> but i don't like the "keep 2 NULL args in gtk 3" < desrt> ya... < desrt> lemme see something < desrt> hmm < desrt> #define gtk_init(...) gtk_init(); < desrt> so this works < desrt> er. no ;, obviously < mclasen> but then you can also call gtk_init (1, 2, 3), I guess < bratsche> desrt: Why no commandline args ever? --sync is a useful one. < Company> and it breaks compat < desrt> if you fancy.... < desrt> Company: it keeps source compat, no? < desrt> bratsche: we're going to add an environment variable for that < Company> bratsche: then let your app provide it < Company> bratsche: GTK_SYNC=1 app otherwise < bratsche> Ah, okay. < bratsche> I'm not up to speed on stuff then. Carry on. :) < Company> desrt: yes, but not binary - or did you want to do that for gtk3 < Company> ? < desrt> Company: gtk3 only < Company> ugh < desrt> btw: it would also keep binary compat :) < desrt> oh. interesting. < Company> let's not start putting hacks into gtk3 < bratsche> What about glib commandline arg parsing? Like --g-fatal-warnings and such? < mclasen> it obviously has cost in invalidating all the cmdlines that people might have stored in desktop files, shell scripts, .Xclients, etc < Company> bratsche: G_DEBUG=fatal-warnings < desrt> so you're proposing that we do the hack in 2.24 < desrt> and just have straight (void) in 3 < bratsche> Okay, cool. < Company> desrt: yes, it's trivial to fix apps and i'd rather have apps look sane < mclasen> bratsche: that one is wierd, because it is actually a gtk option... < Company> desrt: ideally i'd have a different name, but i suppose that's a bad idea for init < desrt> okay... so we'd keep source compat < desrt> and we're keep binary compat, too, actually < desrt> since the new function would just ignore its arguments < bratsche> mclasen: I didn't even realize that. :) < mclasen> desrt: the idea is still that gtkapplication will call gtk_init, right ? < Company> desrt: the hack in gtk2 doesn't work < desrt> yes. < Company> because you'll fail to parse cmdlines < mclasen> so that our 'ideal' application will not ever run into this < desrt> Company: you want commandline arg parsing to continue to work? < Company> desrt: during 2.x, yes < desrt> okay. that's fair. < Company> desrt: otherwise you break ABI < Company> is there a global arc/argv defined in libc? < desrt> right. old ABI is that gtk_init() was a function that removed instances of "--sync" from the strv you passed < desrt> no. i think not. < desrt> we could just have a new function name.... < Company> that'd be a nice workaround < desrt> gtk_start < Company> but everyone and their dog names init functions init < desrt> or we could have it be implicit < ebassi> gtk_setup() < desrt> ya. _init() is certainly the correct name < ebassi> gtk_ready_set_go() < desrt> the other alternative is that we can expect people to #ifdef < desrt> or............ < desrt> we make some #define gtk_ready_set_go() gtk_init(NULL, NULL) in 2.x < desrt> and #define gtk_ready_set_go() gtk_init() in 3 < desrt> so you can use gtk_ready_set_go() if you want to target both < desrt> that's a very very small weight to carry in 3.x going forward < Company> it's all ugly, no matter what you invent < mclasen> I think gtk_init (NULL, NULL) is also a small weight < desrt> and eventually the assumption is that people will only care for 3 < Company> the best thing you can probably do is make gtk_init (...); in gtk 3 < desrt> mclasen: it's an uglier one < mclasen> in particular if you hide it behind gtkapplicaiton < Company> and ignore all passed args < mclasen> ok, should we move on ? < ebassi> yes < mclasen> or are we out of time ? < ebassi> I guess we still have 25 minutes < aruiz> :-) < desrt> soname? < ebassi> then we get to 2hrs < mclasen> ok soname < desrt> is this the -x11 issue? < mclasen> owen pointed out to me that libs we ship in 2.90 have absurd versions < mclasen> libgtk-x11-3.0.so.0.9005.0 < mclasen> because I forgot to update the configure.in hackery that generates them < mclasen> so, the idea we came up with is to change the soname to < mclasen> libgtk-x11-3.so.0.0.0 when we get to 3.0 < ebassi> sounds good to me < Company> is libgtk-x11-3.0.so.1 so bad? < mclasen> since we've already 'wasted' the 3.0 name < mclasen> oh, you mean go to libgtk-x11-3.0.so.1.0.0 ? < desrt> i'm not sure what the benefit here is < Company> yeah < desrt> either way, you require a recompile when 3.0 hits the street < stormer> also 3.1 should not break ABI < mclasen> not sure it makes a difference < mclasen> and yeah, it implies that we'll require a recompile going from 2.90.x -> 3 < stormer> well 3.1 would ship with libgtk-x11-3.0.so.X < Company> stormer: current libgtk is libgtk-x11-3.0.so.0.2000.x < desrt> if we need the recompile anyway, why not just keep the 3.0 name? < mclasen> desrt: because then we're stuck with absurd high versions ? * Company doesn't care < desrt> just bump it back down to the bottom again < Company> desrt: no! < desrt> either way it's the same: stuff already compiled will stop working < mclasen> I don't think the linker will take that gracefully < Company> desrt: then my package manager will do the wrong thing < Company> desrt: it'll link to an old lib because it's newer < desrt> it'll link to whatever the .so file points to.... < 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 < Company> desrt: on make install at least, probably when installing packages, too < mclasen> ldconfig will get confused, at least < desrt> hmm < desrt> is it even possibel to have gtk2.90 and 3.0 packages parallel installed? < mclasen> if you just make install, certainly < Company> desrt: it is on my devel box, i'm sure :) < desrt> i don't see widespread pain and panic here :) < mclasen> no, just a detail to get right < Company> i'd just bump to so.1 and be happy < mclasen> to avoid localized pain and anger < mclasen> ok, I'll consider that < desrt> having the soname vaguely resemble the pkgconfig name is kinda nice... * Company notices his girlfriend is 40 minutes late < desrt> isn't there a phil collins song about this? < mclasen> next, I have some small patches that I just wanted to run by this crowd before landing them < mclasen> first http://bugzilla.gnome.org/show_bug.cgi?id=84188 - an oldie < mclasen> it is about making buttonboxes not fully homogeneous < mclasen> but instead let 'outliers' have their own width < 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) < desrt> an outlier is what? more than 1.5x the average or something? < mclasen> exactly < mclasen> of course, the details can be tweaked < mclasen> I have put some more ideas in the bug < mclasen> we could also add a way to explicitly mark children as non-homogeneous < desrt> seems like a pretty reasonable idea < desrt> mclasen: i think we want to avoid that < desrt> mclasen: for the i18n reason mentioned in the bug < desrt> people might feel like they're being helpful, but actually end up causing more harm < mclasen> I know, but there may be situations where you know a child is going to be different * desrt reads that last statement in a total context vacuum, laughs. < aruiz> desrt, I did the same < mclasen> ok, I'd appreciate comments in the bug < desrt> right. non-text content, i guess < mclasen> moving on, draw-border removal < desrt> as long as we mark the API docs very clearly "don't call this" < mclasen> http://bugzilla.gnome.org/show_bug.cgi?id=426924 < mclasen> we have this experimental style-property to add a 'draw border' around widgets < Company> mclasen: remove it < mclasen> which came out of krh+owens experiments with cairo theming long ago < mclasen> nobody ever used it < mclasen> except at some point we used it as a hacky fix for a problem with mnmemonic underlines in labels < Company> we might want it back later when we actually use it, but we'll do it properly then < mclasen> and it has some performance overhead < desrt> from the minimal understanding i have, my gut agrees with Company < ebassi> I'm all for nuking it < mclasen> so, if there is no disagreement, I'll deprecate in 2.x and remove in 3 < Company> yes < Company> i didn't even know it existed :o < desrt> mclasen: i think you have rather strong agreement, in fact < mclasen> last patch I have is about stock icon names < Company> and it breaks widgets with real windows < mclasen> http://bugzilla.gnome.org/show_bug.cgi?id=626474 < Company> and i bet it doesn't work with csw < Company> :) < mclasen> who knows ? < mclasen> and now we'll never find out... < Company> i don't wanna know :) < mclasen> so, stock icon lookup falls back to icon themes < mclasen> and looks up the stock id in the icon theme < mclasen> and then we have these symlink forests in our icon themes to map stock ids to existing icons < mclasen> the patch I put in that bug moves the map from the filesystem into gtk < desrt> with some extra syscalls to go with, it seems? < mclasen> so we can use 'standard' icon themes without any symlink uglyness < mclasen> syscalls ? < desrt> or is this all benefiting from the icon cache? < mclasen> yes, it all goes through the icon cache < desrt> ya. you mention trying stuff, falling back... < mclasen> the symlinks were reflected in the cache, too < desrt> with the icon cache, that's not so bad < Company> mclasen: reminds me: can we eprecate either stock ids or icon names? < Company> (and remove in gtk3) < mclasen> well, gtkstock has its own mechanisms to associate icons with ids < Company> or is there notable differences? < desrt> stock has text too < mclasen> which can be set from gtkrc files, and whatnot < desrt> and a mnemonic, i think? < mclasen> I think stock items are sufficiently different that we can't really get rid of them entirely on short notice < Company> ok < mclasen> this is just a small step in that direction < Company> they seemed very similar to me, but i only looked at drawwing them ;) < mclasen> I'm bringing it up here, because I like to commit this change to 2.x as well < mclasen> since we'd otherwise be stuck with the symlink forests anyway < mclasen> until gtk2 dies < ebassi> mclasen: since I'm the one getting an earful from hbons every time we go to the pub, I wholly approve :-) < mclasen> it will add a bunch of strings to libgtk < mclasen> so make it a bit larger, and some relocations < mclasen> but not a huge deal, I think < mclasen> and .... I think we've used up our time now < desrt> :( < mclasen> chpe: unless you want to squeeze in your boxed type < chpe> I do < mclasen> ok, 5 min < chpe> https://bugzilla.gnome.org/show_bug.cgi?id=449565 < chpe> patch was adapted to all of timj's demands, and just lacks a final approval < ebassi> chpe: 1/2, as far as I'm concerned < mclasen> sure, lets get this in. I agree < mclasen> in particular since it will actually save code in gio * desrt looks for things to box < chpe> http://bugzilla-attachments.gnome.org/attachment.cgi?id=165043 is a patch that makes all of glib use it < chpe> 7 files changed, 50 insertions(+), 263 deletions(-) < desrt> anything to stop chpe from pushing this now? < ebassi> sounds like a nice day's worth of work :-) < mclasen> small potatoes, compared to Company, but I like it < Company> haha < desrt> meh. < desrt> chpe's work lets other people erase code from their own programs < desrt> that's the true indicator of a good library :) < mclasen> chpe: so, go ahead, I think. Everybody agrees < desrt> Company's work only erases our own :p < chpe> ok, thanks :) < mclasen> desrt: any hackfest news before we part ? < desrt> sign up! < ebassi> oh, oh: one thing for desrt - https://bugzilla.gnome.org/show_bug.cgi?id=626919 < desrt> the wiki looks very empty < desrt> and i know many more people will be coming than are listed < ebassi> desrt: I shall have a confirmation on friday at most < desrt> ehm < desrt> why are you filling this array of paramspecs? < mclasen> to avoid a hash table lookup later on < ebassi> desrt: because calling g_object_notify_by_pspec() cuts the ::notify call time by 10/15% < desrt> oh. i didn't know that. < ebassi> and we emit *a metric fuckton* of ::notify < desrt> i don't like it for a very simple reason: it forces you to write PROP_FOO twice < ebassi> yeah, ideally we should get away from attaching a uint to the GParamSpec to do what an array does better * mclasen needs to run out now < mclasen> next meeting in 2-3 weeks ? < ebassi> mclasen: sure < mclasen> we should probably have at least one more before the hackfest, to work on the hackfest agenda < desrt> i guess we'll easily have 2 or 3 before the hackfest < ebassi> desrt: we can discuss it on #gtk+ or on gtk-devel-list < desrt> bye everyone :) < ebassi> thanks for attending < stormer> bye bye < ebassi> as usual, minutes and log ASAP < aruiz> bye bye