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
This is a special thanks, to you, for spending time for one hundred digests.
Whole community appreciates this.
Thanks DannyAllen, you rock.
( /me is so happy that dannya's exams went fine )
I'd also like to thank Danny for the time and effort he puts into the digest. It is always an interesting read, and I am sure the whole KDE community appreciates all of the work that has gone into it. Thanks!
Amarok 2.0 is starting to look great, it makes me want to get the svn version (regardless of how functional or buggy it is). As a matter of fact, it makes me want to start contributing to Amarok, but unfortunately I currently don't have the time. Here's a thank you to the Amarok developers for the most wonderful player in existence :)
Yeah. I love reading the digest!
Thanks a hundred times!
/Pascal
true!
thank you Danny, I love to read the digest
++
I always look forward to reading the digest!
yes, just another 'Thank you Danny !'
Do you still care to read them after a hundred digests ? ;)
100 thanks !
Danny, thank you very very much for all the work you do for KDE!!
Thanks for the Commit-Digest.
I second.. Thanks
Thanks Danny!!!
I love these snapshots. They're are a quick and easy way to check up on KDE's status. Being 1 week behind helps even, because it feels good that all the announced stuff is fixed and even further along than in the digest. :)
Yay for progress!!!
Thanks thanks thanks for your work :p
Yes, definitely many thanks to Danny for this ongoing series of digests.
As a KDE User and not (yet) developper, I always am very interested in reading it.
Philippe
Just adding mine: Thanks Danny
Seems to me that one of the most important parts was unmentioned in the summary:
"Port the WebKit part to the current Qt 4.4 snapshot. Now I am able to surf in Konqueror with QtWebKit!
It is not really usable at the moment because there are still some glitches / missing features."
"Work on WebKit integration" is the first thing I wrote ;)
Danny
btw.. how can I use the webkit kpart in konqueror?
I installed the library and desktop file (opensuse rpms) but haven't found out how to tell konqueror to use webkit instead of khtml
any hints?
Just found out... renamed the khtml.desktop and ran kbuildsycoca4 --noincremental.
Konqueror now uses webkit.
Great!
While some large pages (for example www.bild.de) are unbearable slow and buggy in khtml rendering mode (rather unusable), it really flies with webkit! Great :)
Would be nice to see it easily configurable to change to webkit rendering (or even make it default?)
I suppose that webkit integration is not planned to be backported to 4.0.x, so by the time, should webkit kpart be good enought, it may be default, but I don't see why one would urge defaulting to webkit wile it's not close to be released ( as it is available with little tweaks too )
Anyway, I'm starting to use some of KDE4 apps in my KDE3 environement, such as gwenview, dragon player, konqueror and sometimes dolphin.
I just miss kontact before I've 99% of my computer time spent on KDE4 apps ^^
Thanks devs for the progress, and thanks danny for the digest
I hope by the time for release kde 4.1 WebKit part will be in very good shape. I want to see what it can provide me which KHML can not.
Or what it can't provide you with that KHTML can.
For one thing working google apps... right now gmail, reader and others don't work well on konqueror :(
Ah, but wouldn't you still use Konqueror, thus still being mistreated by Google's browser check?
Do you think web "developers" will magically learn to check for engines instead of browsers?
Do you mean if I let konqueror pretend like Firefox all the Google applications will work smoothly ?
Yes.
No.
Try using gmail in konqueror sometime. Its very buggy and not very useful. I love konqueror, but any time I have to log into my gmail account I use firefox.
I haven't seen any bug reports to that effect lately.
I've found I need to spoof as Firefox 1.0.x for Gmail to work correctly. Spoofing as 1.5 or 2.0 doesn't seem to work.
Yes, but when you have the Webkit Kpart enabled, you should better pretend that your're Safari.
but there is no such problem because QtWebKit allways pretends to be Safari running on Mac OS X!
In my logs I see:
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.15 (KHTML, like Gecko) Safari/419.3 Qt"
It's neat because that way all the sites work because they think its Safari on Macintosh!
I wonder why Konqueror developers never thought of that?
Just pretend to be a popular browser and sites work better...
> I wonder why Konqueror developers never thought of that?
> Just pretend to be a popular browser and sites work better...
they did - settings | configure | browser identification
And this means server statistics will show you all as Mac users instead of GNU/Linux users. I don't think that's a good idea, it will destroy our market share estimates completely. As GNU/Linux is rarely sold in retail, the web server statistics are one of the best estimates we can get.
mhm, so that's the reason why apple's releasing safari on windows, to let businesses think they have a bigger marketshare than do actually do...
Well, as long as the sites work properly, and I do believe developers will work better if they have to try to be compatible to three browser engines instead of two, I am glad enough.
3? did we went one step future and also exclude Opera now? :-(
Opera is semi-excluded --- they have extensive features to work around broken
sites, in fact.
Systemsettings -> Advanced -> File Associations -> text/html -> Embedding -> Select Webkit -> Move Up (as often as needed) -> Apply.
Some dreaming:
This should have been an URL, so you could click on it and have the lowest possible config page opened... like system://settings/file_associations/text/html/embedding
Or even better a script, that also does the needed actions
#/usr/bin/skript
Object usedComponents =
System.Settings.FileAssociations.text.html.Embedding.UsedComponents;
usedComponents.moveToTop("webkit");
System.Settings.FileAssociations.applyChanges;
Something for another GSoC project?
There is kreadconfig (a command line tool). I've never used it (because I've never had the need of), but maybe it's worth a try.
thanks very much, it worked.
Do I need to enable an option while compiling? I am using the last qt 4.4 from svn and kde from trunk but do not have that as an option.
For anyone else that was clueless, webkit is in playground/libs
One thing I'm wondering: could we also solve the code duplication problem by, instead of wrapping QtWebKit in a KPart, implementing the QtWebKit API in terms of KHTML? How many APIs would need to be added to KHTML for that (if any)? Is anyone interested in trying to pull this off? In particular, are KHTML developers interested? (IMHO they should be, it'd instantly allow using KHTML in Plasma and Amarok.) The KHTML developers are giving good reasons why they prefer KHTML, so I think it could be useful to have it available as an option everywhere (even in apps coded as Qt-only, though they'd gain a dependency on KHTML that way, and the "some KDE APIs need KApplication" problem might come up).
I am not exactly sure of what you're getting at here. KHTML has a very rich API as is, and had it for years. No reason for apps like Plasma and Amarok not to use it (well, if there are reason, they sure as heck didn't communicate them to us).
nope, there are really no reasons. It's even damn easy to just decide at runtime. It works btw already pretty fine to embed KHTML into the Plasma-desktop: http://techbase.kde.org/index.php?title=Development/Tutorials/SuperKaram...
:)
That's pretty cool. Is that just using general QObject bindings or such?
y, signals, slots and properties. So, KHTML is already in a very good state to use it without linking against it what makes it pretty easy to deal with that lib :)
Can you arbitrarily rotate and resize the khtml pages with that? That would be neat :)
yes since it's a Plasma applet :)
I was impressed when I saw the iPhone commercial with webpages being zoomed in etc - I'm very pleased that Plasma can accomplish the same thing :)
I believe that Plasma is about the use of QGraphics*
So is it possible to display KHTML on the canvas like Webkit ?