In this week's KDE Commit-Digest: Work in Plasma, with extra sources for the Weather data engine, work on the applet browser, and the start of SystemTray and RSIBreak plasmoids and a "next generation" application launcher, named Lancelot. Cut-down versions of Korundum and Smoke libraries for writing scripted Plasma applets. More interface work for Amarok 2. More work on XESAM (a shared metadata specification) integration in Strigi. An Akonadi resource for Facebook information. Support for compressed documents, and more work on DjVu support in okular. Several new features in the KRDC Summer of Code project, including bookmark support, sound output, and toolbar options. Custom text shaping in KWord, and significant progress in the colour mixing capabilities of Krita in KOffice. Various optimisations in KBounce, KPixmapCache, KDevelop, Marble and KOffice. KOffice 2.0 Alpha 2 (1.9.92) is tagged for release. Beginnings of a D-Bus interface in KTorrent for KDE 4. KNotes and Kompare begin to be ported, Kenolaba completely ported to KDE 4. Reworkings in Phonon, with the Phonon-NMM backend moved to playground/multimedia, as it is not ready for KDE 4.0. The Kaboodle music player is removed from the kdemultimedia module, whilst kaudiocreator moves to extragear for KDE 4.0.
Comments
Seems like the predictions saying KDE 4.0 will be more like a port to Qt4, with new things coming on 4.1 or 3.2 where mostly right :)
PS: I always said Plasma wasn't going to be on 4.0, now looks I'm wrong but other parts will be missing. I know saying that it irritates some people, more than once I was called troll, but it's better in my opinion to be realistic and don't create false expectations.
KDE 4.0 won't be *that* great and will miss a solid Plasma, Phonon and other things, but remember always 2.0 and 3.0, it weren't anything *that* good, but it leaded to a series of great successes.
Just porting to Qt4 and adding some minor features takes a lot of time, so be patient, we'll get there.
Phonon isn't out, one of the back-ends are out, namely NMM. There is still Xine afaik. And as KDE 4 matures there will probably be a lot more :)
but nmm ist the coolest backend !! :'-(
when was the last stable release of nmm and which distros ship it?
That some unfortunate and disturbing question you have to ask, but still NMM is the coolest alternative comparing the current backends.
The other backends don't really bring anything new, while both the technology and possibilities NMM brings are much more exiting. The vision of network-integrated multimedia are quite compelling.
While it may be great technology; you can hardly expect KDE to depend on unreleased versions of software. Think of the riots that would cause! :)
It may be useful if you can ask the nmm makers if there is something to release after 2 years since their latest release.
I was not expecting KDE to depend on it, even if I find the ideas behind NMM cool :-)
And thanks to Phonon, it's even possible to make NMM the recommended backend in the future when/if the NMM people gets their act together:-)
It seems there is. They just anounced the release of the 1.0.0 version:
http://lists.kde.org/?l=kde-multimedia&m=118708663022124&w=2
Doesn't magically make the phonon backend complete though.
Except you are still wrong.
Phonon-xine and phonon-gst still exist. nmm was just one of the phonon backends. Plasma is also there. Solid is also there. Oxygen is also there. Odd how that works.
> Seems like the predictions saying KDE 4.0 will be more like a port to Qt4,
> with new things coming on 4.1 or 3.2 where mostly right
then you evidently haven't used the beta much. marble, okular, krdc, the games, dolphin, system settings ..... all apps that are pretty well if not completely new in kde. kwin has seen tremendous work .. i could go on. the icon/pixmap cache, seeking in kio, solid and so many more additions to the frameworks which apps are already taking advantage of are also there right now.
so.. yeah. it's a lot more than a port to qt4.
> will miss a solid Plasma,
what you'll miss in plasma in 4.0 are the larger number of extensions that inevitably will only follow post-4.0 and the more advanced things like the networking layer which haven't been on the 4.0 target zone since i started planning what would and wouldn't be in 4.0.
will plasma be better in 4.1 and 4.2? well .. yeah. we're going to continue to develop it and do more cool and crazy things, but what is there will be solid and it will take care of desktop needs.
> Phonon
uhm.. what? mkretz and a handful of TT engineers sat around for the last 1+ week and did a thorough going over of the phonon API (again!) which will be merged into trunk this coming week. it's more solid and ready for production use than it has ever been.
the nmm backend was moved to playground because the *nmm* backend isn't near ready. the xine backend is quite there and the gst one, while needing some work, is also there.
a feature that has been postponed to 4.1 is video effects. that is due to reworking how the pipeline for those works in 4.0 so that we can actually do them properly in 4.1 (which means having to rework the effects stuff, which won't be there in time for 4.0). in other words, it's been made a *more* solid framework at the expense of having video effect plugins for 4.0 (which wouldn't have worked out all that great with the old api anyways =).
so i think you perhaps misread or misunderstood something there.
now.. all THAT said:
> remember always 2.0 and 3.0, it weren't anything *that* good,
> but it leaded to a series of great successes
this we agree on. 4.0 will be a lot like 2.0; much more than it will be like 3.0, actually. the number of new apps (inc the new file manager and desktop workspace, stuff that didn't get revamped as radically since 2.0), the immense number of important new frameworks and the likeliehood of 4.0 not being as stable as the later 3.x releases (for obvious reasons, e.g. the maturity that comes from being banged on by users and developers for years) are all ways it is similar.
and yes, 4.1 will have a lot of stuff over 4.0. ditto for 4.2. kde4 is going to have a long succession of great releases, each better than the last. but while you're concerned about setting 4.0 expectation too high, i'm concerned that you're shortchanging us all here.
i'm looking forward to 4.1 as much as they next guy, but 4.0 is going to be a damn sight better than you seem to consider.
> and yes, 4.1 will have a lot of stuff over 4.0. ditto for 4.2. kde4 is going to have a long succession of great releases, each better than the last. but while you're concerned about setting 4.0 expectation too high, i'm concerned that you're shortchanging us all here.
Lately everyone just takes everything I say here on the bad side...
I just wanted to express that I tough some people (me including) wanted *everthing* done in KDE 4.0 and that's not the reality.
Yes, I war wrong about Phonon, thanks my poor english and eyes hurting today for that, sorry.
I will not post here anymore, just read the news and posts.
Sorry everybody for being a problem for you all and posting foolishes, bye.
"I will not post here anymore, just read the news and posts. Sorry everybody for being a problem for you all and posting foolishes, bye."
Don't stop posting altogether, dude - just take the extra time needed to verify that whatever criticisms you make are accurate, and haven't been done to death already ;) Fresh criticisms are always welcome e.g. see http://dot.kde.org/1185753836/1185808183/1185884790/, and the (only one, admittedly!) reaction to it :)
> seeking in kio
Hmm... How many KIO slaves actually support seeking?
Good question. If its just HTTP and kio_file, I'll be happy.
Well, it's biggest advantage was supposed to be that the network KIOslaves wouldn't have to download a whole movie to watch it, so I suppose they do support seeking. But maybe just nobody got around implementing it...
Some HTTP servers don't allow seeking, if I remember correctly, but most do. I think it would be useful for desktop users to have seeking support for SFTP and SMB KIO slaves so as to make network access more transparent.
In addition to file, sftp and smb are the kio slaves that do support seeking at the moment.
Excellent! Thanks for the info.
I remember someone once saying the cd-ripping IO slave (can't remember what it is called) wasn't as good as it could have been due to KIO's lack of seeking support, so no doubt it is useful.
Oh Aaron, you and your "facts". Wild speculation is much more fun for these armchair quarterbacks who don't code and only troll. Don't ruin their fun by actually informing them of the truth. And how would you know anyway? Oh, you coded those things? Oh, hmmmm.
So things like the whole kde-games now using SVG rather than pixmaps. The whole slew of new features in okular compared to KPdf. Advanced composite support in KWin. The optimizing and rework done to KSysGuard. Inclusion and use of new frameworks like Solid and Phonon, change from KSpell to Sonnet. New applications like Dolphin and Marble. And lots of improvements and added features to many applications compared to their 3.5 versions. Are they just ports?
And if you bother to look on the statistics you'll see numbers indicating more than 5k lines modified and 1.5k new files, every week for months. I'd say that sums up to more than a port to Qt4.
You definitely have no idea about the entire development of KDE 4.0! And no, Phonon is not out, just the nmm backend. But the Xine backend is in place and working. Don't complain about things you don't understand.
The only things which will be not ready until KDE 4.1 are Decibel and maybe Sonnet - the last point is still not decided yet (afaik) and the first one was clear quite early.
The other technologies and especially the applications are in place already. And that the development will go on after KDE 4.0 is typical, everything else would be quite strange.
So why do you state things you have no idea about? This is exactly what trolls do.
Akonadi won't be ready either. And didn't Decibel already support KPhone? I didn't pick up that it won't be ready...
AFAIK Kcall was the first application which used Decibel and Kopete will use Decibel in 4.1
kcall was ported to Decibel, but Decibel itself won't be ready afaik, let alone kopete.
Anyway, Akonadi won't make it? That's new to me, do you have any link or something? I thought I will see kdepim released with KDE 4.0?
There was some discussion a while back on the kde-pim mailinglist about Akonadi being targeted at the 4.1 release. And releasing a kdepim based on the current backend for 4.0. Did a quick search, but didn't see any decision or a current status on the issue.
I would think they would do much the same for Kopete, they will release. And do the Decibel later, when it's ready. At least that sounds like a reasonable way to do it.
Any link for the concept behind Lancelot? What's so "next generation" at this application launcher?
Hmm, the name not starting with a K isn't next gen enough??
Not for my curiosity concerning rivaling solutions ;)
It wasn't supposed to go to the news... ever :)
Lancelot was supposed to be a testbed for no-click interface application launching, not (as everybody would think from this digest) a kmenu replacement...
like katapult !!!
Well, then, without the keyboard too :)
You're working on KBFX/Raptor?
No. I have a personal project. Actualy it's a PyQt-Application. I will port it to plasma (with some new features) in some weeks. It's nothing like an application-menu, more like apples taskdock, with some tabbar-magic, launcher-features and more efficient.
Looking forward to it ;-)
Me too!
:( Yet another missing K
I really liked the ability to quickly know an app intergrates with KDE>
+1
In the long list of new frameworks and apps I can remember by now (Plasma, Phonon, Decibel, Sonnet, Strigi, Dolphin, ...), only Akonadi, Nepomuk, and Okular have a "K".
It's a PR thing to get companies to choose KDE ratehr than anything else.
I miss the K, too, but there were people who thought it was becoming silly, and they seem to have had a majority (at least in voices).
As far as I remember, there was a simple guideline:
* If your app is a smaller library, use the k to show that it is mostly part of KDE and a seperate lib after that.
* If your app is strongly user-visible, don't use a K or don't put much focus on it (like amaroK went to Amarok).
* If your app is a main system component, don't use a K.
I would more vote for using ingenious K, like in Amarok, Akonadi, Nepomuk, and Okular. The K makes an app easily searcheable on search-engines.
For Plasma, Phonon and Solid it sounds OK, because they are the big backends.
For strigi, it's also OK, because it need not be KDE-only (no need to keep Gnome-devs from directly using it, just because tehre's a prominent K in the App), but if something depends on KDElibs, I think that it is very nice to have a k in it.
It gives the nice and warm feeling of home.
Any news on okular being able to display either pdf or ps files before 4.0? If not I assume kpdf and kghostview will still be supported? Loving all your work guys and looking forward to contributing in the future (especially using the python bindings)
huh, for me, PDF support doesn't compile, but it's there in the code. I guess some incompatibility or bug. But Okular sure begun life as a PDF viewer, and I think it's highly unlikely (eg: NO WAY) that it won't be able to view them...
Actually, one of the commits talks about supporting PS and PDF in compressed (tar.gz, bz2) form. Ow, and this support being tested. So it'll work, don't worry.
> Any news on okular being able to display either pdf or ps files before 4.0?
Okular has been supporting PDF for a very long time now, and that support will be included in KDE 4.0. Okular will be a significantly better PDF viewer than KPDF (interface and performance improvements, better text selection, lots of other stuff).
Awesome. :) kpdf is probably my favorite "core" KDE app already.
I've been using okular as default doc viewer (pdf, djvu...) for some time now. The only format I do not use it with is chm.
I think my problem is too many alpha/betas then. I try to use okular (beta) on opensuse 10.3 alpha7 and it doesn't show pdfs at all. Guess it would be a bit rich to complain given those versions :) I'm happy to wait as 3.5.7 is rock solid.
> I think my problem is too many alpha/betas then. I try to use okular (beta) on opensuse 10.3 alpha7 and it doesn't show pdfs at all.
I think your problem is not the alpha/beta/rc/whatever, it's just a distro issue, see http://www.kdedevelopers.org/node/2918
Did plunge into the kde4 svn via Gentoo's overkay (kde with 9999.4 ebuilds) and the thing that was very surprising to me was that when I made my initial merge in the 2nd of Aug last week, the amount of stuff that did not work started to work after doing daily svn rebuilds within some odd hours after I even noticed them... Amazing how the builds morph constantly at lighting speed, I can almost use the desktop already (heh, stuff like the legacy kicker eats 100% of cycles on one core while don't even start the apps from the menu, so I really hope that will be dropped and replaced with that Plasma version soon) and the only option is to start apps by "run command" via 2nd mouse button.
And of course Konqueror is somewhat useless, not only it stucks after the initial page load, but need to disable javascripting so it even renders the pages, but hey, that's life at "Alpha3" stage. :-)
Luckily there are apps that can take care of all the stuff I need using "the other toolkit".
I just wish either the overlay adds kdesupport/kdeplayground/kdeextragear to it's ebuilds, and/or stuff start to crawl to the kde's main packages soon. ;-)
Anyhow, the base structure in Qt4/kdelibs really do work like a dream (and stuff like konsole is way better than it's kde3 version).
Ps. and I hope kdenetwork starts to compile soon, haven't been able to compile it once, always stucks at "[ 43%] Building CXX object filesharing/advanced/kcm_sambaconf/CMakeFiles/kcm_kcmsambaconf.dir/joindomaindlg.moc.o".
Pps. oh yeah, and for some reason the kdegraphics doesn't find my exiv2-0.15 installation (installed as normal on /usr/include and /usr/lib64 dirs) so can't yet play with the cool gwenview that I had on my kde3 setup earlier.
Ppps. I'll start bugging the bigs.kde.org soon, just have to play around for a while first. :-)
Pppps. and sorry for the rant, just can't irc yet. ;-)
I broke KIO for a while. KDE 4.0 beta 1 cannot download anything properly. It corrupts the downloads.
It's been fixed already. Just upgrade again.
Actually after looking into why the kdegraphics doesn't locate my Exiv2 installation noticed that the top kdegraphics/CMakeLists.txt does have the check in place, but for some reason there is no actual check for it in kdegraphics/cmake/modules/, maybe there should be something like FindExiv2.cmake or something? Or is it intentionally left out to disable gwenview compilations (not ready yet)?
Other thing I noticed that is that the http://techbase.kde.org/Schedules/KDE4/4.0_Module_Status is way too lagging, maybe someone could check that out? And possibly adding ETAs for the stuff coming from playground/extragear to base KDE soon, like the Raptor (and kicker removal of course) and Plasmoids?
For example kdelibs has perfectly working kdelibs/cmake/modules/FindExiv2.cmake, so it has to be either a intentionally deleted from kdegraphics, or is just forgotten from moving gwenview to kdegraphics?