On Mon, 23 Apr 2007, Emmanuele Bassi wrote: > On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: >> On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: >>> >>> I am posting to suggest that glib has crossed a threshold >>> of size and functionality and that users would benefit from >>> a splitting of the library into two or more separate libraries. >> >> For the record, I dont think glib is oversized or bloated at >> all, I dont think its size is even a concern worth considering >> even in embedded world, that being said... > > for my experience, you're right: even GTK+ is not "bloated" in that > respect. I've seen my share of compressed filesystem images containing > the whole stack from X up to GStreamer in ~16MB, so everything could be > said about GLib but it being "bloated".
There is nothing implemented in GLib that is not useful in some way to the GTK+ stack. So I agree that the functionality is not bloat. I only suggest that the inclusion of some of this functionality in GLib has increased the scope of GLib. It's no secret that GLib-2 is <cowers> 4 times larger than GLib-1. The absolute number is still fairly small, but the change in size indicates that there is 4 times as much stuff in GLib-2. I suspect that a lot of the increase in size is due to i18n efforts in dealing with strings. And this has caused the dependency requirements of glib to grow, which makes it harder to build (think non linux platforms). I think there are developers out there who would benefit from a narrowing of the scope of glib, so that it only contains "base" data structures and functionality (yeah I know, define "base"). And move the more higher level functionality into another library. -brandon _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
