In this week's KDE Commit-Digest: Work on WebKit integration, the ability to access Plasma data engines in Plasmoids rendered through WebKit, and a HDDtemp daemon data engine are added to Plasma, plus work on Plasmoid packaging and KRunner. Items can now be dragged from the Kickoff menu to the desktop or the panel. More work on syncing Akregator with online reader services. A GUI for declinations in Parley. Support for DGML tags in Marble. Genuine progress in the KTankBattle game. General improvements and the removal of the Helix engine in Amarok 2. A visual redesign of the KGet "Web Interface", with added translation capabilities. Continued work on KPresenter slide transitions, and KCron. Work on importing and exporting shortcut configurations in KControl. The "three stars per character" password mode returns to KDE 4 (from the KDE 3 series). Various speed optimisations across KDE applications. Ligature moves to "unmaintained" status. KDE 4.0.2 is tagged for release. Read the rest of the Digest here.
Comments
yes, it is and it works already fine. See my replies above ;)
So what's exactly the point in using webkit under konqueror or plasma anyway? KHTML works really well and it's quite fast...
web pages support webkit better.
That may be true or perhaps not, truth is that I haven't found many sites as of now that won't work on KHTML (both on last KDE3 and KDE4), but wouldn't be the answer to make KHTML better? Never done anything with webkit, however I'm under the impression that KDE devs think webkit is a bit clunky and complicated to work with. I know that reinventing the wheel is always silly, however KHTML is clean and performant, and has been an integral part of KDE for a very long while. Not to mention that webkit was based on it.
Mind you, the only reason I use Firefox is because of the extensions. If Konq supported them it would be my browser of choice.
Not being funny, but I'm beginning to agree with others about that functionality, stability and performance is being neglected in favour of looks, seemingly ignoring the fact that KDE4 *is* quite buggy at the moment. KHTML is an example of this IMO. File management on desktop, another one. I do use KDE4 on a daily basis though. I miss, though, the rock-solidness and snapiness of KDE3.5. But that's what you get when running very new software so I don't complain and file bug reports instead.
I do remember that KDE3.0 was, well, quite crap, and 3.1 was really good, while 3.2 was amazing, so I would expect the same for KDE4.1.
KHTML renders a lot of sites good and it's fast, but when it comes to sites for banking, or other interactive stuff, it leaves a lot to be desired, most possibly because the sites are bad engineered. Safari OTOH has found more acceptance with webdevs and therefore renders the sites I (perhaps other people too) really need, where KHTML does not. Rendering glitches are not really a big issue, as long as the content is shown, but when you really need something interactive to work and it doesn't, it IS a showstopper, therefor three engines that are widely used would most possibly help other html-engines, (opera has the same problem as KHTML, in fact KHTML has less problems than opera, except from maybe the gmail thing), plus the fact that even in the gtk camp, devs are looking more and more in the direction of webkit instead of gecko which makes webkit a more attractive choice.
> That may be true or perhaps not, truth is that I haven't found many sites as of now that won't work on KHTML (both on last KDE3 and KDE4),
I'm starting to find more and more sites where KHTML doesn't cut it for me sadly. That's mostly sites doing ajaxy things. I'd love to report those, can't find time to make a simple testcase and therefore ignored it.
I can report one or two for you if you post here the URLs
That's OK for WebKit as an alternate renderer for Konqueror. But why for Plasma? What's the point in depending on two HTML rendering engines in a default KDE installation?
Because if KDE4 is a resource hog, everyone will want to use it!
I'd like to know the answer too!
Are you just saying this or do you have some kind of statistics? Sounds like FUD.
See it that way; we have the opportunity to don't only have one very good webbrowser but two of them and both are greatly supported. One is full under our control, community-FOSS and has a rocking codebase while the other is mainly commercial orientated and provided to us. So, looks for me in any case like a win-win situation :)
only that khtml will die, because people will choose webkit over khtml, and when there are no users, there are no bugreports, no devs etc.
I'm not saying this is realy a bad thing, just that it is going to happen.
You should define which people do you mean !!
I will stick with KHTML if it serves my needs
Probably the people that are under the impression that the websites supported by KHTML are a true subset of the sites supported by WebKit. In other words, you get all the sites supported by KHTML plus some additional which currently work under WebKit.
I cannot verify or falsify claims about KHTML's and WebKit's compatability since I don't use any of the so-called "Web 2.0" applications and the websites I visit regurarly work well with Konqueror. If I had to hazard a guess I'd say that some distributions shipping KDE will switch to WebKit as soon as they deem it stable hoping to get some compatibility problems people claim to have with KHTML out of the way (and thus easing support). So I doubt that the actual user's choice will play a significant role which of the two engines will be used in the future.
It doesn't also help KHTML's cause that some "other" developers are pushing WebKit hard either via code or by propaganda in the blogosphere.
Oops, that reply was intended for Zayed:
http://dot.kde.org/1205065133/1205072654/1205088902/1205089355/120510086...
The sheer amount of projects, personnel, testing and general use cases for WebKit far outpaces KHTML allowing KDE to leverage a lot of resources without having to have the team resources to duplicate such efforts.
It's a nice example of community re-use.
I do see the technical reasons, however, I wonder whether the KHTML guys feel left behind... Are they shifting towards working with Apple on WebKit?
No. There have been many attempts to work with Apple before, but they never worked out. Apple is good at having people work for them, not so much at working with them. And while they have some very nice and very smart people who I respect deeply working for them, they do a lot of things which, while they make sense for them, would be simply insane in a community-driven project.
And, speaking for myself, I will not work on any project which is disconnected from the KDE community and provides no way of protecting our interests. I am not willing to hand over control to a good chunk of our infrastructure to Apple. That Qt will be under control of Nokia is bad enough.
Will there be more tries to work together? Who knows. But at this point, it's all moot, since there aren't enough people interested in proper integration of WebCore (no, thin wrappers around incomplete Qt ports of out-of-date versions of the renderer don't count) for it to happen, while there are plenty of people who will spread FUD and lie to our users. I am personally open to that from the technical POV (the community issues are big, and I am not the sort of person to resolve them), but there are things I want to do myself, bug reports from our users I want to deal with, and bug reports from our users I have to deal with because it seems like no one else will.
And to the grandparent poster: go use IE. It has the best financial backing in the business.
> I am not willing to hand over control to a good chunk of our infrastructure to Apple
isn't the LGPL supposed to take care of that?
A lot of people believe that, but it's simply not true in 99% of cases. You need people to make things happen, they don't show up out of thin air.
kdeprint was LGPLd, too, but there wasn't an active community around it, so when the main driving force behind it left, it was orphaned, and then abandoned entirely in KDE4. The result is that KDE4 has made a huge step back in printing functionality.
What some people want to see happen with QtWebKit, and in particular the way they are pushing it, make a chance of any KDE community connection with it close to nil, which means things will soon bitrot, and if one of the big corporate pushers has a change in priorities, we'll be pretty screwed.
That's what I would imagine. Personally I'd continue work on KHTML and stuff out Webkit. "Just" port over good features and the like. What I mean is that KDE has got total control over KHTML, its quality is very high and improvements can be made. I don't know about the quality of the source code as I'm not fit to judge that. But I keep my word on that I've yet to come to a site kthml can't handle since... well, probably KDE 3.4.
Not sure if some parts of the KDE project realize that KDE is made by people and people, as such, can get demotivated, angry, etc. If I was a khtml dev I would feel as awkward about trying to shove in Webkit as a kdelibs guy would feel if a different libs infrastructure was pushed in too.
How is Webkit going to be maintainable at all if it ain't provided by apple as a maintainable piece of software?
So I ain't a KDE dev, but the more I think about Webkit and KDE, the less sense it makes. I think whoever's working on Webkit kde is just wasting time they could be using into something more productive (let it be improving KHTML itself, or getting on with their own lives). The "choice is good" argument is a bit weak here. I've got a choice already: Firefox.
What I'm getting at is that they're written to use the QtWebKit API for whatever reasons, so if we want them to be able to use KHTML, we have to either patch them or emulate the API they're using.
They most likely decided to use QtWebKit because it is the native rendering engine for Mac OS X widgets so they are more likely to work.
And there are more developers and users for WebKit, and TT supports it. Once some technology moved from KDE to Qt, why support it ourselves any longer? Personally I don't see use for that, even though there are some minor differences between KHTML and WebKit...
> why support it ourselves any longer?
and this is what I don't understand. Why do ppl who actually don't work on something believe that they are able to deny others to work on it too? Shouldn't such a decision be up to those who do the job? One of the great things KDE is about is to "be free" and afaik the "those who codes decides" rule is still valid. Also there is just no reason to go with A or B since we can have both and somehow that even matches the "free to choose" way I love so much in KDE.
Since KHTML is part of kdelibs it will have to be supported until KDE 5 as far as I understand it. And the next major revision is years away so it's probably in the best interest of KDE to stay on the good side with the KHTML developers since their loss might not be easily replaced judging by the complexity of the KHTML codebase.
Not really, if khtml development really dies, it wouldn't be that hard to make the kthml API just wrap the webkit API (which we get for free from QT). There would be some extra overhead to doing it this way, but not much - you can already choose webkit or khtml, so most of the time this wouldn't even be used as we can make the default webkit.
What would be really interesting is to separate khtml out (like webkit was once separated from khtml), and get some of the gnome guys working on webkit into khtml. I'm not sure if this is possible, but it would be really interesting. If Apple decides to close up webkit just a little bit (I'm not sure if they can anymore) khtml might be the way to go. Perhaps we can even make khtml an alternative plugin for safari browsers.
I stand corrected then. But 'm curious if such a wrapper wouldn't break ABI compatability which is also guaranteed until KDE 5. I confess that my C++ knowledge is medicore at best when it comes to compiler voodoo.
The QtWebKit API is only a tiny portion of what KHTML provides. And if it weren't, what makes you think anyone would do it? In fact, if people were actually willing to do work, instead of spreading FUD, you might have seen a libkhtml based on WebCore already.
" In fact, if people were actually willing to do work, instead of spreading FUD, you might have seen a libkhtml based on WebCore already."
Is this still possible in 4.x while maintaining BC? What kind of skill level would be required for someone interested, and roughly how much work would you say it was?
For most classes, BC is trivial, for things like KHTMLPart it's not, but doable. The hard part, and the incredible tricky kind of work, is making it integrate properly. That means, for example, that a web page should still be able to embed, and script KMPlayer, that all the settings are followed, etc, that the KIO and KParts hooks are still in there, etc.
Perhaps it is even an advantage of WebKitQt that it does not use KIO with its excessive reliance on DBus-based IPC. I've got a notion that Konqueror feels exspecially sluggish (in comparison to other browsers) when it has initiated a lot of KIO Slaves.
KIO doesn't use DBus for communications with an I/O slave.
Yes, in this case "socket-based IPC" would be more accurate. Nevertheless, if Konqueror's sluggish behavior on some sites is not caused by the rendering engine but by KIO, the KDE bindings of WebKit you are proposing (as opposed to pure Qt bindings in QtWebKit) would not be of much help.
I stand corrected then.
This is the strangest situation I have ever seen in a community project.
Someone demonstrably hostile to our interests has a neat shiny thing and we shun a community based project for one controlled by interests at best undefined (Nokia) to allow loading third party widgets into a single process user interface.
Derek
> interests at best undefined (Nokia)
and for the goals, it suffice to read the announcement at http://trolltech.com/webkit/webkit-announce to get a glimpse of the new corporate focus:
"Announcing the Qt WebKit Integration
Trolltech's Qt WebKit Integration brings Web 2.0 services to *mobile phones*
Helps *mobile operators* and *handset manufacturers* enrich *phone* applications with live web content such as online maps, music stores and instant messaging" (emphasis mine)
Quick, what is the missing keyword in this announcement? ;-(
Nokia worked on Webkit long before Trolltech was involved in it. Long before Apple 'opened up' development to the free software developers that created the original codebase.
Nokia's interests towards KDE are undefined.
Derek
Unfortunately, there are some in the KDE-world who have decided for some arbitrary reason that a beta QtWebKit port is somehow better than what we already have. I say arbitrary, because they haven't done development work on either one.
And also unfortunately, they are very good at propaganda.
Users lose.
Put that way it really does sound outlandish. Unbelievable in fact.
FFS I can't even type my own username
"It is not really usable at the moment" is probably the key phrase.
Its great to see the return of kiosk tool. Hopefully it will get the love that it deserves.
It is very important tool in the corporation environment . It deserves more.
+1 from me.
In the last years a few companies and municipal authorities migrated to OSS.
In one of those, I am responsible for the decision to prefer KDE to other
desktops. We needed a stable, customizable, feature-rich but functional
environment, and KDE3 seemed (and really was - in my opinion) the right choice.
After quite a long while of observing the KDE4 development with anxious hope,
fear and - sorry - disappointment, it's pretty clear that this KDE4 will never fit
our needs. Ok, no one to blame for. But just to mention, after making dolphin
the default file-manager, it was rather 'demagogic' to claim that konqueror will
still be available, as although konqueror is still there, it seems it uses now
the file-manager-part of dolphin. No "View Mode/Tree View" anymore! A not so unimportant
feature at all, for those to have handle large amounts of documents.
[ http://aseigo.blogspot.com/2007/02/konqueror-not-vanishing-news-at-11.html ]
The default start-menu, space-wasting borders, icon-handling on the desktop,
system-settings replaced kcontrol - thats all about usability, but let alone
plasma-stability and performance ...
So is there any chance to get a KDE4 (maybe a fork) without those plasma?
With a Konqueror with fully functionality?
Because - the hope dies at last - and, although I'm not a programmer,
i think the other underlying changes sounded very promising. It would be
too bad that those were overlayed by wrong decisions related to the "front end".
> although konqueror is still there, it seems it uses now
> the file-manager-part of dolphin. No "View Mode/Tree View" anymore!
A tree view is already available again in trunk -> will be part of KDE 4.1 :-)
Yup, the tree-view in every single window (including split-windows) was one
of those outstanding features that made konqueror (and in succession also KDE)
the tool/environment of choice. But - stay patient - there will be a 4.1 ...
... if i only could wait so long ;-)
thanks for the good news Peter!
"After quite a long while of observing the KDE4 development with anxious hope,
fear and - sorry - disappointment, it's pretty clear that this KDE4 will never fit our needs. Ok, no one to blame for."
So, you're basically judging the whole of the KDE4 series, which has at least 4 years of development still ahead of it, by - at best - it's 4.0.2 release, which is basically a series of bug-fixes and a couple of tiny features added to the initial 4.0.0? Seriously?
"So is there any chance to get a KDE4 (maybe a fork) without those plasma?"
What possible reason could you have to do this? You do realise that the architecture of Plasma will make it so much more configurable and flexible than KDE3 that it will make Kicker and the old K-Menu look pretty sad and rigid in comparison? Heck, once it's matured a bit, it probably wouldn't take more than a few weeks to "clone" the old Kicker *and* all of the old Kicker applets in the Plasma framework. Maybe even days.
"With a Konqueror with fully functionality?"
Why on earth would you fork KDE4 to add features that are *already planned* by the devs? Both Peter and David have stated on numerous occasions that they don't want Konqueror to lose any of its KDE3 features as a result of embedding the Dolphin KPart. Any "fork" would be better off just contributing code to the mainline Konqueror.
"In one of those, I am responsible for the decision to prefer KDE to other
desktops."
That's great, but it would be nice if, instead of posting alarmist FUD here on the Dot, you'd spend a few minutes doing some research on KDE4, its current status, and its goals :)