In this week's KDE Commit-Digest: Heavy refactoring and work on merging translation branches in Lokalize (which is renamed from "Kaider", and moved from playground to kdesdk). Work on a question editor in KEduca. Work on real-time cloud imagery in Marble. An initial implementation of a new undo stack in KWordQuiz. The start of a KAlgebra, Rot13, KWorldClock, and Pastebin Plasma applet, with the inclusion of more functionality from KDE 3.5 (such as the multi-row taskbar panel) in Plasma. Progress in scripting support and functionality in Plasma. The "Now Playing" data engine and applet, and the fuzzy-clock Plasma applet move into kdereview. Viewports support declared "complete" on the KDE desktop. "FlipSwitch" window-switching effect in KWin. The start of a KIO slave for handling arbitrary NEPOMUK resources. Draft implementation of a KABC resource based on Akonadi. Wholesale merges from the enterprise branch of KDE-PIM back into the main KDE branch. Move to complete support for the MPRIS media player interaction standard, and support for Video CD's and Audio CD's in Dragon Player. Dragon Player moves from kdereview into kdemultimedia for KDE 4.1. Last.fm streaming radio now works in Amarok 2. Work on gradient editing in Karbon. The Kooka scanning application finds a new maintainer, with various initial improvements. KSystemLog moves from playground into kdereview. Krone, a simple expense manager for KDE 4, is added to KDE SVN. Read the rest of the Digest here.
Comments
Hi,
I haven't seen any news on Amarok 2.0 for KDE. Could someone please update me on the progress of that?
http://amarok.kde.org/blog/
Great job guys!!
Don't let the nitpicking discourage you. See it as a way of people showing interest and exitement about the project.
Keep up the awesome work!!!
> since K3b directly links the stdout and stdin file descriptors of
> processes such as mkisofs and cdrecord to gain maximum performance
> when piping data during on-the-fly burning.
Doesn't http://doc.trolltech.com/4.3/qprocess.html#setStandardOutputProcess handle what is needed to directly link those mkisofs and cdrecord descriptors?
> since there is also no way to use QProcess synchronously in a
> multi-threaded application
Well, that's the way Qt works - asynchronously by design. This might look quite annoying at the beginning, but it really pays off.
lg
Erik
btw... what about libburnia? Does it work in "real world" situations? Would it be an option to get rid of these QProcess calls and program output parsing?
lg
Erik
Hello,
how many media players do we have in KDE 4 now? From KDE 3 I remember kaboodle and noatun. Have they been removed or do we have 3 players (kaboodla, noatun, dragon player) now? I think this is two too many. (I'm talking about the apps included in kde multimedia etc.)
Kaboodle and Dragon Player are different kind of players with a different use case than Noatun, Juk, Amorak, Kaffeine etc. Since they are optimized for a different, but very common use case they should definitely be included too.
As I under stand it, Kaboodle is already removed. But Dragon Player should handle audio files nicely handling Kaboodles tasks too.
The only apps in kdemultimedia are JuK, kscd, kmix and now Dragon Player as well.
Amazing work Till! In shadow of KDE 4 eye candy there are great improvements to Kontact usability and feature wise.
Thanks to whole KDE-PIM team.
I wonder if there are any plans for APIs with pluggable backends for the following things:
1. extracting text from images (text recognition?)
2. voice recognition.
3. automatic translation of text from one language to another.
4. screen reading.
use cases:
automatically generate subtitles for movies.
automatically generate transcripts of interviews.
compile multiple narrative nicely into a single sheet of paper for history class.
create E-Books out of the hard copies you bought.
translate documents you receive into a language you can actually read.
brows ALL the web in your language, regardless of what language it was written in (including images!).
I don't know that KDE should have a library to extract text from images. I'm assuming you're referring to something like OCR, which should be more of a generic library that all desktops should be able to access.
Sonnet was working on language recognition as well as translation, and spelling. Too bad the original developer disappeared. I really hope it gets some love. It is so practical in how it could improve a great number of applications. I'd love to see it become a pillar of KDE 4 as much as Solid.
but I'd like people (maybe myself one day?) to be able to write applications for KDE that work on any platform, with any backend. what if I don't want OCR on my system and instead use something else? I wouldn't want to maintain different versions for each possible backend.
I really like the idea of Sonnet, and consider it as something that should be a pillar of KDE4. I'd also like KDE to switch as much as possible to pluggable backends, including spellcheckers. that means that I think Sonnet should be a backend for a language library. that way, if something better comes along, I could switch to it without any code modifications to the app that uses it. it would also give Sonnet time to be developed while using something else as a placeholder.