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.

19 Comments

  1. solardeity 12 years ago

    How about a Plasma UI for Netbooks, almost like ubuntu’s Netbook remix.. just based on KDE/ Plasma… That would be a great Idea.. *just wanted to release my thought, while talking about new features..

  2. Jos 12 years ago

    The JavaFX website has an eerily Plasma-like look complete with content-sensitive shrinking of the widgets.

    Have a look: http://www.javafx.com/

  3. Hmm 12 years ago

    does KDE really need active desktop? I’m pretty sure Windows 98 tried this 😐

  4. Tom 12 years ago

    The most important thing is porting more stuff from webkit. Really glad you are trying to figure that out.
    For most users having a working browser that works with Digg, gmail etc etc etc. is _THE MOST IMPORTANT_ thing (I cannot stress that enough). Nothing else matters. That is the baseline for most people .. if that is not met KHTML is absolutely worthless to them. ( I have to say it this cruel but it is the truth. Just give a young user Konqueror and watch what happens. )

    So what I want to say is, that you will have a very hard time communicating new features as long as major websites just don’t work.

    If you do not have the manpower to do it you should provide users with an easier access to webkit in some way so that they have a working browser. They can live without a lot of the KDE specific stuff. Trust me on that. There are more important things.

  5. david 12 years ago

    with Konqueror 4.x switching between KHTML and webkit is a click of an button
    via view | view mode

  6. Benoit 12 years ago

    Love the ideas about hooking to Strigi/Nepomuk/Akonadi : integration with the rest of KDE is clearly a great advantage for KHTML in the ongoing “coopetition” with/against WebKit.

  7. christoph 12 years ago

    I would love to see MathML support.

  8. cons 12 years ago

    i love all the ideas in the blogpost.

    A simple extension-api is THE keyfeature for the acceptance of konqueror. I’m a xfce-user again since I didn’t like the feeling of firefox in KDE4, even with gtk-qt enabled. If konqueror had a good/easy plugin-api, I’m sure the most used firefox-extensions would be ported/rewritten in no time.

    strigi/nepomuk/akonadi implementation would be great, too.

    A google toolbar is another thing still missing in konqueror. I know, there are other simple ways to use google from the url-field, but nothing is as comfortable as a google-toolbar.
    BTW: shouldn’t it be possible to earn money with this, just like mozilla does? Is KDE that independent, that it doesn’t need the money google could spend them? I don’t get it ^^

    Good luck with your goals,

    Cons

  9. Maciej Stachowiak 12 years ago

    As always, if there’s anything I can do to help WebKit and KHTML get more in sync, I’d love to know. I think our developers work together pretty well on a technical level and over time we can and should make the collaboration closer.

  10. mikmach 12 years ago

    Make Zoho suite working. This would test js engine and dom implementation to the extreme.

  11. jospoortvliet 12 years ago

    @ Cons: there already is a google toolbar, has been there for years, it’s a plugin. You got to install the right package and you’ve got it 😉

    Sorry, dunno the name, look for konqueror & plugins, should help you find it. It’s a pretty good plugin, too, actually.

  12. Dennis P 12 years ago

    Autotab
    I would love to see a newbie friendly usage of tabbed browsing I thought of:
    When you click a link the linktext would duplicate and travel to a new created tab.
    The link gets a orange background label indicating that the page is still loading/rendering and you should continue reading the current page.
    When rendered the linklabel goes from orange to green.
    You can click the link again to close the current page and show the fully rendered tab instantly.
    Or you may want to leave the current page open and click the tab directly, you know which tab you want because you saw the animation ‘park the link over there’.

    Tabbed browsing explained without words, it just works. The browser seems faster as you no longer look at pages being rendered.

  13. Dirk 12 years ago

    The ideas are all cool.
    Wouldn’t be a kross binding (with DOM bindings) for plugins allow to write plugins in more languages more easy?

  14. ideaman 12 years ago

    Here’s an idea for the future of KHTML: how about dropping it and merging everything you can to webkit. That’s what the very creators of KHTML have done so just swallow your ego and do it.

  15. Grósz Dániel 12 years ago

    ideaman: AFAIK they are forks so both have code that the other doesn’t. So if we don’t want to lose features, we have to merge either WebKit developments into KHTML or KHTML developments into WebKit. Which is the more feasible depends on the attitude of KHTML and WebKit developers.

  16. Sebastian Trüg 12 years ago

    You mention indexing of websites. Actually, we already do that in Nepomuk and it will be comited to trunk next week. This is what happens:

    We started out with tagging web pages. Very basic approach to a new way of handling bookmarks. You do not simply have a list of bookmarks but you annotate websites. For starters this means tagging and rating (as always) but more is in the pipeline. For example annotation of pages with people or the other way around. Or you identify a page with a project or something. We will ge there.

    Anyway, when tagging (or rating) the page will also be indexed through Strigi (without being stored locally, except for the browser cache, but we do not care for that). Thus, you can find it through all nepomuk search interfaces, such as the KIO slave for example. But it also gives the possibility for virtual bookmark folders. Well, things in Nepomuk might go slow but they progress. 😉

    Next week more with a new blog of mine.

  17. cenebris 12 years ago

    +1 for integration with akonadi/nepomuk/strigi/sonnet/google gears in konqueror please 🙂 Add storing images opera way (check images every x minutes/hours/days) and fast rewind and you have very powerful and efficient browser 🙂

    PS Akonadi should be syncable with other computers so that you have your bookmarks, history (and contacts, calendar etc.) synced like opera does and firefox soon will.

  18. Richard Dale 12 years ago

    The KHTML bindings for Python, Ruby and C# in KDE 4.1 already all include DOM bindings. I’m not sure that many people actually would want to do DOM programming in languages other than JavaScript though.

    — Richard

  19. richard, the DOM bindings are flawed, in a very subtle way, which i’m trying to get people to chase down. and yes, i seriously want to do DOM programming in languages other than javascript.

    using DOM manipulation makes for an extremely good widget _desktop set, believe it or not. see http://pyjd.org for details, which operates on top of webkit.

    i’m presently looking to port pyjamas to mozilla pydom / nsdom as well as python / khtmlpart, as a demonstration of quite how powerful and flexible DOM manipulation really is.

    pyqt4 and pygtk2 are quite limited, by comparison. can pyqt4 or pygkt2 use _full_ CSS syntax to modify the look of … a desktop app? (yes i’m aware of gtk-engine-css, being developed by rob staudinger – it’s good, but has limitations in its purpose / design).

Leave a reply

Your email address will not be published. Required fields are marked *

*