kde4 browser roadmap

[James Tyrer]

Duncan wrote:
> Aljosa Mohorovic posted on Tue, 22 Sep 2009 10:48:37 +0200 as excerpted:
> 
> 
>> so, to answer my question - there is no roadmap for kde4 default browser
>> and there doesn't seem to be any people doing any active development
>> compared to other modern browsers.
> 
> Well, I'm not a kde dev (not a dev at all, actually, tho I hang around 
> enough to speak/write a bit of the language, sysadmin level scripting is 
> about the extent of it here), but from what I read on kdeplanet, etc, 
> there's two trains of thought.  One is to continue to develop khtml 
> separately.  The other is that given the limited developer resources kde 
> has for that compared to others, and the resources it takes to do it 
> right, that's not realistic.
> 
>>From my observation the latter seems to be gaining the upper hand, if 
> only for practicality reasons.  But at this point qt/webkit, the logical 
> alternative, is simply too new and not yet as mature or familiar as khtml 
> is, so switching right now wouldn't be practical even if there wasn't any 
> nostalgic or whatever resistance to the idea.  It does seem reasonably 
> clear that's where things are headed, however, as kde is otherwise so 
> dependent on qt that with it now providing a web rendering backend, it 
> just doesn't make sense to require some other dependency for that 
> functionality, or for kde to continue building its own.
> 
> What may happen is that it'll end up working much like phonon is, with 
> kde and qt doing releases from slightly different branches of the same 
> code, alternating releases or whatever.
> 
> Anyway, that would seem to the the future web rendering road map at this 
> point, made even more so because it's so obvious, that the khtml project 
> is likely to have trouble attracting devs for what looks so much like a 
> project ultimately headed for "maintenance mode", thus reinforcing the 
> trend.
> 
> Also, as I noted, plasma, amarok (which now uses plasma) and others are 
> already using qt's webkit.  (Of course, it can be noted that asegio is a 
> Qt-software or whatever they're calling it this week employee and 
> evangalist, so perhaps it's little surprise he's using the qt version, 
> eating his own dogfood as it were.  asegio being plasma's lead dev, of 
> course.) The feel I get is that those are the first experimental steps in 
> that direction.  Any problems they have with qt-webkit integration aren't 
> going to matter as much at the non-critical level of a plasmoid, as they 
> would if kde's main web browsing functionality was centered around it.  
> But IMO it's pretty clearly just a matter of time, letting the technology 
> mature, etc.
> 
> So I wouldn't say it's entirely directionless, even if the roadmap isn't 
> formalized or officially committed to, yet.  There is one, it's simply 
> maintain khtml for the next few releases, and expect that by qt 4.6 or 
> 4.7, qt-webkit will be mature enough to take over.
> 
>> also, please note that i've been devoted kde user for years now and i'm
>> not trying to start a negative/disruptive discussion. i'm only trying to
>> start an active, constructive discussion about possible browser options
>> for kde since i think it's important.
> 
It appears that all of the alternatives have problems.

WebKit using Qt still needs work.  Will this be done now that Qt is 
being changed to community project.

Mozilla using Qt was abandoned so it is not possible to build a browser 
like Epiphany because there is no XULRunner built against Qt available.

The Gecko KPart project was abandoned.

In addition the Firefox code would need considerable work to be XDG 
compliant.

So, there is no good alternative.  I also note that it doesn't seem to 
be a simple matter to port the Gecko technology (which seems to be 
better at displaying broken websites) to KHTML.  This is unfortunate 
since Mozilla has the advantage of years of Netscape experience.

So, the best alternative appears to be to continue to develop KHTML 
unless one of the abandoned efforts is restarted, at least until 
Qt-WebKit is as good as GTK-WebKit.

I don't see how incremental development of KHTML is going to address the 
problem -- applying Gecko rendering abilities would be a big leap.

There is one thing to consider.  IE8 is stated to be W3C and ECMA 
compliant so these broken websites are going to have to be fixed up.  I 
would hope that when this is done that they would go the whole way to 
W3C compliance.  This is going to address the issue from the other side.

There is also the idea to 'shoot the moon' and develop GTK binding for KDE.

-- 
James Tyrer

Linux (mostly) From Scratch
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.