Ways to opimize things.

[kde-optimize@mail.kde.org]

>  
> From: <list@jw.dyndns.org> 
> Date: 2003/01/16 Thu AM 11:09:33 EST 
> To: <kde-optimize@mail.kde.org> 
> Subject: Ways to opimize things. 
>  
> My experiense to kde is that kde needs to be smaller! 
 
Well you don't have to build the whole thing :). 
 
>  
> For example. 
> Why, does kde use arts, without it kde woud be mutch smaller. 
>  
 
It is designed to use arts.  That's the only reason I can give.  Arts presents 
a good layer to KDE so it doesn't have to rely on each system's differing 
drivers/APIs to make sound happen.  Without Arts I think KDE-Darwin sound 
would have been very difficult.  With Arts all we had to do was write the 
proper "glue" to make it call on CoreAudio APIs [which wasn't really that easy 
mostly due to lack of docs for CoreAudio]. 
 
> Other things is the kio - interface. Its great but shoud be vritten in 
> lowlevel c, put in the glibc package not in hi-level kdelibs, whoud it not 
> greate to bring up a console and type 
>  
 
KIO is great isn't it :).  Libferris does similar things and its 100% C++ code 
except for the glib and other stuff it relies on.  In fact libferris uses some 
pretty advanced stuff from Loki like garbage collected allocation....  
 
If you want stuff like KIO/libferris at the system level I suggest you run the 
GNU Hurd and mess with their translator layers... its cool stuff. 
 
GLIBC doesn't run on FreeBSD so that would be useless for KDE-FreeBSD users 
:). 
 
A lot of what you say would severely hurt the KDE design and portability.  Not 
everyone runs or wants to run linux.  Implementing stuff in C is of course 
doable and I don't think strictly prohibited but it requries a bunch of 
interesting glue code to allow C to call on C++ objects. 
 
Not too many people want to waste time writing glue.  
 
Again C++ is not inherently slow... its just more complex a language with more 
gotchas than C.  A good C programmer is not automatically a good C++ 
programmer and some C++ code can be as fast or faster than the equivalent C 
due to special features and behaviors that only happen in the C++ language. 
 
I am glad you are interested in making KDE "go faster" as we all are on this 
list but your suggestions probably won't ever happen here. 
> _______________________________________________ 
> Kde-optimize mailing list 
> Kde-optimize@mail.kde.org 
> http://mail.kde.org/mailman/listinfo/kde-optimize 
>