1 < ebassi> as usual, the agenda is available here: http://live.gnome.org/GTK+/Meetings
   2 < ebassi> I'll paste the relevant points
   3 < jjardon> hello all
   4 < ebassi> • 3.2 planning
   5 < ebassi> • GtkFileChooser refactoring
   6 < ebassi> • Delete GDK_NATIVE_WINDOW
   7 < ebassi> • Pictures library
   8 < ebassi> • Next hackfest
   9 < ebassi> • Miscellaneous
  10 < ebassi> if there are last minute additions, feel free to point them out now :-)
  11 < 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
  12 < ebassi> right on time :-)
  13 < tristan> last minute addition: height-for-width optimizations... and can we land them in 3.0
  14 < tristan> or, 3.0.x
  15 < mclasen> yeah, tight scheduling...
  16 < ebassi> right, first item on the agenda: 3.2 planning
  17  * mclasen goes to look for an agenda
  18 < ebassi> which I guess also touches what can we add during 3.0.x
  19 < mclasen> ok, who drives today ?
  20 < Company> jjardon: i remember people not wanting to remove the native windows stuff when i suggested it in rendering-cleanup
  21  * mclasen takes the helm
  22 < mclasen> so 3.2 planning
  23 < mclasen> I've started to mark sbugs for 3.2
  24 < tristan> what is the 3.2 time frame ? is it a quick release or a normal 6 month thing ?
  25 < jjardon> reference: https://bugzilla.gnome.org/buglist.cgi?quicksearch=target:3.2+product:gtk+
  26 < mclasen> gnome 3 is going with 3.0.x
  27 < mclasen> so my preference would be to treat 3.2 as a normal 6 month cycle
  28 < mclasen> aiming for gnome 3.2 inclusion
  29 < mclasen> any other opinions on timeframe ?
  30 < tristan> I think that's fine, was just curious
  31 < mclasen> ok
  32 < mclasen> 6 months would put us in ~August
  33 < tristan> I'll have some free time and I'll want to give another shot at my pet: composite-containers
  34 < Company> what's that?
  35 < mclasen> ok, next for 3.2 planning is branching
  36 < tristan> Company, it's the thing that lets you define a composite widget class using gtkbuilder input
  37 < Company> ah
  38 < mclasen> I propose to that this week, so that we can start to review and land the rgba work, and the hfw optimization, etc
  39 < Company> tristan: i was worrying it involved gdk_window_set_composited() :)
  40 < tristan> no no
  41 < Company> mclasen: yeah, i prefer branching rather sooner than later, too
  42 < mclasen> I think we got the bulk of fixes into 3.0.2
  43 < tristan> mclasen, you want to postpone the hfw optimizations to 3.2 ?
  44 < 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
  45 < mclasen> except for cosimo who stays behind to fix up toolbar theming :-(
  46 < mclasen> tristan: I think thats still up for dicussion
  47 < tristan> sure, ok, leave it for after
  48 < mclasen> ok, more 3.2 planning: does the list of bugs match reality ?
  49 < mclasen> or is there other stuff people want to target for 3.2 / are working on ?
  50 < Company> mclasen: pictures don't have a bug yet, but i'd want to target 3.2
  51 < tristan> I have another one, add "always-show-arrow" property to GtkComboBox
  52  * tristan searches bug
  53 < Company> hrm
  54 < Company> i'm wondering about hackfest impact on 3.2
  55 < tristan> https://bugzilla.gnome.org/show_bug.cgi?id=301193
  56  * mclasen is doing the drop-gail work as a weekend project
  57 < Company> but i suspect we can target 3.4 at the hackfest
  58 < federico> so, 3.2 in august?
  59 < jjardon> maybe the tristan work to fix GtkApplication?
  60 < federico> that's a good amount of time for the file chooser refactor
  61 < KaL> mclasen: touchscreen related bugs, the ones I'm currently working on for the meego integration project
  62 < mclasen> KaL: good point, we should include those
  63  * mclasen will try to have a fairly complete list of things that are targeted for 3.2 in bugzilla, for a change
  64 < mclasen> I'll add 3.2 to the things mentioned here, after the meeting
  65 < mclasen> shall we talk about the 'what do we backport' topic next ?
  66 < ebassi> fine by me
  67 < mclasen> ie what about tristans optimizations
  68 < Company> i'd like to land them now
  69 < tristan> well, it makes a big difference in performance
  70 < Company> not for perf reasons
  71 < Company> but for api reasons
  72 < tristan> I've been wondering what makes things so slow
  73 < mclasen> how does the api compat story look  ?
  74 < Company> people should be aware of more enum values, and they're not atm
  75 < tristan> the api story is... it's pretty compatible... I did not have to change any code that asks if (height-for-width) ... else ...
  76 < 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
  77 < mclasen> that sound fairly benign
  78 < mclasen> anybody opposed to backporting that into 3.0.x ?
  79 < tristan> there is the other portion of the patch, actually
  80 < Company> related: should we add a comment to GtkSizeRequestMode that more values might be added in the future?
  81 < mclasen> do we really envision any others ?
  82 < tristan> that we should discuss a bit... which is caching of ranges
  83 < tristan> basically caching height for width 10...100 lets us avoid lots of requests over all
  84 < Company> mclasen: that's what i'm asking :)
  85 < mclasen> Company: I can't really see any others coming, but adding a warning can't hurt...
  86 < tristan> yeah... I dont think there are others... however this detail of ranges... could be a request mode I suppose
  87 < mclasen> fair point
  88 < tristan> (now that it's mentioned, I hadn't thought of that though)
  89 < Company> mclasen: we didn't envision any others for 3.0.0 either ;)
  90 < pancake> do somebody test the quartz backend?
  91 < ebassi> pancake: ask on #gtk+
  92 < ebassi> pancake: there's a meeting in progress, right now
  93 < pancake> ok will wait :) i already asked there
  94 < pancake> im gonna prepare some pizzas
  95 < mclasen> tristan: as long as aspectframe works, I think we are pretty safe with the range optimization
  96 < mclasen> in particular if we leave open the loophole of adding an opt out enum value in the future
  97 < tristan> true
  98 < Company> if you allow more enums
  99 < Company> you just need to tell people how to handle them in their code
 100 < Company> probably by treating them the same as CONSTANT_SIZE?
 101 < mclasen> right
 102 < 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
 103 < Company> just mentioning that HEIGHT_FOR_WIDTH_OPT_OUT would make unported containers fall back to CONSTANT_SIZE
 104 < Company> so yeah ;)
 105 < tristan> so if we extend the enum... calling code has to change... eh not sure if that makes sense
 106 < Company> depends on how we extend it
 107 < 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
 108 < tristan> it would work however, if the enum became some kind of mask
 109 < tristan> heh
 110 < tristan> that would break switch () cases though
 111 < mclasen> probably best if we all review the patch with an eye towards this and follow up in bugzilla ?
 112 < Company> we could version get_request_mode() and let the old versions figure out the right value to fall back to :p
 113 < Company> but yeah, bugzilla
 114 < mclasen> but I sense that the general opinion is to get the optimization into 3.0.x
 115 < mclasen> anything else on specific 3.2 bugs/features ?
 116 < mclasen> alex put in 'remove native windows'
 117 < mclasen> if we do so, we should probably remove GDK_NATIVE_WINDOWS in 3.0.3
 118 < ebassi> jjardon already pointed out that the bug has been marked as 3.2
 119 < mclasen> err, deprecate, Imean
 120 < mclasen> does everybody disagree with removing that env var altogether before 4.0 ?
 121 < mclasen> s/everybody/anybody/
 122 < Company> i wanted it removed
 123  * mclasen can't type today
 124 < Company> but someone (you?) said it doesn't hurt to keep
 125 < Company> because it's so little code
 126 < Company> so i kept it
 127 < ebassi> I'd print out a warning if used
 128 < ebassi> during 3.x
 129  * mclasen has no memory of that :-)
 130 < mclasen> fair enough
 131 < ebassi> mostly because people expect it to "make old applications magically work"
 132 < Company> we have to support ensure_native()
 133 < Company> so there's not much work to just call that function immediately after creating every window
 134 < Company> if that env var is set
 135 < ebassi> though if you're porting to gtk3, then there's not much of a point
 136 < Company> but i'm all for removing it
 137 < Company> less flexibility makes for less bugs
 138 < mclasen> yeah, that seems to be the main point
 139 < Company> i'd remove it immediately though
 140 < jjardon> why no remove it in 3.0.x? if not It has to supported that at least for one cycle
 141 < Company> otherwise people go and cry "regression"
 142 < Company> if we do it in 3.0.x we can cry back "bug"
 143 < mclasen> you think they won't do that if drop it between 3.0.2 and 3.0.3 ?
 144 < mclasen> actually, I don't care much about keeping it
 145 < Company> then lets drop it now
 146 < jjardon> there is already a patch 
 147 < mclasen> the patch probably misses a bit for docs
 148 < Company> i'll go and commit it
 149 < mclasen> can you fix up the docs too
 150 < Company> yeah
 151 < Company> and make it print a warning
 152 < mclasen> good
 153 < mclasen> to wrap up 3.2 discussion, I'll do a 3.0 branch later this week
 154 < jjardon> I'll try to fix the docs if nobody do it before me
 155 < mclasen> do we need to plan head for when to do 3.2.0  ?
 156  * mclasen will probably defer that until after gnome 3 is out, to reduce confusion, and to give us some time to land interesting stuff
 157 < mclasen> federico: do you envision doing file chooser refactoring work for 3.2 ?
 158 < federico> mclasen: I'd like to
 159 < federico> mclasen: the idea is more or less:
 160 < federico> - clean up the friggin code; pull out ad-hoc widgetry from gtkfilechooserdefault and create real widgets
 161 < federico> - make those widgets reusable from the outside - places tree, file list, filename entry, pathbar
 162 < federico> - see if we can make nautilus use them
 163 < mclasen> yeah, people have long wanted the pathbar to go public
 164 < tristan> nice, if I can land composite containers branch we can do filechooserdialog using builder xml to pull it all together :)
 165 < cosimoc> federico, \o/
 166 < federico> cosimoc: should we talk about this later?  you'll have ideas :)
 167 < cosimoc> federico, sure
 168 < mclasen> I promised mccann to look at his visual filechooser stuff
 169 < mclasen> that might fit in there as well
 170 < federico> mclasen: is that his patchset in #642712?
 171 < mclasen> if thats the bug, yeah
 172 < mclasen> the one where he tries to match nautilus visually
 173 < mclasen> ok, moving down the agenda...
 174 < mclasen> pictures - Company, anything to discuss on that today ?
 175 < Company> yeah
 176 < Company> i still need a name for the lib :)
 177 < Company> and i'd like to have someone to discuss the whole design with
 178 < Company> ideally in a medium that's more direct than text (phone, personal, whatever)
 179 < Company> because there's some things i'm not sure about
 180 < Company> and i don't want to just decide stuff
 181 < Company> any volunteers?
 182  * mclasen hates phones
 183 < ebassi> there's guadec, but it'll push it back to 3.4
 184 < Company> there'd also be a hackfest
 185 < ebassi> and it's march already, so an hackfest before august would still need to happen in May/June *at most*
 186 < ebassi> and it would still be late for a 3.2 in August
 187 < ebassi> or maybe not - it depends on the cross-section of the API
 188 < Company> it's low impact in that it doesn't change anything
 189 < mclasen> can we try to boil it down to the major open questions and discuss those in text ?
 190 < Company> it's high impact if you want to force people to use it
 191 < Company> we can try
 192 < Company> but it's mostly gut feeling questions
 193 < Company> things like "do you think it's a worthwhile goal to pursue complete rendering of gtk using pictures?"
 194 < mclasen> sounds like perfectly fine thing to discuss in mail or irc...
 195 < Company> ok let's try it
 196 < Company> and unless somebody suggests an awesome name
 197 < Company> i'm probably gonna name it libpfg
 198 < federico> pictures?
 199 < Company> for googlability and TLAness
 200 < federico> (is it on gtk-devel-list?)
 201 < Company> federico: the intro mail, yeah
 202 < mclasen> libpic
 203  * federico reads
 204 < Company> federico: http://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00038.html
 205 < Company> mclasen: that gives -fpic and -lpic, and www2.cs.kuleuven.be/~ares/libpic/index.html 
 206 < Company> and PicPicture sounds pretty stutterish
 207 < mclasen> libpig
 208 < mclasen> makes for a nice logo
 209 < ebassi> heh
 210 < Company> PigPicture PigPicture PigPicture
 211 < federico> Company: thanks
 212  * Company tries typing it
 213 < Company> but i like it
 214 < Company> hrm java has a pig lib
 215 < mclasen> could also go for GtkGraphics and a gg prefix
 216 < mclasen> anyway, we have 'hackfest' on the agenda still
 217 < Company> or gnome grapics
 218 < Company> not sure gg and ggv conflict though
 219 < Company> but yeah hackfest
 220 < Company> i put it on the agenda to find out if that's still on the horizon
 221 < Company> and if we have anyone thinking about it
 222 < mclasen> to do it, we need to find someone who is willing to not just think about it, but do organization
 223 < Company> and to agree on a date
 224 < Company> and a scope
 225 < mclasen> right
 226 < Company> i suspect the scope would not be glib.next, but just gtk
 227 < mclasen> its too late for this spring, realistically
 228 < Company> dunno, the only hackfest i planned happened in 2 months from "let's do it"
 229 < Company> i'm also not sure how occupied we still are with gnome 3
 230 < ebassi> we'll probably be all pretty busy until April
 231  * mclasen has no free hours until late april
 232 < ebassi> a lot of distros and platforms release around that time
 233 < Company> so may would work?
 234 < ebassi> may/june, probably
 235 < ebassi> at least, it would work for me
 236 < mclasen> I have very slim chances of planning weeklong overseas travel with less than 90 days of notice...
 237 < ebassi> unless we do it in the US :-)
 238 < mclasen> us was not an option for some Europeans, last time I checked
 239 < Company> that will only work if the foundation got a piece of the nokia/microsoft deal i suspect
 240 < Company> or if the banshee store goes crazy
 241 < Company> june also has holidays
 242 < mclasen> taking a step back, what would the topic / agenda be ?
 243 < mclasen> do we pick something from the 4.0 agenda that we want to tackle ?
 244 < Company> i would love to sit down and do a hands-on design of animations
 245 < Company> something where we actually come up with at least header files
 246 < mclasen> ok, thats a good topic
 247 < Company> because i have the feeling if we get that too wrong
 248 < Company> we'll spend years working around problems with it
 249 < federico> steal CoreAnimation?
 250 < Company> especially if it grows organically like the current animation support in the theme seems to do
 251 < ebassi> federico: we already have it ;-p
 252 < federico> ebassi: cluttertimeline et al?
 253 < ebassi> federico: nah, those are implementation details. the implicit animation and state machine API
 254 < Company> i'd also like to see where theming is going
 255 < ebassi> federico: Clutter is much more similar to CoreAnimation than even I have ever realized
 256 < jjardon> Some notes from the last hackfest: http://live.gnome.org/Hackfests/GTK2010/RoadmapDiscussion
 257 < Company> theming both in terms of "how do we theme animations" and "what do people use the css stuff for"
 258 < ebassi> Company: as far as I can see, right now CSS3 animation support is mostly used to create crack
 259 < ebassi> Company: and a lot of people are still using javascript toolkits instead, especially because of sketchy support
 260 < ebassi> Company: but it's a good plan to look at that and take away some points from it
 261 < Company> right
 262 < Company> there's also the question of how much we want to expose for people to theme
 263 < ebassi> and especially override on a per-application basis
 264 < Company> a slide-out animation of the expander is something you cannot do with css3, or can you?
 265 < Company> (in the real world everybody does that with jquery, i know that much)
 266 < ebassi> Company: you can animate the size and color of a div using CSS
 267 < ebassi> at least, AFAIR
 268 < Company> we don't have a div for the expander though, so that might involve work in widgets
 269 < mclasen> ok, so to wrap up the hackfest topic, it doesn't seem like we have a venue or volunteer at this time
 270 < mclasen> I know Company investigated a little bit if doing it in Berlin might work
 271 < Company> mclasen: most of all we don't have a date :)
 272 < Company> mclasen: i'd skip start of june due to holidays, and then it's almost guadec (guadec is end of july i think?)
 273 < ebassi> no, mid-August
 274 < mclasen> https://www.desktopsummit.org/
 275 < Company> so we could either do end of may - which would be hard for mclasen
 276 < mclasen> any time will be hard for me
 277 < Company> and then there's the question of doing it close to guadec
 278 < Company> to reduce the amount of travel required for overseas attendees
 279 < Company> or for anyone really
 280  * mclasen is probably going to be booked for the week before guadec
 281 < Company> and with our 3.2 schedule it likely doesn't make sense to target july anyway
 282 < mclasen> so, if we go into the 3.4 cycle, like september ?
 283 < ebassi> that sounds more feasible
 284 < Company> either that or the week after guadec
 285 < ebassi> also, at guadec we should do the usual meeting
 286 < 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
 287 < mclasen> ebassi: of course
 288 < Company> as it seems we don't do a glib + gstreamer + gtk hackfest
 289 < mclasen> who would be interested / available for something end-of-mayish ?
 290 < Company> <--
 291 < 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
 292 < mclasen> I can't really say right now, will have to check schedules here at home carefully
 293 < ebassi> same here
 294 < Company> so we'll all ask around and discuss on irc in the next days?
 295 < 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 ?
 296 < Company> and i'll go ask around for a location
 297 < mclasen> sounds like the best we can do right now
 298 < mclasen> and we are at the 90 minute mark anyway...
 299 < Company> sounds good
 300 < mclasen> anything for miscellaneous, before we close the meeting ?
 301 < mclasen> ok, then lets wrap it up
 302 < mclasen> thanks for coming, see you soon
 303 < ebassi> thanks everyone
 304 < ebassi> I'll send the minutes and the log ASAP