Meeting on irc.gnome.org:#gtk-devel Meeting started November 15 2004 16:05 EST (21:05 UTC) In attendence: Owen Taylor (owen), Jonathan Blandford (jrb), Manish Singh (yosh), Matthias Clasen (matthias), Tor Lillqvist (tml), Robert Ögren (roboros), Anders Carlsson (andersca), Robert Ögren (roboros), John Ehresman (jpe), Ray Strode (halfline) so, what are the issues for today ? I would like to quickly discusse the rsvg pixbuf loader problem that occurred with the threadsafety fixes in gdk-pixbuf since I have the feeling that there may be a fundamental problem there... the issue (as far as I understand) was that librsvg wants to use threads but since it uses pango, the loader has to be marked threadunsafe consequently, gdk-pixbuf locks around all calls into the loader Hmm. grepping for 'thread' in the librsvg returns empty it uses gnome-vfs mclasen: Ah. But what's the problem? reentrancy? I thought the problem is if the app itself is not threaded (ie g_threads_init() hasn't been called), the G_LOCK() in gdk_pixbuf is a no-op, but then the module initializes gnome-vfs, which initializes the thread system so the G_UNLOCK isn't a noop anymore... but I could be wrong That sounds plausible. ugh. one solution would be to add another flag, GDK_PIXBUF_FORMAT_NEEDS_THREADS mclasen: You could easily work around that ... keep a local variable when you lock. that would be better I don't think you can add the flag ... gdk-pixbuf doesn't link to gthread so can't call g_thread_init() is the svg loader making gnome_vfs calls?? I'll try the local flag approach It seems to be, in rsvg-shapes.c talking about loadable modules, owen and I moved the pixbuf theme engine into gtk today so that gtk-engines is now officially just "engines we don't care about" cool So I can file bugs about the pixbuf theme engine against GTK+? :) sure W00t. no guarantee they get fixed any faster though... vektor: if they are "produces ugly results" expect no traction. If they are "forgets to check for a NULL detail" hopefully we can get them fixed quickly I was specifically thinking of performance issues with that engine. vektor: What sort of perforance issues? It should be pretty good performing if the theme doesn't do something stupid Something stupid is basically triggering the general image scaling case owen: I'm pretty sure the "big button is slow" example was from the pixbuf theme engine. Prelight being slow for buttons, basically. vektor: It's certainly possible to get the pixbuf engine to be slow. But it's designed to be fast. when it's easy to be fast Hey jpe Sure, but you can say that about anything. :) I meant that specifically it seems like rendering prelighting is visibly slower with pixbuf-engine based themes, and that this is noticable in applications. I don't have hard numbers so it's a bit silly to discuss it now. I'll file a bug. hello vektor: Sure, sounds good. It may be a theme *file* bug rather a theme engine bug, but hard to say without knowing the theme and circumstances Sync time adjustment is 0.0392 msecs. 2400 reps @ 2.3670 msec ( 422.0/sec): ShmPutImage 500x500 square Sorry. I would like to ask again what the most important issues on the 2.6 API freeze milestone are...otherwise I will just continue to fix whatever is important/interesting to me in the next two weeks. The next gtk release in ca. 2 weeks should probably be api frozen, considering that we want to do a 2.6 release in mid december I'd like 155428, 154615, 154611 fixed. They're all small and simple. did we agree on what lower value to use for the clipboard timeout ? one minute ? owen had said that he was OK with 30 seconds. I prefer 5 seconds, of course. Either of those is much better than 5 minutes until we can get a better consensus on the whole issue, I think. for the bug about the cell background color, I wonder what the intended semantics of the GtkCellrendererText::background property are... override background color only in normal mode ? I agree it's not obvious, it's a pretty broken thing to do. However, I think a policy that selection overrides any colours unless you specifically override the selction colours on the whole tree makes sense. Since you're guarenteed to have the selection foreground and background be well contrasted. jrb: I agree that it only makes sense to use background and foreground together. jrb, what was the idea behind background ? mclasen: parity w/ GtkTextView mclasen: it used to draw a colored rectangle back there, too jrb: what about the interaction with state ? should we use the theme colors for selected cells, even if an explicit background/foreground is set ? I think selection should probably override that ok, do we have more things to discuss ? owen: any update on pango ? mclasen: No mclasen: Eugenia is going to plug the widget gallery next time we do a GTK+ release mclasen: so maybe we should spend 10 min. or so making sure it looks good nice. I'm trying to get the docs a bit more complete for 2.6 currently... we're still missing long introductions for quite a few widgets (some new ones as well) and generally, adding some more high-level/overview type things would be nice mclasen: yeah but I think the widget gallery looks pretty good currently. Did we add the complex dialogs yet ? mclasen: I was just about to suggest that. We prolly need to change the shooter to handle dialogs better mclasen: I wonder if we should organize the widgets in a non-alphabetical way I didn't notice they were alphabetical... mclasen: I think they are Nov 15 16:55:50 * jrb looks again mclasen: they're mostly alphabetical well, image is wrong mclasen: maybe we should organize it the way the overall docs are: one thing we should figure out is why the footer goes fubar on initial loading Windows/Display/Buttons and Toggles... would have to try it, not sure if it would be better/worse/different mclasen: surely it's different... (-; I have to leave now. Quick final question: is this time better for the Europeans ? Should we keep it for next week ? mclasen: yup, this is fine good, lets keep it then. yeah bye bye ciao Meeting ended November 15, 17:04 EST (22:04 UTC)