dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[Albert Astals Cid]

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?

Albert