[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Applets?
From:       Steffen Hansen <stefh () mip ! sdu ! dk>
Date:       1999-05-14 17:43:31
[Download RAW message or body]

On Fri, 14 May 1999, Kurt Granroth wrote:

> > From a "standard" point of view tt doesn't matter at all whether we
> > introduce a new protocol based on CORBA or a new protocol based on X11. But
> > X11 has the advantage, that we don't need Corba for the panel and all the
> > tiny applets. The unix way: use the right tools for the right job.
> > 
> > I'll try to standarize the docking protocol with Alfredo and Raster, so that
> > the same applet will work for kpanel or windowmaker or enlightment etc. 
> 
> Getting the GNOME team to agree to this should be... interesting.  You know
> how they keep pushing the fact that they are using CORBA?  Well, AFAIK, the
> *only* real uses they have for CORBA are:
> 
> 1) Applet communication with the panel
> and
> 2) Their control center
> 
> Asking them to drop CORBA from the panel will be a lot of fun..

Using CORBA also has it's advantages. For example you get shared object
plugins/applets for free. Will the X11 protocol also handle this?

General rant about CORBA bloat: 

Shared libs using MICO get _huge_. The best we can do is to only include
CORBA.h in a minimim of files. An --enable-final option would be nice
also, but it doesn't help that much. I think the problem is that g++
generates code for a lot of unused stuff from the CORBA/stl headers, and
the linker doesn't drop it at linktime because it's compiling a shared
lib. 

But that's not all. By examining a lib with objdump/nm i found that
there are large areas with virtually nothing but zero's in them. I have no
idea why it is so, but lets hope all the 0's dont get loaded into ram :)

MICO doesn't use very much ram for data. For a kded fully loaded with all
.desktop files and an empty Naming Service uses about 800KB for data. When
kded is finished the database will be a little bigger because we still
will need to store a virtual reference for each service to pass to 
the imr. The naming service will go away and be a service in a shared
object of it's own. But still, it's an 800KB lib -- stripped.

One problem with the large libs is that they increase load-time. Just
adding -lmico2.2.6 to the link line (without using anything from it) makes
apps load almost 20% slower on my system. This is really a shame :-(

Does anyone know, why C++ libs get this huge just by including CORBA.h and
a few idl generated files?

BTW: System == linux-2.2.5, egcs-1.1.2, glibc-2.1

greetings,
--------------
Steffen Hansen                              |
email: stefh@mip.sdu.dk, stefh@imada.sdu.dk,|  
       hansen@kde.org                       | ABC...VWXKZ :)
URL:   http://www.mip.sdu.dk/~stefh         | 

[prev in list] [next in list] [prev in thread] [next in thread]