|
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.
|
Inge Wallin and Torsten Rahn discuss the future of the Marble desktop globe application:
|
Marble is a lightweight, easy to use piece of software that brings geographic information to the desktop of everyday users. Currently the part of the framework behind Marble that has received most love by our programmers is the Marble Widget, which is a simple Virtual Globe that can easily be embedded into other applications.
While the Marble Widget itself is based on pure Qt4 code it is now being embedded into a real KDE application with all that entails (KDEPrint support, GetHotNewStuff support, and so on). As such Marble will become a prominent application in its own right in the KDE-Edu module.
The idea is that the central Marble visualization widget will be for geodata what KHTML/Webkit is for HTML: a component that is used everywhere geographic data is displayed, like in KWeather, Kontact, Kopete, DigiKam, KControl, KStars, KGeography, and on and on.
Torsten writes in his Marble manifesto:"'Where?' is a pretty basic question that computer users have got to ask and answer quite often - no matter what they are working on. [...] most people out there are not cartographers and don't want to be. [...] So for casual users there is still missing a fast, flexible, visually pleasing and easy to use map component. For developers, marble offers a light-weight, fast, cross-platform map component..." Also according to the manifesto, Marble should be: fast (right now it starts up fully within 2 seconds), visually appealing, easy to use, be able to fully work on all kinds of hardware wherever Qt compiles, usable online and offline and following free and open standards (like KML, for example). To follow these strict goals, Marble uses many advanced algorithms not commonly found in non-professional software.
It has also gained the interest of the outside world, and in this year's Google Summer of Code, it gained no less than 3 student projects:- vastly improved support for the KML markup language that is used by Google Earth (Murad Tagirov mentored by Torsten)
- a 2D projection mode (Carlos Manuel Licea Vázquez mentored by Torsten)
- support for GPS units (Andrew Manson mentored by Inge Wallin).
If time allows the latter will also include very basic support for gathering data from the OpenStreetMap Project.
At this time, the code is being cleaned up and adapted to the KDE coding standards by Torsten and Inge Wallin. Documentation is being updated to make it easier for the students who are starting to work on it. When this is done, the "Marble Universe" will contain:- The Marble Desktop Globe, a KDE 4 application for KDE-Edu. This application will show off much of Marble's full potential and also act as an educational program.
- The Marble Widget, a KDE 4 widget usable everywhere that geographical visualization is needed.
- The Marble Framework, a framework for providing geographical services for the desktop. It will provide GPS support for KDE and other backends that will help to detect the user's position on our tiny little planet (via hostIP, mobile devices, etc). Part of this framework will also be the "Marble Almanac" which is planned to be developed in co-operation with the Wikipedia Offline Client and as such will contain a minimal set of information about prominent places on earth (like demographic data).
While we certainly intend to have support somewhere in the future to display data from commercial providers, our primary focus is on providing and promoting freely available geographic data.
If you are interested in helping out, you can check out /trunk/playground/base/marble, or wait until it is moved into the kdeedu module, which should happen soon.
|
|
Will Stephenson provides a report on the "Phonon/Solid Sprint" event of the past week:
|
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. Much of the week was spent in API review sessions, where the developers, together with Lars Knoll, Simon Hausmann, Brad Hughes and other Trolltech engineers pored over each class and method line by line to ensure that naming and semantics are as clear as possible. The APIs were simplified to weed out redundancy, hide implementation details and make them as easy to use as possible, and to make sure they follow the Qt and KDE naming style so that programmers will be able to use them intuitively.
In the course of the week, Phonon was redesigned once, Solid Hardware discovery twice and Solid NetworkManager required three rounds of redesign until everyone agreed the APIs were as good as they could be.
The rest of the time the developers were at work carrying out the previous review's changes and ensuring that the previous decisions worked in practice. Given the scope of the changes, this involved some very late nights.
The resulting API is a lot slimmer than it was at the start of the week. Any functions which would only have been of use to a single application have been moved to new -experimental libraries, where they will form the base of platform libraries that exist outside of kdelibs. They will still be available but will not clutter the kdelibs API.
|
|
Martin Heni talks about the latest target of the kdegames scalable graphics drive, LSkat:
|
LSkat is now converted to full usage of SVG.
However, I made the SVG graphics only as a first draft as I am not very good at this. It would be good if an artist could improve them. Fortunately, it uses only a small amount of easy elements (mainly boxes and arrows).
For the artist: The input device icons can be the same as in KWin4. The trump icon #4 is meant to be the face of a "jack" card. The other trump icons can keep the card symbols and only need the background improved.
When an old PNG card set is choosen LSkat can use these old pixmap cardsets and scale them accordingly. Actually this looks not so bad! Probably we should keep the old cardsets for KDE 4.0 as there are some nice ones and I don't think we will be able to move them over to SVG in time.
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.
Card deck backsides are not yet available as SVG (or actually they are part of the SVG cardsets. We should discuss whether they should be available independently in decks/*. Currently the player can choose card set (cards-*) and deck backside (deck/*) to his/her liking. Using them both from one SVG file would probably bind them together (unless we render two files - which we currently don't...).
By the way, you need to update libkdegames to use this latest update!
|
|
Sebastian Trueg reports the inevitable: the first bugfix release of the K3b 1.0 series:
|
Hi folks,
We all know how it works: I release something, you use it and find all the bugs I never see because, let's face it, I am using (and testing) K3b in the same way as I develop it. The result is that I don't find those bugs. Praise the gods of open-source for this concept.
Well, then, K3b 1.0 was not perfect but I am working on it. So here comes the first bugfix release. But before I get into the changes in detail (see how I always list all small changes in bugfix releases but never remember what I did for a major release) I'd like to mention two users that helped tracking down one rather serious threading issue and one really stupid bug. Both Manoj and Antoon Tolboom patched and compiled K3b over and over again until we had tracked down the problems even though both of them do not compile anything on a daily basis. This again shows the power of the open-source approach.
Ok, on with the serious stuff: The ChangeLog:- Fixed crash when using the Device menu without a selected device.
- Fixed DVD copy when reading from a DVD+RW.
- Fixed --without-alsa configure check
- Fixed a crash in Video DVD ripping when the title does not contain an audio stream
- Only use the mkisofs parameters -biblio, -copyright, and -abstract if they have been set. Using them with invalid values (empty) seems to sometimes result in broken iso images.
- Better compatibility with recent transcode development branch
- Fixed Multisession import size handling.
- Fixed Lame quality preset handling.
- Made libk3bdevice really thread-safe. This fixes the disabled DMA bug!
- New configure check --without-cdrecord-suid-root to disable K3b's check for cdrecord permissions. Although not recommended it is requested by many distributors.
- Changed the order of the buttons in the tool dialogs to match the default KDE order.
- Added handling of the newly introduced genisoimage parameter -allow-limited-size
- Make the K3b Sox audio encoder plugin work with newer sox versions (Thanks, Stephan Binner).
Go ahead and grab the sources from http://www.k3b.org. Binary packages will probably surface soon.
Cheers,
Sebastian
|
|
|
![[*]](/images/standard/features)
![[*]](/images/standard/optimise)
![[*]](/images/standard/other)
![[*]](/images/standard/bugfixes)