The KDE Project is happy to set the first beta of KDE 4.1, codenamed Caramel, free today. KDE 4.1 is intended to meet the needs of a broad range of users and we therefore respectfully request you to get testing Beta 1. Beta 1 is not ready for production use but is in wide use by KDE developers and is suitable for testing by Linux enthusiasts and KDE fans.
Highlights of 4.1 are a much more mature Plasma desktop shell that returns much of the configurability that was missing in KDE 4.0, many more applets and look and feel improvements, the return of Kontact and the rest of the KDE PIM applications, and many improvements and newly ported applications. The feature set is now frozen, so the developers look forward to using June and July to metamorphosing your bug reports into rock solid code, completing documentation and translating everything into your language. A series of Bug Days where users can contribute quality assurance to the release will continue towards 4.1's final release on the 29th of July, so watch the Dot for details.
For more details, see the release announcement and info page or if you are at LinuxTag, see KDE 4.1 being presented in Berlin this Friday.
Comments
Why do we need a binding for that M$ language? What's wrong with C++?
Are you claiming that C++ is as easy to write stuff in as C#?
C# is not what a linux or macOSX user may want to have in his
system, and there ia plenty of cause for this.
You're however always free to do yourself bindings for C#, cobol,
fortran and logo languages, nobody will stop you.
i hate c++ and i'm pretty sure there's others like me. anyway just because c#
was conceived by microsuk it doesn't mean that we linuxers can't use it and just for the records i hate windoze so much that i even removed all the windows from my house all i have it's wall:-)
Um, read the reply Richard Dale already provided. The C# bindings help out the QtRuby bindings, so they are good in my book.
Also insert generic "people can spend their free time doing what they want, who the heck are you to say it's a waste of resources which aren't yours".
it's not just wasting personal resources, it's actively helping out a company that stands for everything we as a community are trying to avoid. in general I don't like people complaining about open source either, but in this case, they are actually standing up for it.
I'm sorry, I strongly disagree that I'm 'actively helping Microsoft'. And I couldn't care less about 'open source', as I write Free Software, which isn't the same thing.
What we're actually doing is allowing existing C# programmers to write code using the Qt and KDE apis. I would say that we are helping them to transition away from the Microsoft 'eco system' of IDEs and APIs such as Visual Studio and Win32, Winforms etc, and move to tools and frameworks based on Free Software.
It takes much more effort to learn a large framework such as Qt, than it does to switch to another language, such as going from C# to Java. Hence, once these former Microsoft C# programmers have learned how to write Qt/KDE code in C#, they can pick up C++, Python or whatever fairly easily if they want to.
The Qt guys could give you a huge list, they made quite some effort to improve on it. For some reason Qt is not really C++ but requires the code to be pre-processed.
But come on, can't you think of anything? Type (un)safety? Really crappy polymorphism support? What other languages do you know?
In the announcement it says that "KHTML get a speed boost from anticipatory resource loading, while WebKit... is added to Plasma..."
So is Konqueror going to have WebKit or KHTML?
There is a webkitpart available which you can select at "File Associations" in systemsettings to be the default renderer for embedded HTML contents (such as the web pages in HTML).
Plasma makes use of Webkit to render Mac OS X Dashboard Widgets (as the quoted text states...). That has nothing to do with Konqueror.
Konqueror uses KHTML, Plasma uses WebKit.
(Ok, you can do bizarre things and use webkit under Konqueror, but you'll lose lots of speed optimizations and other stuff.)
Come on guys, just choose one renderer and let it be webkit. I have a lot more compat issues with konqueror than with safari. Webdev's don't give a damn about khtml compatibility. They do about webkit. Qt choose webkit. It's only logical to follow. Performance? nice, but compatibility is more important!
Just my 2 ct.
"Come on guys, just choose one renderer"
Why?
> Webdev's don't give a damn about khtml compatibility. They do about webkit.
They don't. They care about Safari. Incidentally having the same engine does not solve the problem. If at all it makes it easier to "lie" about your real browser identity.
"They don't. They care about Safari. Incidentally having the same engine does not solve the problem."
You're describing something which doesn't get us any further forward in order to try and tell us that the status quo is OK. It most decidedly isn't. The fact is that bug-for-bug compatibility with Safari does count for quite a bit for exactly the reason that the parent has stated - developers care about market share. Do some web developers use user agent strings? Yes they do, but as people use libraries for HTML and JavaScript and write less of it, and owing to the complexity of AJAX, they're being used less and less. The problems now are all about bugs and quirks between different engines. KHTML's bug list is down to user agent strings. Using WebKit gives KDE a far wider pool of web sites that will render well without having to jump on every mole hill in the field, and for those that don't, it gives web developers a far easier avenue to fix their sites and have it render well in any WebKit browser without having to think about it too much.
Continuing to use KHTML isn't going to get us any further forward on that front, and the past few years of Konqueror's limited usage as a web browser should have taught us all that.
The problem is that you don't get bug for bug compatibility with Safari at all just by using WebKit. WebKit is just the rendering engine of Safari, everything else (e.g. client <-> server communication) can (and already does) behave differently between different browsers using WebKit.
"The problem is that you don't get bug for bug compatibility with Safari at all just by using WebKit."
The point is that you have a pretty good shot at it. The situation now is that an undermanned group of people (that are sometimes pretty unresponsive, it has to be said) are having to run around fixing bugs in a rendering engine that few people use, and corner cases are always......just around the corner. There can be no end game to KHTML in terms of it becoming a widely used engine where it will render the vast majority of web pages for people in a confident fashion and where you'll get a KDE web browser that, quite frankly, will be of any use to people.
"WebKit is just the rendering engine of Safari, everything else (e.g. client <-> server communication) can (and already does) behave differently"
I don't see that being a problem in all honesty. The corner cases are in the engine itself. You can work yourself to a set of known issues, and the advantage is that Trolltech are taking the workload on for this.
> The point is that you have a pretty good shot at it.
No you don't. You don't magically get a pony by using QtWebKit. It's a port. It is NOT bug-for-bug compatible with Safari Webkit or feature-for-feature compatible with Safari Webkit.
> The situation now is that an undermanned group of people
If that's going to be your excuse for being unhappy, switch back to MS Windows and just don't use KDE at all. I think only plasma and amorak (which isn't even part of kde proper!) don't fall into the "undermanned" category. Most of the big apps, and the core libs, not just khtml fall into the "need more developers" category. If you want tons of developers and professional marketing, don't use free software.
> "WebKit is just the rendering engine of Safari, everything else (e.g. client > <-> server communication) can (and already does) behave differently"
>
> I don't see that being a problem in all honesty.
This person is trying to point out /why/ it isn't bug-for-bug compatible. And what all is going to be different from Safari Webkit. And that it is a problem. QtWebkit is a port of safari webkit, and would have to be ported to KDE. Doing so will generate all sorts of your "corner cases". And you already claim there aren't enough khtml developers to deal with what is out there.
So go back to Windows, and be sure to FUD khtml and plasma on your way out. As everyone else in these dot comments seems to be happy to do so. :P
"No you don't. You don't magically get a pony by using QtWebKit. It's a port."
*Yes you do*. Repeating the above is not going to magically make it all go away. Yes, it's a port (from the same codebase no less) and that's exactly the reason why you have a shot at it rather than in some totally different and rarely used 'fork' in KHTML that produces corner cases right, left and centre that aren't going to be solved and have no chance of being so.
"If that's going to be your excuse for being unhappy, switch back to MS Windows and just don't use KDE at all."
Boo, hoo, hoo. I don't have to. The fact is that you're never, never have and aren't, going to make KHTML a well supported rendering engine that will be of use to the vast majority of users and web developers out there. The engine that will be used most prevalently within KDE, and in any KDE browser, is the one that has the most support in terms of web pages that people can view well, and the past few years has taught us that that isn't be KHTML. Trying to attack QtWebKit won't change that problem for KDE's users, or KDE's developers trying to get a rendering engine that won't cause them problems for them and their users.
KHTML is a very small island, that hasn't changed and isn't going to.
"I think only plasma and amorak (which isn't even part of kde proper!)"
Rrrrrrrrrrrrright.
"QtWebkit is a port of safari webkit, and would have to be ported to KDE. Doing so will generate all sorts of your "corner cases"."
What are you talking about? QtWebKit exists now, will get developed much further at a pace that KHTML cannot match via upstream code from Trollech, and further upstream from WebKit, and will simply be reused as every other part of Qt is in KDE these days. You make it sound as if there is some insurmountable mountain to get over in terms of porting a Qt component to KDE, which is just plain daft.
"Doing so will generate all sorts of your "corner cases"."
No it won't, and any issues you might have will be far, far, far, far, far smaller than trying to jump on every mole hill in the field and investigate every bug report about a particular site that isn't rendering properly in KHTML. They are exceptionally difficult to debug. You're not going to get any help from any web developers or anyone else in the form of upstream code on that score.
"So go back to Windows, and be sure to FUD khtml and plasma on your way out."
Feel free to ignore the issues as KDE's users and developers leave KHTML behind in favour of something that works for users, and more importantly, has a far, far better chance of continuing to work in the future. The robust 'defence' of KHTML is just a case of 'our ego is bigger than yours' rather than having the best interests of KDE's users and wider developer community at heart.
you know the problem is if QWebKit was one tenth as good as you sad trolls touted it for monthes, it would stand on its own, just like KHTML does without any of this silly propaganda.
You wouldn't need 30+ lines of strange and insane drivel that seem to obey to some kind of personal obsession (sorry).
The truth is current QWebKit suck. It's slow, buggy, and incomplete.
This state of affair might change. It might not.
It's not like any Trolltech employee as a significant role on the WebKit project or any bearing on its future.
They are all just stub-fillers for features made by Apple employees.
Hardly exciting, and certainly not a guarantee of a perrenial and fully functional "product".
"you know the problem is if QWebKit was one tenth as good as you sad trolls touted it for monthes, it would stand on its own, just like KHTML does without any of this silly propaganda."
Very, very, very few people use KHTML at the moment, and it's fair to say that most of KDE's users use Firefox. That's for a reason. Additionally, KDE developers get something that works with QtGraphicsView.
Do the maths. You're right about one thing. KHTML does stand on its own. Very alone, and that's the problem.
"You wouldn't need 30+ lines of strange and insane drivel that seem to obey to some kind of personal obsession (sorry)."
*Shrugs shoulders*. If you're willing to debate it I'm all ears. I'll condense it into something that might make it through your head better - the market decides on the basis of what works best for them, and based on the evidence of the past few years they aren't going to pick KHTML.
"The truth is current QWebKit suck. It's slow, buggy, and incomplete."
If you have something to back that up, I'm all ears. There's a lot of upstream code going into it - most if it from the very people who started KHTML in the first place!!
"It's not like any Trolltech employee as a significant role on the WebKit project or any bearing on its future."
Pfffffffffff. Yer, you're right. Trolltech, Nokia, Apple and all these other people who contribute code to it are just wasting their time when you compare it to the powerhouse of development that is KHTML.
"They are all just stub-fillers for features made by Apple employees."
That's the usual sad line trotted out by Harri Porten and a few others, that WebKit is entirely dependant on the empty stubs that Apple have left for their own features which Steve Jobs has asked for by next week. Well, as I said the market decides and the proof will be in the eating. I don't see QtWebKit having any issues thus far.
See, but virtually nobody uses QtWebKit. Plasma is about the only application based on it. You really don't seem to understand that a port is not an equivelency, and a library is not an application. "Using QtWebKit" is not going to suddenly have the contents of a Konqueror browser look the same as a Safari browser (which does *not* use QtWebKit... it uses WebKit)... it will never do so. Once again, it isn't a magic pony. It's a kit to build your own pony, and the results due to things like different font rendering, network interface and base widgets will mean the two will never look or act the same. Safari doesn't use KIO
QtWebKit is being worked on, and it may replace KHTML at some point, but don't ever think that it will make a bug for bug Safari clone (nor will Epiphany, Android, S60 or any other ported WebKit project). It is already different than WebKit, and attaching it to a different system with different IO system and rendering system will result in a different application no matter how close you want it to be.
Otherwise, if it were this lego like simplicity you seem to think it is... why would it take any effort and new code in the ongoing effort to port it?
Come on guys, why you all are fighthing each other? The fact is: QtWebKit is there, it is not (yet) as good as Safari with WebKit, it might be distributed as KPart for KDE 4.1, but seems the WebKit KPart will only be ready for daily usage for 4.2 onwards.
Meanwhile, KDE will still ship KHTML as the default for Konqueror, providing the best for the user. And even after 4.2, users will be given a choice between that two, I don't know which one will be the default. Those who still want the uber performance of KHTML or those who want compatibility with each website out there.
Just my personal opinion: QtWebKit still needs to mature first, for compatibility, I really should rely on Firefox/Gecko (I try QtWebKit from time to time)
"The situation now is that an undermanned group of people (that are sometimes pretty unresponsive, it has to be said)"
I just hope that the KHTML devs can successfully sync directory structure of KHTML and WebKit (and also helped by a GSoC to port WebKit's SVG to KDE) so that both projects can synchronize each other easily (but I guess WebKit won't bother to sync with KHTML...). I guess it would be the best path for KHTML.
And also, having KHTML in our tree IMO won't hurt, WebKit is good, but KHTML is also progressing very nicely. I also hope with the availability of KHTML on Windows can significantly grow KHTML market share.
And also, don't underestimate a small team. I'm so grateful that even though WebKit is there, the KHTML devs still maintain and develop their own baby. As a comparison, just imagine if KOffice devs had dropped KOffice in favor of OOo long time ago, we would not have a hope that someday we can have a viable alternative to a slow and resource intensive office suite.
"I just hope that the KHTML devs can successfully sync directory structure of KHTML and WebKit"
They can't. KHTML is now a fork of WebKit, and as Zack Rusin puts it, not a terribly good one at that.
Yish, people can actually buy THAT line?
Sad.
"Yish, people can actually buy THAT line?"
Yes, because the proof as they say is in the eating. Take a look at the last few years. KHTML has just not emerged into an engine of sufficient reliability and quality for people, and developers, to use confidently enough, and there is no reason at all to believe that situation will change.
I'm not entirely sure how often that needs to be repeated.
Repeating it often doesn't make it any less of nonsense. It's completely and utterly absurd.
"Repeating it often doesn't make it any less of nonsense."
Uh huh. Repeating it isn't going to make it go away.
"It's completely and utterly absurd."
Why? I don't use KHTML because it has a lot of widely recorded issues with browsing a lot of web sites on a day-to-day basis, and KDE developers outside the world of KHTML are reluctant to use it because of that. There's no reason at all that you can point to as to why that situation is going to change.
That is *why* it's not absurd. Did that not become clear at any point?
"They can't. KHTML is now a fork of WebKit, and as Zack Rusin puts it, not a terribly good one at that."
Nothing is impossible ;) Harri Porten is doing that job (you can see from KDE 4.1 Feature Plan in techbase), I don't know whether it will be ready for 4.1. Also we get one SoC project to port WebKit SVG to KDE/KHTML, seems that it will tremendously help ;).
Don't forget that the status quo is the reason why we are able to choose between different browsers since else everybody would be on IE which is still the leading browser.
To if-elif-else Browsers at webpages is not the solution but the problem since that list will always exclude some users and may it only those that depend on the IBM blindreader or another kinder of useragent.
If you look a bit more close at things like ACID1+2+3+n, IE8 quirks vs standard and so on, you may also note, that the general goal is to be independend of browser-implementations and this is the only correct way to go in the long run to prevent incompatibility, to easier the job of webdesigners, to prevent to exclude smaller user-groups and to have real interoperability.
"Don't forget that the status quo is the reason why we are able to choose between different browsers since else everybody would be on IE which is still the leading browser."
There is a balance to be struck between having a choice of rendering engines that open up other platforms for people, and having something that, uhm, works. The status quo just doesn't work for KDE users currently.
For compatibility, I'd rather go for Firefox/Gecko (or even IE, I bet 99% websites out there is compatible with IE :D). I still see some compatibility issues with Safari/WebKit. Also, there is a recent news that a guy from Mozilla is working for Qt/Gecko.
For performance, KHTML is still the winner (especially the latest KHTML from trunk). I still use Konqueror/KHTML as my main browser since it serves me well for my 99% browsing need. And I just fire Firefox when I encounter site which is not compatible with KHTML.
Same for me. The only place where I need Firefox is the Wordpress post editor, but afaik KHTML now has WYSIWYG editor support, so this might be solved already.
I'm also almost exclusively using Konqueror / KHTML to browse the web, it's simple the fastest I could find and has the nicest rendering in my eyes, leading the pack by a large margin.
Unfortunately ECMAScript / JavaScript support with KDE 3.5's KJS is a bit flaky, but as far as I understand that's not directly KHTML's fould.
I'm looking forward to KDE 4.1 and I'm curious to see how Konqueror has improved. :-)
In case of compatibility problems with web sites I resort to Firefox, but it's just too slow for daily work and many pages get rendered just plain ugly... Maybe Firefox 3 will improve something on that front, I've not tested its betas yet.
Last I heard, qt's webkit was using the same user agent that konqueror was.
Change yours and then you can stop complaining, that's all the site wants.
Of course, then it will look like you're using something that isn't konqueror, so you might as well just go ahead and install internet explorer.
Web developers seem to care very little about standards. And Firefox has written its own. Picking which rendering standard to implement is non-trivial. Deal with that for a while then come back and complain about compatibility.
p.s. qt's webkit != safari's webkit
"Last I heard, qt's webkit was using the same user agent that konqueror was.
Change yours and then you can stop complaining, that's all the site wants.......p.s. qt's webkit != safari's webkit"
I'm afraid that this is the myth that lots of people want to perpetuate, but it simply isn't true I'm afraid. Using the same WebKit engine and code allows for bug-for-bug compatibility with Safari, and with greater market share that counts for a lot, and it's far easier to drive market share up together for the engine. That's why Nokia and lots of others are using it.
Peruse through KHTL's bug list and you'll see that the problems arise from differences and quirks between how KHTML handles certain elements and other engines. Very few, if any at all, of the real problems are down to user agent strings as some people want to pretend.
"Using the same WebKit engine and code allows for bug-for-bug compatibility with Safari"
I'm pretty sure this isn't and will never be true. http://zecke.blogspot.com/2008/01/joys-of-debugging-webkit.html
That doesn't paint a pretty picture.
HTML and JavaScript engines never are pretty. Debugging issues with any engine is damn hard, whether it be WebKit or KHTML. In the end' it's a question of what ends up being easiest to work with in the long run, and gives better results.
What happened there was they GIT merged a new branch into QtWebKit, got pointed to a known bug by the Apple people (which affected nightly builds of WebKit and Safari as well) and ended up being OK. In reality, they didn't need to resolve and patch this themselves although they did need to find out what was happening in their port. Try doing this with your own engine that no one else works on.
Unfortunately, this doesn't prove your point at all.
I have been developing web browser components for 9 years. Yes, all the way back when HTML4 was brand new and AJAX wasn't even AJAX (it was all "DHTML" :)
Simply put, having Konqueror use WebKit means that Konqueror and other QtWebKit embedding applications will be running the same rendering engine. This means, if a site fails to load in one, it will fail in the other. The current state of affairs is that Konqueror renders it one way using KHTML (note, badly most of the time) and QtWebKit from a very recent WebKit build (~SquirrelFish checkin time) will render it very nicely. And 3x faster.
To say that it will be bug-for-bug compatibility, is wrong, that is for sure - the abstraction of QtWebKit is different to Safari, so you may see bugs in Qt classes, but then you will also see these in Konqueror, perhaps hidden behind different, confused codepaths. But, WebKit is maintained by Nokia (alone as well as through Trolltech for QtWebKit), Apple and a large team of developers, and the bugfixes and better abstractions will be committed in, and there will be more concerned developers working on WebKit than there are on KHTML.
In fact the blog URL you posted just goes to prove THAT :)
The major benefits will be that Konqueror will develop new features in lockstep with WebKit, and not be a second-rate cousin implementing it's own development path. Rendering, DOM, Javascript and bugfixes can be consolidated, and resource usage reduced (why load two whole rendering engines when you can use one?). Konqueror could concentrate on being the best wrapper around a browser it can be, instead of trying to knock against the status quo. There is no benefit in writing The Best HTML Renderer That Nobody But Konqueror Uses.
I think KDE developers should at least produce some affirmation of their stance on this, and correct the hundreds of not thousands of articles which proclaim that Konqueror is "based on WebKit", when in fact it is based on KHTML which is where WebKit came from. If there is no plan to support WebKit Actual as Konqueror's renderer, then say so. Tell us all, so we can start porting the surrounding Konqueror components into a WebKit-based browser :)
Hmm is flash supported yet? Support for swfdec and/or gnash would be cool...could u puhleeeez cute em? :)
and not really anywhere else
at least with newer versions
also, they don't support 64bit systems
complain to them
sorry folks, firefox is THE monopoly today
(but yes, it does work, depending on what version you use)
Read again. He was asking for Qt ports/adaptions of swfdec and gnash, which aren't the binary trash Adobe tosses out.
Konqueror can use both KHTML and WebKit, I believe, though WebKit plugin support is still experimental. The added support of WebKit for Plasma is probably for better compatibility with OS X Dashboard widgets.
Konqueror has always been technically renderer agnostic. Which is good, since essentially the "free market" (in the form of distros and users) will decide what ends up being the primary renderer of Konqueror. It would've been ugly if what renderer Konqueror used had to be a top-down decision...
Judging from what I've seen blogged about WebKit in Qt 4.5, it sounds like WebKit won't really be ready until then (Qt 4.5 will be probably be late 2008).
That is all :)
+1
+999999
(I learned)
First of all thank you all who are involved in this wonderful work and for another important beta release.
There are a few things that I am personally missing, they are not vital but nonetheless missing.
Flickr - could somebody tell me where Flickr disappeared to?
Thumbnail preview (composite) doesn't seems to be working although it's turned on and the KWin compositing effects has brought my system to a crawl once again although it was quite fast with previous builds. Anyone here has similar problems?
Well... I still don't see any word on proxy support in the release notes. More is a pity, but I cannot even try KDE 4.x in a reasonable fashion (well, that is try KDE and KDE programs) without fixed proxy support. I could always use firefox, pidgin, liferea, thunderbird and other non-KDE programs to access the net, but in that case I don't see the point of using KDE. I hope they will fix this soon.