Konquering the problem
I've been on a fairly long hiatus from this blog. However class, contracting and starting a business have left me without much extra time. That being said, there have been a lot of different things kicking around in my head. This one has for awhile:
Konqueror
There is a lot of talk about the KDE web browser, but there seem to be a lot of issues which surround it which never really progress much. So I want to tackle things from a different perspective, that of a web developer. There are a unique set of concerns that come with this and they tell an interesting story.
Concern #1
The number of browser and javascript engines. The more there are, the worse it is. While standards help solve this they don't prevent buggy behavior from occuring. Thus, having a browser which sticks to the standards without having buggy behavior (very consistently) is very important. While in theory KHTML and KJS can deliver standards compliant behvaior they generally don't because of they are quite buggy (a quick survey of sites leads to some interesting results). While by no means a perfect measure the English Breakfast Network can give us an idea of problems related to a piece of code. KHTML does not fair well.
Unless konqueror and by extension KHTML and KJS recieve significant market penetration it is hard to justify to web developers the value they will get out of ensuring correct behavior for this platform and that's a big concern because that has implications for adoption of KDE as technology and as a platform.
Concern #2
Is technology being pushed by konqueror? Are there cool things being done with the browser and the underlying engines that will add value and will cause people to adopt the platform? I'm not talking just about javascript performance either (although the current Firefox is modestly better, the upcoming version is significantly faster). But things like worker threads, allowing for real time video motion tracking (you do need FF 3.1b2+ for this to work) written in javascript. Even support for the HTML5 video element which is making appearances in webkit as well as in gecko.
Unless a substantial amount of development talent is brought on to help with KHTML I see it continually playing catch up, simply trying to implement technology seen in other platforms and not really innovating. This is a big concern, especially because I do not see how this could cause more people to use KDE.
The numbers tell the same sad story.
Unforunately, I think problems like these are really reflected in users. For instance, on dot.kde.org you get the following picture. There are almost more users visiting dot.kde.org with firefox on windows than with konqueror on linux. Had this been a couple of weeks ago there would have actually been more.
But that is with a KDE site. How are the numbers borne out elsewhere? I formerly worked at the Minnesota Daily, the largest student newspaper in the United States. What do things look like there?
Not surprisingly, konqueror does not even show up and Linux makes a poorer showing than Safari on Apple's iPod. Things are indeed somewhat grim.
A Matter of Goals
There are a lot of issues surrounding this and I think a lot stem from a lack of goals. What is KDE for? How does software within the KDE ecosystem fit into that vision?
I think it's foolish for KDE to maintain a browser engine. Browser engines are complex beasts and it takes a significant amount of effort to maintain a high quality, standards compliant browser engine. Further, it prevents the creation of valuable and useful technology which attract people to KDE as a platform.
Beyond that, I think it's very important that KDE finds a way to start innovating with web technologies. I'm not sure how to do this, but I think the role of KHTML and Konqueror really need to be thought out. Where do they fit into KDE and what are they trying to accomplish?
Some food for thought
I'm not trying to whine. I think there are important questions that surround Konqueor and KHTML and that there needs to be some thoughtful dialog. What are they for? Are they fufilling the task? I'd like to hear all your thoughts.
webkit is khtml in successful
Let's not forget that webkit was and is based on the khtml code base. And not only that. Some of the khtml developers are now working on webkit, including Lars Knoll, the main khtml initiator and architect. Webkit really is khtml in successful. It's a large developer community, commercial and spare time, and an ever growing user base.
I have been forced to use firefox for the past years, as konqueror/khtml couldn't do many of the sites I wanted to visit, or was forced to use (company intranet, online shops). Firefox has nothing to do with KDE. With a webkit based browser, I feel like I'm using a very successful part of KDE. On my mobile, even on my Mac at home.
Everybody who loves KDE can be proud and happy that an important part of our project has gotten loads of external contributors and is konquering the world. I am, and I know Lars is.
Well put!
Always nice to have prestigious visitors :).
I think this is very well put and I think that it would be smart for people to remember that history. I think that continuing KHTML in its current form might be a mistake because of the amount of effort involved in maintaining a browser engine. Thanks for the supportive comment!
switch to arora
I usually avoid konqueror in kde , i use only arora and for development i use firefox (just for firebug)
It make sense to use arora browser with qt 4.5 because it passes all the acid3 tests and almost all the css3 ones
also is very fast and from 0.6 it started to add kde integration , i think it needs more love from kde community
Konqueror
I've used KDE4's Konqueror extensively at work, even using it to debug web-development issues. I was using it as my main browser for a period of about two months.
During that time I can say I recognised a number of things.
Firstly, that Konqueror is brilliantly integrated into KDE4. I love it. Everything was so smoothly integrated - it was a dream - the main reason I kept using it.
Secondly, I noticed that it was very unstable with many websites. The KHTML rendering engine was OK, but with its issues combined with the JS engine, it would crash - or at least something would break - on every second website I used. This was really disappointing because I love it - its just really well integrated.
I'm really thankful to the KHTML and Konqueror devs for the brilliant work thats been done, but I also wonder if its time to start integrating some of the other great open source work thats being done around the place (ie. WebKit, Firefox and Chrome elements). There's some major enhancements happening in the industry and it would be a huge pity if I couldn't use Konqueror in all of this - I love it!
Just my $0.02.
Fibs, lies, and statistics
I use Konqueror and Akregator.
I don't show up on PlanetKDE stats, because I use Akregator.
I am not the only Konqueror user who uses Akregator
Therefore, I imagine a lot of Konqueror users don't show up on PlanetKDE.
Not PlanetKDE
This isn't from PlanetKDE, this is from dot.kde.org. While Akregator and Konqueror are in some sense similar, they aren't the same. After all, you really don't browse through mail, etc. with something like Akregator.
Personally, I don't use much
Personally, I don't use much of Konqueror - for various reasons including the particular sites I visit and the Firefox extensions I use, as well as the fact that I can't set the cookie policy I want in Konq (although I could file a bug for that or code it myself). But does that give any weight to the argument that Konq (or, rather, KHTML) should be scrapped? Not one whit. I'm only one user.
Most of the comment threads on posts on this subject (however well meaning and carefully written the posts themselves are) degenerate into "I use Konq and it works for me, so naysayers are deranged/stupid/evil" and "I tried using Konq and it didn't work on my favourite site, so it SUCKZ". Then we get the developers chiming in with "you can't stop us working on it", which is completely true and largely misses the point, followed by the ex-developers saying "come over to the dark side (Webkit)" or some such. And everyone ends up getting angry and falling out, much to the amusement of the trolls.
I don't think there's much useful to be said until QtWebkit matures some more, though. What I've seen of it looks very promising, but I don't get the impression that it's quite there yet. And maybe what will actually happen is that QtWebkit will take over by stealth, gradually replacing parts of KHTML until KHTML is little more than an interface to webkit. That would probably be the happiest solution for everyone concerned, but pointless flamewars are not going to make it happen any more quickly or slowly.
Honestly, what is the point
Honestly, what is the point of this blog? What possible reason can you have for basically telling someone else to give up on what they're doing? It's not like that will solve any problems...
KHTML and Konquerer aren't nearly as bad as you make out. Sure they have room for improvement but if you look ar the last few releases of KDE there is an amazing rate of improvement. Far more than WebkitKDE as far as I can tell.
Plus KHTML is a part of KDE libs and has to be supported for the rest of the KDE4 series. So basically the answer to any current problems is to make KHTML (or Konquerer) better. Which is exactly what the devs are doing. And doing it very well too.
Oh there's very valid
Oh there's very valid point
If bitching is only way to get something from the devs then so be it.
There's no roadmap, no direction. There're hardly any news anywhere. Nobody talks, promotes or whatever tell wtf is going on in this quite important space called web browsing (in KDE) which is evolving pretty fast these days. Unlike plasma devs who do wonderful job of telling their roadmap, plans and so on...
Frankly it helps to keep us "whiners" down when you now that devs care and you know that something actually happens. They do it for free...we know and it's appreciated but they'd do themselves a big favor when they'd just communicate and interact with users now and then and for example tell why something won't ever work if it so.
These are all very valid criticism If something works everywhere else and it doesn't in konqueror then you should tell it.
Yeah www.digg.com comments chokes konqueror. KJS could use some love i think that's konqueror's achilles heel these days. I have hard time believing that 3 people can maintain any modern and competive js engine just ripoff squirrelfish extreme you've every right to do that :)))
Arora's blog
At least for Arora I try to pretty regularly blog with the current state of things http://arorabrowser.blogspot.com/
JavaScript is non-existent
The use of Konqueror as your daily browser is limited by its non-working JS implementation. More often than not I see the little bug in the bottom bar. Even simple menu structures tend to fail witn nonsense error messages. Then I switch to FF to get stuff done...
Although I personally like to surf with Konqueror (If I don't need to use a menu on the site I'm visiting), I am in fact disappointed with the recent KDE4 version of it. That is because I used a lot of the integration features of Konqueror (its biggest strength IMHO, for example the "bluetooth:/" integration) and with KDE4, half of it won't work any more. Or is abandoned for "Dolphin", the ugly duckling. Why invent the wheel again, I ask as a user? And don't anyone tell me "please wait, the feature will be here soon", as long as the use of KDE4 is actively promoted by the team. It was there in KDE3.
It is a tendency I see since about a year in the whole KDE and Linux development: to switch to new without giving functionality of the old. The same issue with kernel-drivers.
Last thought: If at any point of time, Konqueror should be left out of KDE for whatever reason, PLEASE port the bookmark features, they still are the best around. The ability to navigate in my bookmarks and then just click "add bookmark here" is brilliant, and not available in standard FF configuration (although in Opra, but with one additional click).
greetings.
Kill it with fire
I think Konqueror is really dragging KDE4 down, mainly because of KHTML.
I say kill KHTML with fire of even konqueror and go for KWebKit.
I use Google Docs all the time and there's no way i can make it work with Konqueror.
There are other projects out there, like Rekonq (krappy name) or Arora that are using qt and KWebKit and will get KDE4 integration sooner or later it seems.
In KDE4 most people use a lot of gnome/GTK+ stuff, like Firefox or pidgin.... really hope KDE4 will get at some point where i won't need any more GTK+ applications because out of the box they look fugly inside KDE4.
While using GNOME i'm all good with only gnome/GTK+ apps that i really enjoy.
Konqueror 4
I recently moved from KDE 3 to KDE 4, with matching browsers. By far the biggest improvement was Konqueror. Not without issues but I've never found a perfect browser. I switch to Firefox if something doesn't work (quite rare), just like I did on KDE 3, but I kill FF right when I'm finished again. Konqueror is my all time favorite _application_ (not just browser) and I was actually very optimistic about its future.
So from my point of view, using your words: does Dolphin "cause more people to use KDE"? If you're looking for developer talent, I'd look there ;-)
I see your point and I can only counter with that the world's a better place with Konqueror.
Konqueror 4
I'm also very happy with the latest konqueror updates. I've limited the use of FF to a couple of sites (Google Docs and bank account), for the rest i use konqueror.
But i do agree KHTML devs should communicate their plans and their achivements to keep people calm and wishing the next release, just like plasma guys manage to do. I read planet.kde.org every day and would appreciate some KHTML news also.
You did not do your homework,
You did not do your homework, troll. KHTML will not leave KDE until at least KDE 5. That aside, KHTML works perfectly on 97.8% of the websites I visit and it will improve.
What I think is going to happen, is to Webkit and KHTML to continue to merge, little by little. KHTML already uses code from WebCore and Webkit is taking portions of SVG and DOM code of KHTML. In a not so far future, I think KHTML may be written entirely with QtWebkit.
Just be patient. The current state of FOSS was not made in a day, and KHTML already rocks.
Trollish?
There are several trolls in the comments section of this post, but I think calling Kyle a troll is unfair. He's not attempting to stir up troubles and tension, but is aiming for a rational discussion (on a contenteous subject) and is providing a viewpoint that hasn't (AFAIK) been given before (at least on the planet).
How about we just take back
How about we just take back what is actually ours anyway and make it even better and more innovating.....
lets RE-Fork WebKit!!!! I mean Apple could of just worked on KHTML instead of fork'in it, so lets get it back...
Webkit is maintained by
Webkit is maintained by Nokia,Apple and Google, KHTML is maintained by the KHTML devs.
Webkit actually has working implementations, Konqueror is immature.
The other part is that:
Konqueror is friggid and lacks functionality.
Very few Konqueror plugins available out there, Konqueror would need to embrace Firefox's extension API, so that it would be compatible with Firefox extensions, but the devs can invent a "better" API that nobody would care about.
The choice is up to the konqueror team.
>embrace Firefox's extension
>embrace Firefox's extension API,
Oh, yes, a wonderful idea. Just hold on a second while I crank out mature KDE/QT/KHTML compatible implementations of XUL, XPCOM and XBL. Oh, and I'll need to rewrite Konq to use XUL for its chrome. I'm sure I can have it done in a week, tops.
Please stop trolling
I use Konqueror from KDE 3.5 almost exclusively and I am more than satisfied with it. Calling it immature is just trolling. Please go home to your cave.
Old and stuck in Web 1.0??
OK, simple test:
Start Konqi with KTML and open in tabs Gmail, Google docs, Digg comments, Youtube and netvibes and see what happens.
Those are sites most people fequent all day and they all suck in KHTML. BIGTIME!!
Keep KHTML, but use Webkit for the web. Because it works. KHTML does not!
Well said.
Well said.
web experience
I think right now the web experience in kde is poor. We should think how to improve it as community not leave that huge job on 3 volunteers. As for web engine, khtml is more than enough and it is improving in good way.
Konqueror is missing:
- some sort of awesome bar
- google suggestion in search bar.
- private mode
- easy plug-in installing
- improve tab button.
>khtml is more than
>khtml is more than enough
Not really. Khtml and kjs are both behind the times, and I haven't seen any khtml activity towards html5, so it is about to fall even further behind.
Are you sure ?
which better IE6 engine or KHTML ? About HTML5 , are you kidding me ? IE8 just now implement CSS2.1, nobody will design a public website with HTML5 till mircosoft will implement it (say after 10 years from now). By the way, there some activities on supporting HTML5 in KHTML (the developers are working on add video and audio tags, and WYSIWYG support). Please, read this article to see how advance khtml is :
http://www.legendscrolls.co.uk/webstandards/khtml
Awesomebar is coming through
Awesomebar is coming through a GSoC project with akonadi intergration.
A Google suggestion patch is sent to kde-devel, i dont know if its applied or no though.
As a web developer, i use
As a web developer, i use konqueror all the time.Its fast and very well intergrated and stable.
I use konquerors js debugger which *works* better that Firebug in debugging js code.
There are missing features and the UI is uglier than firebug but im pretty happy with it.
I have no idea why you are saying these, khtml is doing very well and is developed/maintained very well.If you have any problem with a site then fill a bug report.
Its irritating that some *volunteers* are developing and maintaining khtml while most people just nag.
Not nagging, considering
I'm not nagging. This is merely meant as a way to try and explore these issues.
While KHTML is well maintained for the number of people that work on it (which as far as I can tell is not many), however to a degree maintaining a browser engine seems to partially be brute force. Keeping up just requires a lot of work.
Its irritating that some *volunteers* are developing and maintaining khtml while most people just nag.
I think you'll find that the number of people who can and want to work on a browser engine and web browser overall is relatively slim. I don't think this is an issue of volunteering (unless a lot of people start committing to this), it's an issue of if maintaining these kinds of things in KDE makes sense and if not the course of action that can be taken to resolve this discrepancy.
I disagree
Konqueror (Khtml) is as far as I can tell neither fast nor stable. I`m a simple user but every time I gave konqueror a chance I regreted it.
krazy checks?
LOL - did you check *where* are those bugs detected by krazy check-ups and their origins???
ROTFL - over half of them is in SVG module which was imported with minor changes from WebKit :))))))))
Just imagine - how many bugs would krazy find in whole WebKit :))))
Boo Hoo. It's All WebKit's Fault
I'm afraid trying to pin the blame for this on WebKit doesn't help, as well as not being as amusing as some think. So it was imported from WebKit? Errrrrrr. Importing usually gives you bugs, especially where complicated engines like KHTML and WebKit are concerned. Just use QtWebKit and lean on some some bug fixing and testing.
The noise over KDE's lack of a decent web browser is onyl going to get louder. Either KHTML steps up to the plate, which it has failed to do (hence all the original KHTML people going off to work ot QtWebKit) or something else has to be looked at. It's nice to see someone sensible who gets it posting on Planet.
Stats
It's pretty well-known, I thought, that most Konqueror users switch their UserAgent to Firefox so that popular sites like e.g. GMail don't deliver broken/ limited html based on the UserAgent. What's interesting is that DesktopLinux were running their 2009 survey, and Konqueror had, the last time I looked, about 19% of the browser share - more than Opera, even. There were upwards of 7000 votes at the time.
Unfortunately, they silently pulled the survey a few weeks ago. It used to be located here:
http://www.desktoplinux.com/cgi-bin/survey/survey.cgi?view=results&id=01...
A Problem In Itself
It's pretty well-known, I thought, that most Konqueror users switch their UserAgent to Firefox
I think this really frames the problem nicely. This issue isn't only Konqueror, it's that Konqueror doesn't have acceptance. If KDE users have to use hacks within Konqueror to get major websites to function correctly KDE as a whole suffers.
Sorry if I might sound too
Sorry if I might sound too crazy for this post but I really thing that best solution for KDE would be to make xulrunner qt port which is almost or might even already done and make a better integration with a kde desktop itself. I don't think that any of non religious kde users cares about engine their browser is using, they just want to visit pages which will be rendered properly.
Looking seriously do you think there's a way to compete with firefox chrome on linux and then with safari and opera on other platforms. Even if you think the answer is yes, do you think that's what KDE want's to do ?
Can't compare size of the Mozilla and KDE communities but I believe difference is not that significant. Mozilla is mostly focusing on a browser.
Cheers!
"Can't compare size of the
"Can't compare size of the Mozilla and KDE communities but I believe difference is not that significant."
Mozilla has tens of millions of dollars per year coming in from Google. KDE doesn't.
There are far more direct ways of getting excellent web page compatibility without porting millions of lines of Firefox code to Qt - working on WebkitKDE, for example.
I know this is a touchy
I know this is a touchy subject. But I think this is not a matter of telling where the KHTML devs should be focusing their efforts, it's more about where KHTML fits in the KDE project.
In my opinion, if anyone wants to develop in KHTML, let them. They are working on an open source engine that, as far as I read somewhere else, is easy to understand and mostly standards compliant.
However, I really believe that integrating Webkit in Konqueror would be the better option for increasing KDE adoption because it would render almost all the web. KDE by default could still choose KHTML as the default renderer, but Distros could chose Webkit if they wanted to.
Now all you need are developers that are interested in getting Webkit to work better in Konqueror ( which was always the problem in the first place ).
Interesting analysis
I totally agree with this analysis. As a KDE user (and supporter) I would like to to be able to use Konqueror as my default browser since it would integrate nicely with the desktop, but I am forced to use Firefox instead. Konqueror does not work properly with some of the web sites/applications I use, while Firefox does.
Wouldn't WebKit solve many of the nuisances of Konqueror? Are there only cultural obstacles to its adoption or also technical problems?
1st class Webkit
Please just make Webkit a first class option in all of KDE.
I think once it is KHTML will be neglected pretty soon.
The KDE project as a whole
The KDE project as a whole can not direct resources like a commercial project could and so KHTML is supported by people who are interested in that and wouldn't necessarily work as hard elsewhere if the KHTML project was to suspend development. The only thing that could change would be KDE as a whole moving from KHTML to QT Webkit but there needs to be interest to do that.
Interestingly the stats shown above will be obscured due to browser identification, Google just says you can't use the full Gmail if your using Konqueror and works much better when you spoof another browser. The Konqueror released with KDE 4.2 crashes when using Gmail so I started using Firefox - glad I did, very nice it is. At work I have to use Windows and that is where most of my browsing is done, I'd prefer KDE but XP is still more than good enough and is a deal more reponsive (probably not KDE3 but definitely better than KDE4 imho)
Great Post
Nice one Kyle, this really needs to be said. No doubt the KHTML/Konqueror developers will appear at some stage and tell you you are wrong but I totally agree with you. What Konqueror needs is a bit more functionality and just to use Webkit. KDE already has a Webkit dependency in Plasma, it's just pigheadedness that's stopping Konqueror from using Webkit, there is no good technical reasons I've heard, only cultural ones.
Hopefully this will lead to more people thinking about the issue, thanks again for posting this!
"there is no good technical
"there is no good technical reasons I've heard"
WebKit does not export a DOM (although it seems that WebkitQt 4.6 will).
WebKitKDE is still too immature to be used.
Having said that, it's becoming increasingly clear that Khtml is only going to fall further and further behind. I'm a big believer in a small group of very talented programmers being able to out-compete whole teams of other programmers - and there is some frankly phenomenal talent amongst the Khtml devs, real creme-de-la-creme - but the weight behind WebKit is simply too much.
Of course, the people simply saying "drop KHtml!" seem to be ignoring the fact that Khtml is part of kdelibs and as such is promised to be source and binary compatible until KDE5.0. They are also ignoring the fact that people will work on what they want to work on, and outright forbidding people to work on Khtml would be stupid and would likely drive the developers out of KDE altogether. I for one would hate to see e.g. Maksim leave KDE development. Additionally, the question of what engine Konqueror uses is largely immaterial: does any aspect of Konqueror care that Khtml is being used? The plugins might, but anything else ... ?
"Fall further"? - On my
"Fall further"?
- On my machine Konqueror (4.3svn + Qt4.5) is faster than Firefox.
- The only browser which doesn't massacre layout when using increased font size (I have problems with eyesight), Opera isn't bad but I don't like interface.
There is no real alternative for KHTML in KDE - despite all storms WebKitKDE gets almost no attention, no one is putting their feet where their mouths are (Arora crashes each 2 minutes).
Also if you dig into official specs KHTML and Opera are the only browsers which are going with de iure standards.
AJAX kills Konqueror
I use Konqueror as my main browser and I've got to admit it works stable and is quite fast. As long as you browse plain sites.
Anything Web 2.0 tends to kill Konqueror. See https://bugs.kde.org/show_bug.cgi?id=177245 for a good example. Or try to use Wordpress (haven't tried to do so for some time I must admit). At least Google Maps works again in 4.2.2. Also, minitools (otherwise known as Bookmarklets) is completely broken, see https://bugs.kde.org/show_bug.cgi?id=166628
Nothing against Konqueror/KHTML/KJS in general but all in all it looks to me like just doesn't have enough developers to keep with the pace the web develops. And, as Kyle wrote, that hurts KDE as a whole.
About the specs: I, as a user, don't care if Konqueror is the only browser obeying the specs and was the first to have 100% in ACID2 (?). I want my shiny Web 2.0 to work!