* mclasen looks for the agenda
< kris> garnacho: carlos is a graaaaaaape carlos is a graaaaape
< ebassi> http://live.gnome.org/GTK+/Meetings
< aruiz> kris, you bet
< ebassi> 1. gobject-performance branch status; 2. gtk+ 2.90 branch; 3. GLib 2.22 branch and future; 4. GtkFileSystemModel branch status; 5. Miscellaneous 
< kalikianatoli> maybe we could add "reviewers" to the topics? it was mentioned on the list a few days ago
< mclasen> I think that may go under 3. "and future" ?
< kris> it was mentioned as part of 1. ;)
< kris> but i agree with putting it up explicitly
< kris> or under 3
 * mclasen has some 'feature work for 2.20' items
< kalikianatoli> no idea what future is exactly. if that includes "who is gtk 3" then I guess it fits
< bratsche> I have some feature work in my queue, for whatever is the next major release.
< garnacho> me too
< kris> I have a snow leopard machine now woooooooo
< aruiz> beware
< bratsche> :)
< kris> so I can make the gtk+ backend more awesome
< aruiz> :)
< mclasen> ok, shall we start running down the agenda ?
< aruiz> mclasen, yes
< kris> I also have my tiger machine still, so I can retain compat ;)
< mclasen> 1. gobject-perfomance status
< mclasen> I believe alex merged the easier parts of that branch to glib master and proposed to look at the rest after branching
< mclasen> and I have seen some review activity from timj there, recently
< timj> jup, and alex told me the remaining stuff isn't as urgent
< mclasen> so, we are over that hump for now, it seems 
< mclasen> anything else on that topic ? 
< mclasen> ok, then lets move to the next topic, I guess
< aruiz> :)
< mclasen> 2. gtk 2.90 branch
< kalikianatoli> I haz one
< bratsche> I can offer to setup PPA builds of gobject-performance and/or GtkFileSystemModel branches and get someone in Ubuntu to advertise them and get some user testing on them if you think it would be useful.
< kalikianatoli> or rather, I started working on that, and I'd like to push it to git.gnome.org and let others join the fun
< aruiz> bratsche, that would help a lot
< aruiz> at least for the ubuntuers around
< aruiz> kalikianatoli, is there anything stopping you to push that branch upstream?
< bratsche> It would help get more users testing it, but I'm not sure it's worth the effort of dealing with bug
reports from people using the branches since they may not know what issues are being caused by the branch vs. not.
< mclasen> can we summarize the purpose of that branch again, quickly ?
< kalikianatoli> aruiz, The lack of having discussed it :)
< mclasen> this is for dropping deprecated stuff and build with gseal, right ?
< kalikianatoli> Yes
< kalikianatoli> like the # in the wiki page
< mclasen> and we are going to keep it otherwise in sync wiht master ?
< kalikianatoli> Yes, that's the idea
< ebassi> kalikianatoli: do you plan merging or periodically rebasing it?
< kalikianatoli> I think javier also suggested to get some patches to master where it makes sense
< kalikianatoli> ebassi, Yeah
< kalikianatoli> s/javier/jjardon
< jjardon> hello all
< kalikianatoli> jjardon mentioned applying some of the accessors/ 2.9 things onto master
< bratsche> Is the idea to have a GtkFooPrivate* member in your GtkFoo instance struct, and internally call foo->priv->x?  Or to call priv = FOO_GET_PRIVATE() and access priv->x that way?
< bratsche> Currently the code rewriter is doing the second way I think.
< ebassi> bratsche: no, don't use FOO_GET_PRIVATE() (if it maps to G_TYPE_INSTANCE_GET_PRIVATE())
< kris> bratsche: as far as I know the latter has proven to be a performance bottleneck, so I guess we should definitely go with the former
< kalikianatoli> GET_PRIVATE at runtime is a performance nightmare :)
< bratsche> Okay, then I'll change the rewriter.
< ebassi> kalikianatoli: yeah to which one? merging or rebasing? :-)
< kalikianatoli> ebassi, Oh, rebasing :)
< ebassi> kalikianatoli: ok, good to know
< ebassi> kalikianatoli: having the 2.90 branch on git.gnome.org would certainly be good - one less remote to check :-)
< kalikianatoli> Yep, definitely
< kalikianatoli> Btw did we discuss the pkgconfig name yet?
< bratsche> Not that I've seen.
< bratsche> I assumed it would be gtk+-3.0
< jjardon> kalikianatoli, yeah the idea is only use -> (direct acces) to access own variables, and accesor functions for the rest
< mclasen> who is going to take on the job of keeping master and 2.90 in sync ?
< bratsche> I don't mind sharing this responsibility, but I can't take on the entire job.
< mitch> um, too bad i'm late
< bratsche> mitch: We've assigned all the work nobody else wants to do for you. ;)
< kalikianatoli> Maybe we can see that one out of n people does
< kalikianatoli> Otherwise I will try to find the time for it
< mitch> was the issue of adding api to 2.18.x i brought up on #gtk+ already discussed?
< ebassi> kalikianatoli: I can also volunteer for that
< bratsche> mitch: No.
< mitch> ok
< kris> mitch: could you be more specific as well maybe? :)
< mitch> yes
 * mclasen envisions 2.90 to be a relatively minor branch that gets rebased periodically. am I wrong with that ?
< mitch> i'm suggesting to add missing accessors for sealed member to 2.18.x
< ebassi> mclasen: I'd expect that as well
< bratsche> http://live.gnome.org/GTK+/Meetings  (we're on the 2.90 item now)
< mitch> mclasen: no that's mostly right
< mitch> mclasen: minus removal of all deprecated api
< kalikianatoli> ebassi, I'd like to have names and tasks somewhere in the wiki, to organise this a bit
< kalikianatoli> ie. roughly see who can do what
< ebassi> kalikianatoli: sure
< mclasen> mitch: ah right, the deprecated stuff is going to be large
< mitch> rationale for adding api to stable: we expect people to port to sealed gtk during the 2.18 period, and they can only do that if the needed api is there
< bratsche> mclasen: The changing of internal functions from foo->x to foo->priv->x is going to be a lot I would imagine.
< kalikianatoli> ebassi, I'll update http://live.gnome.org/GTK+/3.0/Tasks after the meeting, and add you with a new item there :)
< ebassi> kalikianatoli: sure
< mitch> any opinions about my suggestion?
< mclasen> I'd rather do an intermediate 2.20 to pick up remaining api additions
< kalikianatoli> I'd rather see an intermediate release of Gtk than new API in stable
< kalikianatoli> heh
< mitch> so what about new unstable features that are in master at that point?
< aruiz> I sort of agree there, also, there are deprecations that we might want to add before 2.90
< mclasen> mitch: we won't merge them to master before they are stable enough for a release ?
< mitch> mclasen: who decides that they are stable given nobody tests branches? :) not going to work...
< kalikianatoli> unit tests!
< mitch> i'm really talking *exclusively* about accessors
< mitch> like gtk_foo_get_bar()
< mclasen> mitch: realistically, new features in master won't be really tested until apps start using them in the next cycle either
< mitch> that's not "new features"
< mitch> mclasen: granted
< kalikianatoli> mitch, even you make typos, don't you? :)
< jjardon> I really need mitch accesors to complete some patches
< mclasen> mitch: maybe it would help to look more concretely at the 'unstable features' we've actually lined up for merging...
< bratsche> Do you have any idea how long until you want to do a 2.20 release?  Or is it too early to ask that?
< mitch> yea, and from gimp experience i can definitely say that i can't
port gimp to sealed gtk 2.18 because there is so much stuff missing
< mitch> mclasen: indeed, but i didn't see that line so far
< Company> would it make sense to do a quick 2.20 with all those features?
< mclasen> mitch: off the top of my head, I know at least the toolpalette stuff, xi2, and filesystemmodel
< mitch> mclasen: which all looks safe apart from xi2, sorry garnacho ;)
< bratsche> Depending on the time frame, I was hoping to get decorations stuff into 2.20.
< mitch> mclasen: is there anything that speaks against a really quick 2.20 release?
< bratsche> But if it's really soon then I guess it waits.
< mclasen> there are probably more things that would be nice to have, but not ready, like the extended geometry stuff
 * aruiz wants to deprecate the tab-pack child property before 3.0
< mitch> i mean, now is the time to ask people for missing accessors
< mclasen> mitch: not from my perspective
< aruiz> for GtkNotebook that is
< mitch> i need about 10-20 accessors to seal gimp's gtk call completely
< mitch> that's almost nothing compared to 2.16
< mitch> calls*
< mclasen> do we have one of those gnome love pages to track the progress of building gnome with gseal ?
< mitch> yes, a pretty good one actually iirc
< mclasen> http://live.gnome.org/GnomeGoals/UseGseal
< aruiz> http://live.gnome.org/GnomeGoals/UseGseal
< aruiz> heh
< mitch> but but but
< mitch> we really need regular meeting like this one if we want to push this
< kalikianatoli> aruiz, bug 596083
< ebassi> I'd rather have the new geometry negotiation between 2.90 and 3.0, if it also means cleaning up GtkWidget, SizeGroup and Label
< mclasen> mitch: we can try to reestablish that
< mitch> mclasen: please, it's really a motivation push
 * mclasen is still short on time, though
< mitch> me too :/
< aruiz> kalikianatoli, I'd assume that patch is not upstream, is it?
 * mclasen adds to the end of the agenda: schedule next meeting
< aruiz> mclasen, yeah :-)
< kalikianatoli> aruiz, Unfortunately not, but I'd hope to have it in the "quick" release
< aruiz> yeah
< aruiz> so we have a couple of reasons to have a quick 2.20 release
< mclasen> so, how quick are we talking about ? before the end of the year ?
< kalikianatoli> I have other deprecations as well =)
< mclasen> is that too late ?
< aruiz> mclasen, way to late imho
< mitch> aruiz: what?
< mitch> aruiz: do you have time to add all the accessors?
< mitch> let's rather aim for 6 instead of 12 months, to be more realistic
< ebassi> before the end of the year sounds good to me; leaves a month and a half for porting applications before 2.30
< mclasen> end of year seems realistically the best we can do
< jjardon> I have some bugs here to request some accesor and complete the patches to build with GSEAL enabled if anyone interested
< bratsche> I can add accessors if there is a known list of what needs to be added.  Figuring out what's missing sounds like the part that would take a lot of time.
< mclasen> if we branch now, and establish the dual-branch setup
< ebassi> and eventually deprecate/add more stuff
< mitch> yes, the very best
< mclasen> and merge the features that are ready
< jjardon> I post them in http://live.gnome.org/GnomeGoals/UseGseal if you want
< mclasen> then we'll have a month or so left to accumulate accessors and deprecations
< mclasen> might be a good idea to target a few 'big' apps to be completely sealable as a goal
< bratsche> seb128 said we could queue up a build of everything on an Ubuntu build server with GSEAL set and collect the output, but I think that may not be as useful as it sounds.
< mclasen> like gimp, epiphany and one more...
< mitch> mclasen: i volunteer to do that for gimp
 * mclasen figured
< jjardon> mclasen, I've already created patches for some of them
< kalikianatoli> should we have a meta bug?
< jjardon> see http://live.gnome.org/GnomeGoals/UseGseal for a complete list
< kalikianatoli> to track all these issues
< mclasen> jjardon: I know, thanks for doing that
< jjardon> kalikianatoli, https://bugzilla.gnome.org/show_bug.cgi?id=585391
< kalikianatoli> jjardon, I mean for 2.20 specifically
< kalikianatoli> ie also with features and deprecations
< mclasen> so, do we agree on this plan, as far as gtk 2.20 is concerned ?
< kalikianatoli> ++ from me
< bratsche> Do you have any idea how far away you want 2.20 to be?
< mclasen> and do we aim for a "2.80" to go along with it ?
< kalikianatoli> what is 2.80?
< aruiz> kalikianatoli, 2.90 for 2.20
< aruiz> :)
< mitch> mclasen: a clear nope from here, we should just try to make 2.20 what 2.18 was supposed to be
< kalikianatoli> and it would be experimental?
< mclasen> clearly
< mclasen> just a testrun for 2.90...
< mitch> yea
< kris> if we want to merge new features into 2.20, I would guess that that branch should be opened about nowish ...
< mclasen> right
< kris> if the intention is to release before the end of the year
< mitch> yeah
< mclasen> kris: rather, I'll do a 2-18 branch, so master can take 2.20 features
< kris> if its just accessors, it can wait for a bit i would say
< ebassi> sounds good to me
< kris> mclasen: yea, that's what I aimed at :)
< kris> I think we usually branch off other .2 anyway
< mclasen> I'll get that gtk-2-18 branch in place this week
< kris> s/opther/after/
< bratsche> Anything more to discuss in the 2.90 bullet point, or should we move on?
< mclasen> yeah '0 csw regressions' is a nice branchpoint, anyway
< bratsche> Item #3 is GLib 2.22 branch and future
 * mclasen scrolls back to agenda
< ebassi> 3. GLib 2.22 branch and future
< mitch> um, speaking of glib, we need class private data for a proper gtk 3.0
< ebassi> I guess: when we branch for 2.22, what features should land and will there be a GLib 3.0 in the future?
< kris> mitch: there's a patch for that
< kris> mitch: which I pre-reviewed
< kris> mitch: it completely makes sense to me
< mclasen> I will do a stable glib branch at the same time
< kris> mitch: the final word for that is with timj
< mitch> kris: yes i've seen it too, looks totally sane
< kris> mitch: oh yea and we even found a bug when i reviewed, hah
< kris> ;)
< mitch> heh
< ebassi> I'd like to propose a DOM based on GMarkup for 2.22
< mitch> oh and gmarkup needs my patch to deprecate the old vtable
< ebassi> GBookmark in GIO and GBookmarkFile would use it
< danw> you mean 2.24. 2.22 is now stable
< kalikianatoli> is there a  bug for that?
< ebassi> yeah, 2.24
< mclasen> ebassi: where did that come from ?
< ebassi> mclasen: people have been asking for a DOM based on GMarkup; I know that desrt wrote one as well
< ebassi> mclasen: the format used by GBookmarkFile has support for external metadata sections that KDE has recently started using
< ebassi> if you load a file saved by KDE into GBookmarkFile and then save it back, you'll loose the KDE-specific metadata
 * mclasen not really positive on the idea of including two xml parsers in glib
< ebassi> because a SAX-like parser does not really work
< ebassi> mclasen: it's not another parser; it's a DOM on top of GMarkup
< mitch> ebassi: does that work without gmarkup being a general parser (meaning it is capable of ignoring/externally handling unknown stuff)?
< mclasen> ebassi: oh, sorry, I somehow read 'parser' up there
< ebassi> mitch: yes
< mitch> ebassi: um, it doesn't even handle unknown entities
< ebassi> mitch: if you need a proper XML parser then you should be using a proper XML parser :-)
< ebassi> mitch: a DOM based on GMarkup would have the same limitations as GMarkup
< mitch> ebassi: well there is only this little bit missing to make it parse any valid xml :/
< kalikianatoli> there is a patch for namespaces iirc, that would be nice to have
< ebassi> mitch: that's mostly orthogonal to having a DOM tree, though
< ebassi> kalikianatoli: there's a bug open about namespaces
< mitch> maybe, but with the same limitations
< ebassi> kalikianatoli: and GBookmarkFile implements a somewhat naive namespace resolution internally
 * mclasen thinks namespaces are nicer to avoid than to have...
< mitch> good point :)
< ebassi> mclasen: true :-)
< kalikianatoli> ebassi, yeah, I know about the hack, but it's still just a hack :)
< mitch> but it doesn'T choke on namespaces, but it does choke on unknown entities
< mclasen> so, I don't think we are going to be able decide the 'gmarkup dom' idea today, should probably be developed on the list
< ebassi> kalikianatoli: doing it inside GMarkup would be better, but last time I tried it implied changing GMarkup's API
< mclasen> do we have other things that need to land in glib ?
< mclasen> I've already heard class private data
< danw> I am planning to add TLS (SSL) and proxy support to GSocket
< ebassi> mclasen: I'll bring it up on the list, and will try to get desrt's code as well
< mclasen> danw: how is that going to work out dependency-wise ?
< danw> they'll use extension points, so they won't drag any new dependencies into glib itself, but we'll need to put the gnutls-using and libproxy-using code somewhere. the libproxy stuff would make sense in gvfs since it would be unix-only, but the gnutls code might be used on windows too, so it fits there less well
< danw> (gvfs already depends on both gnutls and libproxy indirectly via libsoup)
< mclasen> danw: that sounds less scary than I thought...
< ebassi> about GIO and glib-next: how's GSetting?
< mclasen> danw: is that ready to ready to land ?
< danw> the glib-level tls API will be not-quite-fully featured; you'll be able to say "accepted certs from this trusted CA file" or "accept all certs", but if you want to pop up confusing "do you trust verisign" dialogs, your app will need to link to gnutls (or openssl or nss) directly so that it can parse the binary blog that gsocket gives it to validate
< danw> mclasen: no, not yet. before new year
< danw> mclasen: maybe *much* before that, but definitely by then
< danw> binary *blob*, not blog :)
< mclasen> just asking to figure out if it makes sense to try for glib-2.24 at the same time as gtk 2.20
< mclasen> I hope to pick up the gdbus idea that was floated on the list earlier
< mclasen> but I'll have to see how that fits in the schedules of davidz and alexl
< bratsche> So 2.24 would pull in dbus?  Or is this after 2.24?
< mclasen> in what form it will pull in dbus is still an open question, I think
< bratsche> Fair enough.
< mclasen> and it might indeed be after 2.24
< mclasen> that seems more realistic
< bratsche> People at work have been asking about this and if I know anything yet, so was just curious. :)
 * mclasen notes we have passed the 1 hour mark, time to speed up
< bratsche> Next item: GtkFileSystemModel branch status
< ebassi> that would be one of the candidate features for gtk+ 2.20 at this point
< mclasen> no update on that from me; I have run it for a few days without noticing any obvious problems
< bratsche> Company or federico have any comments?
< mclasen> I haven't looked at the code yet
< mclasen> federico has, and was also supposed to test it
< Company> can be merged fine :)
< mclasen> but, since we decided to branch _now_ and have a quick 2.20 it makes indeed more sense to merge it into 2.20
< Company> but then, i might be biased ;)
< aruiz> ebassi, sorry, was afk, gsettings is progressing quite good, ryan is going to make a release soon
< ebassi> aruiz: cool
< mclasen> the main problem with gsettings is not one of code, but of communication :-(
< mitch> i'd merge it right after the branch
< mclasen> it doesn't help to have desrt work in his closet for years on this...
< aruiz> mclasen, I can help with that
< Company> yeah, i think with 2.20, we should just merge the gtkfilesystem branch asap
< aruiz> mclasen, any particular course of action you would like him to take?
< Company> it's had quite some testing and code review from federico and me, so i suppose it's solid
< jjardon> I've created this page for Gsettings migration: http://live.gnome.org/GnomeGoals/GSettingsMigration
< jjardon> if helps
< mclasen> I agree, I will try to find federico and sort out the merging with him
< ebassi> jjardon: it helps, in part
< mclasen> I don't know that we can talk about migrating to gsettings yet, if we haven't even agreed to the design yet...
< aruiz> mclasen, I can ask him to come to the next meeting, or arrange one between the interested people just for that purpose
< mclasen> desrt seems to be marching on with his gvariant thing, despite early less-then-perfect reception to that...
< ebassi> aruiz: some of the collateral information is lacking; the schema format, how is going to support translations, how do we write a gconf-editor replacement, etc.
< mclasen> so I don't foresee a 'just merge it' in the near future...
< Company> mclasen: i'll volunteer to cleanly rebase the filesystemmodel branch onto master
< mclasen> Company: thanks
< federico> mclasen: I've been running it, not actually explicitly testing it, but it runs just fine (no crashes; I can open/save files, etc.)
< federico> I need to make some time to test it
< jjardon> bratsche, I've created a tracker bug for missing accesor functions: https://bugzilla.gnome.org/show_bug.cgi?id=597610
< bratsche> jjardon: Thanks dude.. can you CC me to it?
< bratsche> bratsche@gnome.org
< federico> so, should we just merge it or rebase it?  it's an old branch...
< jjardon> bratsche, sure
< mitch> jjardon: me too mitch@gimp.org
< aruiz> ebassi, I will send him those questions and send the answers to gtk-devel/ddl
< ebassi> aruiz: gtk-devel-list; d-d-l is just bad for that kind of discussion
< ebassi> aruiz: and thanks, that's much appreciated
< Company> federico: i'd like to rebase it (it only really touches one file that's not completely rewritten after all)
< aruiz> ebassi, you're welcome
< Company> federico: the incremental changes to GtkFileChooserDefault will certainly help bisecting regressions should there be any
< ebassi> should we move to: 5. patch reviewers
< ebassi> ?
< mclasen> yes, lets move on
< Company> can anyone pastebin the gobject-performance discussion for me?
< aruiz> Company, I will
< aruiz> Company, http://pastebin.valadoc.org/353.html
< mclasen> so, patch reviewers
< mclasen> the problem is most pressing in gobject, but far from limited to it
< kalikianatoli> I think a system with n reviewers needed to decide what commit-now from mclasen does today would be cool
< mitch> it's not that only mclasen can grant commit-now, the other trusted people are just lazy ;)
< mclasen> I mostly use that as a marker for myself really
< jjardon> bratsche, I've created a tracker bug for missing accesor functions: https://bugzilla.gnome.org/show_bug.cgi?id=597610
< bratsche> jjardon: Thanks dude.. can you CC me to it?
< bratsche> bratsche@gnome.org
< federico> so, should we just merge it or rebase it?  it's an old branch...
< jjardon> bratsche, sure
< mitch> jjardon: me too mitch@gimp.org
< aruiz> ebassi, I will send him those questions and send the answers to gtk-devel/ddl
< ebassi> aruiz: gtk-devel-list; d-d-l is just bad for that kind of discussion
< ebassi> aruiz: and thanks, that's much appreciated
< Company> federico: i'd like to rebase it (it only really touches one file that's not completely rewritten after all)
< aruiz> ebassi, you're welcome
< Company> federico: the incremental changes to GtkFileChooserDefault will certainly help bisecting regressions should there be any
< ebassi> should we move to: 5. patch reviewers
< ebassi> ?
< mclasen> yes, lets move on
< Company> can anyone pastebin the gobject-performance discussion for me?
< aruiz> Company, I will
< aruiz> Company, http://pastebin.valadoc.org/353.html
< mclasen> so, patch reviewers
< mclasen> the problem is most pressing in gobject, but far from limited to it
< kalikianatoli> I think a system with n reviewers needed to decide what commit-now from mclasen does today would be cool
< mitch> it's not that only mclasen can grant commit-now, the other trusted people are just lazy ;)
< mclasen> I mostly use that as a marker for myself really
< mclasen> I may try to come up with the beginning of such a list...
< kalikianatoli> btw jjardon do you mind me putting you in the 3.0/Tasks page as sealing person?
< kalikianatoli> you seem to be on it
 * mclasen also thought that the bug cleanup lists or whatever it was called that some people sent to the list semi-regularly helped a bit in getting me to look at patches
< ebassi> mclasen: some automated summary for patches in need of review
< jjardon> kalikianatoli, go ahead ;)
< ebassi> mclasen: would be a good start
 * mclasen needs to go in a few minutes
< Company> :/
< mclasen> before I drop off, lets get the next meeting scheduled
< Company> i'd like to have picked up the gobject-performance stuff again
< kalikianatoli> So is there any chance we can establish "reviewers"?
< ebassi> two weeks from now?
< mclasen> 2 weeks from now ?
< mitch> heh
< ebassi> kalikianatoli: I think it'll require some discussion on the list
< Company> but i guess it can wait till the next meeting
< kalikianatoli> ebassi, Okay
< ebassi> kalikianatoli: or off-list but with a concrete proposal for a review team
< mclasen> ebassi: will you invite ?
< ebassi> mclasen: sure
< mclasen> cool, thanks
< Company> i just don't agree with alex's notion that the other stuff isn't important
< Company> in fact, the critical parts for gstreamer aren't merged yet, only the boring stuff
< mclasen> I think he also said 'far from trivial' and 'needs much more review' ?
< ebassi> Company: s/important/as urgent/
< mclasen> so it seems very appropriate to delay those parts to the unstable branch
< Company> ebassi: i think the gstreamer guys were pondering rewriting some stuff to accomodate for the slowness, so i'd describe it as rather urgent
< Company> but yeah, i wouldn't wanna push it into stable
< mclasen> it won't be forgotten, definitively on the agenda for early 2.23
 * mclasen about to drop off
< Company> that's great then
< Company> let's talk about it in 2 weeks
< mclasen> thanks everybody for coming, and ebassi for inviting, and legwork
< ebassi> thanks everyone