Re: becoming embebbed

[Tim Janik <timj gtk org>]

On 30 Mar 2000, Owen Taylor wrote:

> 
> Tim Janik <timj@gtk.org> writes:
> 
> > On 30 Mar 2000, Havoc Pennington wrote:
> > 
> > > 
> > > "Chang Woo Lee(Ultracat)" <ultracat@gmate.co.kr> writes: 
> > > > how can we reduce GTK's size?
> > > > 
> > > 
> > > It should be a configure-time option:
> > >   ./configure --core-widgets-only
> > > 
> > > This would compile a smaller GTK+ if you want it.
> > 
> > there's never going to be *the* standard set of "core gtk widgets"
> > for more than one application.
> > introducing --core-widgets-only means that you have 50% users
> > complain that it doesn't include their favourite pet core widget,
> > and 50% users complain that its still to huge and GtkFooInCore
> > could not be considered a core widget.
> > the right thing to do is to move _seldomly_ used widgets (and with
> > those i mean stuff that isn't used in every-day applications, and
> > is unlikely to be found in other toolkit distributions as well,
> > like GtkRuler and GtkGamma) along with widgets that don't belong
> > into gnome-libs into a seperate library, which also may come with
> > more dependancies than gtk, and be done with it.
> > any vendor that's really going to setup gtk-based embedded devices,
> > will do his own trimming of the toolkit and other components anyways.
> 
> This has the exact same problem. (OK, I agree that GtkRuler and GtkGamma should
> get moved out of the GTK+ distro, but that is only a small saving)
> 
> But with either solution, if we split GTK+ into core widgets and non-core
> widgets, then if you want a single non-core widget, you have to pull in
> all the rest of the non-core widgets. Same problem.
> 
> What you probably want to do is something like let the user specify:
> 
>  - Which widgets get linked into libgtk.so
>  - Which widgets get their own (per-widget)libraries
> 
> The default would be everything in libgtk - fastest and simplest. But
> when space was tight, then each app could pull in exactly the 
> non-essential widgets it needed.

so you say, by default, gtk should include all gnome-libs widgets that
don't really belong there, and don't introduce further dependancies?
(i.e. if things like the canvas get pulled, we'd definitely still want
them in a package above gtk, that comes with more deps than gtk itself)

i see at least one problem here, how does app Foo that uses widget Bar
which usually comes in gtk proper, know that it has to link against an
extra library on some systems and not on others, depending on how the
user split up his gtk?

i guess the best solution so far has been presented by
dg50@daimlerchrysler.com, i.e. suggesting to let gtk form
a profile for certain applications that can be used to strip
it down for specific purposes.

another thing that hasn't really been mentioned here is, there are
quite a bunch of places in gtk and glib where we trade memory for
speed. while i don't suggest we actually trim structures to squeeze
the last byte, there's still plenty of room for optimizations in
the caching arena. i guess adding a configure option to optimize
for memory and honouring that in a couple of code portions will
have a greater impact than sorting out random widgets.


> Regards,
>                                         Owen
> 

---
ciaoTJ