dependencies on KJS/KHTML in kdelibs and kdebase-runtime

[Volker Krause]

On Saturday 25 September 2010 18:41:05 Albert Astals Cid wrote:
> 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?

not exactly sure what you are refering to, but maybe my original mail was a 
bit unclear as well. So, let me try to clarify that :)

We definitely do not want to fork kdelibs. There has been some patching of 
course, all of which happens in our work branch in branches/work/komo/. The 
branch is based on 4.5 and is necessary to isolate us from kdelibs/kdebase 
trunk changes (and potential breakage), something we can't afford with the 
tight project deadlines (this did bite us during a previous project a few 
times). However, we are merging all changes that meet kdelibs quality 
standards into trunk. In fact, by far the most of the changes for Maemo are 
in trunk already by now. Overall there weren't much changes necessary, this 
is mostly a bit of platform integration and making some dependencies 
optional. The KJS/KHTML stripping mentioned above happend largely in kdepim 
itself, and on the packaging level. I had missed KTranscript there originally 
and only became aware of it when Aaron mentioned it to me. It's loaded at 
runtime on demand and none of the language we tested with (English and 
German) uses it apparently.

Same for kdebase/runtime, although we didn't really change much there besides 
disabling components that still required Qt3Support at that point (which is 
not available on Maemo for example). Again, most of the size reduction work 
was done on the packaging level by splitting up the packages in a way that we 
can install only the minimal set of things we actually need.

For Win CE (which also is a target platform for the Kontact Mobile project) 
quite a few more changes were necessary though. They are far more intrusive 
than the Maemo changes an probably also much more controversial when it comes 
to inclusion in kdelibs trunk. On our Win CE target device we have 32M 
virtual address space per process (which includes libraries shared among all 
processes that are not loaded in the 64M shared DLL address space, of which 
we have about 8M left on a new device). This required some drastic changes 
affecting kdelibs:
- use a minimal Qt configuration (see qconfig.h), which results in lots of 
#ifndef QT_NO_FOO all over the code
- build nearly everything on top of Qt statically, including static linking of 
plugins. This results in various changes to the build system, various bits of 
code that can't handle static linking, as well as most things loading plugins
- disable large parts of the desktop ui elements in kdelibs, right now an ugly 
mess of #ifndef WINCE in code, as well as various similar changes in the 
build system.
- and btw, there is not enough space for QtWebKit in such a contrained 
environment either, so we have a simplified QTextBrowser based message viewer 
in KMail there

Which of these changes make sense for kdelibs trunk is something we still have 
to talk about, we will at least submit these changes for discussion/review. 
Right now we don't use anything from kdebase/runtime on Win CE, so no further 
changes needed there.

All changes to akonadi/kdepimlibs/kdepim are done in trunk directly, and 
that's where most of our changes are happening anyway. This includes some 
pretty nice optimizations that also affect the normal desktop apps of course, 
such as the recent 80% reduction in IMAP memory use :)

I hope that explains a bit better what we are doing :)

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100926/548320dc/attachment.sig>