< desrt> greetings friends and loved ones < mclasen> excellent, a new talk show host < bilboed> all rise for the honorable... < mclasen> so, do we have an agenda ? < bratsche> http://live.gnome.org/GTK%2B/Meetings < desrt> mclasen: i think that's what priests say before weddings :) < bratsche> I'm probably not going to stick around long today, but I wanted to ask about schedules for post-2.20 < bratsche> As in, what's next? Is there a 2.22 or will it go directly to 3.0? And either way, if there is any idea what the timetable is. < mitch> or before funerals? < mclasen> ok, lets do that first, then < bratsche> Just for the purpose of scheduling things with my manager at work. < desrt> mitch: i hope not :) < mclasen> I think we should aim for 3.0 next, provided the sealing business is in good shape in 2.20 < mitch> which reminds me i need to add about 10 sealings < mitch> so gimp builds < mclasen> but thats just my opinion, I don't foresee having a ton of time to push things that way... < danni_> there are still a bunch of outstanding feature branches (resolution-indep., extended layout) are we going to wait until 3.0 to push these? < mclasen> I think thats on the agenda as the next point... < ebassi> at some point we'll have to stop cramming stuff in 2.x :-) < Company> there's also a lot of features people would like to get rid of, refactor etc < danni_> mclasen: so it is! < bratsche> Yeah. < mitch> we should compile a list to *remove* fo 3.0 rather than to add < bratsche> Is there any rough idea of how many months after 2.20 before we want 3.0 to be released? < danni_> Company: yeah < bratsche> Or is that going to be depending on Gnome 3.0's release schedule? < danni_> Company: yeah < bratsche> Or is that going to be depending on Gnome 3.0's release schedule? < mclasen> mitch: a good idea, but most things to be removed in 3.0 ought to be deprecated in 2.20, I think < mitch> mclasen: some things cannot be deprecated, like signals < mitch> but generally, yes < mclasen> mitch: they can always be documented as deprecated < danni_> ooher, can we invent a way to deprecate set-scroll-adjustments ? < mitch> right < mclasen> you may not be able to make the build break if they are used... < mitch> but we could warn < mitch> don't signals have flags? < mclasen> danni_: someone had a patch for a scrollable interface in bugzilla at some point < mclasen> was that you ? < danni_> mitch: python style, yeah < danni_> mclasen: that was not me < jpetersen> i have a patch to add a GtkScrollable interface < mitch> like GtkContainer::add ::remove (the signals, not the vfuncs) < kalikiana> we have a diagnostic mode in the plan to take care of signal and prop deprecations :) < kalikiana> ^^ mitch < jpetersen> https://bugzilla.gnome.org/show_bug.cgi?id=468689 < mitch> mclasen: we also have a list of things that need to go into gobject for 2.20 to happen < danni_> but a Python style g_warning in some Deprecation domain, could be useful here < mitch> like class private data < mitch> deprecation flags for signals < mclasen> kalikiana: is that mode something thats going to be ready for 2.20 ? < kris> mitch: and all the performance stuff is on that list as well ... < mitch> kris: yeah < kalikiana> mclasen, not sure, so far it's mostly planning, hardly code < kalikiana> would you think that's preferrable? < mitch> deep derivability of fundamental types < mclasen> kalikiana: better late than never, but if the diagnostic mode is supposed to be useful in preparation for porting things to 3.0, it better show up in a 2.x release, no ? < mitch> yes < mclasen> so, it sounds like we would be better off making a list of things that need to happen for 2.20 < kalikiana> yes of course. Just asking if we should try to get it in 2.20 as opposed to 2.22 < kris> the main issue with the "diagnostic mode" is that there is nothing concrete ... < Company> somewhat related question: how would we handle switching GdkPixbuf from RGBA to CAIRO_FORMAT_ARGB32? < Company> assuming I wanted to write a patch for that < kris> Company: doesn't that break the publicly exposed pixels pointer? < mitch> Company: that's hardly possible i think :/ < danni_> could it be added as another colourspace ? < Company> kris: yes it does < mitch> for the reason kris gave < jjardon> mclasen, I think you can use http://live.gnome.org/JavierJardon/GTKRoadmap for that list (move the page to other place if you want) < ebassi> another colorspace would be interesting < mclasen> danni_: thats 'formally api compat', but hardly in practical terms < kalikiana> so the current one would have to be deprecated < kalikiana> not impossible, just ugly < mclasen> because nobody ever checks colorspaces < danni_> mclasen: well, you'd make it so that people had to explicitly request that colourspace < kris> you can add another colorspace, but you cannot set the other colorspace as default < mclasen> jjardon: I was actually less interested in writing that list myself... < danni_> mclasen: rather than make it the default < danni_> but mention it in the docs < Company> i think something like that would only be doable for 3.0, which is why i'm asking < danni_> it would make a lot of people's lives easier < danni_> even if it wasn't the default < mclasen> yeah, adding a non-default cairo colorspace might be doable for 3.0 < Company> if the consensus is that it's not possible/shouldn't be done, then i'll look at a complete replacement more < danni_> on this note, I've been trying to think how to have a gtktreemodel API that uses quarks < danni_> so we can have named columns < danni_> but I think this would have to break API < Company> danni_: treemodel api should be broken anyway < Company> danni_: because get_value is so slow < desrt> *ahem* libmodel < Company> desrt: do you have a treeview widget for it already? :) < desrt> listview only < desrt> treeview in development < desrt> but targetting clutter, not gtk :) < Company> cool < Company> not that cool then < desrt> gave a quick demo in boston < ebassi> desrt: cool :-) < danni_> desrt: do you use quarks for columns? < desrt> not sure if anyone who was there is here... except maybe ebassi? < desrt> danni_: no. strings. < ebassi> desrt: I either missed it or was completely asleep < desrt> danni_: and they're not columns * mclasen missed it too < desrt> mclasen: it was on the last day :( < danni_> desrt: strings are fine too, I suppose * danni_ wishes she could have been in Boston < desrt> mind if i talk about it briefly? < ebassi> desrt: I think the meeting is going to take some time < desrt> i'm ok with waiting until next time then < kris> i dont see how quarks solve anything < Company> did i mention i'd like to see GQuark deprecated and replaced by interend strings? < desrt> Company: that's an exceptionally reasonable proposal < kris> Company: I think breaking get_value() like that is on the same line as suddenly changing the pixel format of GdkPixbuf < danni_> kris: really it's the named columns I want < kris> Company: I don't think we have envisioned such breakage initially, we have always promised a smooth migration < danni_> kris: however they're looked up is an implementation detail for me < Company> kris: yeah < mclasen> Company: quarks give you interned strings today < mclasen> or do I miss something ? < kris> danni_: ah, named columns instead of numbers? < desrt> mclasen: but they also give you a new namespace < Company> mclasen: yes, it's just the ugly API < danni_> kris: right < kris> danni_: aah right < danni_> kris: because numbers suck in GtkBuilder < danni_> and in the bindings < mclasen> Company: you can just ignore the quark api and use g_intern_string ? < kris> danni_: in C code as well, unless you create an enum < danni_> kris: yeah < Company> mclasen: yeah, that's what everyone should do < desrt> danni_: https://desrt.ca/gitweb/?p=model;a=blob;f=model/model.vala;h=e30d580c5a111e9170a8186a15e0d89f061fdea7;hb=HEAD < Company> mclasen: and then you deprecate the quarks api so you can get rid of loads of public API \o/ < bilboed> Company, by which you mean you wouldn't have to explicetely create the quark, but just have some kind of decorator ? < mclasen> Company: ok, I can buy that; except for cases where you really want to have an int as a identifier < danni_> kris: basically I've always felt that named columns would fix so much up < ebassi> can I ask to get things under a little bit more of control? < desrt> danni_: references, lists, dictionaries. i'll bring it up at the next gtk meeting. < kalikiana> Company, quarks are glib, won't help to deprecate them :-/ < Company> mclasen: where would that be? < Company> kalikiana: not yet ;) < mclasen> Company: dunno, you brought this topic up, so I am not prepared... < Company> bilboed: you use g_intern_string() which gives you a unique gchar * < Company> mclasen: ok, then i'll just assume there's no such case for now :) < kris> maybe we can move all the new topics to the next meeting? < kris> since I thin kthe list for this meeting was already long < desrt> kris: a fine idea! < mclasen> ebassi is right, we should get some order here < mitch> yea we don't discuss the agenda here :) < ebassi> I doubt an IRC meeting is going to solve the "future stuff" agenda point < bilboed> kris, agreed < Company> mclasen: you can use GPONTER_TO_SIZE() on the interened string if you want a number anyway < kris> not that I don't want to discuss it :) < mclasen> so, the question bratsche wanted answered ( and he needs to go soon) < ebassi> so, can I ask everyone that has a proposal to send it to the mailing list and/or open a page under bugzilla (bug references are welcome)? < mclasen> was when we target the release after 2.20 < ebassi> mclasen: thanks :-) < ebassi> mclasen: I think it depends on when the release-team decides to spin GNOME 3.0 at this point < ebassi> if GNOME 3.0 is going to depend on gtk+ 3.0 < mclasen> yeah, thats the one thing < mitch> they said they don't need to < kris> we need to have a plan at least < jjardon> From Gnome people Feb 22: http://live.gnome.org/TwoPointTwentynine < mitch> and would be willing to break abi in 3.2 < kris> if they "like" the plan, they might base gnome 3.0 on gtk+ 2.current and have gtk+ 3.0 for gnome 3.2 < mclasen> the other is what amount of feature branches we decide to pull in after 2.20 < danw> from talk in boston it sounded like people are expecting this spring to be GNOME 2.30, not 3.0 < desrt> mclasen: on that point, i'd like to have the floor for a few moments after this conversation :) < desrt> danw: that's officially not decided yet < kalikiana> ^^ why not keep "follow up" topics for after the official agenda, and see who can stay longer :) < kalikiana> otherwise we keep disrupting the topic < danw> desrt: no, but we probably shouldn't *assume* 3.0 will happen this spring < mclasen> so, it looks like we will have a hard time making a solid plan here; from what I can see, our best bet is to ensure that we land all the '3.0-readiness < desrt> danw: actually, i argue that's exactly what we *should* assume :) < mclasen> ' things in 2.20 < kalikiana> I'd think if we are prepared, it's good. And if we're prepared but GNOME 3.0 isn't happening, no problem < mitch> leaving out the possibility of not being prepared? :) < ebassi> mclasen: agree < kalikiana> mitch, I think the timeframe is doable, if we don't insist on getting everything, milk and ponies into 2.9 ;) < mclasen> and to make sure we have all the 3.0 readiness items covered, we should collect them on the wiki page that jjardon has volunteered < mitch> yes please < mitch> like, we still have no plan on how to seal class structures < desrt> jjardon: can you move that page to some semi-official place before we all try to edit it? :) < kalikiana> mitch, question: who can take charge of class privates? < ebassi> jjardon: under GTK+/Roadmap < jjardon> ok < kalikiana> maybe it would help to get that a bit going < mitch> kalikiana: timj < kalikiana> mitch, Let me reword: is timj available right now, to do that? < kris> again, on the class private patch < mitch> it's not a big change < kris> I have "pre-reviewed" it < kris> it makes fully sense < kris> together with the reporter I found another bug that has been fixed < mitch> yes it does, i looked at it too < kalikiana> Maybe it's not big, I'm just saying it would be good to get it done sooner than later < kris> it can't be more than 30 mins work for a gobject maintainer to accept it < Company> then just commit it < Company> there is no gobject maintainer right now :o < bilboed> where is that branch located ? < jjardon> done: http://live.gnome.org/GTK+/GTKRoadmap < Company> bilboed: it's a patch in bugzilla i believe < mclasen> kris: I'd tend to agree with Company here. Commit it, and invite timj to review it in-tree * kalikiana thinks Company forgot his pink glasses today :P < mitch> mclasen: which brings up the agenda point of glib branching? < Company> kalikiana: no, i'm just fed up with everyone blocking on timj * bilboed seconds Company's point-of-view < ebassi> kalikiana: if two people like kris and mitch reviewed it, then I think we can commit it :-) < Company> kalikiana: but i'll elaborate on that when we hit the gobject-performance agenda point < mclasen> mitch: I did create a glib-2-22 branch, I believe < kalikiana> The situation is annoying alright, but nobody other than Company seems to be eager to accept that :) < mitch> cool < mitch> back to agenda :) < mitch> what is git surgery? < kris> i have been wondering about that one as well < mitch> fixing the 2.90 branch name? < kalikiana> git surgery is cutting up an idiot I presume < mclasen> volunteers ? < bilboed> what needs to be done for that ? < mitch> mclasen: you? ;) < desrt> i'll do it if we agree < desrt> you don't need surgery < ebassi> mitch: 2.90 branch name and gtk-2.16 < desrt> just need to push an empty ref to the branch < ebassi> or what jjardon added to the wiki :-) < Company> git push origin :gtk-2.16 < Company> bye bye < desrt> yup < desrt> then just push thte 2.90 branch as 2-90 and do the same thing for 2.90 < desrt> the 'how' is less important than the 'why' and 'should' < mclasen> ok, sounds like desrt has the necessary expertise to handle this comfortably < kalikiana> ++ < mclasen> the why is easy: both were misnamed by accident < mclasen> and the 2.16 branch is just an accident altogether < mitch> let's do it < desrt> ok. i'll do it < ebassi> desrt: thanks :-) < kalikiana> customer happy, neeeext point < desrt> gvariant/gsettings/gdbus/etc, plz? < ebassi> desrt: did you put those on the agenda? :-P < bilboed> desrt, not on agenda < desrt> no. but it's on jjardon's lovely list < desrt> i suppose i have to wait until next week? < ebassi> desrt: it can go in miscellaneous < ebassi> if we cut some corners to save time :-) < Company> desrt: it's a wiki page, edit it! < desrt> i'm okay with deferring < bilboed> Company, gaaaah, shaddap < desrt> davidz and i are still hammering some small details down < kalikiana> Company, editing during the meeting is cheating :P < desrt> i'll make sure it's on the schedule for next week < ebassi> I've seen garnacho's email on gtk-deve-list < davidz> desrt: for the gdbus stuff we probably want alexl to review it - he's gone for the next week and a half (clone()/fork() in his family) < kalikiana> (maybe we should consider a metting next instead of after next week, since we have many topics) < desrt> i'm gonna skip out now. just one note: < ebassi> for xi2 < davidz> desrt: (e.g. he had a son) < desrt> when you're discussing the abstract application base class stuff, consider under the assumption that you'll be able to use DBus from GTK < desrt> davidz: a boy? nice. < kris> with all the dbus stuff i am still wondering how that will work for cross platform stuff < mclasen> desrt: sure, unique-app + session-client is the two main gtk-level motivations for doing the dbus stuff in the first place < kalikiana> hopefully not like gvfs, ie half done < desrt> kris: i'll have an agenda item for next week < Company> kris: i bet desrt will write a COM equivalent for windows < kris> i think we should either fully support it, or not at all, but not half done < danw> kris: the actually d-bussy APIs will depend on win32 dbus. the higher-level apis (unique app, session client) will not use dbus on win32 < kris> as i fully understand the motivation from a gtk+/gnome standpoint to have it, and I don't want to hold that back < kris> danw: oh, interesting * desrt out. < davidz> libdbus-1 for win32 exists - it's just not in the mainline fd.o libdbus repo (it's a fork - fd.o dbus wants to merge it, it's not a lot of work but no-one qualified has stepped up... if we merge gdbus into glib someone should just step up and do the work) < davidz> anyway, we can cover that next week < davidz> everyone is aware of the problem and there's a way to solve it < mclasen> so, back to the agenda item of 'interesting topic branches' ? < jjardon> xi2 seems to be ready: https://bugzilla.gnome.org/show_bug.cgi?id=596725 < mclasen> I have poked murrayc/tbf last week, and they made noises that sounded like they would get the extended layout work revived < ebassi> as mitch pointed out on #gtk+, xi2 should be tested with gimp to check its readiness < tbf> oink. oink. < ebassi> if it hasn't already < mclasen> without having looked at the branch at all, xi2 strikes me as the one topic that would be most interesting to get squeezed into 2.x still < mitch> mclasen: agreed < ebassi> yup < mclasen> unfortunately, I am crazy short on time for GTK+ stuff in the near future < mclasen> so, if we could muster some additional review power, that would be cool < jjardon> RI branch seems to be ready too, I think only testing is needed: http://bugzilla.gnome.org/show_bug.cgi?id=546711 < kalikiana> ^^ more review power would so rock < bilboed> no excuses now with splinter < ebassi> jjardon: davidz said in boston that some more testing with complex non-gtk apps like openoffice, eclipse and firefox should be in order for RI review < danni_> I think it also needs a bit more forward porting < danni_> from when I last worked on it < kalikiana> mclasen being a machine and all that, but he deserves some relief < danni_> it also needs some integration with settings < danni_> since it doesn't have any atm < davidz> yeah, there's a separate task of figuring out the gnome ui for configuring this < davidz> and then ensure that the apis we want (in particular GtkSettings) work with that < danni_> I've never really had inspiration for how it might be configured < danni_> or how the settings should look < davidz> right, we just need a high-level idea so we are sure that the api supports what we want < danni_> mmm < danni_> maybe we need to punt this to a designer ? < danni_> get some ideas < ebassi> danni_: yes < davidz> danni_: yeah, something like that would be great < ebassi> I can probably ask Nick Richards on my team < mclasen> s/punt to/consult with/ < kalikiana> mclasen, maybe you could just write down a list of people you consider able, otherwise it could take years to sort that out < danni_> ebassi: neat < kalikiana> and just see who also has time < ebassi> because if the configuration involves a ruler then I think we failed already :-) < mclasen> kalikiana: I think I promised something like that last time, didn't i ? < danni_> ebassi: yeah, I think we all agree there < danni_> ebassi: tbh, I'm not sure that most people will want that much RI < danni_> and certainly not multimonitor RI < danni_> (although that's where the configuration nightmare starts) < kalikiana> mclasen, I just remember it was supposed to be sorted out after the meeting, and so far nothing looks sorted =) < davidz> so I think with RI it's like: 1. figure out high-level story for configuration; 2. review API changes (mostly GtkSize and GtkSettings multi-monitor changes) in the patch; 3. go through all of gtk+ and do s/12/GTK_SIZE_ONE_TWELFTH_EM(1.0)/ where appropriate < davidz> (maybe find a shorter macro name too!) ;-) < danni_> davidz: right < ebassi> GTK_DEFAULT_SPACING :-) < danni_> I did a lot of (3) when I was using the work < davidz> then 4. test on lots of apps / desktop sessions; 5. merge it < danni_> but still needed (1) and (2) < davidz> right < danni_> there were a few other things I'd been meaning to fix < danni_> like the signal on GtkSettings.. seemed a little nutty < danni_> possibly belonged on GdkScreen, etc. < davidz> yeah < davidz> anyway 3. and 4. can happen in parallel so ideally more than one person can work on them < danni_> yeah < davidz> but for 1. and 2. it's mostly a one-man job < danni_> I had a script to track down 3 somewhere < danni_> it had a list of API calls that take a size < davidz> cool < danni_> I wonder what I did with it < danni_> (although I never delete anything, this doesn't mean those things are easy to find) * mclasen peeks at the next topic < mclasen> deprecations... < mitch> please! < mitch> these classes have bevome entirely useless < mitch> and we can simply keep gtk_hbox_new() etc. as utility functions < mitch> instead of gtk_box_new(GTK_ORIENTATION_FOO); < mclasen> well, we still can't instantiate the flippable ones... < mitch> i know < mitch> i wanted to have them instantiatable * mclasen too < mitch> and i still didn't get what exactly we should change with default values < mitch> apart from e.g. gtk box to pack shrinking by dwfault, not expanding < ebassi> didn't the wiki page about that already listed the changes? < ebassi> for the properties, I mean < mclasen> so, should we reconsider that 'defaults block !absract < mclasen> ' decision from long ago < mclasen> ? < mitch> we should go over the list again i think, but yes < mitch> timj wanted to e.g. make these widgets visible by default < mclasen> tangentially related: we should fix the orientation properties to have correct declared initial values < mitch> but that's something that should be done for all widgets imho < jjardon> davidz, I've created this, if it's useful :http://live.gnome.org/GTK%2B/RI < mitch> mclasen: initial values? < Company> mclasen, mitch: related to that, would a g_param_spec_copy_with_new_default (const GValue *default) make sense? < Company> so that subclasses could override default values? < mclasen> yeah, if you can figure out how to do it < mclasen> the last time I looked at teaching the paramspecredirect to change defaults < mclasen> I couldn't figure it out < mitch> you mean *just* the default value? < davidz> jjardon: cool, thanks < mclasen> I guess if you just copy, then that'll work < kalikiana> yes, without re-creating it entirely < Company> mitch: yeah, so HBox and VBox can have a different default orientation < mitch> yea < mitch> Company: i'm rather for killing these classes < danni_> mclasen: you could make it not a redirect < Company> ya, it was just an example * danni_ did something similar to that very recently < Company> it's useful elsewhere < danni_> it just proxied cmp, and validate < mitch> problem is that they would also all have to become CONSTRUCT properties < mitch> for overridden defaults i mean < Company> mitch: you'd have to do that in instance_init, too < Company> for non-construct ones < mitch> Company: not if they are construct < mitch> yea < mclasen> we already do it in instance_init, no ? < Company> mclasen: yes < mitch> that's error prone ;) < Company> mclasen: but it confuses apps like glade < mclasen> I know, thats why I want the declared default fixed < mitch> aaah < Company> i suggested to tristan that he should write a test that instantiates all widgets and compares their property values with the defaults < Company> just to see how many cases we have where they don't match < mclasen> Company: like gtk/tests/defaultvalue.c ? < Company> don't think he ever did < mitch> Company: such a test is already there < Company> oh :) < mclasen> Company: that one blacklists all the properties where its broken... < mitch> heh * Company HAS A LOOK < mclasen> well, in some cases its unfixable, like object-valued properties < Company> /cas-lock < jjardon> For the record, this is the code of GtkHBoxButton after remove deprecated code: http://git.gnome.org/cgit/gtk+/tree/gtk/gtkhbbox.c?h=gtk-2.90 < mitch> fixing that for next stable is also a good goal < kalikiana> Company, so you like unit tests but never looked at gtk's tests? tsts ;) < mitch> jjardon: looks like hbox, hruler, hscale etc ;) < Company> kalikiana: that's mostly becaue they're not taken serious enough < kalikiana> I guess they are just too chaotic < jjardon> mitch, yeah: see GtkVBoxButton: http://git.gnome.org/cgit/gtk+/tree/gtk/gtkvbbox.c?h=gtk-2.90 < Company> kalikiana: and not run often enough < mclasen> mitch: so, clearly, before we can even talk about deprecating h/v variants, we have to solve the abstractness issue < Company> kalikiana: and you're not shamed publically if you break them < kalikiana> Company, yeah, we need a bot to IRC and email breakes < kalikiana> that would be cool < mitch> mclasen: all classes i hacked up just work totally fine when you remove ABSTRACT < mclasen> the thing is, they don't break that often < mclasen> ...lack of coverage... < mclasen> mitch: no doubt < bilboed> did I hear buildslaves ? < mclasen> the holdup here is entirely about default values < mitch> yea... < mclasen> but we cannot really change the defaults in 2.x. Or can we ? < mitch> mclasen: only if somebody instantiates a gtkbox directly, < mitch> mclasen: i'm just not totally sure about the how < mclasen> well, then you gotta give all derived classes the old default back < mclasen> how are you going to do that for out-of-tree stuff ? < mitch> void < mitch> _gtk_box_set_old_defaults (GtkBox *box) < mitch> { < mitch> GtkBoxPrivate *private; < mitch> g_return_if_fail (GTK_IS_BOX (box)); < mitch> private = GTK_BOX_GET_PRIVATE (box); < mitch> private->default_expand = TRUE; < mitch> } < mitch> that's how we do it now, as an example < mitch> um, good point < mitch> maybe we should simply got for GTK_IS_VBOX() || GTK_IS_HBOX() here < mitch> ugly but works < mitch> and will go away as soon as we remove te deprecated hbox and vboxed < mitch> vboxes* < kalikiana> mclasen, wouldn't out-of-tree classes inherit the subclasses defaults? < kalikiana> if we fix them that is < mitch> yes, right actually < mclasen> kalikiana: if we change the default for boxes to visible= true, we can fix hbox/vbox to be !visible still < mitch> as long as they derive from the old subclasses they inherit their hacks too < mclasen> but some gimpbox thats directly derived from gtkbox is going to be visible by default, then < kalikiana> does it actually inheit gtkbox? < kalikiana> is that allowed yet? < mitch> mclasen: and it will know that, because it derives from gtkbox! < kalikiana> s/allowed/allowed by gobject < mitch> kalikiana: deriving is allowed of course < kalikiana> Hm.. ok. Wasn't sure if it was protected somehow < Company> kalikiana: yes < jjardon> Related bug about properties: https://bugzilla.gnome.org/show_bug.cgi?id=587256 < mclasen> one can perhaps play horrible games to figure out at construct time whether its a box or a subclass... < mclasen> ...but the pain involved is certainly considerable... < mitch> you can do that in init() < mclasen> the thing is, you need to do it in a box function, not in a function of the derived class < mitch> it's a simple == but you can't use the type definition macros any longer :( < jjardon> (that bugs makes glade unusable for some people) < mclasen> we probably need a worked out example of that... * mclasen looks at the rest of the deprecation list < mclasen> those look easier... < mitch> what list? < mclasen> notebook tab packing, gtkcurve, multihead < mitch> oh, yea, the usual stuff :) < mclasen> so, I don't think we need to discuss gtkcurve really < mitch> die die die < ebassi> and the tab packing on Notebook either < ebassi> evilness < Company> but i want my help tab on the right! < mclasen> looking at gtkcurve, theres some more in the too-specialized departement < mclasen> gtkruler and its ilk < mitch> ruler is used in many apps though < ebassi> Company: :-P < mclasen> mitch: oh, in that case, we should move it out of the 'too-specialized' section in the docs < mitch> mclasen: well actually gimp has gimpruler now, so... ;) < ebassi> if I had to implement a ruler nowadays I'd probably reach for cairo and DrawingArea < mclasen> mitch: cool ruler features you are holding back ?! < Company> did anyone review all the APIs we have for "too specialized"? < mitch> haha :) < Company> stuff like GtkLabel::pattern? < mitch> mclasen: but yes indeed ;) < mitch> Company: wtf is that? < kalikiana> Company, I doubt so. It would be a good idea, though < mclasen> Company: nobody did, as far as I know < ebassi> mitch: underscore a label's contents using a pattern < mclasen> so, we have agreement to deprecate gtkcurve and notebook tab packing < mclasen> what about !multihead-safe api * mclasen is a bit torn on that < mitch> please < ebassi> mclasen: for that I kinda agree with your comment on the bug < mitch> i know owen's argument of simplicity here, but it just sucks to have these legacy apis :/ < mitch> bug #? < mclasen> https://bugzilla.gnome.org/show_bug.cgi?id=547920 * mclasen rereads his own comment < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=547920#c24 < desrt> btw < desrt> - [deleted] gtk-2.16 < desrt> * [new branch] gtk-2.90 -> gtk-2-90 < desrt> - [deleted] gtk-2.90 < desrt> bye :) < mclasen> thanks, desrt < mitch> mclasen: how it multihead dying? < mitch> i'm not totally up-to-date on that front < mclasen> mitch: you don't have multiple screens anymore < mitch> is* < mclasen> you have a single screen, with multiple monitors < mitch> oh heh < mclasen> since nobody does the b/w + color monitor workstation setup from the 80ies anymore < bilboed> and even so it would be handled at the X level < kalikiana> what about remote? < danni_> remote is a separate Display, rather than a separate Screen < mitch> does any app apart from emacs and gimp support opening another display? < mitch> danni_: so it is a separate screen too < danni_> mitch: ok, valid < kalikiana> danni_, I just mean sth like running an app over ssh so it has a different gtk-settings :) < danni_> mitch: I guess though, since you're connected to a new Display, you'll get the default Screen for that Display < mclasen> so, I kinda see the point that this is a nice amount of api to get rid off < mclasen> do we know if gtk builds with multihead-safe turned on ? < danni_> can you hold connections to two separate Displays in X? I guess you could... I've never tried < Company> danni_: gstreamer-cairo holds roughly 50 < mitch> danni_: you can, try that sick hack in gimp ;) < Company> danni_: so the stuff can pass thread boundaries (it's X Displays, not gdk displays though) * kalikiana ponders saving that gimp quote as a universal excuse for new api < mitch> heh < Company> next item? < kalikiana> eeeeebassi < Company> hilight fail < Company> ebassi: next item! < mclasen> night item is 290 branch for glib < mitch> freudian slip? < mitch> i'm tired at least ;) < kalikiana> freudian gstring < ebassi> heh < mclasen> nah, I just omitted the . < mclasen> so, do we need one ? if so, what for ? < bilboed> ebassi, what would that entail ? < ebassi> bilboed: I do not know -- jjardon added it :-) < kalikiana> as far as I realize glib 2.9 was voted down quite loudly < kalikiana> since it's not worth it < ebassi> I guess it revolves around the "what do we do with glib" question < mitch> we don't have much to do there apart from remove deprecated stuff < mitch> not worth a 3.0, or? < ebassi> kalikiana: pretty much, though people have been asking for all sorts of crazy stuff to land in the next 3 months without testing and review ;-) < bilboed> crazy as in additions ? or crazy as in fixing tons of little stuff nobody's ready to review ? < ebassi> crazy as in additions < kalikiana> ebassi, crazy but painful is better than pain without gain :P < Company> desrt and davidz is a recipe for crazy < Company> and i mean that as a compliment < kalikiana> or typos < ebassi> like the usual < ebassi> ""collection API" < ebassi> request < Company> ... < mitch> treemodel into glib!!1!1!! < Company> is anyone using libgee outside of vala? < ebassi> doubt it < kalikiana> gee, nobody does < mitch> are we idling? < bilboed> ebassi, seems like a moo point < ebassi> yep < bilboed> ebassi, if stuff is reviewed... why put it in another branch ? < mitch> gobject-performance? < mitch> ok we're back on the last point :) < bilboed> just waiting for ebassi to close the previous topic :) < ebassi> as for the "application class" point, I'd say we wait until the D-Bus stuff lands :-) < mclasen> yeah, that should wait until then < Company> i'd like to have a schedule for gobject-performance < ebassi> bilboed: nothing much to close :-) < Company> because i'm kinda afraid noone will be looking at it and then it's too late to land < bilboed> right < Company> and then the gstreamer guys will keep ranting about glib maintainers being idiots < bilboed> which maintainers ? :) < Company> and then it'll all be my fault again < mclasen> Company: you live in the same town, no ? you could just casually 'meet' timj somewhere... < Company> mclasen: he's big and scary < mitch> yea bring some chains to bind him to the table < mclasen> but you have performance-enhancing branches * bilboed was worried this topic would go haywire < bilboed> mclasen, yes, gobject-performance on glib, and some others on fdo < bilboed> mclasen, the point is ... merging them < kalikiana> "some others" sounds like it must be very well organized < mclasen> Company: so, I would love to get serious about the gobject-performance stuff when alex comes back in a few weeks < Company> i'd just like to avoid everyone blocking on timj < Company> just like with class data < bilboed> kalikiana, you'd prefer me to pollute git.g.o with 500 branches ? < mclasen> and at that point, I'll try to reroute review around timj and get stuff unblocked < kalikiana> bilboed, Hm.. you realize you don't *have* to branch only because it's git :P < mclasen> does that sound fair ? < bilboed> kalikiana, agreed, I should just commit to master < Company> mclasen: yeah < mclasen> ok, cool < mitch> mclasen: it sounds like something nobody can object against < Company> mclasen: as long as it makes next stable glib, i'm happy :) < bilboed> same here < mclasen> almost at the 2 hour mark, should we defer remaining issues until ...when ? < mclasen> next week ? < mitch> yes please < Company> aren't we done? < mclasen> there's misc, and I would have brought up some tooltips revamp I'm doing right now < mitch> there is misc on the agenda :P < mclasen> but I'll table that for today < mitch> mclasen: yet another revamp? < ebassi> so next meeting in two weeks? < ebassi> November 3rd < ebassi> ? < mclasen> mitch: just a facelift < mitch> next week? < mclasen> rounded corners, that kind of stuff < mitch> mclasen: neat :) < mclasen> and maybe better positioning < Company> ebassi: didn't someone suggest next week? < ebassi> or next week * Company doesn't mind < bilboed> fine by me < mclasen> there was some motion to meet earlier, because we have stuff on the agenda < ebassi> either is fine by me - I just need the date for the wiki (and for the reminder) < mitch> since we don't have infinite time i'd say next week < mclasen> so make it next week, then < ebassi> okay, next week, October 27th < ebassi> thanks everyone < bilboed> thx