Could kdecore depend on kjs?

Leo Savernik l.savernik at aon.at
Wed Mar 14 17:45:45 GMT 2007


Am Mittwoch, 14. März 2007 schrieb Chusslove Illich:
> Regarding the memory overhead when kjs is loaded/linked, should there be
> any? KJS is anyway going to be loaded by something else (Konqueror...) in
> a KDE session.

Not every KDE app is of konqueror's size. Think small helper apps like kdialog 
for which it's more important to be up and running fast to perform their 
special task than supporting kjs. Other examples are kppp, ksnapshot, 
kcolorchooser or kruler (which really rulez ;-) ).

Also, a big amount of people will never in their lives have a necessity to use 
a locale for which kjs-support is mandatory. Therefore, they should not be 
penalised with increased loading time and memory usage for every KDE 
application even if it intrinsically makes no use of kjs whatsoever.

That's why I'm much in favour of a plugin solution (and apparently not the 
only one).


Btw, there was a similar discussion regarding built-time linking of khtml to 
libthai. The author of the thai-linebreaking patch first introduced a 
build-time dependency on libthai. Given the fact that only thai users 
effectively have any need for a libthai dependency while all other users had 
to face additional loadtime and memory penalties, the author was asked to 
dynamically load libthai, which he eventually did.


This discussion isn't so much about adding a hard dependency to a specific 
small library, but about the multitude of hard dependencies that will be 
added if we don't pay attention. Even if a single small library may only 
increase loading time by 50ms, ten small libraries make a noticeable 
difference.

Kdelibs shouldn't primarily draw its power from being a sink for all sorts of 
functionality, but from being *the* interface provider whose functionailty 
and versatility may be enhanced ad infinitum by plugins and extensions.

mfg
	Leo




More information about the kde-core-devel mailing list