[no subject]

78200 May 23  2002 libICE.so.6.3     
31672 May 23  2002 libSM.so.6.0 
702096 May 23  2002 libX11.so.6.2          
56744 May 23  2002 libXext.so.6.4         
94120 May 23  2002 libXft.so.1.1       
54336 May 23  2002 libXpm.so.4.11                
7896 May 23  2002 libXrandr.so.1.0     
18000 May 23  2002 libXrender.so.1.1  
18532 May 30  2002 libXtst.so.6.1         
42904 May 23  2002 libxrx.so.6.3 

1104500 TOTAL (or, 1078k) for X11 libs

1018576 libgtk-1.2.so.0.9.1                     
188664  libgdk-1.2.so.0.9.1
150912  gtk/themes/engines/libxeno.so.0.8

1358152 TOTAL (or 1326k) for X11 based gtk/gdk libs

There's some internationalization stuff in lib/X11, mine does japanese
and english in about 600k more

X11 Binaries

738380 Xipaq
 27224 blurt
254492 dillo
 41140 matchbox
  4940 mbcontrol
 13660 miniapm
 11612 minisys
  7848 minitime 
 10612 minivol 
  7980 miniwave
  8792 monolaunch   
 11615 xkbd 
 10002 xrandr                                                
 21004 xset                                          

1169301 TOTAL (1141k)

You wouldn't be measuring properly if you didn't count glib 1.2, too,
so:

174604 libglib.so
  8916 libgmodule.so
  7964 libgthread.so
191484 TOTAL (or, 186k)

Total size of a PDA sized GTK+/X11 distro - with a useful window
manager, virtual keyboard, web browser and tools - without fonts: 

3731k

As I wrote before, fonts are a bigger part of the size problem than the
libraries themselves - truetype fonts, in particular, are huge. And the
rest of the Linux OS overhead ain't too shabby either, in my case, over
5x the size of the graphics core. 

Got numbers for a directFB one, on arm? (glib 2.0/gtk 2.0/pango/atk/etc)

> > GTK2, which is required for DirectFB, is at least 1MB bigger than gtk
> > 1.2.10 (and requires a ton more supporting libraries as well)
> 
> and it offers a lot more functionality and much improved i18n support.
> 

At the expense of backward compatability.

> > Giving up the infrastructure of standard X + gtk 1.2 to use DirectFB +
> > gtk2 + (pango, atk, etc) strikes me as a losing proposition, at least
> > today. There are very few applications available for gtk2. Gtk2 has been
> > underperforming gtk 1.2 by as much as 5x, and DirectFB would only
> > complicate portability/reliability matters further. 
> 
> IMO you are mistaken. No new application will be developed using
> GTK+-1.2 and almost all existing applications will very soon be
> available as GTK+-2.0 applications and will continue to be developed
> on this platform. If you are building up a software environment now,
> you should try to use bleeding edge technology, otherwise everything
> you've just build up will be out-of-date as soon as it is finished.

I agree, if I was building a single application, from the ground up, I
would chose gtk 2.0 as a base. I ported one of my own apps (keytap) to
gtk2 a while back. I'm thinking about running GNOME2 on my
workstation... but:

People manufacturing a product, particularlly a heavily embedded one
such as a PDA, one that uses applications from many different sources,
cannot afford to live too far out on the bleeding edge, where their core
libraries are concerned. 

Being out of date is not such a bad thing if your support hotline isn't
lit up.

> We started to use GTK+-2.0 over a year ago since we knew that we will
> need its features and that it will be the stable GTK+ platform when
> our software reaches the stable state. 

As I recall, convergence.de (author of directfb, and many other useful
things) bet heavily on gtk 2.0 shipping on time for their line of MHP
based products. At least in part, the year+ delay in releasing gtk+2.0
put them on hiatus (effectively out of business) in september of last
year. (They recently got ressurected by being bought)

Betting the company that a given core library or application, not under
your control, will be ready for you to ship, when you need to ship, is
foolish.

While I agree that many gtk based applications will migrate to 2.0 over
the next two years, not until a wide enough ecosystem exists supporting
it and the code has been heavily debugged in the field, would I be
comfortable embedding it in a general purpose device like a PDA. If I
had to go into code freeze on a PDA in July of next year I'd consider
gtk 2.0.

In the case where I was running ONLY one application (example, MHP), at
this time I'd certainly consider gtk 2.0, and maybe even directfb. 

As an aside: Java-centric guys do bug me, I recall a conversation with
an <unnamed> MHP company (not convergence) where I asked about using
third party apps (say, a game, or mozilla) in conjunction with their
MHP. The answer - "Rewrite it in Java and use our APIs!" - was far from
satisfactory.

So, although I'm working personally with gtk 1.2 and 2.0, and have hope
that 2.0 will be useful for an OEM in the fairly near future, I'd still
be very reluctant to get away from X, over directFB - as leveraging X
gives easy - non-tool-kit-specific - access to many different
applications, written in many different languages - from many different
vendors, today. Python. Java. C. C++. To name a few.

> I can not imagine how one can
> nowadays even consider to use GTK+-1.2 for anything new.

Because it's small, stable, well documented, well understood, and has a
wide variety of off the shelf applications already available for it that
I can just use? Has working themes? A squished version with properly
sized widgets?

I think gtk 1.2 has a lot of life in it yet.

> > Also, since most handhelds today have 32MB of compressible flash (the
> > above base configuration compresses down nicely to about 14MB - and yes
> > I have a full blown mozilla running on my ipaq in less than 32MB of
> > overall flash). Moore's law still functions - capacities will double
> > again in 18 months - so, today, you'd be better off focusing on
> > shrinking off the shelf applications (gaim, abiword, skipstone, etc) to
> > fit the screen size rather than on reducing the size of the libraries
> > themselves. 

My core point remains - At the moment I'd focus on making the good open
source apps work with small screens and stylus input more than I would
worry about dropping in a lighter weight, less compatible lib like
DirectFB and a bleeding edge gtk2.0.

> We have written DirectFB with settop-boxes in mind where the typical
> flash size is about 2MB.

The settop boxes I'm seeing this year *all* have 16-32MB of flash. All
that energy spent on DirectFB that could have been spent harnessing
moore's law and focusing on fixing the applications....

> 
> 
> Salut, Sven
-- 
______________
Michael Taht			BLOG: http://the-edge.blogspot.com
Member, Visionary Staff 	MontaVista Software

"The difficulty in managing [technology] displacement threats is often 
attributed to an unwillingness to cannibalize existing technology 
investments; organizational inertia; and the inability to adopt
necessary 
skills needed to engage in the new technology." - Ron Adner