< ebassi> as usual, the agenda is available here: http://live.gnome.org/GTK+/Meetings < ebassi> I'll paste the relevant points < jjardon> hello all < ebassi> • 3.2 planning < ebassi> • GtkFileChooser refactoring < ebassi> • Delete GDK_NATIVE_WINDOW < ebassi> • Pictures library < ebassi> • Next hackfest < ebassi> • Miscellaneous < ebassi> if there are last minute additions, feel free to point them out now :-) < jjardon> ebassi: for the GDK_NATIVE_WINDOW issue, Itś already reported and targeted for 3.2, so maybe you can remove it from the agenda < ebassi> right on time :-) < tristan> last minute addition: height-for-width optimizations... and can we land them in 3.0 < tristan> or, 3.0.x < mclasen> yeah, tight scheduling... < ebassi> right, first item on the agenda: 3.2 planning * mclasen goes to look for an agenda < ebassi> which I guess also touches what can we add during 3.0.x < mclasen> ok, who drives today ? < Company> jjardon: i remember people not wanting to remove the native windows stuff when i suggested it in rendering-cleanup * mclasen takes the helm < mclasen> so 3.2 planning < mclasen> I've started to mark sbugs for 3.2 < tristan> what is the 3.2 time frame ? is it a quick release or a normal 6 month thing ? < jjardon> reference: https://bugzilla.gnome.org/buglist.cgi?quicksearch=target:3.2+product:gtk+ < mclasen> gnome 3 is going with 3.0.x < mclasen> so my preference would be to treat 3.2 as a normal 6 month cycle < mclasen> aiming for gnome 3.2 inclusion < mclasen> any other opinions on timeframe ? < tristan> I think that's fine, was just curious < mclasen> ok < mclasen> 6 months would put us in ~August < tristan> I'll have some free time and I'll want to give another shot at my pet: composite-containers < Company> what's that? < mclasen> ok, next for 3.2 planning is branching < tristan> Company, it's the thing that lets you define a composite widget class using gtkbuilder input < Company> ah < mclasen> I propose to that this week, so that we can start to review and land the rgba work, and the hfw optimization, etc < Company> tristan: i was worrying it involved gdk_window_set_composited() :) < tristan> no no < Company> mclasen: yeah, i prefer branching rather sooner than later, too < mclasen> I think we got the bulk of fixes into 3.0.2 < tristan> mclasen, you want to postpone the hfw optimizations to 3.2 ? < mclasen> there's probably going to be a bit more in terms of theming, but we should be ok to move on to 3.2 now < mclasen> except for cosimo who stays behind to fix up toolbar theming :-( < mclasen> tristan: I think thats still up for dicussion < tristan> sure, ok, leave it for after < mclasen> ok, more 3.2 planning: does the list of bugs match reality ? < mclasen> or is there other stuff people want to target for 3.2 / are working on ? < Company> mclasen: pictures don't have a bug yet, but i'd want to target 3.2 < tristan> I have another one, add "always-show-arrow" property to GtkComboBox * tristan searches bug < Company> hrm < Company> i'm wondering about hackfest impact on 3.2 < tristan> https://bugzilla.gnome.org/show_bug.cgi?id=301193 * mclasen is doing the drop-gail work as a weekend project < Company> but i suspect we can target 3.4 at the hackfest < federico> so, 3.2 in august? < jjardon> maybe the tristan work to fix GtkApplication? < federico> that's a good amount of time for the file chooser refactor < KaL> mclasen: touchscreen related bugs, the ones I'm currently working on for the meego integration project < mclasen> KaL: good point, we should include those * mclasen will try to have a fairly complete list of things that are targeted for 3.2 in bugzilla, for a change < mclasen> I'll add 3.2 to the things mentioned here, after the meeting < mclasen> shall we talk about the 'what do we backport' topic next ? < ebassi> fine by me < mclasen> ie what about tristans optimizations < Company> i'd like to land them now < tristan> well, it makes a big difference in performance < Company> not for perf reasons < Company> but for api reasons < tristan> I've been wondering what makes things so slow < mclasen> how does the api compat story look ? < Company> people should be aware of more enum values, and they're not atm < tristan> the api story is... it's pretty compatible... I did not have to change any code that asks if (height-for-width) ... else ... < tristan> because when you query a widget gtk_widget_get_preferred_height_for_width(), and the request mode is CONSTANT_SIZE, then it becomes a get_preferred_height() internally < mclasen> that sound fairly benign < mclasen> anybody opposed to backporting that into 3.0.x ? < tristan> there is the other portion of the patch, actually < Company> related: should we add a comment to GtkSizeRequestMode that more values might be added in the future? < mclasen> do we really envision any others ? < tristan> that we should discuss a bit... which is caching of ranges < tristan> basically caching height for width 10...100 lets us avoid lots of requests over all < Company> mclasen: that's what i'm asking :) < mclasen> Company: I can't really see any others coming, but adding a warning can't hurt... < tristan> yeah... I dont think there are others... however this detail of ranges... could be a request mode I suppose < mclasen> fair point < tristan> (now that it's mentioned, I hadn't thought of that though) < Company> mclasen: we didn't envision any others for 3.0.0 either ;) < pancake> do somebody test the quartz backend? < ebassi> pancake: ask on #gtk+ < ebassi> pancake: there's a meeting in progress, right now < pancake> ok will wait :) i already asked there < pancake> im gonna prepare some pizzas < mclasen> tristan: as long as aspectframe works, I think we are pretty safe with the range optimization < mclasen> in particular if we leave open the loophole of adding an opt out enum value in the future < tristan> true < Company> if you allow more enums < Company> you just need to tell people how to handle them in their code < Company> probably by treating them the same as CONSTANT_SIZE? < mclasen> right < tristan> well if we add an opt out of caching for range, it either becomes HEIGHT_FOR_WIDTH_OPT_OUT/WIDTH_FOR_HEIGHT_OPT_OUT.. or a flag/added vfunc < Company> just mentioning that HEIGHT_FOR_WIDTH_OPT_OUT would make unported containers fall back to CONSTANT_SIZE < Company> so yeah ;) < tristan> so if we extend the enum... calling code has to change... eh not sure if that makes sense < Company> depends on how we extend it < tristan> in the odd case that you want your widget to not cache ranges of values, it doesnt mean you dont want it to be height-for-width anymore < tristan> it would work however, if the enum became some kind of mask < tristan> heh < tristan> that would break switch () cases though < mclasen> probably best if we all review the patch with an eye towards this and follow up in bugzilla ? < Company> we could version get_request_mode() and let the old versions figure out the right value to fall back to :p < Company> but yeah, bugzilla < mclasen> but I sense that the general opinion is to get the optimization into 3.0.x < mclasen> anything else on specific 3.2 bugs/features ? < mclasen> alex put in 'remove native windows' < mclasen> if we do so, we should probably remove GDK_NATIVE_WINDOWS in 3.0.3 < ebassi> jjardon already pointed out that the bug has been marked as 3.2 < mclasen> err, deprecate, Imean < mclasen> does everybody disagree with removing that env var altogether before 4.0 ? < mclasen> s/everybody/anybody/ < Company> i wanted it removed * mclasen can't type today < Company> but someone (you?) said it doesn't hurt to keep < Company> because it's so little code < Company> so i kept it < ebassi> I'd print out a warning if used < ebassi> during 3.x * mclasen has no memory of that :-) < mclasen> fair enough < ebassi> mostly because people expect it to "make old applications magically work" < Company> we have to support ensure_native() < Company> so there's not much work to just call that function immediately after creating every window < Company> if that env var is set < ebassi> though if you're porting to gtk3, then there's not much of a point < Company> but i'm all for removing it < Company> less flexibility makes for less bugs < mclasen> yeah, that seems to be the main point < Company> i'd remove it immediately though < jjardon> why no remove it in 3.0.x? if not It has to supported that at least for one cycle < Company> otherwise people go and cry "regression" < Company> if we do it in 3.0.x we can cry back "bug" < mclasen> you think they won't do that if drop it between 3.0.2 and 3.0.3 ? < mclasen> actually, I don't care much about keeping it < Company> then lets drop it now < jjardon> there is already a patch < mclasen> the patch probably misses a bit for docs < Company> i'll go and commit it < mclasen> can you fix up the docs too < Company> yeah < Company> and make it print a warning < mclasen> good < mclasen> to wrap up 3.2 discussion, I'll do a 3.0 branch later this week < jjardon> I'll try to fix the docs if nobody do it before me < mclasen> do we need to plan head for when to do 3.2.0 ? * mclasen will probably defer that until after gnome 3 is out, to reduce confusion, and to give us some time to land interesting stuff < mclasen> federico: do you envision doing file chooser refactoring work for 3.2 ? < federico> mclasen: I'd like to < federico> mclasen: the idea is more or less: < federico> - clean up the friggin code; pull out ad-hoc widgetry from gtkfilechooserdefault and create real widgets < federico> - make those widgets reusable from the outside - places tree, file list, filename entry, pathbar < federico> - see if we can make nautilus use them < mclasen> yeah, people have long wanted the pathbar to go public < tristan> nice, if I can land composite containers branch we can do filechooserdialog using builder xml to pull it all together :) < cosimoc> federico, \o/ < federico> cosimoc: should we talk about this later? you'll have ideas :) < cosimoc> federico, sure < mclasen> I promised mccann to look at his visual filechooser stuff < mclasen> that might fit in there as well < federico> mclasen: is that his patchset in #642712? < mclasen> if thats the bug, yeah < mclasen> the one where he tries to match nautilus visually < mclasen> ok, moving down the agenda... < mclasen> pictures - Company, anything to discuss on that today ? < Company> yeah < Company> i still need a name for the lib :) < Company> and i'd like to have someone to discuss the whole design with < Company> ideally in a medium that's more direct than text (phone, personal, whatever) < Company> because there's some things i'm not sure about < Company> and i don't want to just decide stuff < Company> any volunteers? * mclasen hates phones < ebassi> there's guadec, but it'll push it back to 3.4 < Company> there'd also be a hackfest < ebassi> and it's march already, so an hackfest before august would still need to happen in May/June *at most* < ebassi> and it would still be late for a 3.2 in August < ebassi> or maybe not - it depends on the cross-section of the API < Company> it's low impact in that it doesn't change anything < mclasen> can we try to boil it down to the major open questions and discuss those in text ? < Company> it's high impact if you want to force people to use it < Company> we can try < Company> but it's mostly gut feeling questions < Company> things like "do you think it's a worthwhile goal to pursue complete rendering of gtk using pictures?" < mclasen> sounds like perfectly fine thing to discuss in mail or irc... < Company> ok let's try it < Company> and unless somebody suggests an awesome name < Company> i'm probably gonna name it libpfg < federico> pictures? < Company> for googlability and TLAness < federico> (is it on gtk-devel-list?) < Company> federico: the intro mail, yeah < mclasen> libpic * federico reads < Company> federico: http://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00038.html < Company> mclasen: that gives -fpic and -lpic, and www2.cs.kuleuven.be/~ares/libpic/index.html < Company> and PicPicture sounds pretty stutterish < mclasen> libpig < mclasen> makes for a nice logo < ebassi> heh < Company> PigPicture PigPicture PigPicture < federico> Company: thanks * Company tries typing it < Company> but i like it < Company> hrm java has a pig lib < mclasen> could also go for GtkGraphics and a gg prefix < mclasen> anyway, we have 'hackfest' on the agenda still < Company> or gnome grapics < Company> not sure gg and ggv conflict though < Company> but yeah hackfest < Company> i put it on the agenda to find out if that's still on the horizon < Company> and if we have anyone thinking about it < mclasen> to do it, we need to find someone who is willing to not just think about it, but do organization < Company> and to agree on a date < Company> and a scope < mclasen> right < Company> i suspect the scope would not be glib.next, but just gtk < mclasen> its too late for this spring, realistically < Company> dunno, the only hackfest i planned happened in 2 months from "let's do it" < Company> i'm also not sure how occupied we still are with gnome 3 < ebassi> we'll probably be all pretty busy until April * mclasen has no free hours until late april < ebassi> a lot of distros and platforms release around that time < Company> so may would work? < ebassi> may/june, probably < ebassi> at least, it would work for me < mclasen> I have very slim chances of planning weeklong overseas travel with less than 90 days of notice... < ebassi> unless we do it in the US :-) < mclasen> us was not an option for some Europeans, last time I checked < Company> that will only work if the foundation got a piece of the nokia/microsoft deal i suspect < Company> or if the banshee store goes crazy < Company> june also has holidays < mclasen> taking a step back, what would the topic / agenda be ? < mclasen> do we pick something from the 4.0 agenda that we want to tackle ? < Company> i would love to sit down and do a hands-on design of animations < Company> something where we actually come up with at least header files < mclasen> ok, thats a good topic < Company> because i have the feeling if we get that too wrong < Company> we'll spend years working around problems with it < federico> steal CoreAnimation? < Company> especially if it grows organically like the current animation support in the theme seems to do < ebassi> federico: we already have it ;-p < federico> ebassi: cluttertimeline et al? < ebassi> federico: nah, those are implementation details. the implicit animation and state machine API < Company> i'd also like to see where theming is going < ebassi> federico: Clutter is much more similar to CoreAnimation than even I have ever realized < jjardon> Some notes from the last hackfest: http://live.gnome.org/Hackfests/GTK2010/RoadmapDiscussion < Company> theming both in terms of "how do we theme animations" and "what do people use the css stuff for" < ebassi> Company: as far as I can see, right now CSS3 animation support is mostly used to create crack < ebassi> Company: and a lot of people are still using javascript toolkits instead, especially because of sketchy support < ebassi> Company: but it's a good plan to look at that and take away some points from it < Company> right < Company> there's also the question of how much we want to expose for people to theme < ebassi> and especially override on a per-application basis < Company> a slide-out animation of the expander is something you cannot do with css3, or can you? < Company> (in the real world everybody does that with jquery, i know that much) < ebassi> Company: you can animate the size and color of a div using CSS < ebassi> at least, AFAIR < Company> we don't have a div for the expander though, so that might involve work in widgets < mclasen> ok, so to wrap up the hackfest topic, it doesn't seem like we have a venue or volunteer at this time < mclasen> I know Company investigated a little bit if doing it in Berlin might work < Company> mclasen: most of all we don't have a date :) < Company> mclasen: i'd skip start of june due to holidays, and then it's almost guadec (guadec is end of july i think?) < ebassi> no, mid-August < mclasen> https://www.desktopsummit.org/ < Company> so we could either do end of may - which would be hard for mclasen < mclasen> any time will be hard for me < Company> and then there's the question of doing it close to guadec < Company> to reduce the amount of travel required for overseas attendees < Company> or for anyone really * mclasen is probably going to be booked for the week before guadec < Company> and with our 3.2 schedule it likely doesn't make sense to target july anyway < mclasen> so, if we go into the 3.4 cycle, like september ? < ebassi> that sounds more feasible < Company> either that or the week after guadec < ebassi> also, at guadec we should do the usual meeting < Company> or if we keep it rather small, we can probably fit in the openismus office, and we could get might done quickly for end of may < mclasen> ebassi: of course < Company> as it seems we don't do a glib + gstreamer + gtk hackfest < mclasen> who would be interested / available for something end-of-mayish ? < Company> <-- < Company> i'd prefer it quicker both to keep the momentum we got with 3.0 and for a pictures review / animation planning session, as i do intend to work on that < mclasen> I can't really say right now, will have to check schedules here at home carefully < ebassi> same here < Company> so we'll all ask around and discuss on irc in the next days? < mclasen> so, seems like we should investigate the possibility of a smaller, shorter meeting around may/june and if that falls through, we try for after the summer ? < Company> and i'll go ask around for a location < mclasen> sounds like the best we can do right now < mclasen> and we are at the 90 minute mark anyway... < Company> sounds good < mclasen> anything for miscellaneous, before we close the meeting ? < mclasen> ok, then lets wrap it up < mclasen> thanks for coming, see you soon < ebassi> thanks everyone < ebassi> I'll send the minutes and the log ASAP