Meeting on irc.gnome.org:#gtk-devel Meeting started June 14 2004 17:06 EST (21:06 UTC) In attendence: Jonathan Blandford (jrb), Matthias Clasen (mclasen), Owen Taylor (owen), Federico Mena Quintero (federico), Soeren Sandmann (ssp), Anders Carlsson (andersca), Manish Singh (yosh), John Ehresmann (jpe), Robert Ögren (roboros), James M. Cape (Jimbob), Carlos Garnacho (garnacho), Ray Strode (halfline), Tim-Philipp Müller (tim), Sandino Flores (tigrux) should we start ? (now that jrb is here...) sorry I'm late ok, so we have almost reached the mid-june date which we set for 2.6 features... and we have quite a few prototypes in various places (libegg, bugzilla, ...) hrm. anders isn't here. I think he wanted to push forward goption and eggiconlist I guess we need to sit down at some point and make go/no-go decisions on our featurelist. Could do that next week, could do it at guadec. (Though not everybody will be there) we should probably have a gtk bof we should have a pow-wow at GUADEC anyway guadec sounds like a good occasion to do the feature sorting; gives everybody two more weeks to polish their prototypes... does anybody disagree with that ? will most of the gtk team members be at guadec ? disagree with what? mclasen: I'm guessing ~50% guadec sounds like a good occasion to do the feature sorting; gives everybody two more weeks to polish their prototypes... But GTK+ team membership is sort of a loose concept I am not 100% sure I'll be there who will be there? Jun 14 17:16:41 * federico raises his hand Jun 14 17:16:47 * mclasen raises his hand Jun 14 17:16:56 * owen raises his hand Jun 14 17:17:10 * owen raises jrb's hand since he doesn't seem to be paying attention I will be there Jun 14 17:17:22 * yosh raises his hand um Jun 14 17:17:26 * andersca raises his hand Jun 14 17:17:31 * jrb raises his hand belatedly I think that looks pretty decent. We can certainly include the remaining people via IRC... but let's make that meeting earlier, then, as 22:00 UTC is going to be food/drink time at guadec :) ok, the other item I put on the agenda is "growing the team" - I wonder whether we should try to attract some more people to become actively involved in gtk development. I came up with that item because a) I noticed a comment from Tor in a bug proposing to give cvs access to John Ehresman and b) because I noticed that we don't seem to have anybody who feels motivated/qualified to keep the linux-fb backend from bitrotting... I have someone here who is hacking on it... let me ask him federico: I just noticed linux-fb patches piling up in bugzilla... I did get CVS access; my only suggestion about growing the team is to make it as easy as possible to contribute to gtk jpe: what's preventing that, in your impression? Part of it is the size of the code base, part of it is the difficulty of building a development version on win32 federico: yo tigrux works here at novell/mexico and he's hacking with gtk-fb hi tigrux tigrux: we need someone to look at the patches for fb that are in bugzilla federico: I can test those patches, but really, I'm not an expert. having someone test patches would already help... I want to help. :) you can find linux-fb specific patches in bugzilla.gnome.org, product gtk+, component linux-fb Thanks mclasen speaking about gdk backends, I asked mitch/neo earlier today about the status of their directfb backend, and they were not optimistic about pushing it for 2.6, since it will need a lot of polishing... should we try to squeeze in some memory profiling? or some other sort of performance work? ssp: I saw that you worked on your performance/flicker patches for gdk ? Are those ready to go in HEAD, or did you uncover some new issues ? mclasen: well, *I* would be comfortable committing them ... are those the xsync patcheS? federico: I promised rambokid that I would come up with numbers for the short-circuit event signals, but I haven't gotten around to it yet andersca: yeah, and a patch to unset background in some cases, and one to predictively expose child and override redirect windows ah cool has anyone volunteered to do the icon cache ssp: oh, cool ssp: so you're waiting on another round of comments from owen ? mclasen: yeah federico: the bug is already WONTFIX'ed, so making that promise was probably over-optimistic, though ... ssp: it can't hurt to have it in... we have a bunch of signals that no one cares about (over-optimistic in the sense that nothing will probably come of it) hmm what would be the right way to do shared icon data for gtk apps? create a flat pixbuf at compile/install time and mmap() it later? federico: did you see owen's mail on the subject? andersca: owens mail was about shared index information, not shared image data, wasn't it ? right sorry, I have to leave now. ok federico: using the same format as for gdk_pixbuf_new_from_inline might work federico: I mean, that's what gtk+ does for its internal pixbufs Does anyone mind if I suggest a few features here? andersca: but gtk's are linked in, aren't they? we have to do something that lets apps change themes and still share the new icons federico: yeah, but you can pass in an arbitary pointer to _new_from_inline a little question, where/when should be the best place for suggesting new features? Meeting ended June 14 18:07 EST (22:07 UTC)