KDE Commit-Digest for 9th December 2007

In this week's KDE Commit-Digest: The "simple menu" (similar to the menu found in the KDE 3 series) becomes usable. The clock receives a popup-based calendar widget, with KRunner becoming multi-threaded in Plasma. Work continues the long-awaited update of KBugBuster, with important development milestones reached. Version Control and other general work in KDevelop. Start of a DirectShow (for Windows) backend for Phonon, and the integration of this backend in Amarok 2.0. Continued work on the BitTorrent plugin for KGet. KBlogger gets KWallet integration. The beginnings of a simple vector text shape with support for text-on-path and exact positioning, and the start of another painting framework in KOffice. A bitmap (BMP) export filter for Krita. Support for SVG animations in KDM. Important work on the KNewStuff2 framework, through the work of a new maintainer. Adjustments in colour schemes intended for KDE 4.0, more work on adapting icons to the FreeDesktop.org icon naming standard. Abakus, a calculator application, begins to be ported to KDE 4. KDE 4.0 Release Candidate 2 is tagged for release. Read the rest of the Digest here.

Dot Categories: 

Comments

by mactalla (not verified)

Thanks, Danny!

by Emil Sedgh (not verified)

+1

by shamaz (not verified)

+1 \o/

by Leo S (not verified)

Fourthded

by Anon (not verified)

5th'd!

More interesting news: people have tried KDE4 RC 2 on the EEE, and it runs very nicely - incredible as the KDE team probably haven't even gotten to the main optimisation phase yet! Check it out:

http://digg.com/linux_unix/KDE4_on_the_Asus_EeePC

by WPosche (not verified)

Amazing! I just ordered my Eee a few days ago and the shipping date in Germany will probably be January 10th. Well, I don't have to tell you the release schedule for KDE 4.0, so I guess it's just perfect timing.

by peter (not verified)

Very much so!

by LB (not verified)

Yes, thank you very, very much. The commit digest is appreciated as much as the development, translation, usability, artist, promotion and all the other great stuff that is happening in the KDE atmosphere.

by Peppe Bergqvist (not verified)

I'm glad to hear about the progress for nepomuk and I'm even glader to see that it seems to be in a runnable, usable state. This I hope can be a very usable "thingie"/feature in the kde4 desktop and I'm looking forward to try it out. Is this available in the RC2 or did I just miss it somehow?

I want to thank all the developers for all the hard work, the semantic desktop is coming closer each day;-)

by Federico Gherardini (not verified)

Disclaimer: Question not criticism!

I agree it all sounds very interesting. I was just wondering whether desktop search using strigi is already available in kde4. I've been playing with betas and RC's and I haven't been able to find a way to use it. I've also googled around but couldn't find anything. Is there a strigi applet in kde4 or something similar?

by Anon (not verified)

"Disclaimer: Question not criticism!"

Relax: Devs can tell honest questions from unconstructive criticisms :)

"I agree it all sounds very interesting. I was just wondering whether desktop search using strigi is already available in kde4. I've been playing with betas and RC's and I haven't been able to find a way to use it. I've also googled around but couldn't find anything. Is there a strigi applet in kde4 or something similar?"

Ensure that strigidaemon is running. There is a very primitive GUI called strigiclient which can be used to interact with the daemon and perform searches.

by mat69 (not verified)

Indeed!

This is one of the features I like most as it maybe will help me to keep my files a little bit more organized.
Ok, not really, but it will help me to find my unorganized files. :D

I'm afraid this is going to be another post that sounds like criticism, when it's mostly just curiosity.

From the post, it sounds like work is being done on amarok to make it use the phonon directshow backend? Surely the whole point is that phonon is used in an app once, and then backends can be added without changing the apps? Has there been an API change or something?

On another note... the talk of phonon implementing subtitle streams and multiple audio streams is making me think more and more of gstreamer. Don't get me wrong: those are necessary features, but doesn't it seem to be leading to the same inevitable reproduction of features to anyone else?

Again, no criticism intended; just asking questions because I'm sure someone has good answers.

Well, Phonon needs applications having use-cases to determine a sensible API and get everything to work flawlessly. I guess one of the developers of Amarok is trying to build it with Phonon on Windows and is coworking with the Phonon maintainer to make this work.
About the subtitle and multiple audio streams, I guess Phonon implements these only if all the backends support or otherwise implements some kind of capability detection. Phonon still adapts, so there is no reproduction of features.
Im just guessing though, im neither connected to phonon nor to amarok development.

Well, one key difference is that phonon would be able to support a bunch of backends. A gstreamer backend for phonon should eventually be available.

As for Amarok, my guess is that some Amarok developers are helping to create the directshow backend.

by Aaron J. Seigo (not verified)

> post that sounds like criticism

nah .. at least to me it sounded like curiosity and honest questions.

> work is being done on amarok to make it use the phonon directshow backend

no; rather a simple phonon backend was developed to allow amarok to work at its most basic level on windows. it stayed in amarok because it's a temporary solution, as the amarok people didn't want to wait on a full featured DirectShow backend emerging, which is understandable.

> the talk of phonon implementing subtitle streams and multiple audio streams
> is making me think more and more of gstreamer.

what phonon lacks is the high level abstraction APIs. these will be coming in future releases and will use the underlying capabilities of the given media frameworks as much as possible. that's why right now Video Player needs to access the xine backend directly: there is no high level API for it.

so it's not that phonon is going to implement ripping subtitle streams from dvd's directly, but it will provide an API for it that the phonon backends will then implement the support for; xine/gstreamer/quicktime/directshow/whatever will still be doing the heavy lifting there wherever possible. so in future Video Player (and others) should be able to use this high level API and not worry about the backend.

hth.

Just to add to what Aaron was saying, the APIs for subtitle access is already there and commented it out. It only adds a couple methods, its not a big deal. Which is partly why I feel OK about adding the Xine dependency back to Video Player, since it is a very slight dependency and will be easy to switch to 100% phonon with KDE 4.1.

This Commit Digest is apparently already out-of-date. Trolltech has released gstreamer and DirectShow Phonon backends already! http://dot.kde.org/1197535003

>On another note... the talk of phonon implementing subtitle streams and
>multiple audio streams is making me think more and more of gstreamer. Don't
>get me wrong: those are necessary features, but doesn't it seem to be leading
>to the same inevitable reproduction of features to anyone else?

Well, phonon is realy an duplicated layer, but is there for an good reason. Gstreamer people could not guarantee API and binary compatibility (this will come only after the 1.0 release, probably) for the entire KDE4 life-cicle (planed for 5 years), so an abstraction layer is needed to protect KDE aplications from those changes.

There is also the possible problem of mantainability. If, for some reason, Gstreamer development is stoped in comming years, it would be impossible to maitain +30k lines of alien C code, and the story of Arts will repeat. With Phonon, we can automaticaly migrate to the next greater mm backend, and not remain stuck with an unmanteined GStreamer.

by scroogie (not verified)

Thanks for the commit-digest! Theres a lot of interesting stuff this time! Just two little things: in the second paragraph you confused Robert Knight and Eike Beer (headline of kgpg stuff) and the link to kgpg40rc1.png doesnt work.

About Nepomuk: awesome project! i hope you get all performance problems under control. Will there be a possibility of defining own vocabularies? or connecting files with arbitrary predicates? There are so many possibilities with RDF!

by Danny Allen (not verified)

Fixed, thanks (that's what I get for moving stuff around ;))!

Danny

by tfry (not verified)

Hi,

I had closed on the order of 40 bugs the week ending Sunday, and b.k.o showed me as top bug-killer (still defeating my position). However, I'm not even listed in the bug-killer ranking in the commit digest. I want my bragging rights! (I already sent you a mail about this, but I just can't wait...)

Thanks for the otherwise great digest.

Regards
Thomas

by Boudewijn Rempt (not verified)

If you're thomas friedrichsmeier, your stats now show 72 -- way cool!

by tfry (not verified)

Yes, that's me. I'm afraid the number will soon start to decline, however, as I'm running out of easy-to-close reports in kate...

by Danny Allen (not verified)

Hey Thomas,
Sorry! There was an issue with the script which extracts the statistics from the bug page where it only looked for email addresses up to 40 characters in length!

Fixed now (and for future achievements ;))!

Thanks,
Danny

by tfry (not verified)

Thanks!

Thomas

by Lee (not verified)

I just realised that soprano (or at least sopranocmd) is in the kubuntu KDE4 rc4 packages I installed yesterday! That's GREAT; I'm going to have to play with that real soon :D

One thing though... it dumps its help to stderr, rather than stdout, which is strange and evil ;)

by Sebastian Trueg (not verified)

Hm, you are right. I should write the help to stdout. Well, let me fix that...

by Richard Van Den Boom (not verified)

Thanks for the Digest, Danny.
I'm 100% in favor of VideoPlayer integration in kdemultimedia. It's the perfect fast-loading media player you use to check a video or a music by double-clicking on the file or when downloading it from the web.
It is the perfect complement to apps like Amarok, which I use to organize my collections of music but which is not exactly suitable for fast view of media file.
A similar app to Amarok but for videos (allowing to organize collections and view them) would be great. I currently somewhat use kaffeine for that, but it's playlists should be improved. In fact, reusing somewhat the way Amarok works, but for videos, would be great.
Anyway, thank you all for your time and efforts, I'm really looking forward to KDE4.

BTW, one small question : is there any "migration" tool planed? Something allowing to recover many KDE3 settings when moving to KDE4, like passwords in kwallet, for instance. Or maybe it won't be needed?

by Iuri Fiedoruk (not verified)

Indeed great news about the menus.
Sometimes it's good to have multiple choices and let them eat each others ideas so a better one will prevail in people's hearts for the better of them all :)

by Ian Monroe (not verified)

Glad you like Video Player. :)

Not sure about it being the default for music files, its not really optimized for that. At aKademy this year, we were thinking about having adding a 'quick start' mode to Amarok where it would load a basic window and start playing the file immediately before loading the database and such. This way we can support the use case of a user quickly wanting to listen to a file, as well as the user who already has Amarok open or who wants to use its various features when launching a file from Dolphin or Konqueror.

For Amarok 2.0 we're working really hard just to get feature parity with Amarok 1.4, but I expect this feature will make an appearance somewhere in Amarok 2.x, where x is > 0.

by Leo S (not verified)

Video Player (well ok, I've only tried codeine) absolutely rocks. Best damn video player out there. The only time I ever use VLC is when I need to use the slow motion buttons, or if xine can't handle a particularly tricky wmv file.

Starts fast, super simple to operate, minimal UI, and the position saving rocks!

by DanaKil (not verified)

"A similar app to Amarok but for videos (allowing to organize collections and view them) would be great. I currently somewhat use kaffeine for that, but it's playlists should be improved. In fact, reusing somewhat the way Amarok works, but for videos, would be great."

I'd love something like that (like Amarok or KPhotoalbum) : you can tag your videos with custom tags, and view not only simple thumbnails but small "movie strip" (a few frames to have an overview of the entire video file)

Maybe something wich use the strigi data (video size...) too and you can search something like : "I want all my family video with a size superior to 100 mo and created before xx/xx/xxxx"...

by Bobby (not verified)

First of all thanks to you Danny for putting so much energy and time in the Commit-Digest, to give us a view of what is going on behind the scene.
Well at last I hope that we will get an end to the everlasting Kmenu discussions seeing that the KDE team has been listening to it's users. Big thanks and compliment to you guys!

Concerning the Kclock, I have just one question: There is the possibility to configure the present clock in 3.5x so that one can see the time in different countries when one moves the mouse over the clock, will this feature be in the upcoming version of KDE? I would rather have that than the train station clock that so many people are crazy for :)
Once again thanks and keep up the good work!

by Emil Sedgh (not verified)

You could add these train-style-clocks to you panel and desktop as many as you want and change the configurations and timezone of each of them.

by Bobby (not verified)

You are right but I think that the present KDE 3.5x style is more clean, clearly arranged and more practical. Instead of having a dozen clocks for a dozen countries I have one clock and with a mouse hover it gives me a popup menu which shows me the time in a dozen countries. I love this because I sometimes call foreign countries and instead of searching for their local time on the net all I need to do is move my mouse over the clock (of course I have to configure the time zones before).

by anonymous (not verified)

+1

by Aaron J. Seigo (not verified)

do you know who implemented the features you talk about, such as the popup showing all the timezones at once? me. know why? because i damn well needed it ;) so don't worry, it'll all be there eventually because i still need all that stuff =)

by Bobby (not verified)

Thanks very much Aaron, that put a big smile on my face :)

by Anon (not verified)

Ok, these kind of questions keep on coming up, so let's try for a generic answer - hopefully I'm not mis-representing Plasma and Aaron's plans for it, here.

"will this [panel] feature be in the upcoming version of KDE?"

In KDE3, kicker's design made it rather difficult and tedious for a programmer to implement their own taskbar, systray, menu etc, so it rarely happened: thus, most panel features came from the small team of kicker developers. If you wanted a new panel feature, you had to ask them and, if they didn't have time for it or flat-out vetoed it (as has happened with at least one request: many users hate that mouse-wheeling over the taskbar switches the currently focused app as it is easy to accidentally trigger it on a laptop touchpad, but requests for an option to configure this away have been denied), you were largely out of luck. Thus, pre-Plasma, this kind of petitioning the core devs with a "will you implement this?" makes sense.

Plasma, however, aims to make both the creation *and* the deployment and installation of new panel functionality (be they more exotic Plasmoids such as the Fifteen Piece Puzzle plasmoid, or generic ones such as a new, uber-configurable taskbar) much, much easier, so we no longer have to rely on the Plasma team to approve and grant requests. Think of it in similar lines to Firefox: people no longer have to petition the Firefox devs to add, say Undo Close Tab support to Firefox, or mouse-gestures, or a feature that makes all Dot comments flourescent pink: the framework allows such extensions to be easily created and installed, and this is precisely what has happened: all manner of handy and interesting extensions have been created, and the users and devs are much happier: users no longer have to depend on the whims of a core group of developers to implement their wishes, and the devs are free to worry about other things than balancing a mountain of conflicting user requests.

In short, Firefox's extension system has Democratised the Web, in that users can easily customise their web experience to their heart's content without having to depend on a small, harassed and potentially stubborn team of developers. Similarly, Plasma should Democratise the Desktop. I don't want to over-emphasise the similarity between Plasma and Firefox, here, as it smacks of false advertising, but to me personally, it seems that some of the parallels are very striking indeed.

So, in a post-Plasma world, you *could* ask if Plasma's clock with have feature $X, but there's really no need anymore; if there is a popular feature but they don't want to add it, then it's very probable that someone else *will*, and you'll be able to effortlessly install it regardless of technical skill via GHNS. Accusations of GNOME-ifying KDE (which for the record I think are groundless anyway for reasons that have been repeated ad-nauseum: Plasma is a from-scratch re-write of the desktop, and the devs simply haven't had time to re-implement the old features yet) become meaningless: Firefox presents a very simple set of features and configuration options by default, yet it's actual configurability as a web browser is, IMO, completely unsurpassed: if the default functionality and configurability does not meet your requirements, simply take the few seconds required to add more!

Hopefully this will put some fears to rest. Oh, and this shouldn't be taken as a statement that the Plasma team will be deliberately and lazily stripping out features just because more functional replacements can be added so easily: given time, I'm sure that the default Plasma interface will be just as rich as the KDE3 one :)

by Andre (not verified)

+1 insightfull

by Bobby (not verified)

Thanks very much for your simple, transparent and understandable explanation Anon. I think that I now have a clearer picture of plasma. It sounds like a very good, innovative concept. I was a bit curious for the simple reason that these implementations and configuration possibilities are still absent in the present release but I will exercise patience until the pieces of the puzzle are put together ;)

by Anon (not verified)

Thanks for your understanding :)

by Aaron J. Seigo (not verified)

things are absent because it's very hard to get all the pieces together to make what we are working towards possible. it took kicker, kdesktop and minicli 7 years to get where they are. we've had ~18 months to get the replacements in the form of plasma and krunner to where they are, and we're doing a number of rather more advanced things.

also, while kicker/kdesktop just lived with the warts and what not of Qt3, with plasma/krunner i've made sure that when things sucked we've dived into Qt4 and fixed things (many thanks to all the understanding TT devs out there =)

by ac (not verified)

"will this [panel] feature be in the upcoming version of KDE?"

"In KDE3, kicker's design made it rather difficult and tedious for a programmer to implement their own taskbar, systray, menu etc, so it rarely happened: thus, most panel features came from the small team of kicker developers. If you wanted a new panel feature, you had to ask them and, if they didn't have time for it or flat-out vetoed it (as has happened with at least one request: many users hate that mouse-wheeling over the taskbar switches the currently focused app as it is easy to accidentally trigger it on a laptop touchpad, but requests for an option to configure this away have been denied), you were largely out of luck. Thus, pre-Plasma, this kind of petitioning the core devs with a "will you implement this?" makes sense.

Plasma, however, aims to make both the creation *and* the deployment and installation of new panel functionality (be they more exotic Plasmoids such as the Fifteen Piece Puzzle plasmoid, or generic ones such as a new, uber-configurable taskbar) much, much easier, so we no longer have to rely on the Plasma team to approve and grant requests. Think of it in similar lines to Firefox: people no longer have to petition the Firefox devs to add, say Undo Close Tab support to Firefox, or mouse-gestures, or a feature that makes all Dot comments flourescent pink: the framework allows such extensions to be easily created and installed, and this is precisely what has happened: all manner of handy and interesting extensions have been created, and the users and devs are much happier: users no longer have to depend on the whims of a core group of developers to implement their wishes, and the devs are free to worry about other things than balancing a mountain of conflicting user requests.

In short, Firefox's extension system has Democratised the Web, in that users can easily customise their web experience to their heart's content without having to depend on a small, harassed and potentially stubborn team of developers. Similarly, Plasma should Democratise the Desktop. I don't want to over-emphasise the similarity between Plasma and Firefox, here, as it smacks of false advertising, but to me personally, it seems that some of the parallels are very striking indeed.

So, in a post-Plasma world, you *could* ask if Plasma's clock with have feature $X, but there's really no need anymore; if there is a popular feature but they don't want to add it, then it's very probable that someone else *will*, and you'll be able to effortlessly install it regardless of technical skill via GHNS. Accusations of GNOME-ifying KDE (which for the record I think are groundless anyway for reasons that have been repeated ad-nauseum: Plasma is a from-scratch re-write of the desktop, and the devs simply haven't had time to re-implement the old features yet) become meaningless: Firefox presents a very simple set of features and configuration options by default, yet it's actual configurability as a web browser is, IMO, completely unsurpassed: if the default functionality and configurability does not meet your requirements, simply take the few seconds required to add more!

Hopefully this will put some fears to rest. Oh, and this shouldn't be taken as a statement that the Plasma team will be deliberately and lazily stripping out features just because more functional replacements can be added so easily: given time, I'm sure that the default Plasma interface will be just as rich as the KDE3 one :)"

--------------------------

WOW, that's allot of delicate, but informatively intended words, even with concepts such as Democracy, GNOME<>KDE and easing fears added to them.

"will this [panel] feature be in the upcoming version of KDE?"

No, not likely, also looking at how delicate the responses are. Very likely, when there is a new bug reported about this, it will be supported again.

This is mostly a question of available time and priorities at the moment I think. This rather effective bug reporting process is how it used to work and how it continues to work so far. Now with the concepts and new realities of plasma, I bet your mother we can expect so many more cool things on the desktop, even when it comes to 'mere' clocks. Still, the concept of report bug -> arrive at feature, still very much is the same. The only thing that is changing is how larger and larger groups of people with different interests communicate on the Dot itself.

by chris.w (not verified)

Thanks a lot, Anon, for your insightful explanations. I'm really looking forward to cool things to come. Looking at what cool stuff the user community has already been creating for KDE 3.x (see www.kde-look.org), and combine this potential with the possibilities of Plasma, the future of KDE looks more than bright.
On the other hand, I don't think I'll recommend any average user to use KDE 4.0 as soon as it's release. It will be a great playground for enthusiasts and contributors, but most probably won't be anywhere near to ready for, say, my grandma. I think you should consider this in your marketing strategy, or else many people might get disappointed due to false expectations.

by sebas (not verified)

Thanks for stating the obvious. It's a bit light on the buzzword side, but still rather helpful. ;-)

by Luca Beltrame (not verified)

This reply is truly interesting. I recently proposed a Plasma FAQ and I was wondering if I could use these bits of information in the document (also properly citing you as well).

by Anon (not verified)

Please clear it with Aaron, first - I don't want to make promises he can't keep :) Feel free to use any quotations you want from the post. I generally prefer to remain anonymous, so you'll have to take my word for it that I'm the Anon you are responding to ;)

by Rudolhp (not verified)

"As every detail of KDE 4.0 seems to need a water-tight disclaimer these days, i'll just state that the green colour scheme shown in the screenshots is not the default of KDE 4.0!"

this is true, cut this message and past every site where a screen of kde4 appears.

and the integration of soprano is really nice, and thins like this http://www.kde-look.org/content/show.php/smart+file+browse?content=71417 could be possible ???