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