On 08/15/2010 06:41 AM, Enrico Weigelt wrote: >> because loading tons of small libraries is actually going to cost >> much more in terms of resources (memory, I/O, linking and loading >> time) > Really ? did you measure it ?
Can you prove that it doesn't? Until you can, there's no logical reason to change the way GTK+ is currently done based on your say-so. To blindly experiment on a massive scale as you propose is very expensive. Most GTK+ development is, of course, volunteer-based. And what has been done works well for many, many, people and companies, embedded or no. > Well, on my system, only a few apps need gtk, and most of them only > small portions. You souldn't do the mistake of building everything > on unrealistic assumptions like gtk is only used in "typical" GNOME > environments. (otherwise it someday *will only* be used there and > and loose the all the rest of the userbase). Any change to GTK that slows GNOME down is likely going to be unacceptable, since that's where GTK+ is used the most. That said, GTK+ is being used quite nicely in a number of small, embedded environments. So is Qt, and Qt is at least as monolithic as GTK+. In any case I don't see GTK+'s size as being a problem in embedded development (yes I have done some embedded GTK+ developing in past years). >> for the past five years there has been an impressive effort in >> reducing the amount of small libraries scattered across the >> platforms - > > Yes, that's exactly why I've given up gtk+ development. I simply > dont have the spare manpower to drive everything on my own, and if I > had, I'd start afresh with different very concepts. Your comment does not logically follow. Reducing the dependency on various, small libraries makes it easier to "drive everything on [your] own." Everything is streamlined. How does forcing you to examine numerous, dependent libraries and APIs make your life any easier? If you have given up on GTK+ development, why are you still talking about it here? There are lots of other options including Qt. Sorry to sound short, but I'm not buying into your arguments. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
