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
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.