Ideas for KHTML

Ideas for KHTML

Now that KDE 4.1 there is some time to think about new features again. As almost every piece of KDE the KHTML library had been heavily affected by the changes in the underlying infrastructure. The switch to Qt 4, replacement of DCOP with D-Bus, new networking code and others required adaptions (and consequently bug fixing) that did not leave much room to even think about adding new features.

We did a bit of brainstorming on the #khtml IRC channel lately. Some of the ideas that were brought up:

  • Integration with strigi to index visited sites. Together with Nepomuk this might allow some nice things later. Answering the question “Hmm. Where did I read about XYZ today?” and getting rid of temporary bookmaks would be the easiest one.
  • Hooking into Akonadi for central storing bookmarks and history
  • A “Web Desktop” based solely on KParts with KHTML being one of them. Already had a prototype running based on 4.0 that displayed desktop icons with HTML, CSS and JavaScript. Together with some KDE-specific bindings (see below) that opens the door to those that wish to customize their desktop with the only requirement being HTML and JS experience.
  • A plug-in system for adding KDE extensions like a clone of Greasemonkey. Could offer both a C++ and a scripting language API.
  • DOM bindings for languages like Python or Perl. I personally do not bother but I know that each language has its fans.
  • The JavaScript library has already become quite fast and will get faster but it’s time to improve the “developer experience” through a better debugger, a profiler and the like.
  • With KDE 4.1 containing a public KJS API I can finally continue work on bindings to KDE technology (like KIO), normal file and network I/O etc. to push JS as a desktop scripting language comparable with Python and Perl.

Keep in mind this was just some brainstorming so the ideas might be need some expert input to start making sense and become realistic.

On the topic on how to deal with syncing or merging with the WebKit sources: the importance of being able to maintain a KDE-specific code base (for features like the above) is hopefully clear to everyone by now. In which repository that happens does not play such a big role. With the rest of Qt classes like QString, QTime etc. removed from the core of WebKit it has become admittingly a bit akward to sync with it closer. But one possible approach played out nicely recently: keep the component APIs compatible. I tried that with the implementation of the HTML 5 audio and video elements (and where able to copy over the files almost 1:1) and our Google SoC student Vyacheslav Tokarev has proven the concept on a much bigger scale for backporting KDE’s SVG code: without the need of forking he integrated the code for KDE 4.2 thus allow easy syncing. Maybe that’s a feasible approach for keep the fork limited or even integrating everything into one repository. Apple developers have been very open about it at least.

Ok. Time to close. Allen and Vyacheslav will be at Akademy. The other KHTML/KJS developers have opted for coding instead of talking. I admit it’s not true: I could not sincerely ask my wife to drop our summer vacation in exchange of a KDE e.V. General Assembly spawning new working groups and rules. We have packed our stuff and will now take off to the harbour of Travemuende where a ferry will take us to my second home country Finland.