1 < ebassi> okay, as usual: the meeting agenda is available at http://live.gnome.org/GTK%2B/Meetings
   2  * mclasen goes for coffee
   3 < mclasen> ok, shall we go ?
   4 < ebassi> fine by me :-)
   5 < mclasen> do we have anything else for the agenda ?
   6 < ebassi> I didn't receive any further point
   7 < mclasen> ok
   8 < mclasen> first one is the assistant redesign
   9 < ebassi> okay, first point: • GtkAssistant design refresh: 648136 (committed, comments still welcome)
  10 < mclasen> I landed that by now (and just found some issues with it today...)
  11 < mclasen> the one thing why this is worth discussing at all
  12 < garnacho_> I think it needs some love for the default theme, I may take care of that
  13 < mclasen> is that I had to slightly weaken our guarantees for child properties
  14 < ebassi> I saw a bug from hadess about adding titles for pages; do we need to check every Assistant use and see if the title is not set? or do should we add a fallback to avoid unnamed pages?
  15 < mclasen> so that containers can have internal structure
  16 < mclasen> the problem in hadess' bug was that the control center code was poking at the internals of hte assistant
  17 < mclasen> to make the page titles take markup
  18 < ebassi> ah, okay
  19 < mclasen> and since we've moved the internals around, that broke...
  20 < Company> "poke at the internals"?
  21 < Company> in what way?
  22 < mclasen> list all direct children, and assume that the page labels are among those
  23 < Company> ah
  24 < Company> yeah, that is supposed to break
  25 < Company> if you do things in a way that is obviously not the right way to do things but works around a missing feature, you should expect it to break in the future
  26 < mclasen> I'm slightly worried that glades assistant handling seems pretty busted
  27 < mclasen> but maybe it was so before, too ? not sure...
  28 < Company> like calling APIs reserved for containers from random code
  29 < Company> (glade is pretty broken in lots of ways anyway)
  30 < ebassi> mclasen: relaxing the child properties worries me a bit; it might happen that you start poking from a button to its grandparent :-/
  31 < mclasen> ebassi: the alternative would have been to introduce a much heavier 'composite' interface, and duplicate all the child property machinery
  32 < ebassi> mclasen: or add a GParamSpec *(* find_property) to GtkContainer?
  33 < ebassi> mclasen: then the assistant would overrid it
  34 < ebassi> override, even
  35 < mclasen> one alternative I proposed was a 'is_this_your_child?' vfunc for containers
  36 < mclasen> I think this somehow relates to tristan's ideas about composites, but I'm not sure yet how, in detail
  37 < Company> i think it boils down to protected vs public API
  38 < mclasen> anyway, I don't plan to go on a wild chase to introduce indirect-child properties all over the place
  39 < mclasen> although it would be handy in some places, e.g. response ids in dialogs
  40 < mclasen> if there is nothing else on assistants, I think we can move on; I'll keep an eye out for regressions, and hope to get cosimo/garnacho to apply some theme love to them
  41 < garnacho_> for sure :)
  42 < mclasen> next topic on the list was GtkLockButton
  43 < cosimoc> mclasen, will get to it
  44 < mclasen> I've committed that as well before 3.1.4
  45 < mclasen> the slight concern here is that this is fairly specialized
  46 < mclasen> but otherwise, it should be a straightforward widget
  47 < ebassi> not any more specialized than the GtkSwitch, or the Assistant :-)
  48 < mclasen> the only things it is missing atm is a tailored a11y implementation and a nice example in gtk-demo
  49 < mclasen> I was struggling a bit with how to add a nice example without adding a polkit dep, I may try again at some point...
  50 < mclasen> should probably move on further to the interesting topics
  51 < mclasen> the next one is certainly more interesting: GeditOverlay
  52 < ebassi> I still need to see that in action
  53 < mclasen> its what you get if you search in gedit, no ?
  54 < Company> GeditOverlay is the popup in nautilus and epiphany, no?
  55 < mclasen> yeah, it is used there too
  56 < cosimoc> nautilus uses it for the floating statusbar yeah
  57 < Company> (i'm not gonna comment on it because i think it's really crappy UI)
  58 < Company> other than that it's interesting because it stacks widgets
  59 < Company> which no other "serious" widget does
  60 < ebassi> does it use compositing or is it just stacking?
  61 < aruiz> my only concerns with it is the navigating behaviour
  62 < aruiz> it is inconsistent with firefox for example
  63 < ebassi> as soon as you tab out, it goes away
  64 < aruiz> and not very nice to navigate the results with the keyboard
  65 < mclasen> ebassi: I think it has compositing support, but turned off by default, since it was causing performance problems with scrolling
  66 < ebassi> which is also inconsistent with chrome
  67 < mclasen> I don't think the hide-on-focus-out is builtin, or is it ?
  68 < ebassi> dunno, I haven't seen the code :-/
  69 < cosimoc> I don't think it is, no
  70 < Company> why is it 2 widgets?
  71 < aruiz> ebassi, my concern is more about the usability of it than the consistency with other apps, how to navigate is not very discoverable
  72 < mclasen> Company: it isn't really; and I've commented that the child thing should probably just go away and be turned into regular child properties
  73 < Company> ah
  74 < Company> a workaround for child properties :)
  75 < mclasen> no, I think it is because they needed a window in between
  76 < mclasen> but you have just demonstrated how to do that without extra widgets in gtkpaned, as I understand...
  77 < Company> the handlebox can do without, too
  78 < Company> yeah, it should be quite simple to do with gtk_widget_set_parent_window()
  79 < ebassi> aruiz: to fully copy from chrome, you'd need to add a close button
  80 < mclasen> so, my general feeling is that we should probably take a container like this, since it seems to be a pattern that is actually used in apps
  81 < xan> mclasen: it is because of the need for a window, yes
  82 < ebassi> aruiz: that at least would allow closing it without a) tabbing out or b) pressing Esc
  83 < aruiz> ebassi, nod
  84 < mclasen> and we should probably get some more eyes on the code to get it closer what we want 
  85 < mclasen> I already did one round of review...
  86 < ebassi> mclasen: and probably, to avoid another Switch, some input from the design team
  87 < cosimoc> my feeling is that the interaction can be improved, but it belongs to the embedded widget really
  88 < ebassi> mclasen: about usage guidelines
  89 < mclasen> ebassi: good point
  90 < Company> cosimoc: it should pretty much be done manually and not be part of the overlay
  91 < Company> cosimoc: the overlay should just be about displaying the overlay widget at some given position
  92 < cosimoc> Company, yeah that's what I'm saying - the overlay could indeed offer some high-level helpers like "move on the other side on mouse hover"
  93 < Company> cosimoc: or not if its visibility == FALSE
  94 < cosimoc> but that's just about it
  95 < mclasen> the overlay also needs to handle focus, somehow
  96 < Company> yeah
  97 < Company> it needs to do the magic for this stuff
  98 < Company> probably provide some signals to hook up to
  99 < mclasen> ok, I'll try to condense this discussion into a comment on the bug - anything else on the overlay ?
 100 < mclasen> do people agree that this would deprecate gtkfixed ?
 101 < Company> no
 102 < Company> wait
 103 < Company> gtklayout is scrollable, gtkfixed isn't, right?
 104 < cosimoc> mclasen, I don't think the overlay can be assigned an arbitrary x/y
 105 < Company> but nonetheless, fixed should be deprecated (just like handlebox)
 106 < mclasen> there is a 'static' mode; just not implemented, from what I saw
 107 < mclasen> could be easily added, I think
 108 < cosimoc> mclasen, at least the copy I copied in nautilus only worked on corners...yeah not too hard to add
 109 < Company> i would use align flags for that btw
 110 < Company> use gtk_widget_get_halign (child) to layout the child
 111 < ebassi> Company: +1
 112 < cosimoc> that's a good idea
 113 < ebassi> fixed coordinates is not a great solution
 114 < ebassi> especially with resizable windows
 115 < cosimoc> that would make it more similar to clutter constraints too
 116 < ebassi> cosimoc: yeah, though I'd like to add Constraints to gtk ;-)
 117 < mclasen> yeah, not sure that fixed coords is going to be very useful
 118 < Company> and it'd make it possible for totem to use it
 119 < Company> if they'd want to
 120 < mclasen> although you already have it, kinda, with the offsets 
 121 < Company> totem could use valign end and halign center or fill
 122 < mclasen> ok, further comments in the bug ? this clearly needs a few more rounds of refinement...
 123 < ebassi> agree
 124 < mclasen> ok, the next one should be a fun topic too
 125 < mclasen> font selection dialog
 126 < aruiz> \o/
 127 < Company> i'd suspect it goes through some more blog posts
 128 < aruiz> so, I've been working on a branch to implement a design I've been discussing mostly with aday, but with input from jimmac and most recently hbons
 129 < Company> until no more UI guys comment ;)
 130 < mclasen> has anybody other than me tried th ebranch ?
 131  * Company hasn't, he only argues on irc or blogs
 132 < aruiz> I'm taking that as a no
 133 < cosimoc> I did not...some screenshots would probably be useful? :)
 134 < aruiz> Company, I implemented your idea of hiding the preview entry
 135 < aruiz> Company, with a property
 136 < aruiz> cosimoc, sure, one sec
 137 < aruiz> cosimoc, http://dl.dropbox.com/u/4524326/Screenshot-Font%20Selection.png
 138 < aruiz> so with this design, the major controversial point is what to do with the preview entry when it grows
 139 < aruiz> mclasen, suggests that it should eat the treviews space up to a maximum
 140 < ebassi> aruiz: resize the entry at the expense of the treeview
 141 < aruiz> okay
 142 < aruiz> that's a +2
 143 < Lethalman> isn't it possible to compute the maximum size of the preview?
 144 < aruiz> Lethalman, for the standard sizes, yes
 145 < mclasen> you don't want to show tiny text in a huge entry, really
 146 < aruiz> mclasen, I guess that makes sense
 147 < aruiz> most times you have sensible sizes there
 148 < ebassi> plus, you want to make sure that a) the dialog does not need resizing and b) it doesn't occupy the whole screen on netbooks
 149 < mclasen> one alternative you could try is to avoid the vertical scrollbar and go for a paned instead
 150 < mclasen> which lets you manually shrink the list to make the preview fit
 151 < aruiz> ebassi, yeah, I've designed the dialog with small screens in mind
 152 < aruiz> mclasen, I had something like that in 2.x, but the size_request behavior changed
 153 < cosimoc> aruiz, why the marks on the range?
 154 < aruiz> cosimoc, those are the standard sizes
 155 < aruiz> cosimoc, it's more convinient than a treeview
 156 < mclasen> some of the designers favor a different arrangement: http://bugzilla-attachments.gnome.org/attachment.cgi?id=187582
 157 < aruiz> and they are not critical enough to use the space of a whole treeview
 158 < ebassi> I like the slider; it's more informative than a spin button
 159 < aruiz> mclasen, I have several problems with that design
 160 < Company> mclasen: the fontselectionwidget is orientable!
 161 < Company> mclasen: :)
 162 < mclasen> more like a netbook mode
 163 < cosimoc> I like the slider too, but I think marks other than the default size don't really add anything
 164 < ebassi> it could detect the aspect ratio of the screen
 165 < aruiz> mclasen, the first one is that it scarifies horizontal space for both the treeview and the preview
 166 < ebassi> and change orientation based on that
 167 < aruiz> mclasen, the other one is that the slider will be next to the treeview's scrollbar
 168 < aruiz> very confusing
 169 < mclasen> yeah, I noticed that too
 170 < mclasen> so, lets not get hung up on this one thing
 171 < aruiz> and the relationship between the spin button and the slider is lost  in that layout
 172 < aruiz> yeah
 173 < aruiz> I mean, I'm open to suggestions
 174 < mclasen> there's some other questions that are maybe more relevant for this meeting
 175 < aruiz> but I did run through a lot of iterations with jimman and aday
 176 < aruiz> and I moved over stuff to C when there was some consensus in gnome-design
 177 < mclasen> such as the deprecated old apis, and code to support them
 178 < aruiz> yes
 179 < aruiz> So I deprecated the accessors to the old treeviews, but still implemented them to work alongside the new UI
 180 < mclasen> I guess there's two questions here:
 181 < mclasen> if they give you a treeview thats not actually shown, is that cheating ?
 182 < aruiz> mclasen, yes :P
 183 < mclasen> and is that going to be useful for whatever use people might have for those accessors ?
 184 < ebassi> I do wonder if somebody is actively using those
 185 < cosimoc> aruiz, so you create a treeview on the fly that mimics the old behavior?
 186 < aruiz> cosimoc, yeah, there's some signal spaghetti involved, but yes
 187 < mclasen> would it not be more straightforward to just return NULL ?
 188 < ebassi> because I honestly can't see the point in accessing the treeview of a composite widget
 189 < aruiz> ebassi, AFAIK, none
 190 < ebassi> we don't allow that for GtkFileChooserWidget
 191 < Company> mclasen: depends on your goal - NULL would break apps
 192 < aruiz> I searched through codesearch
 193 < aruiz> and found nothing but bindings
 194 < ebassi> (even though people begged us to do that)
 195 < mclasen> Company: assuming any apps use these apis
 196 < Company> mclasen: yes
 197 < ebassi> I'd return NULL, and if apps break then we can fake it
 198 < Company> mclasen: but if we break it anyway, we could just remove the API
 199 < mclasen> the obvious alternative would be to leave the old fontsel in place, and put a new api next ot it
 200 < aruiz> honestly, I though you guys would yell at me if I returned NULL
 201 < mclasen> but then people have to port
 202 < aruiz> :-)
 203 < Company> mclasen: and claim it was a bug we left it in for 3.0
 204 < ebassi> Company: bindings are more resilient against NULL than against a missing symbol
 205 < Company> ebassi: true
 206  * aruiz is happy to maintain that code
 207 < Company> ebassi: we could also just return the font list tree view -.-
 208 < ebassi> mclasen: GtkFontChooser?
 209 < cosimoc> I think I would like better having a new widget altogether
 210 < cosimoc> that leaves no room for misunderstandings
 211 < Company> yeah
 212 < Company> doing subtle things leads to subtle bugs
 213 < aruiz> that would be two new widgets or just one?
 214 < aruiz> I mean
 215 < Company> i know from GtkLabel::width-chars
 216 < aruiz> GtkFontChooser + Dialog
 217 < ebassi> aruiz: GtkFontChooserWidget and GtkFontChooserDialog
 218 < mclasen> aruiz: it would be 2, I think
 219 < aruiz> or would GtkFontSelectionDialog use FontChooser underneath?
 220 < ebassi> aruiz: like GtkAppChooser, GtkRecentChooser and GtkFileChooser
 221 < Company> gtk_font_selection_dialog_get_apply_button()
 222 < ebassi> aruiz: no, I'd deprecate GtkFontSelection*
 223 < Company> we do have awesome apis...
 224 < aruiz> okay
 225 < ebassi> aruiz: like we deprecated GtkFileSelection*
 226 < aruiz> Company, yeah, I thought the same thing :P
 227 < Company> ebassi: +1
 228 < aruiz> okay
 229 < mclasen> ok, so we all think that that is better ?
 230 < mclasen> cool
 231 < aruiz> you guys tell me what to do, I have no strong opinions in this regard
 232 < mclasen> it does mean that apps need to be ported, but that should not be hard, I assume
 233 < Company> we can then reuse the "selection" term when we deprecate the cooser widgets
 234 < mclasen> aruiz: I hope you don't mind the extra work
 235 < aruiz> mclasen, I'll cry a little bit for the few afternoons I spent on the deprecated stuff, but that's about it :-)
 236 < aruiz> I'm fine with it
 237 < Company> aruiz: you now have full freedom in redesigning the API
 238 < Company> aruiz: so i'd throw out everything that people don't need :)
 239 < mclasen> that is an added benefit, indeed
 240 < ebassi> just make it small :-)
 241 < mclasen> and we probably do want some extra apis
 242 < aruiz> ebassi, yeah
 243 < mclasen> like app-provided filtering (monospace !)
 244 < aruiz> mclasen, the monospaced filter
 245 < ebassi> and, for god's sake: no poking at internals!
 246 < aruiz> mclasen, app-provided?
 247 < aruiz> with some sort of filtering function?
 248 < mclasen> as opposed to by-the-user
 249 < aruiz> ebassi, absolutely
 250 < mclasen> like a little brother of GtkFileFilter
 251 < Company> i suppose that's easy - gboolean (* FontFilter) (PangoFontSomething *font, gpointer data);
 252 < aruiz> mclasen, is that a requirement for an eventual merge?
 253 < mclasen> no
 254 < mclasen> just something to keep in mind
 255 < aruiz> I will, definitively
 256 < Company> mclasen: GtkFileFilter sucks, don't use that...
 257 < ebassi> a simple function would do
 258 < mclasen> now that we gave aruiz enough to do for the next week, we should probably move on...
 259 < ebassi> we don't need mime type or regexp
 260 < mclasen> quite a few more things on the agenda
 261 < aruiz> yup
 262 < ebassi> right, next up: GProperty
 263 < mclasen> gproperty ? I lost track of the developments there
 264 < mclasen> whats the latest ?
 265 < ebassi> I have a v0.2 which bypasses GValue and adds some API that makes Company happy :-)
 266 < ebassi> missing docs+examples, a bunch of cosmetic fixes, a GVariant variant, and locking
 267 < mclasen> ok
 268 < Company> i mainly added it to the list
 269 < Company> so that everybody is aware of it
 270 < ebassi> it's on a branch on git.gnome.org now
 271 < Company> i expect that ebassi, me and whoever is interested will review it
 272 < ebassi> so people can check it out (though I rebase it quite often)
 273 < mclasen> anything to discuss there today ? or just ongoing in bz ?
 274 < Company> and then merge it when we're happy
 275 < mclasen> sounds good to me
 276 < Company> and then port gtk
 277 < mclasen> although we probably need to hire janitors at some point
 278 < Company> and other stuff
 279 < mclasen> we are already behind on the latest property technology in gtk
 280 < Company> to make sure it really works how we imagined it
 281 < Company> what are we missing in gtk?
 282 < mclasen> the pspec array stuff
 283 < ebassi> mclasen: the nice part is that changing this + array of paramspecs is a single job
 284 < ebassi> since it integrates nicely, and both touch the same code
 285 < mclasen> that is nice, indeed
 286 < ebassi> but yeah, it'll need some of the old jjardon magic :-)
 287 < mclasen> I'll look at v2 when this gnome release is behind me
 288 < mclasen> does it still do the atomic stuff, or did you drop that ?
 289 < Company> while we are at announcing stuff
 290  * aruiz is in the same room that the so called janitor
 291 < Company> i should probably announce the pending css parser merge
 292 < Company> especially now that garnacho_ listens
 293 < mclasen> good point
 294 < Company> so for anybody not aware of it:
 295 < ebassi> mclasen: I didn't drop the API, just the implementation; I actually added API for overriding the lock/unlock primitives
 296 < Company> i've a rewrite of the css parser that does not use GScanner and conforms closer to css
 297 < Company> *css parsing rules
 298 < ebassi> mclasen: I'll work on the default implementation along with the rest of the fixes
 299 < mclasen> makes sense, I guess
 300 < Company> the main reason is that i want proper error handling with line numbers
 301 < Company> and long term i want to get to making css work properly with inherit etc
 302 < jjardon> ebassi: give me the first patch ;)
 303 < Company> i'm doing that with cosimoc
 304 < Company> so if anyone wants to provide input there, it's in gnome git, the parser branch
 305 < mclasen> I will, after 3.1.1
 306 < mclasen> I don't have a ton of time today, so let rush the deprecation topics, if you don't mind...
 307 < ebassi> sure
 308 < mclasen> there's various: h/v variants, table/box, misc/alignment and color
 309 < ebassi> my take: yes, yes, yes and yes :-)
 310 < mclasen> not sure there is too much to discuss here, even
 311 < cosimoc> box is going to be huge
 312 < Company> question is how quickly we want to deprecate it
 313 < mclasen> I did merge tristan's rgba textview patch, so we are much closer on gdkcolor
 314 < mclasen> box is not really realistic for 3.2, I think
 315 < jjardon> links to the bugs in http://live.gnome.org/GTK+/Meetings
 316 < Company> yeah, color should go asap
 317 < jjardon> cosimoc: yeah, thats the most difficult task
 318 < mclasen> the others are much easier
 319 < Company> color just requires someone doing the work
 320 < Company> misc should go asap, too
 321 < mclasen> what exactly is left in gdkcolor ? just style properties ?
 322 < ebassi> misc and alignment should just go
 323 < jjardon> Company: I'm sending patches to the bug to review. Thanks mclasen btw
 324 < Company> mclasen: i think it's just the API
 325 < Company> mclasen: style properties should all be rgba by now
 326 < ebassi> one thing for Box would be a nice migration chapter, with examples for each setting
 327 < ebassi> and screenshots
 328 < mclasen> there's some leftovers like link colors
 329 < Company> damn
 330 < jjardon> mclasen: the link colors
 331 < ebassi> those are pretty trivial
 332 < mclasen> ebassi: yep, that would be of utmost importance
 333 < Company> and we can't change that i guess because of API stability?
 334 < ebassi> it's just two: link and link-visited, AFAIR
 335 < mclasen> the thing is that nobody really uses style properties as api
 336 < Company> there might be subclasses?
 337 < mclasen> they are just set in css (where we parse whatever) and used inside gtk
 338 < jjardon> bug here: https://bugzilla.gnome.org/show_bug.cgi?id=648989
 339 < Company> i'd like to move a bunch of properties around fwiw
 340 < ebassi> you cannot set style properties directly anyway
 341 < Company> and i'm not yet sure how to do that without breaking API
 342 < mclasen> what kind of properties ?
 343 < Company> ebassi: but style_get (widget, "link-color", &gdk_color, NULL) will break...
 344 < ebassi> you can mark properties as deprecated
 345 < Company> mclasen: big thing is merging style properties and style context properties or whatever they are named
 346 < mclasen> Company: we can add a rgba property next to it, deprecate the original, and keep them in sync
 347 < mclasen> but yeah, just phasing out style properties altogether might be better
 348 < Company> mclasen: that's kinda ugly in the css though, we'd need special cases there...
 349 < Company> should link-color be using :visited or some generic state flag?
 350 < Company> or is :visited too css specific?
 351 < Company> also: it's probably something not for this meeting
 352 < mclasen> sounds like a nice idea, actually
 353 < ebassi> :active, :hover, :visited
 354 < ebassi> would be nicer using pseudoclasses like that
 355 < mclasen> yeah, so: anything else on deprecations ? it seems jjardon is working on it, and I will try to do some work on the migration docs too
 356 < mclasen> if not, I'd like to close the meeting and run off, unless there's misc items to bring up
 357 < ebassi> not here
 358  * mclasen has one himself
 359 < jjardon> yeah
 360 < jjardon> what about the new website?
 361 < mclasen> I haven't followed that, tbh
 362 < ebassi> jjardon: I think the person that was working on that disappeared or something
 363 < ebassi> we'll have to poke martyn again
 364 < mclasen> there was a mail from martyn today
 365 < mclasen> where he said 'I'll migrate it shortly'
 366 < ebassi> oh, cool
 367 < jjardon> oh, ok, I didnt see that
 368 < mclasen> sent 3 hours ago
 369 < mclasen> I wrote an initial patch for hiding focus rectangles
 370 < mclasen> when not doing keynav
 371 < mclasen> the designers wanted something like that to reduce clutter
 372 < cosimoc> mclasen, how do you detect if we're doing keynav or not?
 373 < mclasen> it is somewhat limited, but maybe people want to give it a try anyway
 374 < mclasen> I just show the rectangles when any key event comes in
 375 < ebassi> mclasen: do you have a bugref?
 376 < mclasen> no good way to discriminate between e.g editing in an entry and 'keynav' per se
 377 < cosimoc> mclasen, ah so it's hidden by default and activated after the first keypress
 378 < mclasen> https://bugzilla.gnome.org/show_bug.cgi?id=649567
 379 < ebassi> thanks
 380 < mclasen> yeah, I tried to be smart and inherit the initial value from a transient parent
 381 < mclasen> but what you would really need is to pass not just a timestamp along, but the entire event, when activating a window/application
 382 < mclasen> so you could see if it was activated 'by keynav'
 383 < jjardon> about GtkBox -> GtkGRid transition, what do you think about set a GnomeGoal / GtkGoal as seems a huge work but that can be done for new contributors?
 384 < mclasen> I think we need the docs first, before such a goal can make any sense
 385 < mclasen> also, I just found what looked like some issues with nested grids today
 386 < Company> yeah
 387 < Company> i'm not sure how expand flags should really work yet
 388 < mclasen> so maybe not quite ready for widespread conversion yret...
 389 < Company> and i don't think hp is either...
 390 < jjardon> mclasen: sure
 391 < mclasen> sorry, I have to go now. Thanks everybody !
 392 < mclasen> see you sometime soon
 393 < jjardon> see you!
 394 < ebassi> thanks everyone for attending
 395 < ebassi> as usual, minutes will be sent to the list ASAP, and log will be on the wiki
 396 < ebassi> next meeting in two weeks, if everyone is alright with that