dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[koos vriezen]

2010/9/25 Albert Astals Cid <aacid at kde.org>:
> A Dissabte, 25 de setembre de 2010, Volker Krause va escriure:
>> On Saturday 25 September 2010 01:25:36 Aaron J. Seigo wrote:
>> > On Friday, September 24, 2010, John Layt wrote:
>> > Kross's JS support is 364 lines of code. if we subtract the factory class
>> > that is not KJS specific (it's Kross specific) then we have 320 lines,
>> > all in one file. it's extremely pedestrian code, and should actually
>> > shrink significantly in a move to QtScript. for someone with even
>> > moderate experience with QtScript (e.g. myself) it's a day's work.
>>
>> Kross already has a QtScript backend, so there is no need to port its KJS
>> backend at all :)
>>
>> This only really leaves KTranscript in kdelibs as something that would need
>> porting to QtScript I think, and from the Kontact Mobile POV I'd obviously
>> welcome that. We have stripped out KJS/KHTML dependencies to reduce disk
>> and memory usage for that already, the KMail message viewer is based on
>> QtWebKit, the Kross parts have been changed to use the QtScript backend
>> (which in most cases just meant renaming the files from .js to .es), and
>> we have splitted up the packages in such a way that we don't install
>> things depending KJS/KHTML by default (khelpcenter for example, which
>> doesn't really work on mobile screens anyway, but right now also
>> KTranscript).
>
> May i ask why Kontact Mobile people decided to "patch/fork" kdelibs instead of
> working on a solution?

Maybe because "patch/fork" kdelibs is a solution to port to mobile
(mobile as in pads or handset devices).

There is a very nice article on osnews (
http://www.osnews.com/story/23832/HP_Slate_vs_Samsung_Galaxy_Tab_or_Why_HP_Bought_Palm_
)
why desktop oses don't cut it on mobile.
Also see http://apidocs.meego.com/mtf/classes.html that even nokia is
building a custom ui framework on top of the Qt core classes.

Afaiks, its inevitable for KDE apps going mobile, to fork or port to
Qt based libraries completely. Not to mention that kdelibs is more or
less targeted as being a complete DE controller.

Of course this doesn't say anything whether kjs/khtml should be phased
out or not (only about the argumentation being presented).

Koos