Attachment '20091124.txt'
Download 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 Files
To 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.