Re: disabling GTK+ features to shrink GTK+

[Enrico Weigelt <weigelt metux de>]

* 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.

> To blindly experiment on a massive scale as you propose is very expensive.

I don't propose any blind experiments, but at least no more additions
unless there's a damn good reasons to have it inside the current lib
instead of a new one.

For example, recent releases added several new widgets. They could
have easily been implemented in their own libs.

In the long run I imagegine a smooth way:

#1: grouping functionality into distinct modules (eg. each non-basic 
    widget will get one) and add dummy .pc files for them, telling the
    clients to use that.

#2: split off the big gtk+ library into a core library (only the really
    fundamental parts), separate per-module libraries and create a 
    (virtual) libgtk+ which pulls everything together.

#3: fix the interface specification for core and modules and then
    tell clients to migrate to using them directly (instead of the
    old big one).

> Most GTK+ development is, of course, volunteer-based.  And what has
> been done works well for many, many, people and companies, embedded or no.

Yes, I'm well aware of that. 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. I'm willing to spend a lot of resources into it again, if 
it won't be dropped away like that again.

Oh, btw: once we've got the whole thing crosscompile'able in clean
sysroot environments, I'm offering automated mass-builds and -tests
(I'm speaking of hundreds to thousands of variations), But the 
crosscompiling issue is a primary constraint for that (cannot work
w/o that, by design).

> Any change to GTK that slows GNOME down is likely going to be
> unacceptable, since that's where GTK+ is used the most.

Do you have any proof that just the number of libraries is the root
cause of a noticable slowdown ? I'd suspect other factors way more
important.

> That said, GTK+ is being used quite nicely in a number of small,
> embedded environments.

hmm, isnt v3.x going to drop directfb support ? well ...

> So is Qt, and Qt is at least as monolithic as GTK+.

Qt is even worse than 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).

Depends on how much resources your target platforms have and how much
time you'd like to spend for a target-specific trimdown.

> > 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."  

No, I was talking about the decision between splitting gtk+ or designing
toolkit w/ similar functionality completely afresh. I case of a redesign
I'd probably move away from the classical widget library approach towards
an more intelligent GUI server, where clients speak to it via 9P channels
and just describe the GUIs structure. (the actual GUI will then run in
separate processes). But that's a completely different paradigm ...

> How does forcing you to examine numerous, dependent libraries and APIs
> make your life any easier?

In the end, these APIs would be very small and state their purpose
by their name. So for example an library name "gtk-filechooser" is 
self-explaining. Yes, my application will have a lot more separate
dependencies, but I'll only have to write them down once - my build
system will know what to do then.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt metux de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------