|
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.
|
This week saw the final adaptation of the "Simple Menu" (started off weeks ago by Robert Knight) into a working mechanism, by Sebastian Sauer. For all those menu-fanatics outh there, proof of this new development (and also of the clock calendar popup also added this week):
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!
|
Rolf Eike Beer talks about recent developments in a redeveloped KGPG application, KGPG2:
|
My name is Rolf Eike Beer, also known as Dakon on IRC and in KDE SVN. In real life I prefer my second name, Eike.
KGPG is a graphical frontend for GnuPG and has been shipped in the kdeutils package for ages. Since I felt it became orphaned I started working on it last year with a major boost this year. Before that I had done little C++ work and no Qt programming at all, so it is both an improvement in my programming skills as well as (hopefully) for the application. Currently there are three flavors of KGPG which I would like to introduce to you. I've taken three pictures of the same keyring with all three different versions so you can easily compare them.
KDE 3.5.x contains version 1.2.x (currently 1.2.2) which is the classical, Qt3 based application I have only touched very little. This version is considered stable for everyone and is only touched for bug fixes. There will be no new features for this series (at least from me).
The KGPG 1.7 series is included in KDE 4.0 and is basically a port of the 1.2 series to KDE4. It still uses the Qt3 compatibility classes and also suffers from some regressions compared to 1.2. The most visible one is that dropping a text or file on the systray icon does not have any effect as those icons are no longer a anchestor of QWidget. One the other side it has a number of improvements, some of them can be seen in the screenshot:
- The key groups are much more usable now compared to KGPG 1.2 as you can now expand them and see there members in the key manager. In KGPG 1.2 you have to open the group edit window to find out the group members.
- The key sorting has been improved for usability. On the top are always the key groups, followed by your private keys (not shown in the pictures) and the public ones. The signatures are also sorted to show the ones from unknown keys at last.
- There are more colors for the different trust levels so you can now distinguish between fully and ultimately trusted keys as well as disabled and expired keys.
In /branches/work/kgpg2 you can find a version of KGPG that will eventually grow into KGPG2. I just started porting this to model/view architecture and neither is this finished nor is it very usable. You can see that the old KeyListView widget is still around (the debris on the upper left) as well as the column headers are not set. The goals for this branch include:- full port to model/view framework
- port to gpgme or similar library where useful
- remove more limits, like where only one signature at a time can be deleted
- add some often requested features like editing or signing single identities
|
|
Ian Monroe provides a progress update on Video Player, the video application formerly-known as Codeine:
|
Recently, i've been working again on Video Player. The codebase of Video Player is nice and small, and so it's pretty easy to make significant progress. First thing I did was remove the remaining dependencies on KDE 3 Support and Qt 3 Support elements. I can't really say that the application is fully ported yet, but it is certainly no longer using any deprecated APIs. Thanks to some help from Matt Rogers of Kopete fame, it also no longer crashes on exit. In fact it has no known crashes, an important milestone with any software, though a state that's usually short-lived!
Phonon in KDE 4.0 will not have APIs for subtitle or multiple audio streams (like on DVDs and .mkv files). So Matthias Kretz added a property to the Phonon xine backend to give direct access to xine_stream_t, an important data structure in xine. I was able to use this property to add subtitle support for Video Player. Currently, it doesn't have any way of knowing when a new subtitle is available (for instance on a DVD, the title screen may have no subtitles, but then they are available when you start playing the movie), and it just asks xine every 5 seconds. Hopefully I can find some solution for this, perhaps from the Phonon xine engine or directly from xine.
This all means that Video Player will have a direct dependency on xine and the Phonon xine engine until at least KDE 4.1 (though it could probably work with other engines, just without subtitle or multiple audio streams).
Last night I re-added fade-out on exit (as seen in Codeine). And when I have more time, I plan on fixing up all the other little features that make Codeine great, mostly involving keeping state.
I think kdemultimedia has a need for a simple video player. Video Player would fit this niche nicely. I hope to make some indepedent releases and then with community approval be included into kdemultimedia in KDE 4.1.
I actually do have an idea for a less generic but still simple name for Video Player, but i'll keep it private until I buy the domain.
|
|
Sebastian Trueg writes a report on the status of NEPOMUK in KDE 4:
|
After months and months of development, Soprano, the RDF storage framework all of NEPOMUK is based on, has finally reached "release candidate" status. Version 2 is nearly a complete rewrite of Soprano 1, and brings a lot of nice features, including a full-text index based on CLucene, which indexes all RDF literals. Soprano has storage backends for Redland and Sesame2.
Yes, Sesame2 is a java RDF store, I know. Anyway, I would hope that until we have a proper (i.e. fast) C(++) implementation of an RDF store, distributions could ship Sesame2 as its performance is so much better than Redland's (especially regarding queries).
Soprano of course has a nice D-Bus interface when run as a daemon. Each RDF model (one big graph of RDF quadruples) has one D-Bus object. Querying the model creates a new object which has an iterator interface. The best way to test that is to use the powerful 'sopranocmd' command-line client. Or if you are within an application, just forget about D-Bus and let Soprano handle it all internally using Soprano::Client::DBusClient and Soprano::Client::DBusModel (Actually this is done internally by libnepomuk when using Nepomuk::ResourceManager::mainModel()).
Well, so much for Soprano, the data foundation of it all. What has happened in SVN? We now have the NEPOMUK Server in kdebase/runtime. NEPOMUK Server is a KDED module which provides the NEPOMUK data store (based on Soprano) and controls Strigi. The latter meaning that it starts and stops Strigi (well, at least tries to stop, as Strigi does not actually like being stopped and is a D-Bus autostart service anyway. But we will get there! ;))
With the KDED module comes a configuration KCModule called "kcm_nepomuk" which allows to enable and disable both Strigi and NEPOMUK. Disabling NEPOMUK makes Strigi use its plain CLucene backend instead of the NEPOMUK store.
Yes, Strigi can now use the NEPOMUK store as data backend. Thus, metadata indexed by Strigi and metadata created through NEPOMUK (like tags or ratings) can be queried in combination. And thanks to the CLucene full-text indexing in Soprano queries are as fast as they are with the default Strigi backend.
I also did some development in playground again: in playground/base/nepomuk-kde/filewatch you can find yet another KDED module which updates the metadata when files and folders are moved or deleted. As it is based on inotify, you may run into problems with more than 8000 folders in your home directory. Any help for improvement is greatly appreciated.
As for the NEPOMUK library - which is used by Dolphin to do the tagging and rating and so on - I am currently experimenting with some caching methods. It looks promising.
Ok, enough talk, I did a little screencast. Actually I made it for an internal NEPOMUK project presentation, so there is quite a lot of RDF to see. But maybe it is of interest to you, too.
As a final note I would like to say how happy I am that I get the chance to introduce NEPOMUK technology into KDE.
|
|
|
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)
![[*]](/images/standard/bugfixes)