dependencies on KJS/KHTML in kdelibs and kdebase-runtime

koos vriezen koos.vriezen at gmail.com
Sat Sep 25 20:36:53 BST 2010


2010/9/25 Albert Astals Cid <aacid at kde.org>:
> A Dissabte, 25 de setembre de 2010, koos vriezen va escriure:
>> 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.
>
> How is "kdelibs" not a Qt based library?

Good point! I meant something like meegotouch or pure Qt, i.e. not
having to completely rewrite in say Gtk like I had to do for the n770
(of course you couldn't have known that).

Koos




More information about the kde-core-devel mailing list