Linked by Thom Holwerda on Wed 13th May 2009 20:36 UTC, submitted by poundsmack
KDE The KDE team has pushed out the first beta release of KDE 4.3. The highlights of this release are the integration of many new technologies, such as PolicyKit and Geolocation services, new window animation effects, a more usable run command popup, many new and improved addons in Plasma, Many bugfixes and improvements across all applications, and more integration of features coming with the KDE 4 platform.
Thread beginning with comment 363500
To read all comments associated with this story, please click here.
Keeping KHTML hanging on
by tyrione on Wed 13th May 2009 21:20 UTC
tyrione
Member since:
2005-11-21

The fact they are taking portions of WebKit and refactoring them into KHTML and keeping that going, instead of moving to WebKit directly and using it's engine for the Help System amongst other subsystem features in WebKit tells me Ego runs amuck in some areas.

Just looking at the Plans section:

``Move KDE integration of QtWebKit into kdelibs (but not KPart!) ''

The rate at which GTK+ WebKit is starting to move it'll be more complete in Epiphany than Konqueror is with WebKit duct taping.

Reply Score: 1

v RE: Keeping KHTML hanging on
by google_ninja on Wed 13th May 2009 21:23 in reply to "Keeping KHTML hanging on"
Thom_Holwerda Member since:
2005-06-29

He's still right. Khtml is a total and utter mess compared to Webkit.

I refuse to use KDE4 because I don't want to use Khtml. They can call me the moment they get sane again and ditch Khtml in favour of Webkit.

Reply Parent Score: 1

RE[2]: Keeping KHTML hanging on
by Luminair on Wed 13th May 2009 22:13 in reply to "RE: Keeping KHTML hanging on"
Luminair Member since:
2007-03-30

its not a troll

kde deserves all the credit in the world for creating what would become webkit

but webkit is more popular and better than khtml now, and so that is what kde should use

Reply Parent Score: 4

sbergman27 Member since:
2005-07-24

I'm not certain I understand your comment, which is unusual, so I expect I am missing something significant.

Also, I should disclaim that I follow the khtml/webkit relationship very closely. But I will say that while KDE is off using their own thing, I feel a slight but unsettling disturbance in The Force, as if things are not quite as they should be.

That said, Epiphany's Gecko->WebKit conversion, although it has experienced delays, is now coming together quite nicely. I think it is on course for a solid debut in Gnome 2.28 coming this Fall.

I'm running a recent 2.27 build of Epiphany-Webkit pretty much full time. And with just a couple of workarounds, I'm loving it. For anyone interested, the two things lacking for me at this time are adblock and on-disk cache. However, unlike in previous releases I have tried, proxy support works quite nicely. So I just chained Squid with Privoxy... and voilá! Still lacks the nice process-based model of Chrome. But hey! That's life. At least for now. I'm happy as a clam, though I must confess that I've never understood what clams have to be so eternally blissful about. The predation you see in those nature shows on the public channel gets downright grisly.

Edited 2009-05-14 02:32 UTC

Reply Parent Score: 3

RE: Keeping KHTML hanging on
by KAMiKAZOW on Thu 14th May 2009 01:05 in reply to "Keeping KHTML hanging on"
KAMiKAZOW Member since:
2005-07-06

The fact they are taking portions of WebKit and refactoring them into KHTML and keeping that going, instead of moving to WebKit directly and using it's engine for the Help System amongst other subsystem features in WebKit tells me Ego runs amuck in some areas.

Yes, KHTML sucks big time, but for the KDE 4 life time this refactoring is the best choice. The main problem is, that the KHTML devs managed to get KHTML into kdelibs. kdelibs the the KDE module that guaranies 100% binary compatibility throughout the life time of a major revision.
So that means that we can't get rid of KHTML anytime soon. The best solution is to replace the inner workings of KHTML with WebKit code bit by bit in a way that's binary compatible.

Just looking at the Plans section:

``Move KDE integration of QtWebKit into kdelibs (but not KPart!) ''

That's not so bad as it sounds. Putting the KPart into kdelibs requires kept binary compatibility as well. I don't think that it is crucial that the KPart in addition to QtWebKit is put into kdelibs.

Reply Parent Score: 4

RE: Keeping KHTML hanging on
by segedunum on Thu 14th May 2009 07:54 in reply to "Keeping KHTML hanging on"
segedunum Member since:
2005-07-06

Yer, I'm afraid the penny still hasn't dropped with some people that the reason why Konqueror wasn't well used was because KHTML provided you with an unreliable browsing experience. Sorry, but web developers just do not test for your insignificant HTML and JavaScript engine.

Thankfully, that's why the original and sensible KHTML people like Lars Knoll and George Stalkos, amongst others, decided the brick wall had been reached and started working on QtWebKit.

While KDE developers are free to use the engine they want it's a safe bet that they'll end up using what works better for their users as QtWebKit improved and APIs get better - regardless of what is in kdelibs which is the usual excuse. That's why Plasma uses it. That takes a bit of time.

Edited 2009-05-14 08:11 UTC

Reply Parent Score: 2

RE: Keeping KHTML hanging on
by michi on Thu 14th May 2009 12:36 in reply to "Keeping KHTML hanging on"
michi Member since:
2006-02-04

It is possible to use webkit with konqueror. Here are some instructions how to do it on Debian:

Create a directory for the sources, e.g. /usr/local/src/kde4 or ~/kde4. cd to that directory and do

svn co svn://anonsvn.kde.org/home/kde/trunk/playground/libs/webkitkde/

It will create a directory webkitkde with the sources. Do

cd webkitkde

and create a build directory:

mkdir build

Go to that directory and run cmake:

cd build
cmake ..

If you get error message, you have to install the appropriate headers (you can find them using apt-cache search package name. You need to install the packages that end with -dev). When cmake finishes without errors, run make:

make

Next you have to install the kpart:

make install

This might not work as normal user. If it does not work, do it as root. The webkit kpart will be installed to /usr/local. Next you have to restart KDE. Then open a page in konqueror. You can switch engines with

View -> View Mode -> {KHTML, WebKit}


This only works if a page is open. If you want to set the WebKit part as default, run:

keditfiletype text/html

and move "WebKit (webkitpart)" in the "Embedding" tab to the top. For me, youtube did not show any videos with the webkit kpart (it does with khtml).

The webkit kpart is not included in KDE because it is not finished. I think the only way getting it into KDE soon is to help developing it. Complaining in forums wont help.

Reply Parent Score: 2

RE[2]: Keeping KHTML hanging on
by tartugo on Thu 14th May 2009 12:39 in reply to "RE: Keeping KHTML hanging on"
tartugo Member since:
2009-05-14

Tks michi now i know how to do this on Debian..tks

Reply Parent Score: 1