Re: disabling GTK+ features to shrink GTK+

[Michael Torrie <torriem gmail com>]

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.