Meeting on irc.gnome.org:#gtk-devel Meeting started September 7 2004 17:03 EST (21:03 UTC) In attendence: Anders Carlsson (andersca_) Matthias Clasen (mclasen), Owen Taylor (owen), Federico Mena Quintero (federico), Billy Biggs (vektor), Soeren Sandmann (ssp_) Is everybody here ? I guess we should start... sure Does anybody have additional agenda items ? No, but I can cross off my agenda item... other than the approach to milestones? (or defer it anyways) since I ended up not getting to figuring out anything for Pango what's the plan wrt gnome 2.8? are we code-frozen right now? owen: ok, deferred isn't there a good enough version of gtk+ (2.4.9) out? good enough for gnome 2.8.0 that is federico: Well, I dont' think we are observing the freeze, but consequently we really should avoid doing another 2.4.x release before 2.8 unless we really have to (Or if we really have to, we should branch from 2.4.9 to do it) following the general plan of 4-6 weeks between stable releases, 2.4.10 would be due in early October kmaraas fixed a memory leak in the file chooser yesterday was it bad? don't know. the bug was #151985 there are worse bugs in gnome 2.8 than a file chooser leak... yes, I don't plan to do a release for that andersca_: what is the state of the icon cache footprint reduction patch which you worked on ? mclasen: ...working pretty good last I tried let me put it up somewhere http://andersca.org/patches/icon-theme-cache.diff http://andersca.org/patches/generate.tar.gz it doesn't cache pixbuf data, but that could be fixed using the gdk-pixdata stuff andersca_: thanks What about the const for gtk_check_version(), federico ? Do you still need that urgently, or is it ok to just fix that in HEAD ? mclasen: not that urgently now; they patched gtk# mclasen: I'll put it just in HEAD federico: ok, please remember to change glib HEAD accordingly ok, I have one more question. How do people feel about the PLT reduction changes that are currently in GTK+ head ? Do they work ok ? Is there a good way to hide the gtkalias.h dependencies from make ? I'm asking because I wonder whether I should do the same thing for glib/gobject haven't really measured it mclasen: A big problem is the g_return_if_fail() messages __internal_alias now owen: we could a) shorten that suffix to __ia b) try to prettify the function name by stripping the suffix mclasen: I think b) would have to be done .. even __ia is too ugly . it's actually easy for g_return_if_fail(), though we'd have to add some more functions to handle g_assert(), etc. (more functions like g_return_failed_internal) although we have to be careful to not inadvertedly mangle honest function names * mclasen considers naming the function g_return_failed_no__internal_alias so, is there a way to hide dependencies from make ? mclasen: touch -t.... maybe the script that generates gtkalias.h could check if it changed ssp_: I think the point is that a gtkalias.h change matters iff. a real header the source file is including changes the problem is that gtkalias.h includes all headers, and all source files include gtkalias.h, so if any header file is changed... everything gets rebuild and the dependency is not really necessary, since any relevant header file change should also cause a gtk.symbols change mclasen: Another relatedproblem is that include files in the C files may rot... (include statements) because all get included via gtkalias.h now ? mclasen: Yeah. but gtkalias.h is empty if visibility is not supported, so gmorten will keep the includes from rotting... i was considering to try the gmorten "correct" approach to plt reduction in glib, but it is just a lot more work... * mclasen has to leave now, sorry. I'll put the logs on the web tomorrow Meeting ended September 7, 17:56 EST (21:56 UTC)