In this week's KDE Commit-Digest: A week-long Phonon/Solid developer sprint redefines and strengthens their API's. The start of a command-line client for Strigi. Continued improvements in the Konsole refactoring work. More work on visual effects in the KWin window manager composite support branch. Experiments to utilise Solid for connection management in Mailody. Initial support for the Jamendo music service in Amarok. A KDE frontend for Marble is begun, to complement the Qt-based original interface. LSkat, KLines and KLettres get support for scalable graphics. SuperKaramba now supports widgets written in Python and Ruby using Kross - Kross is now the default scripting engine for SuperKaramba. Kiriki is moved from playground/games to the kdegames module. The Guidance utility suite is moved to the extragear module, becoming the first non-C++ application in KDE SVN.
Comments
"Matthias Kretz, Kévin Ottens and Will Stephenson spent the week in Oslo as guests of Trolltech. The goal of the week was to apply Trolltech's expertise in API design to the Solid and Phonon APIs."
Cool! Many thanks to the Trolls. Are all of the KDE4 API:s similarly reviewed?
i would like the nepomuk api included for kde4.0
It is being integrated into KDE 4, however as with many APIs, they will only really mature as the apps start to take advantage of them... so NEPOMUK may not have a huge visual presence in 4.0
Recently there are more and more webpages showing up which redirect you automatically to your local language. Would be a great idea if those pages were all of the same quality. Unfortunately they aren't. Sometimes they contain older news and sometimes the language is just strange. Don't you hate it to read such strange word-by-word translations of English expressions like "spread the word". They would rather keep those pages in English if they are unwilling to invest in proper translation. I rather read a foreign language than really bad German all the time.
It would'n be in english but in french, Jamendo is a belgium (fr side) website :)
But it's support in amarok is, well, finaly pointing out :)
Amarok will hopefully suport more than just download + listen music, as jamendo is a whole plateform for musician to get famous (whith date of concerts, criticism of albums, ..., oh, and lirycs)
The Jamendo support is currently VERY preliminary, and as I wrote in the intial commit message, the main reason I started is now is to mature / refactor the service framework that will hopefully allow many more services like Magnatune and Jamendo to be easily integrated into Amarok.
As for supporting more than just listening and downloading, this requires a more flexible way of getting data from the Jamendo site, as the xml file I am currently working with does not contain much of this information. (except for lyrics for some tracks). It might be possible to parse the site for some of this info though...
Anyway, I have pretty big ambitions with regards to integrating services into Amarok, but am limited by the time available and the multitude of interesting services out there... Hopefully, when the framework is a bit more stable, more people will be interested in adding and maintaining services
Well, actually it is a Luxembourgish site, not a French one ;-).
Checkout: http://www.jamendo.com/en/static/contact/
> When a new SVG cardset is chosen it uses the full SVG capabilties. Unfortunately, using so much SVG rendering is not exceedingly fast. KPat uses threading and pixmap caches to speed this up: Maybe it would be useful to have something like this in the kdegames libraries.
Both plasma and ksysguard also cache etc do speed up svgs. The best thing way to do this is for everyone to use Plasma::svg (that aseigo wrote) so that we can have a common caching etc class. Perhaps kdegames should use this?
plasma::svg is part of kdebase/workspace, and therefor cannot be relied upon to be present on all platforms (as workspace is only present on unix/X11) and kdebase is not a requirement for running programs from kdegames, for instance.
Better solution would be to make it more generic, and put it in kdelibs... that deadline, however, is very rapidly approaching... you should probably talk to Aaron about this...
i think my quad core can handle your tiny svg's perfectly - please but your effort somewhere else
Not everyone has quad cores... I'd rather KDE 4.0's minimum requirements to not make Vista's look low end...
right now i'm really only interested in working on this functionality for apps in workspace/, the reason is that we can experiment more aggressively there both with APIs as well as techniques.
once those classes mature and prove themselves, them i'll look to see if they make sense for kdelibs. in particular: are there enough apps that would benefit from these classes, and benefit enough to add to the size of libkdeui.
that's been my plan from the start with libplasma, and so far it seems a sensible one.
so maybe for 4.1 =)
This is not strictly necessary, many games in kdegames already have their own caching mechanism for SVG elements, and in some cases optimized for the usage pattern of the game. Most games that are using SVG have some sort of cache manager that leverages the QCachePixmap class in Qt, and some go one step beyond and even cache rendered backgrounds between sessions, so the game starts faster the next time it is launched.
I have been a Linux/KDE user since mandrake 5.3 festen ( I still have the linuxmall disc!) And I always loved the way KDE worked/works, I like the idea that it doesn't treat the user like and idiot, that I can adjust anything I like or lock down the DE for people that actually need it to be locked down :P
In my opinion, it has the best integration than any other DE, most all KDE apps are complete and useful, love the feature of getting new content seamlessly within
various apps like wallpapers and kopete. and oh! the magic that is kopete, what a sane app, Ktorrent is looking real nice, still uses alot of my system resources though,looking forward to future releases of this torrent client. but still better in my opinion than having to install that slow Java bittorrent client.
K3B, there is nothing to say about K3B except Sebastian Trueg and co RULE!
I really have to thank ALL of the developers of KDE, Without you I probably would have never stuck with Linux much less made it my only OS.
P.S.
Amarok, the only music app I have ever used on a daily basis. it's worth is that of 50 proprietary music apps!
The Guidance tool looks very intersting. I need to test it :-)
I wonder if there is any cooperation between the Guidance developers and the distro@s? Thay all have their own different tools taht does basically the same. There should be some common ground and devlop toghether here?
Birger
Not sure about others, but Kubuntu uses Guidance extensively.
Great to see Marble coming along, might be time to jump in soon, but my one question is why the base widget is going into the Edu module? I'm sure KWeather, Kontact, Kopete, DigiKam, and KControl don't want to be dependent on the entire Edu module just get the base widget? How is this going to be organised?
Cheers!
John.
This is a good point. Perhaps the notion is that Marble is a bit heavy for kdelibs?
Hi Odysseus,
> Great to see Marble coming along, might be time to jump in soon,
We'd certainly be happy if you jumped in to help.
I'm always trying to gather the latest information about virtual globes on other websites and as such your biggest contribution to Marble so far has probably been http://www.kartographer.org which contains quite some ideas for inspiration ;-)
> why the base widget is going into the Edu module?
The idea is to let it mature there as an educational application first. Later on once it proved to be ready for real-life purposes I'd like the backend to move into a more central place where it can be used by other applications as well. So it's rather a matter of not jumping the gun and doing everything step by step.
Torsten
I see SuperKaramba is still evolving and got new features included. That's very surprising since I thought it was planned to be superseded by Plasma ?! Can someone explain what is happening ?
Is it still evolving for compatibility reasons with KDE3.x's widgets or... ?
SuperKaramba is still being developed so that when people start to use KDE 4, they will still have the ability to run their widgets if they choose. Yes, Plasma is supposed to supercede SK, but it doesn't hurt to keep existing functionality available for users that would like to use it in future versions of KDE.
We also try to limit features unless they are bugfix related for the most part as we don't want to "take Plasma's thunder" if you get my drift.
The kross work is to demonstrate the ability to write bindings quickly for applications. For more of the reasoning and explaination behind that, stop into IRC and talk it up in the #superkaramba channel on irc.freenode.net. I'm personally not the one that did the kross work, so please ask in the channel.
Thanks for listening.
-Ryan aka p0z3r
http://www.p0z3r.org
While Ryan already provided a very good reply, I like to add, that you probably shouldn't see it only as SK improvement, but also as one for Kross... SK does have very good use-cases for scripting + working scripts for testing + an already working implementation (those based on python) to compare with and the SK-team did everything related to the SK-internals (thx btw) while most of the work that was done by me, was done at the Kross backends and are therefore reusable anyway. So, all in all this looks like a win-win relation to me :)
there seem to be a cool developement in kwin. will this go in a 3.5 release or do we have to wait a year to get this on our computers?
You'll have to wait :) Additionally, this development is still happening in a branch in order to not destabilize the development environment for other KDE 4 coders. Lubos' plan, last I checked, was to merge before 4.0 ships, though it needs a good configuration interface to all of the neat stuff that's in the works...
From Lubos' blog on kdedevelopers.org:
"And finally, since the kwin_composite branch, while still far from being done, is not really different from trunk when compositing is disabled, it will be merged soon back to trunk, defaulting to compositing turned off."