< jdahlin> ebassi: should we start? < mclasen> tbf: if you file a bug I may have a look, or ask danw < ebassi> jdahlin: yes, we should start < ebassi> I'll write down the points: < ebassi> * extended layout management (tbf) < ebassi> * offscreen redirection (mitch, ebassi) < ebassi> * 2.14 status (mclasen) < ebassi> * guadec team meeting < ebassi> * consider adding EggToolPalette (murrayc, tbf) < ebassi> these are the points that are on the wiki and that have been sent to me in addition to the first two < ebassi> so, who wants to start? :-) < mclasen> small addition under misc: Gnome tool kit vs GTK+ toolkit < bratsche> I also want some discussion of http://bugzilla.gnome.org/show_bug.cgi?id=540529 < ebassi> oh, yeah < bratsche> I don't know what to do with it, if anything. < mclasen> should we discuss that first, to get it out of the way ? < kris> yea why not < mclasen> I think it is largely just a miscommunication < kris> I don't see any point of removing references to GIMP < kris> GTK+ has a history < kris> and its history is "GIMP Toolkit" < jdahlin> I also wanted to discuss formalising the review process, but that might be better to do at guadec. < bratsche> I don't have any opinion one way or the other, I just want to know what I should do with it. < kris> I don't see anything that is wrong with this < mclasen> I thought the request was mainly about removing a misleading name from visible places < rhult> behdad only asked to remove it from the pc file, afaik < rhult> which makes sense and nobody has objected to < bratsche> The bug title says "Remove all GIMP references", so I took that literally and changed the name in all the .[ch] files as well. < mclasen> rhult: and I said it might be good to look through the docs, too < jdahlin> I might argue that we should keep it consistent, if we remove it in one place we should remove it everywhere < rhult> mclasen, right < mclasen> and the result was a patch that touched every single source file < kris> what is the problem with "gimp toolkit" at all? < mclasen> kris: no problem per se, except for it being slightly misleading < hpj> i think "gimp" is frequently taken to mean "inferior" < jdahlin> right, gtk+ is used outside of gimp. < mclasen> the new website never spells GTK+ out as Gimp tool kit, as far as I can see < kris> how? people think it is 100% tied to gimp? < mclasen> kris: there is nothing wrong with acknowledging the history < mclasen> I've proposed to add a history section to the docs < kris> anyway, if we have to, I would update the pkgconfig file to say "GTK+" or "GTK+ UI toolkit" < kris> but not touch source fioles < yosh> honestly, changing every source file should've been a giant red flag < kris> adding a history section to the docs sounds like a nice idea < yosh> pkg-config can just say "GTK+" no expansion < mclasen> that seems to be a clear agreement. < mclasen> bratsche: good enough ? < bratsche> Yeah, so leave the docs/.pc/whatever files and revert GTK+ Toolkit -> GIMP Toolkit in all the .[ch] files? < kris> what happened to the docs? < bratsche> I updated -every- reference. :) < mclasen> yes. I can look into a 'history' section for the docs in my 'spare time' < kris> I don't see the need to update the docs < ebassi> okay then. ACTION: bratsche will revert the changes to the source files < kris> from the original situation (before this commit) I would *only* update the pkg-config file < kris> leave all source code and docs as is < kris> add a history section to the docs at some point < bratsche> Well wait.. revert all the .[ch] files for sure. Should I also revert all docs? < kris> and GTK+ toolkit sounds wrong (TK is toolkit), please use just "GTK+" or "GTK+ Graphical UI Library" or something if it needs further explanation < yosh> yeah, only change the .pc file, and I'd argue to make it just say "GTK+" instead of "GTK+ Toolkit" < kris> yosh and I clearly agree here ;) < yosh> so revert the entire patch, then just change the .pc file to just say "GTK+" < jdahlin> I wouldn't call it GIMP Toolkit in the documentation, unless in an historical section < tbf> yosh: just saying "GTK+" is really sub-optimal < yosh> tbf: why? < jdahlin> following the precedent set by the new website < tbf> yosh: the .pc file description should be at least a little bit descriptive < kris> tbf: then we should go for "GTK+ Graphical UI library" or something like that < kris> not "GTK+ Toolkit" < tbf> kris: yup < bratsche> I like that. < yosh> tbf: I don't agree. do you really think someone who knows enough to look at pkg-config doesn't know what GTK+ is? < bratsche> So that goes in .pc files, everything else goes back to the way it used to be right? < mclasen> bratsche: that seems the way to go < bratsche> yosh: Maybe they know what it is, but how is additional information harmful? < tbf> yosh: when dealing with new libs i do < yosh> we're not talking about the generic case < yosh> but "Graphical UI Library" is fine < tbf> yosh: i just answered your question < tbf> yosh: even if it was suggestive < mclasen> lets send the fight over the exact pc file line to a subcomittee < kris> mclasen: I think we have just agreed though ;) < tbf> yosh: also think about applications like anjuta which might use that description entry < mclasen> tbf: they are already broken by not getting translations < tbf> mclasen: that's no reason to break it even more < mclasen> true < kris> Is anybody against using "GTK+ Graphical UI Library"? < kris> if not, we can settle this and continue ;) < mclasen> moving on... < ebassi> yeah, moving on < bratsche> Yes, I will do this tonight after work. < bratsche> Thanks everyone. < mclasen> I'd like to do 2.14 status next if thats ok < bratsche> When is the 2.14 release date? < mclasen> so, the plan at last years guadec was to have a 2.14 release by this years guadec < kris> I would propose to discuss the 2.14 release date at guadec, just like last year (and the year before) < mclasen> thats obviously getting a bit tight < mclasen> kris: fine with me, but I won't be there < kris> mclasen: oh really? suck :( < mclasen> kris: family obligations... < timj> mclasen: urm, really bad news.. < mclasen> kris: I already took my 2 conference days this year... < kris> mclasen: too bad :( < bratsche> I told Andre Klapper I would try to finish up my GUnitTest (or whatever you call it) for #56070 by then, but I haven't yet. I'll try to do it this week if there is a chance to get this in by 2.14 release. < kris> so what is left for 2.14? < mclasen> what I'm interested in today is what people want to get into 2.14 still ? < mclasen> any major outstanding features or fixes ? < kris> I am pondering to *maybe* get tree view column resizing into 2.14 < kris> but I found new bugs at the airport last weekend, need to look into that again to make a good estimation < kris> I guess it could go into 2.14.x also < bratsche> If I can finish this test really soon then I'll propose it and the current patch for #56070 < jdahlin> mclasen: pbor wanted me to proxy the request for builder root support < timj> bratsche: comment #134 there sounds like you should joint the gtk+ BOF at guadec. i'd like to talk about changes in event processing there < kris> timj: when it the GTK+ BOF scheduled btw? < tbf> guess extended layout and eggtoolpalette are out due lack of time? < bratsche> timj: I'm not at guadec though. :( < kris> timj: I couldnt find it in the schedule today < mclasen> tbf: if either are ready to be dropped in right now, I don't see that as a given < jdahlin> tbf: are you going to push and do the integration ? < timj> kris: after your talk, i think the schedule says something else that "BOF" < Sonderblade> there was quite a few accessors missing after the GSEAL merge, i think it would be nice to have them so that compiling with sealing enabled would be feasible < kris> timj: oh really? < mclasen> in particular the toolpalette is probably a fairly isolated piece ? < tbf> mclasen: well, eggtoolpalette is quite isolated and finished < timj> tbf: yes, definitely my feeling, it's too late for those < jdahlin> I'd also like to see extended layout go in, not sure what state it is in though. < kris> timj: not on the schedule here http://guadec.expectnation.com/guadec08/public/schedule/grid/2008-07-11 < mclasen> tbf: the question is: where are the uses that justify the rushed inclusion into gtk ? < timj> mclasen: i don't think it's a good idea to push major new APIs at this point. that usually needs proper review and we're late with the schedule promised for gnome already < kris> Sonderblade: do you have a list of what's missing? < mclasen> yeah, I tend to agree < tbf> mclasen: so far only glom uses it < tbf> afaik < jdahlin> yes, if we're late then we should defer new api to the next release < mclasen> tbf: would it be a major disaster for glom to ship its own copy for a little longer ? < mclasen> tbf: ie until 2.15 opens ? < mclasen> tbf: I know that is probably a bit disappointing considering all the work you've sunken into the extended layout already < jdahlin> (or if it will be 3.1) < Sonderblade> kris: no list, but there are some bug reports, "quite a lot" is missing even if much have been fixed < timj> tbf: we should really talk through your exact layouting changes at guadec, we didn't really get a chance to finish that last year (and in berlin we both were too busy) < tbf> mclasen: not really, but it would be reasonable to have a proper done tool palette in gtk at some time < kris> Sonderblade: I can't imagine much is missing though < tbf> mclasen: there are quite some apps which use have-assed versions < mclasen> tbf: would e.g the gimp switch to that implementation ? that would be a major selling point, in my view < tbf> mclasen: well, regarding extended layout i am also quite guilty of not pushing it enough < kris> to me extended layout sounds really nice to start 2.15 with < kris> if we can review and land it early, it will get large amounts of testing < mclasen> tbf: you should nail down the available parts of the GTK+ maintainership at guadec to have it discussed to the end < mclasen> together with mitch's box flipping... < mclasen> ok, coming back to unfinished things in the current tree < mclasen> what is the state of the GSEAL merge currently ? < jdahlin> there's a wiki page iirc < timj> mclasen: all uncontroversial bits of our branch have been merged < jdahlin> http://live.gnome.org/GTK%2B/3.0/PendingSealings < mclasen> all abi accidents straightened out ? < timj> people have started sealing gtkrcstyle, gtkstyle and more, but i haven't really looked at those yet and don't know whther that's trivial enough to actually have it. < mclasen> i'm asking because I want to get another snapshot out this week, before guadec < timj> i'm not aware of ramaining abi accidents < kris> I guess we are having a 2.16, which means that having GSEAL done is not a 2.14 requirement < timj> remaining < mclasen> timj: is the goal to have the remaining things sealed before 2.14 ? < timj> mclasen: no, i think keeping the gnome schedule is more important < timj> it'd be nice to have more things sealed, but i don't think we should hold off the release further because of this < mclasen> timj: ok, good < jdahlin> timj: off topic: is GtkStyle really that hard, seems to me that it just need a lot of getters taking one GtkStateType argument? < timj> jdahlin: i cannot provide you with a well informed opinion on gtkstyle at this point < jdahlin> timj: okay, I'll open a bug and discuss there. < timj> i.e. prefer to investigate this before being pressed for a call ;) < mclasen> the other critical piece is the file chooser... < kalikiana> jdahlin: You might talk to garnacho who's working on gtkrcstyle which is a bit related < garnacho> yeah, also began working on GtkStyle :) < mclasen> bratsche: do you have any idea how well the trunk filechooser works on win32 currently ? < bratsche> mclasen: No, but I can find out if you want. < mclasen> bratsche: that would be useful, I know hans and tor did some work in gio to make it better < bratsche> mclasen: I haven't been working off of trunk on Win32 so far. < bratsche> Okay, I'll look into it then. < mclasen> so you probably need trunk glib too < bratsche> Yeah. < mclasen> or just wait until I do releases later this week... < bratsche> So far I haven't really looked into gio Win32 stuff. I'm mostly just familiar with gdk/win32 so far. < bratsche> Okay, I made myself a note to look into this. < mclasen> so, action on this topic: I do releases this week, and the guadec meeting discusses the final schedule ?> < timj> mclasen: fine, taking a note on the guadec todo here < timj> mclasen: we'll prolly discuss the schedule for the next stable gtk, i guess... < mclasen> yeah, that too < ebassi> apropos guadec < mclasen> and the version number... < kris> this gtk+ 2.14 < kris> next 2.16 < kris> done < kris> ! < mclasen> easy as pie < bratsche> :) < ebassi> hehe * timj is all for syncing versions numbers at latest with 3.0 < kris> timj: yes, with 3.0 we will sync < kris> timj: i will break abi in glib for you, so you can call it 3.0 < kris> done! < ebassi> apropos guadec: who's taking the minutes? < kris> ebassi: I wouldnt mind to volunteer again < ebassi> cool, thanks kris < kris> unless the previous year's minutes sucked and somebody wants to take over < timj> guadec minutes? i'd love to have you do them kris ;) < kris> oaky < kris> I would bring my student notebook and pencil again < kris> would->will < timj> kris: they were great, i think even owen replied and said so < ebassi> kris: the minutes last year were great :-) < kris> okay < kris> settled then < kris> done! < mclasen> ebassi: anything else on guadec meeting preparations ? < ebassi> we already have a slot, so I'll round up the usual suspects when the day comes :-) < mclasen> sounds good to me < mclasen> what topics do we have left, offscreen redirection ? < ebassi> yes < ebassi> no mitch, though < ebassi> well < bratsche> Yeah, he said he probably wouldn't be here. < timj> mclasen: offscreen pixmaps are in, offscreen refactorings are in, event procressing is planned for post-2.14 with having a dicussion on event processing during guadec < timj> i.e. event processing would be nice to get in later this fall < hpj> i've a question for the misc section < ebassi> timj: yeah, it would. is the GdkOffscreenWindow slated to go in for 2.14 then? < mclasen> hpj: lets finish offscreen, then we'll take your question < ebassi> timj: it would at least enable embedding complex widgets in canvases, even without the event transformation < ebassi> I agree that the event translation is too complex to go it now, though, and it will require some API talk with the other out-of-tree canvases as well < timj> ebassi: i've definitely not given the rest enough review to say it can easily go in < ebassi> timj: yeah, I understand that < timj> and it seems the remaining patch still has some issues, so it's probably better to reconsider integration when those have been straightened out. considering that we're running late already, that's most probably post-2.14 again < ebassi> okay, fair enough < mclasen> does that leave us with something useful in 2.14 ? < mclasen> at least we have the snapshotting, I guess < ebassi> mclasen: well, gtk_widget_get_snapshot() and a huge refactoring of GdkWindow < timj> yes, and i consider both huge gains already ;) < timj> they definitely took quite some work from alex, ebassi and me at least ;)) < bratsche> What is the refactoring in GdkWindow? < mclasen> sounds fine to me then < mclasen> anything else on offscreen ? < mclasen> else we should hear hpj's question < ebassi> bratsche: moved most of the api into a GInterface < timj> mclasen: nothing else from em < timj> me < ebassi> bratsche: implemented by the backends - some of which are now broken, I guess :-) < ebassi> mclasen: nothing more from me < kris> quartz has been fixed on Friday at least < kris> works fine < bratsche> ebassi: Cool, thanks. I'll look it up, I'm curious since I work on the Win32 part of it now. < mclasen> ebassi: might be good to collect some hints on how to fix the backends... < ebassi> mclasen: sure < mclasen> unless they are all fixed already < mclasen> I guess directfb is the problem child < ebassi> I think win32 is broken, and surely directfb < bratsche> I didn't know anything about this, and I usually don't build trunk. < bratsche> So I'll look into it since I told mclasen I would build trunk to test filechooser anyway. < ebassi> bratsche: thanks < mclasen> hpj: what was your question ? < hpj> so i've been toying with a new GDK backend that renders each toplevel GdkWindow to a respective cairo image surface and leaves further rendering and event generation up to the application < kris> bratsche: adapting the backend was not harrd for quartz < hpj> is there any chance of a backend like that making it into GTK proper if i maintain it? < kris> bratsche: just look at the quartz and X11 change sets < bratsche> kris: Cool, thanks. < bratsche> I'll look at this maybe tonight after work if I have time. < hpj> my use case is applications that want to use windows in a peculiar rendering context < hpj> like SDL/OpenGL games < hpj> or anything else you can think of that's not tied to a particular windowing system/device like X11, DirectFB, win32, quartz < ebassi> hpj: I think this matches some of the OffscreenWindow capabilities < mclasen> hpj: there was an abstract framebuffer backend in bugzilla at some point < mclasen> is this similar ? < hpj> yes, it's similar to offscreen rendering, but handles all application windows and does not depend on a display subsystem < timj> hpj: can we talk this through at guadec as well? particularly about event processing.... < hpj> i basically resurrected the linuxfb code and took out the device-specific parts, made it render each toplevel to a separate surface and not to a screen surface < hpj> i have mouse events and rendering (mostly) working < hpj> (testing using gtk-demo) < hpj> timj: sure < hpj> i was just wondering if i should make the effort to get this integrated or if the answer is no right off the bat < hpj> because of the overlap with offscreen rendering < timj> hpj: yeah, but that's logic that is replicated in a bunch of backends and offscreen rendering, ideally, we'll have only one implementation of that at some point < timj> hpj: in general, if a backend has valid use cases, and especially if its well maintained, there's no reason to reject it up front < mclasen> hpj: we have a bit of bad luck with retaining backend maintainers...linuxfb, directfb,... < hpj> timj: cool < timj> the biggest problems we usually have with backends is bad maintenance < hpj> i think i'd be a reliable maintainer < hpj> i've been around for a while < hpj> so i'll pursue it for eventual inclusion, then < mclasen> sure, noone doubts that :-) < hpj> backends don't disturb the code much, fortunately < timj> hpj: sounds good then. ;) added to the guadec talk todo < hpj> especially a "special needs" one like this one < mclasen> but I share tims concern that this feels like we should be able to share a lot of the code across backends < hpj> timj: thanks! < kris> we should refactor all backend crap in 3.x!!! < kris> :) < hpj> yeah, the GDK stuff is a bit hairier than it could be for backend implementors < kris> a bit??? < hpj> but that's a different project :) < hpj> heh * kris would love to get rid of all X11 specific crap < mclasen> kris: death to subwindows... < bratsche> Come on, it's FUN! < kris> and make it much simpler < bratsche> :) < kris> mclasen: that too < hpj> yeah, subwindows make it interesting :) < ebassi> hehe < hpj> ok, that's it for my question < jdahlin> kris: many people has said that, nobody has written a proposal... < mclasen> I think we are done then ! ebassi ? < ebassi> done deal :-) < kris> jdahlin: lemme first finish univeristy, okay? ;) < jdahlin> kris: always the same excuses. < kris> jdahlin: tsss < arc> kris, you'll finish, and then you'll realize that you don't have more spare time < ebassi> okay, thanks everyone - I'll send the minutes to the list later tonight