Ars takes a look at the new RC2 release of KDE 4.0. "Transitions are always hard, but when the dust settles, a clean break between versions and an opportunity to introduce some innovative new ideas should lead to a stronger user experience. After years of development, unnecessary cruft builds up and things tend to get disorganized. The KDE 4 transition, though it will definitely be rocky at first, gives developers the ability to cut away the cruft and reorganize code in a manner that makes the whole environment more future-proof and easier to maintain."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-10-13
That's because half of the KDE developers have decided it's going in, and half that it's not. I've never seen the KDE community so divided over a project before. It will definitely be in Qt4.4, though, which means it will almost certainly be included some ways in KDE4.1. I think Aaron Seigo mentioned it would be used in Plasma so that the OSX applets could be rendered. There are a lot of Konqueror developers who are dead set against it, though, and I don't think anything is going to change their minds. In the end, I think you may have somebody fork Konqueror, unless they end up making the backend swappable. Then users will decide which one gets used.
Member since:2005-09-21
Member since:2005-07-07
That's because half of the KDE developers have decided it's going in, and half that it's not. I've never seen the KDE community so divided over a project before. It will definitely be in Qt4.4, though, which means it will almost certainly be included some ways in KDE4.1. I think Aaron Seigo mentioned it would be used in Plasma so that the OSX applets could be rendered. There are a lot of Konqueror developers who are dead set against it, though, and I don't think anything is going to change their minds. In the end, I think you may have somebody fork Konqueror, unless they end up making the backend swappable. Then users will decide which one gets used.
I'm typing this from a KHTML Konqueror window, and yeah, the KHTML situation is a mess:
1) Because Apple's PR talked a far better game then their 'minimal licence compliance' INITIALLY delivered. (That's gotten better. See: http://lists.kde.org/?t=119647157600003&r=1&w=2 )
2) Some KDE developers announced plans very publically about KDE's glorious Webkit based future before a consensus was reached. That lead to hurt feelings.
I think a 'Dolphin Like' plan for Webkit could be in order. Something like:
KDE 4.1: A non-default Webkit Kpart for Konqueror.
KDE 4.2: A standalone (like Dolphin) KDE Webkit browser based on the part.
KDE 4.3: Assess if Apple's proclamations have lived up to reality and assuaged the fears of the KHTML developers enough to warrent making the Webkit Kpart and Browser Bits the default in Konqueror. If apple is playing nice, and the KDE Webkit supporters aren't talking out of school too much, this shouldn't be a problem for reasonable people.
With that being said, I don't want my KDE based Web Browser held captive by a non-responsive upstream entity. (Be it Apple or Trolltech or Whomever.) KHTML works well for me. But yeah, the issue has 'powder keg' written all over it for those who've been following the bouncing ball...
Edited 2007-12-14 04:52
Member since:
2007-12-08
I keep hearing conflicting information about what, if anything, is going to be done with webkit. There was a kpart that went unupdated, and unusable, for a while. That was about three or four months back if I'm remembering correctly. I stopped following the story sometime around then, and in the time since I've heard everything from it being moved into the official html rendering engine to it being pretty much tossed to the side, to almost nobody in the KDE project knowing either.