Submitted by “Trolltech has released the Qt 4.4.0 technical preview, a pre-release that allows software developers to begin experimenting with the new features that the company has implemented for the next version. I compiled the technical preview release from source code and tested it on my desktop computer with Ubuntu 7.10. For testing purposes, I experimented with several of the new features, examined the included demo applications, and created a few simple programs of my own. The 4.4.0 technical preview adds a new concurrency framework, enhanced XML support, the Phonon media framework, and an integrated HTML renderer widget based on WebKit. This release is also the first to include support for rendering widgets on a GraphicsView component – a feature that will enable Qt developers to create richer and more dynamic user interfaces.”
Sigh… I’m currently learning QT, and they keep adding features faster than I can make use of them 😛
Good news anyway, QT keeps getting better and better
All I can say is WOW, trolltech really does amazing work. I read the whole article and the things they have accomplished are really amazing. I’m really looking forward to this being implimented into a point release of kde 4.
As the first poster stated, the only problem is Trolltech is implimenting these new features at such a fast rate that it is hard to keep up (which is really not a problem at all).
Edited 2007-12-26 17:57
I do find it noteworthy that once Trolltech ported it’s Qt environment to OS X that it has incorporated similar functionality available in OS X at a much faster pace.
This isn’t a coincidence.
> This isn’t a coincidence.
the two things are hardly connected at all.
Please repeat that if and when Trolltech decides to go deep into the Windows market.
KDE is interdependent upon the progress Trolltech makes.
No need to repeat it, as this is the current situation.
Most Trolltech customers have a Qt licence for Windows, some even only for Windows.
I *think* some of the Plasma devs stated a while back that the combination of WebKit in Qt and Widgets on Canvas is precisely what is needed for the long-promised OS X Dashboard widget support in Plasma, so hopefully we can see that reasonably soon. The development of Widgets on Canvas was of course largely driven by some of the Plasma devs requirements.
Look for this in KDE 4.1, KDE 4.0.0 does not require Qt 4.4, but at a minimal 4.3.x.
Shawn.
To be even more precise, qt-copy in trunk is 4.3.3 with patches.
I think I beat you to this one Thom.
Trolletch is doing some interesting things with qt. The cool thing is that most of this can propagate to KDE at some point. I wish the GTK team would get off of their asses and start bringing the toolkit into the 21st century. The most interesting thing is input redirection. I would like to see that make it into GTk as well as some of the other things developers like Macslow have been asking for for a while.
Ebbeh?
What’s this “input redirection” that you’re referring to?
If a set of widgets is transformed (eg enlarged) you should be able to click on the NEW location of the widgets and get an event (eg a dropdown menu). This currently doesn’t work in the very hacky GTK stuff which can transform widgets; Qt has this covered, which is quite a big thing as it makes transformed widgets actually usable.
WebKit is being ported to GTK+ and don’t be surprised that they do what Trolltech did: Port GTK+ completely to OS X. At the very least they will have learned a lot of how Apple develops and should speed up the advances of GTK+/GNOME.
Focusing more on Windows was suicide for GTK+.
WebKit is being ported to GTK+
It won’t be ported to GTK, but Epiphany can certainly use WebKit I think, and Nokia is using it in those tablet thingies.
…don’t be surprised that they do what Trolltech did: Port GTK+ completely to OS X.
Creating a reliable cross-platform toolkit is exceptionally hard, but when you have to take into account the differences on a platform like the Mac, it gets doubly hard. That’s going to take an awful lot of time and effort.
Focusing more on Windows was suicide for GTK+.
Well, GTK purports to be a cross-platform toolkit, and that’s how it markets itself. I’d say Windows qualifies on that score.
> Nokia is using it [WebKit] in those tablet thingies.
That is actually incorrect. The Nokia-made web browser in the ITOS2006 and ITOS2007 releases used to be powered by the Opera engine; the browser in the newly-released ITOS2008 is powered by Gecko. There are third parties working on bringing WebKit to the device via the WebKit GTK+ port, but this effort hasn’t achieved general availability yet.
You’re probably thinking of the web browser that Nokia ships as part of its latest generation Symbian-powered “Series 60” cell phones, which is indeed based on WebKit.
That is actually incorrect. The Nokia-made web browser in the ITOS2006 and ITOS2007 releases used to be powered by the Opera engine; the browser in the newly-released ITOS2008 is powered by Gecko.
I stand corrected. I thought Nokia had done some customisation stuff with them as well as having WebKit powered stuff on their Symbian browsers.
I couldn’t remember that Qt3 moved that fast from 3.0 to 3.4. At one point it is great to see the growth of Qt but on the other point it is also frightening. Personaly i prefer a development platform which doesn’t move that fast.
“Personaly i prefer a development platform which doesn’t move that fast.”
How so? It’s all backwards-compatible (within a major version, that is), so the rapid rate of progress needn’t inconvenience anyone at all – if you don’t need the new features, simply don’t use them!
One of the most exciting stuff in 4.4 is WebKit. We will see *for sure* that WebKit becomes the renderer for Konqueror. I know, I know, not every developer shares this opinion, but in the end it will happen. If we wait for some releases WebKit will clearly out perform KHTML, and the shift will happen.
And this means again that a major part of the KDE desktop is maintained outside the project, giving the project more resources available for all that cool stuff that is out there (like Plasma).
I can hardly wait what KDE 4 (read people: I said KDE 4, not KDE 4.0) will bring us!
“And this means again that a major part of the KDE desktop is maintained outside the project, giving the project more resources available for all that cool stuff that is out there (like Plasma).”
It is highly unlikely that the small handful of KHTML hackers will suddenly down tools and begin working on Plasma, especially as, as a part of kdelibs, KHTML will need to be maintained until at least KDE5.
It is highly unlikely that the small handful of KHTML hackers will suddenly down tools and begin working on Plasma
Code and development tends to gravitate what users want, and what works for developers.
KHTML has had years to turn into a reliable rendering engine that will work for the vast majority of users with the vast majority of web sites out there. It has failed. Nothing is going to paint over that fact.
KHTML will need to be maintained until at least KDE5.
No it doesn’t. That’s basically telling people that they’re ‘stuck with it, so tough’. That’s a poor comeback. We’re not stuck with KHTML.
“KHTML has had years to turn into a reliable rendering engine that will work for the vast majority of users with the vast majority of web sites out there. It has failed. Nothing is going to paint over that fact.”
Failed by not doing what? Becoming the rendering engine of one of the world’s top three browsers? :p
Just kidding. But seriously, I am curious as to why you say KHTML “failed.” Was it not “good enough” for Apple to choose it to build off of for their Safari browser? Apparently not, otherwise Safari would be based on Gecko or something. I haven’t used KDE or Konquerer for a while; however, I saw no problems with the rendering of the pages in general. It was the layout of the browser itself that felt cluttered and its various quirks that made it insufficient for my needs and kept me from using it.
Sure, Konqueror will work fine as long as all you need to do is browse and read web pages. However, as soon as a web site makes heavy use of AJAX technologies, konqueror performs very poorly, meaning that a KDE user wishing to participate in the web 2.0 world simply cannot avoid to install firefox. Konqueror’s Java/ECMAscript performance always lagged behind the other rendering engines.
Therefore a WebKit backend would be a reason to rejoice, however this would require browser checks of the respective web sites to be less moronic than they are today. Instead of “firefox” or “safari” they should check for WebKit and Gecko.
Agree. WebKit (Safari at least!) works much better with AJAX than Konqueror. I have spent many hours developing AJAX code, and I know that I am saying here!
I have never developed serious application in Qt, as I’m using mostly Java at university and Ruby at work, but I am keeping track of all new features and I’m trying to be up to date with both library and development tools.
I just yesterday refreshed my memory on Qt 4, building simple DBus application for my personal use, and this gave me much more pleasure than any other development recently. I just love the clean design, I admire documentation and everything is in place, very professional.
But there is only one bit missing for me from Qt distribution – a good IDE. Yes, there is KDevelop (which I quite like BTW), and you can use VisualStudio with it. Anyway, KDevelop is not as good as NetBeans and VisualStudion won’t run on my Linux box
. I heavily use NetBeans for all of my other tasks.
I have never tried Qt development on NetBeans, but I know this is possible – but painful. Qt netbeans integration would be my killer plugin, but I guess not much other people are interested in this topic!
Since alle KHTML-based browsers (even Safari) have “KHTML, like Gecko” in their user agent, that one is pointless too.
In the “quest” to become compatible with the web sites out there, the user agent strings became insanely long in recent years.
I am afraid that the people developing browser checks just don’t have enought knowledge to actual code reasonable ones. They probably don’t even know what purpose the different sections of the user agent string serve, yet alone which value they can have and which value a check should evalute.
Sometimes I wonder why people assume that “web code” will miraculously be fixed again and again, whenever a new client side technology becomes available. History has shown that they “web code” will just be adjusted to check for this new technology explicitly, e.g. for Firefox while a reasonable check should have got Gecko added or Safari while a reasonable check should have got WebKit added.
Switching another browser to one of those render engines does not make the work automaically, it will just give their users an easier way to find a suitable override user agent
History has shown that they “web code” will just be adjusted to check for this new technology explicitly, e.g. for Firefox while a reasonable check should have got Gecko added or Safari while a reasonable check should have got WebKit added.
Better yet sites would check for capabilities instead of browser name or even renderer name. Sites should be checking whether the user’s browser implements the features it needs rather than constantly updating their list of browsers and what those browsers are capable of. Instead of maintaining a database, just ask.
Sniffing user agents is not ideal. They are always getting more complex, browsers lie (masquerade), there are often new browsers based on the same rendering engines as other capable browsers that get shut out because they don’t have a known name etc. Sniffing, if done, should be done to weed out browsers that are known not to work, while assuming otherwise that browser X does, while offering a way to gracefully degrade.
http://www.sitepoint.com/article/dhtml-utopia-modern-web-design/4
http://www.b-list.org/weblog/2006/dec/18/sniffle/
Exactly!
Unfortunately the majority of developers doing this checks have stopped updating their knowledge at the turn of the century. At least it seems to be like this, otherwise user agent checks would have long been a thing of the past
I am afraid that the people developing browser checks just don’t have enought knowledge to actual code reasonable ones.
There are a lot of issues involved in doing any checks. Web developers do not generally check for capabilities even as much as they used to because it guarantees nothing. Browser engines are full of slightly different implementations, and just because a browser says it supports something it doesn’t mean that it supports a complete implementation.
Bug for bug compatibility is important in knowing whether something is going to work, and that’s why web developers tend to write and certainly test for specific browsers and engines especially for any complex Ajax type stuff. You can squeal about the rights or the wrongs of that, but that’s the way it is.
Sometimes I wonder why people assume that “web code” will miraculously be fixed again and again, whenever a new client side technology becomes available. History has shown that they “web code” will just be adjusted to check for this new technology explicitly
I’m afraid that’s no excuse for maintaining the status quo, and this doesn’t help KHTML now. This has been played out on umpteen KHTML bug reports – web developers are not going to pay any attention to a rendering engine with no significant share and one which will not achieve that any time soon.
Switching another browser to one of those render engines does not make the work automaically, it will just give their users an easier way to find a suitable override user agent
Ask yourself why you need to change the user agent.
The overriding motivator as to what user agents they will pay attention to is market share. In addition to Safari, Nokia’s and many other browsers will be utilising WebKit. If that is the case then web developers will check for the common denominator, which is ‘WebKit’. It’s that simple. In addition, bug for bug compatibility will ensure that it certainly can work.
They never pay any attention to rendering engines at all, they always only pay attention to browsers.
This is just an assumption.
Based on experience not a very likely one, they will continue to check for browsers with large enough market share, independent of the respective render engine being used in different browser.
As I said it will only make it easier to choose which browser to pretend to be.
I have given up on web “developers” actually understanding web technology. Right now they are just adding workarounds whenever something get important enough so they no longer can use an excuse.
Failed by not doing what? Becoming the rendering engine of one of the world’s top three browsers? :p
Amongst other things. The sad fact is that web developers are not going to ‘fix’ their code to accommodate KHTML or the inferiority of KJS at all, and that impacts KDE’s users and the developers who are using any web KPart.
But seriously, I am curious as to why you say KHTML “failed.” Was it not “good enough” for Apple to choose it to build off of for their Safari browser? Apparently not, otherwise Safari would be based on Gecko or something.
Apple hunted around for something different that they could say was faster than IE and Firefox.
I haven’t used KDE or Konquerer for a while; however, I saw no problems with the rendering of the pages in general.
You haven’t used it enough. KJS is a long way behind in terms of all the Ajax stuff out there now.
KHTML was a nice foundation for Apple. But just that: a foundation.
Apple did way more than just port KHTML to Cocoa. Compatibility and speed of WebKit are greatly enhanced compared to KHTML.
Well, I find it quite reliable, I have been using Konqueror as my main browser for years now.
I do have Iceweasel installed just in case but I often don’t need it for months.
Yes, it does.
It is part of the KDE libs and as such available until KDE5 can break API and ABI compatability again.
Well, I find it quite reliable, I have been using Konqueror as my main browser for years now.
Sorry, but you haven’t been using a whole lot of Ajax sites and those using a fair bit of JavaScript. GMail keeps breaking in Konqueror, and the only way to keep fixing it is to follow some Mozilla emulation more closely or to fiddle with the user agent string. That’s not sustainable.
Yes, it does. It is part of the KDE libs and as such available until KDE5 can break API and ABI compatability again.
No it doesn’t. It’s interfaces may well be there for the foreseeable future, but whether it will be used and maintained is down to other factors.
Edited 2007-12-27 21:40
Quite possible, I usually just visit sites for their content and do not check how they deliver it to me.
My browsing happits might be different to what other people do, I mostly use the browser for reading articles, participating in forums, doing online-shopping and internet banking.
Has been working fine with Konqueror for a couple of years now.
Yes, it does.
It might not be used but since there is no way of telling whether nobody is using it any longer and since it is part of the API/ABI guarantee, it has to be available and being available implies being maintained, if for nothing else at least for security reasons.
GMail keeps breaking in Konqueror, and the only way to keep fixing it is to follow some Mozilla emulation more closely or to fiddle with the user agent string.
Meaning what? That it would work if gmail thought it was another browser? Meaning that it’s perfectly capable but is being shut out because of its user agent? And how is that an indictment of the capabilities of KHTML?
If google is going to shut out a browser that would otherwise work, they will likely continue to do so even if it switches rendering engines.
Now I haven’t tried using gmail’s ajax view with konqueror for a while but last time I checked it did work. I’m away from my machine but I’ll check it out in a bit. If it does work (with agent spoofing) it’s hardly a good example of how KHTML is deficient is it? Of course that’s not to say there aren’t other sites where it might be.
Gmail isn’t the best example; frankly, I’m cynical enough to believe that Google is intentionally breaking compatibility with KHTML because it seems to happen after every KDE update. I don’t know what their specific agenda would be in breaking compatibility, other than their commitment to Mozilla, but since I’m cynical I don’t really need a justifiable reason to believe they’re doing it.
Spoofing as Safari generally worked well for me, but Google inevitably manages to find some corner-case implementation of their scripting that just happens to break KHTML, and forces the devs to scramble to fix it and push patches to svn. It would be fine if the breakage happened after Google added some cool new feature to the interface, but I’ve yet to see a correlation there.
As far as I’m concerned, the issue lies with the google devs likely trying to customize the interface to the nth degree for each of the major browsers, and discarding the rest. But pragmatically, that doesn’t solve my problem if the KHTML devs still have to scramble every time Google farts.
I like Konq, have been using it full time for a couple of years now, and I’d compare the site compatibility to Opera in terms of the rarity I see in not being able to render sites properly. But I don’t like the cat and mouse game, the devs won’t win against obstinate web designers, so ultimately I want something that will work and if that winds up being webkit in KDE/Qt, then so be it.
I’m not sure Firefox’s success is a real victory in my books, since instead of dealing with websites optimized only for IE, I’m now faced with websites optimized for IE or Firefox only. Since I don’t consider either browser a preferable option, then if webkit can at least leverage Safari compatibility, rather than standing alone as KHTML seems to do, I’d be willing to go that route, all due respect to the KHTML devs who I think have done a fantastic job given the resources they have.
I think you are a bit too optimistic. The lead developers for KHTML/KJS currently are doing their best to keep from using WebKit. It wreaks of egoism and frustration that they aren’t being given some prominent recognition for KHTML/KJS work. If one checks the source of WebKit it’s clear that KHTML/KJS is just one bit of a much larger project and growing daily.
It’s so f*cking ugly to read those “I want KHTML gone, hail WebKit” posts.
People who say that KHMTL sucks and needs to go have absolutely no idea of what open source really is.
Open source should be fun in the first place. People who spend their spare time to work on something they like.
You see, when you say that these people will just as easily move to another project, you’re mistaken. They like to work on KHTML and nothing else.
And when they work on it in the KDE repository, they can make their own roadmap, their own deadlines, their own progress etc… Do you think that people with limited time have anything to say on the progress of WebKit or can just start hacking on it?
WebKit takes the whole development process away from the KHMTL developers. It makes the KHMTL developer’s hands bound on their backs. The whole blablabla about WebKit reaching out to the KHTML developers and making it easy for them to hack on WebKit is just a nice wrapper around an ugly gift for them.
Using this or using that is just like religion, it’s personal, so keep your opinions for yourself. Expressing your opinion in such a way that you adore one thing and in the mean time hate another, you’re going to hurt a lot of people. Use WebKit if you want but don’t say that KHTML sucks.
If you were working on a project, spent all your free time in it, answered hundreds of questions and bugreports, etc. and you suddenly see lots of messages saying your project sucks and everyone should use the other project… how would that make you feel? Will it make you feel good? No, it will make you feel extremely bad. No wonder that the KHTML people want to defend their project. And yet, they are portrayed as people with big egos.
People who say such things probably have not achieved much in their lives so they have no idea what they say.
And don’t even try to compare a piece of software like WebKit with HTML.
WebKit is developed by Apple/TrollTech/KDE/GNome/Adobe/… and has probably more than 100 people working on it, many full paid professionals.
KHTML is developed by a few enthousiasts without corporate backing.
It’s like comparing my RF model plane with a state of the art F-35.
KDE is an incorporated entity. If you’d bother to do some research you’d find that they are funded and by some prominent corporations.
PDF Quarterly report:
http://ev.kde.org/reports/ev-quarterly-2007Q2.pdf
Excerpt:
“The KDE e.V. is pleased to report that Intel, Klaralvdalens Datakonsult AB, and Novell Inc. are now Patrons of KDE.”
Do you really think that all this Open Source development is done for the sake of Liberty alone? People write their career resumes by doing these projects. Many of these developers go on to work for such large corporations as Intel, Google, IBM, Red Hat, SUN, Apple, etc.
There are thousands of KDE Developers contributing to the KDE Project. Look it up on the statistics. These people do it because they love to learn as well as to improve their skills to which they later can charge much higher Consulting Rates to do Corporate work.
Edited 2007-12-27 10:07 UTC
He wasn’t talking about KDE but KHTML.
KHTML is a funded project under KDE.
It’s so f*cking ugly to read those “I want KHTML gone, hail WebKit” posts. People who say that KHMTL sucks and needs to go have absolutely no idea of what open source really is.
The only metric that matters here is what engine users want to use, what KPart KDE developers end up using and whether that component renders the vast majority of sites out there without trouble. Bug for bug compatibility with Safari would count for an awful lot.
No one is saying they want KHTML destroyed, because if KHTML did the above then everything would be fine. It doesn’t and it isn’t, however.
WebKit takes the whole development process away from the KHMTL developers. It makes the KHMTL developer’s hands bound on their backs.
No it doesn’t. The WebKit developers have made efforts to reach out, and if that isn’t good enough for the ‘KHTML developers‘ then they’re free to continue on their own. What users and other developers use is an entirely different matter, however.
and you suddenly see lots of messages saying your project sucks and everyone should use the other project… how would that make you feel? Will it make you feel good? No, it will make you feel extremely bad.
C’est la vie I’m afraid. That doesn’t give KHTML developers the automatic right to comment on absolutely anything about WebKit and tell us all that KHTML is still the default, that the WebKit people are so unhelpful, that QtWebKit is an irrelevant fork of KHTML and anyone who disagrees with that view is not a member of the ‘KHTML team‘. People will use what they want to use and the code will decide, ultimately. In fact, more of the original KHTML ‘team’ is contributing to WebKit these days rather than KHTML – people like Lars Knoll and George Staikos who have done so much for KHTML over the years.
And don’t even try to compare a piece of software like WebKit with HTML. WebKit is developed by Apple/TrollTech/KDE/GNome/Adobe/… and has probably more than 100 people working on it, many full paid professionals.
That’s exactly why it makes sense for KDE’s users and developers to use it, and incidentally, is why KDE uses the Qt toolkit in the first place. The number of commits to KHTML versus WebKit is simply not enough if you’re going to have an engine that people can reliably use every day, and that you can make an awesome KDE web browser out of.
Save your breath. Give this thread a week and you’ll find countless comments and ratings dropped from KDE devs running around attempting to prove such claims as false and that their are superior reasons for this or that not being adopted, yet they bitch that proprietary companies are unwilling to go more open source.
Pick the best solution, eh? I think it’s rather wise on Trolltech’s part to port WebKit and utilize it for it’s areas both in embedded markets and mainstream markets. They are a business afterall and as a commercial entity want to make money and not just off of consulting services.
Yes, they can. The WebKit trunk is in constant development. No deadline dictates anything, because when eg. Apple decides to release a new version of Safari in x months, they create a branch from the trunk and concentrate to work in that branch. It’s a similar development model that Mozilla uses for Firefox. A branch was created for Firefox 2.0 during the timeframe of FF 1.5 when the work on the trunk (what later becomes FF 3.0) continued.
Lies. WebKit is free software under LGPL just like KHTML. If (big *IF*) WebKit proved to be harmful for KDE, WebKit can easily be forked again into a new KHTML release. That way KDE would benefit from all enhancements made to WebKit and still have their freedom to do whatever they like with it.
But no, instead of porting WebKit to KDE (with Wallet integration etc), they continued to work on KHTML leaving their user with an inferior rendering engine.
No, it’s not like religion, because in KHTML’s case (unlike religion) you can measure how good it is. Speed and standards conformance can be measured.
In case of speed measurement I don’t even need a timer, because the speed difference between Konqueror and Safari (at least on my slightly older PC) is so obvious. It’s a difference of several seconds with any site. In extreme cases Safari renders a site in 2 seconds while Konqueror needs 10! (IIRC http://www.ign.com is such an extreme case.)