1 < ebassi> agenda, as usual: http://live.gnome.org/GTK+/Meetings
   2 < ebassi> 1) Client-side decorations, RGBA windows [ bratsche ]
   3 < ebassi> 2) MPX awesomeness [ garnacho ]
   4 < bratsche> Hi.
   5 < ebassi> 3) Drop tear-off menu items [ jjardon ]
   6 < ebassi> 4) Implement drag (finger) and kinetic scrolling [ jjardon ]
   7 < ebassi> 5) Deprecate non-multihead API in Gdk and Gtk [ jjardon ]
   8 < ebassi> and the evergreen "miscellaneous"
   9 < mitch> yay
  10 < bratsche> garnacho isn't here yet. :(
  11 < mitch> ebassi: [action] lart garnacho
  12 < ebassi> haha
  13 < bratsche> Well, should we go ahead and get started?
  14 < ebassi> bratsche: we can start
  15 < ebassi> I'll reshuffle the minutes if Carlos joins :-)
  16 < bratsche> Okay, well.. I've got time to finish up the work I started on client-side-decorations, so I want to try to get this done and into 2.20 if possible.
  17 < mitch> retroactive scripting ;)
  18 < bratsche> I've kind of documented some of the remaining work to be done on this, but there will probably be a little unforseen fallout from switching stuff to RGBA.
  19 < jjardon> bratsche, that's great :)
  20 < ebassi> bratsche: awesome sauce :-)
  21 < ebassi> bratsche: moblin is very interested :-)
  22 < Enselic2> Have we reached the "miscelaneous" point already?
  23 < ebassi> Enselic2: no, not yet
  24 < mitch> haha :)
  25 < bratsche> For example Nautilus/gnome-bg are currently broken on this branch.  I managed to fix it so that Nautilus's background works correctly, but then the Nautilus windows' icon views look a little borked right now so that's a separate issue.
  26 < tickle> bratsche: how close is csd+csw to using a single cairo_t per expose?
  27 < jjardon> bug, webpage and git branch of Client Side Decorations here: http://live.gnome.org/GTK%2B/Roadmap
  28 < bratsche> And I talked to Evan Martin from Google about c-s-d, since Chromium is obviously doing its own thing here and they'd rather use gtk's c-s-d if possible.
  29 < bratsche> I think one of the things he was wondering about is if they can throw a Google logo in a GtkImage up into the decoration area.  My response was that they can do that with some extra effort, but I don't want to expose API for doing weird shit like that or things could quickly get out of control.
  30 < bratsche> I've got some code that builds up a region of the opaque parts of the window.  This was something owen was interested in having and exporting to the WM.  I'm not yet sure how to actually export it to the WM, so that's still something I need to figure out.
  31 < jjardon> bratsche, As you are the developer, feel free to update the "status" field ;)
  32 < kalikianatoli> bratsche, presumably using a pixbuf would be enough?
  33 < kalikianatoli> if he is mainly interested in icon handling from gtk
  34 < ebassi> bratsche: gtk_window_set_transparent_extents()?
  35 < krh> bratsche: we can create make the region an Xfixes region and set the XID of that as a window property
  36 < ebassi> bratsche: using GdkRegion
  37 < bratsche> Oh hey krh!
  38 < krh> hi :)
  39 < tickle> bratsche: how easy would the opaque/damage region detection be to implement in cairo, since that's what ssp started once upon a time.
  40 < bratsche> Yeah, so I have some code that builds up a GdkRegion by subtracting the allocations of widgets that are known to be opaque.. then it makes an Xfixes region.  I'll ping krh about how to export that Xfixes region so the WM can see it.  I've never done that before.
  41 < krh> we don't need pixel precise opaque detection though
  42 < krh> we're shooting for something like "this is my opaque content area, anything below is obscured"
  43 < tickle> krh: if it's useful enough for xlib, would other system see a benefit? (other than the obvious full screen on-top window is opaque)
  44 < ebassi> do we need something submitted to EWMH or do we care only about mutter/metacity?
  45 < bratsche> Well, owen was expecting basically "the decoration is translucent, the contents are opaque".. but I was thinking we should be a little more specific than that.  So I was traversing down the widget hierarchy and subtracting widget allocations as I go.
  46 < krh> ebassi: I think a standardized property name makes sense
  47 < kalikianatoli> ebassi, As an xfwm4 user I would prefer proper spec
  48 < krh> it's basically just a matter of agreeing of the propert name
  49 < bratsche> Would this spec block me from getting this feature into 2.20?
  50 < bratsche> What actions should I take to initiate this discussion with the right people?
  51 < ebassi> I'd prefer a spec too, but it might impact the deadline
  52 < krh> bratsche: I think it makes sense to traverse deeper
  53 < kalikianatoli> Maybe you can prefix with something? Like X- in desktop files?
  54 < ebassi> bratsche: there's the ewmh mailing list
  55 < bratsche> krh: Deeper than just widget allocations?
  56 < krh> bratsche: oh, no, I meant deeper than what owen proposed
  57 < bratsche> Oh, okay cool.
  58 < tickle> but higher than pixels ;-)
  59 < bratsche> Well I think I have that code done, except for exporting it to the WM.
  60 < bratsche> tickle: Right. ::)
  61 < bratsche> :)
  62 < bratsche> Wow, four eyes!
  63 < krh> I imagine themes will do a transparent menubar/toolbar that visually integrates with the title bar
  64 < kalikianatoli> bratsche, if you post/ file something at the wemh, could you forward the link to me?
  65 < krh> so we need to dig a little deeper that just the frame/window contents split to get a usable result in that case
  66 < bratsche> kalikianatoli: Sure, will do.
  67 < kalikianatoli> Thanks!
  68 < bratsche> Right now most WMs give you a menu with things like "move to next/prev desktop".. so to do that I expect I might have to look at importing some libwnck functionality.  Is this an important enough feature do you guys think?
  69 < bratsche> Also, drop-shadows.. I've started on some code to do this but it's still a little wonky so I haven't committed yet.
  70 < kalikianatoli> bratsche, what is the alternative to using libwnck?
  71 < bratsche> I think owen and desrt both argued against doing drop-shadows client-side, but krh was for it.
  72 < kalikianatoli> can't you simply say "please get me the menu"?
  73 < tickle> bratsche: out-of-cairo-curiousity what technique are you using for the blur?
  74 < krh> bratsche: definitely client side
  75 < bratsche> kalikianatoli: I wasn't planning to link to libwnck, but to look into how it does it and copy this functionality into gtk+.
  76 < kalikianatoli> bratsche, I'm pretty sure people will love to theme drop shadows
  77 < bratsche> tickle: For now I stole some of MacSlow's code from notify-osd.  If there are better suggestions I'm open. :)
  78 < krh> the point about avoiding the non-antialisaed edge between app and frame just moves to the frame edge if you don't do shadows client side
  79 < tickle> ah, krh help me out here! ;-0
  80 < bratsche> krh: Yup.
  81 < kalikianatoli> bratsche, Yes. So what is it that needs libwnck code?
  82 < krh> the point is to make sure the GL primitive edge is basically translucent
  83 < bratsche> kalikianatoli: Only the "send this window to the next/prev desktop" I think.  Maybe I'm wrong.
  84 < krh> which means that we need the entire window+shadow inside the texture
  85 < krh> so that the drop shadow fades to translucent towards the edge of the texture
  86 < kalikianatoli> bratsche, Hm. That would be disappointing to lose. I guess you could defer that to the next release, though
  87 < kalikianatoli> depending on how complicated that is
  88 < ebassi> bratsche: that should just be a change in a property
  89 < bratsche> tickle: I'm not a Cairo master like you guys though, so if you have other suggestions for the blur/shadow code I'm definitely open.
  90 < krh> bratsche: there's no good blur story right now
  91 < krh> for cairo, anyway
  92 < tickle> heck, I'm just trying to find a good implementation to base an api around
  93 < krh> it's doable with GL shaders
  94 < tickle> given the right h/w
  95 < ebassi> and the right driver
  96 < bratsche> krh, tickle: It seems like you only have to perform the blur once right?  Then just cache the cairo surfaces globally so each GtkWindow can tile them whenever it draws.
  97 < krh> bratsche: true, in fact the drop shadow could just be part of a pixmap
  98 < tickle> with care and [nearly] fixed shape
  99 < bratsche> Jason Smith wrote a new blur in notify-osd that is supposed to be faster and slightly less nice looking than what MacSlow wrote.  I'll take a look at his.
 100 < krh> bratsche: there's also this: http://cgit.freedesktop.org/~krh/wayland/tree/cairo-util.c
 101  * bratsche bookmarks :)
 102 < bratsche> Wicked.
 103 < krh> if you don't mind fallwing back to sw
 104  * tickle thinks along distance-from-path gradients for cairo
 105 < bratsche> This is all internal stuff too, so we can totally swap this out any time after 2.20 without changing gtk+ APIs.
 106 < krh> yup
 107 < bratsche> So lastly I just have a few small things to do: make some nicer icons for min/max/close instead of using crappy stock icons... add support for themes to change the button positions/orders... and test out doing window resizing entirely in gtk+ instead of passing control to WMs.
 108 < ebassi> was about to ask about resizing :-)
 109 < bratsche> The last thing was because mclasen said that in Metacity the contents of the window lag behind the way it is now.  This doesn't happen in compiz, and I'm not sure about mutter.. haven't tried yet.
 110 < ebassi> I remember that point from Boston
 111 < bratsche> I'll do it right after this meeting.  Should take 20-30 mins to write the code and test it.
 112 < bratsche> Otherwise, this is all I've got today for this. :)
 113 < krh> the problem with all client-side resizing is snapping to other windows and respecting struts and other desktop geometry
 114 < bratsche> Oh right.. yeah, if we do drop shadows then we need to export an Xfixes region to the WM so it knows where to snap windows.
 115 < krh> yeah
 116 < bratsche> Is this going to slow down window resizing a lot to be re-computing these regions when the window resizes?
 117 < krh> it should be much faster than the actual rendering
 118 < ebassi> okay, so the issue on csd being ready for 2.20 is mostly the region update for the WM, am I right?
 119 < tickle> should do, since the internal relationship is constant
 120 < tickle> *shouldn't
 121 < tickle> no, this is gtk+, sorry they can change
 122 < bratsche> ebassi: Yeah, I think so.
 123 < ebassi> okay
 124 < ebassi> cool
 125 < tickle> (and there is faster region code than gdkregion if you need it0
 126 < bratsche> Cool.
 127 < bratsche> Well, this is pretty much what I've got today.  I'll start committing shit to git again, and I'll email krh about helping me with exporting the Xfixes region since I don't know how that works yet. :)
 128 < ebassi> bratsche: sounds cool
 129 < krh> bratsche: please do :)
 130 < bratsche> Thanks!
 131 < bratsche> Still no garnacho. :)
 132 < ebassi> so, no garnacho (yet); can we skip to 3) Drop tear-off from GtkMenu?
 133 < ebassi> "off with their heads" said ebassi; "off with their heads" said mclasen
 134 < bratsche> heh
 135 < ebassi> let's round up to three votes in favour?
 136 < ebassi> the bug is: https://bugzilla.gnome.org/show_bug.cgi?id=597904 by the way
 137 < bratsche> "off with their heads" said bratsche
 138 < ebassi> yey, so let's get rid of this UI style from 1994 :-)
 139 < bratsche> Wicked!
 140  * jean needs to get that out of goffice too :(
 141 < pbor> as far as I am concerned, we could kill menus tout-court :)
 142 < ebassi> pbor: one step at a time ;-)
 143 < ebassi> that's the seekreet plan
 144 < bratsche> Oh noes!
 145 < bratsche> heh.. then I figure what I have to say for #5 isn't going to be well-received. :)
 146 < ebassi> okay, if nobody raises any objection, I'd say we skip to 4) finger and kinetic scrolling
 147 < ebassi> jjardon: care to explain?
 148 < krh> omg physics models!
 149 < jjardon> kinetic bug number: https://bugzilla.gnome.org/show_bug.cgi?id=601923
 150 < jjardon> kalikianatoli added support for this in midori recently, maybe this stuff could be added to gtk+
 151 < bratsche> Sounds sexy. :)
 152 < ebassi> mmh, there's also the old MokoFingerScroll that Cwiiis did for openmoko
 153 < Enselic> Is it really reasonable to patch a small part of GTK+ with touch/finger support? I think this should be handled on a bigger scale 
 154 < pbor> sound all stuff mobile-related though... I know mobile has been a big driver for gtk in recent times, but it still sounds like something that can well live in mobile specific "forks"
 155 < shaunm> is this the same kind of widget as HildonPannableArea?  i.e. you can grab anywhere inside it to flick?
 156 < ebassi> and in this case it's a well-separated widget
 157 < ebassi> could be interesting to revisit for 3.0
 158 < kalikianatoli> ebassi, I would wonder if it makes sense to support that in scrolled window itself
 159 < ebassi> kalikianatoli: well, yeah: if we decided to get it in gtk+ I'd definitely vote for adding the feature to ScrolledWindow
 160 < kalikianatoli> shaunm, yep, and you can choose whether it should just drag, or also move further
 161 < kalikianatoli> I mainly used the code because it's independent from any particular mobile toolkit
 162 < kalikianatoli> Unlike the moko or hildon analogues
 163 < shaunm> ok, so one of the quirks I noticed is that other widgets needed to be modified/subclassed so as not to consume the drags in order to work correctly inside a pannable area
 164 < shaunm> because events in gtk are handled innermost-first
 165 < shaunm> at least in hildon.  do other implementations have a less hacky way around this?
 166 < kalikianatoli> shaunm, modified for what? you still want buttons to work, or not?
 167 < shaunm> kalikianatoli: buttons are fine.  but e.g. there's HildonTextView, which is a subclass of GtkTextView with little more purpose than not using drags to select text
 168 < kalikianatoli> shaunm, Ah, now that you mention it, MicroB doesn't select unlike Midori
 169 < kalikianatoli> That's probably the same
 170 < kalikianatoli> I saw this as a feature and didn't look into :-]
 171 < kalikianatoli> But I didn't have a text view
 172 < jjardon> the code: http://maemo.gitorious.org/hildon/hildon/blobs/master/hildon/hildon-text-view.c
 173 < kalikianatoli> thanks jjardon
 174 < kalikianatoli> indeed looks like it special cases the dragging
 175 < kalikianatoli> shaunm, it doesn't look specific to pannable area, though
 176 < kalikianatoli> shaunm, Probably a property would solve this. To say whether it should select or drag
 177 < shaunm> yeah, I'm kind of wondering if gtk could have a cleaner way for parents to intercept events, without relying on the good faith of child widgets
 178 < shaunm> maybe a two-pass event propagation: top down and back up
 179 < ebassi> shaunm: just like clutter ;-)
 180 < kalikianatoli> shaunm, so you would let the child process and say "I ignore you anyway"?
 181 < kalikianatoli> I don't remember much from clutter, I only experimented a bit with it
 182 < ebassi> kalikianatoli: no, the first pass is: top-level to innermost child; the second pass is: innermost child to top-level
 183 < kalikianatoli> ah
 184 < kalikianatoli> seems like a good idea, not only for this case
 185 < ebassi> so the kinetic scroller would intercept the events before they reach the children 
 186 < shaunm> ebassi: hot damn.  I was half afraid I'd suggested something stupid.
 187 < kalikianatoli> although then you can't know if the child had a better idea of how to treat the situation
 188 < ebassi> it would imply adding a new event and doing the event chain in reverse order; then, if nothing returned TRUE, continue with the current behaviour
 189 < ebassi> kalikianatoli: there are always side effects :-)
 190 < kalikianatoli> a bit like going from not good to not good either :)
 191 < ebassi> you could handle the event and let it through anyway
 192 < kalikianatoli> but I definitely recall more than once where that would have been useful
 193 < kalikianatoli> so I would like to follow the idea if it can be done
 194 < ebassi> we added that behavioir exactly after doing the finger scrolling window on openmoko :-)
 195 < ebassi> behaviour, even
 196 < kalikianatoli> heh
 197 < bratsche> You mean 'behavior'.
 198  * bratsche runs!
 199 < ebassi> hahaha
 200 < kalikianatoli> was that the en_FR spelling? ;)
 201 < bratsche> hehe
 202 < ebassi> bratsche: we're going to rename ClutterColor to ClutterColour as well, one day ;-)
 203  * kalikianatoli always needs to remember to choose the "right" spelling in email, commits, changelogs and whatnot.
 204  * bratsche gets ready to blacklist Clutter..
 205 < bratsche> jk :)
 206 < Enselic> Ok misc: Bug 598768 -  Use recommended autoconf input name: `configure.ac'    
 207 < Enselic> https://bugzilla.gnome.org/show_bug.cgi?id=598768
 208 < ebassi> one sec
 209 < ebassi> there's still 4) Deprecate non-multihead safe API
 210 < Enselic> ok
 211 < ebassi> bratsche has an opinion on the matter that apparently we're not going to like :-)
 212 < jjardon> bug number: https://bugzilla.gnome.org/show_bug.cgi?id=547920
 213 < ebassi> Enselic: I'm adding that to the points
 214 < bratsche> Hmm?
 215 < bratsche> Oh the menu thing.. yeah, I have something to talk about when we get to "misc".
 216 < ebassi> ah, right
 217 < ebassi> so, 4) I guess blocks on mclasen and mitch having a big fight in the Thunderdome
 218 < bratsche> haha
 219 < ebassi> so we can skip to 5) Rename configure.in to configure.ac
 220 < ebassi> Enselic: that depends on mclasen
 221 < ebassi> (as well
 222 < ebassi> )
 223 < pbor> sounds good and trivial to me though
 224 < Enselic> it is
 225 < ebassi> yup
 226 < bratsche> Depends on his mood, which I guess depends on how much pain his dentist is inflicting on him right now. :)
 227 < Enselic> I have a patch ready to be pushed
 228 < pbor> when we get to misc I was wondering about an update on gdbus status, if desrt is around
 229 < ebassi> Enselic: for glib as well?
 230 < Enselic> ebassi: no, but I am willing to create one
 231 < Enselic> ebassi: I wanted to get the GTK+ patch through first
 232 < ebassi> and I'd also go through the platform libraries and see what's still using old style autotools conventions
 233 < ebassi> jjardon: this could fit in a GnomeGoal, if we wanted to be extra-evil to newcomers ;-)
 234 < kalikianatoli> Enselic, is there any compatibility issue involved in the rename?
 235 < Enselic> kalikianatoli: not any unexpected ones. for example, external scripts may rely on configure.in being present.
 236 < Enselic> so anyway, I have to clear this with mclasen?
 237 < kalikianatoli> Presumably if package maintainers do that, they check their build before upgrading anyway
 238 < bratsche> Yeah.
 239 < Enselic> ok.
 240 < jjardon> ebassi, :) autotools are a bit hard but I think is a good idea. I can create a new GnomeGoal for that if you want . Any good example to use as a model?
 241 < ebassi> Enselic: I'd say so, yes
 242 < kalikianatoli> autotools are the dream of everyone with too many free hours in the evening :-)
 243 < ebassi> jjardon: if we could come up with a template it would be interesting
 244 < bratsche> kalikianatoli, heh :)
 245 < ebassi> jjardon: clutter, cairo, glom; I guess there are projects that don't just blindly copy-and-paste
 246 < ebassi> next point...
 247 < ebassi> bratsche: ?
 248  * desrt stumbles in late
 249 < bratsche> desrt: Suckfest dude, sorry you're sick :(
 250 < jjardon> ebassi, could be added to http://live.gnome.org/GTK%2B/BestPractices when it was done
 251 < ebassi> desrt: UDS-flu?
 252 < desrt> hini
 253 < desrt> but yes.  possibly uds-related
 254 < bratsche> ebassi: Oh yeah.. okay, so I feel kind of dumb bringing this up here since I don't have code to share yet.  But it's "misc" so I figured I'd mention this as something I'm getting started on..
 255 < bratsche> desrt: Suddenly I'm even happier that I was feeling antisocial and didn't go to the big party at the end. :)
 256 < ebassi> desrt: sucks :-(
 257 < desrt> according to the doc the timing of the onset says i caught it on the plane
 258 < desrt> but uh.  this is a meeting about gtk? :p
 259 < jjardon> Is there any command to warn if old style autotools conventions are being used?
 260 < bratsche> So Ubuntu wants to do these new "application indicators", which seems to basically be exporting menus over dbus or something.  So I'm trying to push us to do the right thing and develop this into more of a generic interface in gtk+, so I started working on a general menu proxy that I hope will be usable and I can share soon.
 261 < desrt> bratsche: i was talking to vuntz.  he thinks that libgiggity is insane.
 262 < bratsche> But basically I think it could be useful for the Ubuntu indicators, for the gtk+ MacOS backend to do the top-menu thing right, and also for us to do menubar overflow right directly in gtk+
 263 < bratsche> desrt: Yeah it is. :)
 264 < desrt> you guys might have a hard sell on that particular part of your proposal
 265 < bratsche> desrt: I think so too, but nobody at work listens to me.
 266 < bratsche> Fortunately doing a general-purpose menuproxy is useful anyway.  If nothing else we can implement the top-menu for MacOS and we can do menubar overflow the way we already do toolbar overflow.
 267 < desrt> yes.  i agree with that much.
 268 < bratsche> Sorry I don't have code yet, but I'll try to have something by the next meeting.  I don't expect there's enough time to do this for 2.20, but I just figured I'd mention it here in the "misc" section.
 269 < desrt> ya.  this stuff definitely isn't 2.20
 270 < bratsche> Yup.
 271 < desrt> ted indicated that his intention is to be shipping a separate library for lucid timeframe and probably also for lucid+1
 272 < desrt> so this is a year out :p
 273 < bratsche> Yup. :)
 274 < jjardon> So is posible to implement something similar to globalmenu? http://code.google.com/p/gnome2-globalmenu/
 275 < ebassi> jjardon: it's already possible, through hacks; whether that make sense it's another matter entirely
 276 < timj> sorry to be late guys, familly... i'd actually have one "small" issue for the agenda still: #) frequent build issues with jhbuild
 277 < bratsche> jjardon: Yeah, and I was planning to go talk to the author of that at some point once I have the proxy bootstrapped better.  It's already possible to do something like that with what I've got now, but I'm trying to expand my menuproxy to be useful for menubar overflow as well.
 278 < kalikianatoli> bratsche, did you check the global menu code for that?
 279 < kalikianatoli> iirc it already exports menus via dbus
 280 < ebassi> timj: sure
 281 < kalikianatoli> oh, nevermind, I missed the last 6 lines in scrollback
 282 < jjardon> bratsche, sounds great, maybe you can get some help from globalmenu guys ;)
 283 < bratsche> kalikianatoli: Right.. what I've got now is a simple menuproxy that uses GTypeModule (thanks to mitch's tutorial for that ;), and my idea is that globalmenu could implement this GTypeModule to do their thing, and we could have an implementation for MacOS.
 284 < bratsche> It just occurred to me more recently that the proxy could be useful for menubar overflow as well, so I'd like to think some more about this before I push any code.
 285 < desrt> timj: what's the status of the gobject performance work patch?
 286 < bratsche> And class-private-data patch. :)
 287 < jjardon>  gobject performance: http://bugzilla.gnome.org/show_bug.cgi?id=585375 and class-private-data: http://bugzilla.gnome.org/show_bug.cgi?id=521707
 288 < timj> bratsche: i've looked at it last week, found it mostly good but needed to test something. which brings me to my agenda item: frequent jhbuild issues in various modules continue to keep me away from the code base
 289 < timj> i really don't have the time these days to hunt build issues in random dependency modules. i think we need someone to regularly take care of keeping things buildable on recent stock systems (e.g. ubuntu & fedora)
 290 < jjardon> I think the last issue was the use of a newer atk function, It's solved now
 291 < ebassi> timj: recent as in "latest stable"?
 292 < timj> yes
 293 < jjardon> timj, ubuntu karmic here (latest stable) and I didnt have any compilation problems, but I don't use jhbuild. What are the conflictive libraries?
 294 < pbor> does anyone else experience many problems? I performed a fedora 12 installation from scratch, installled my usual collection of post-install packages, copied over jhbuild and it built up to gedit without any problem
 295 < pbor> (and I've been doing that for years)
 296 < ebassi> I think the issues arise on the cusp between stable releases - when, e.g. F11 is not going to cut it but F12 hasn't been declared stable
 297 < ebassi> (sed Fedora with Ubuntu)
 298 < pbor> we also have http://build.gnome.org/
 299 < pbor> ebassi: that may be true if you are using system libs, but with jhbuild it is not a major issue imho
 300 < timj> pbor: which module set? the gnome one?
 301 < pbor> timj: yes, jhbuild build gedit
 302 < timj> i'll probably setup another build tree later this week after upgrading to karmic, if anyone is willing to give me a hand with possible build issues after that, that could help me to concentrate on actual bug work
 303 < pbor> timj: this is my jhbuildrc if it helps http://www.gnome.org/~pborelli/jhbuildrc
 304 < jjardon> As a side note: Do somebody know the status of GtkStyle sealing? https://bugzilla.gnome.org/show_bug.cgi?id=541136
 305 < jjardon> (and GtkRcStyle: https://bugzilla.gnome.org/show_bug.cgi?id=540392 )
 306 < bratsche> I noticed that garnacho posted a branch recently that's related to it, but I haven't looked to see if he's done further work on it.
 307 < bratsche> It's not really a sealing, since I think GtkStyle is hard to seal.  But basically a replacement for it for 3.0.
 308 < ebassi> we'll have to ask garnacho next time
 309 < ebassi> right. unless somebody else has a point to propose, should we close here?
 310 < bratsche> Sure.
 311 < pbor> I asked for a quick update on gdbus
 312 < ebassi> pbor: ah, right
 313 < bratsche> desrt, ^
 314 < ebassi> no davidz, but maybe desrt knows
 315 < jjardon> pbor, from davidz in the last meeting: The branch is basically feature complete sans some GDBusProxy surgery/fixes. Waiting for a final review
 316 < pbor> basically if it is still on track for next glib 
 317 < pbor> we have to decide if spending time on creating a dbus interface
 318 < bratsche> My magic 8-ball says, "Signs point to yes"
 319 < pbor> ok
 320 < jjardon> I think GVariant stuff is needed first
 321 < ebassi> jjardon: yep
 322 < ebassi> and that too is still pending review
 323 < bratsche> Right, but my understanding is that both are targeted at the next glib and are being reviewed.
 324 < jjardon> you can see the status of all of that here: http://live.gnome.org/GTK+/Roadmap
 325 < bratsche> And if anyone has time to help with the review I'm sure it would be greatly appreciated. :)
 326 < ebassi> more people should send reviews to the mailing list :-)
 327 < ebassi> final point: next meeting in a week or two?
 328 < kalikianafk> s/a/one
 329 < jjardon> one :)
 330 < ebassi> one week from today is 2009-12-01
 331 < kalikianafk> I suggest one week, because for instance garnacho could talk about his bits
 332 < pbor> I guess one would be good if we can get mclasen and garnacho here
 333 < bratsche> Very cool.
 334 < bratsche> Thanks for organizing things ebassi!
 335 < ebassi> if !garnacho && !mclasen skip week :-)
 336 < ebassi> thanks everyone for attending