KDE browser work team
majewsky at gmx.net
Wed Jul 1 22:23:47 BST 2009
Am Mittwoch 01 Juli 2009 23:02:39 schrieb Aaron J. Seigo:
> gathering use cases would be useful to direct feature work, but actually
> deciding what to work on and what solutions to choose is a technology
> decision and one that needs to be made based on an actual understanding of
> the technologies at hand. most users, and even most developers for that
> matter, lack the basis to make an informed decision.
I would really desire more information from the KHTML developers on that
topic. Perhaps someone has links to mailing list archives? I just can't afford
to scroll through the last two years of kfm-devel, although I'm now subscribed
there to follow the discussions there (should something happen).
By now, I only have two reliable expert opinions: (links at the end)
 Adam Treat has worked on the Webkit KPart, and complains that Konqueror is
much too much tied to the API of KHTML, and proposes to push KDE integration
of Arora as this browser is modeled around Webkit. (My fear continues that we
lose a unique selling point if our swiss knife Konqueror is not anymore the
default web browser. It was the reason why many of us started to use KDE at
the turn of the millenium. But that's a whole other story, and I might be
misguided by my emotions in this regard.)
 Vyacheslav Tokarev from the other front (KHTML) stresses that the KHTML
developers work on this code because they want to, and he notes that he
specially is not comfortable with being forced to work on Webkit.
 Aaron Seigo adds that QtWebkit does not fulfil the requirements of desktop
developers yet. Could you expand more on that point? I used neither QtWebkit
nor KHTML up to now, but I will most probably have to explain people the KHTML
vs. Webkit issues on the next booth duty.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel