Re: disabling GTK+ features to shrink GTK+

[Paul Davis <paul linuxaudiosystems com>]

On Mon, Aug 16, 2010 at 9:22 AM, Enrico Weigelt <weigelt metux de> wrote:
> * Michael Torrie <torriem gmail com> schrieb:
>
>> 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.
>
> There're a lot of other reasons for smaller libraries, for example
> reducing memory footprint, easier systems maintenance (smaller libs
> normally mean less changes, since many of them will be done elsewhere),
> easier code review (less code to look at per iteration), etc, etc.

you don't appear to understand how virtual memory interacts with
dynamic library linking, which
means, fundamentally, that your point about smaller memory footprint
is just wrong. it would appear
that you think that because an application has a library mapped into
its address space that its memory
footprint just grew by the size of the library.

its also been explaned to you how creating a massively variable
configuration for "GTK"
actually increases the maintainance load. you might feel otherwise,
but i'm going to give
the benefit of the doubt to the people actually doing the current
maintainance task. there
may be some ideal world in which every single GTK widget is its own
self contained module along
with a "core", but that isn't the codebase we have right now, and
there are much, much, much
more important things than this going on with 3.0 that are attracting
most of people's attention.

given this, when i read you saying:

> I had done some works on gtk+ (especially
> for clean crosscompiling, trimmed-down builds, etc) several years ago
> but gave up due contigious frustration - nobody even listened to my
> arguments.

it doesn't seem so suprising to me.