KDE Commit-Digest for 18th February 2007

In this week's KDE Commit-Digest: The Dolphin file manager is moved into kdebase. Continued work in Umbrello courtesy of the Student Mentoring program. Graphical element representations start to be introduced in Kalzium. More new country maps in KGeography. KSpaceDuel begins the porting process to a scalable graphics interface, with further SVG integration work in KMines, KWin4, KNetWalk, KBlackBox and KMahjongg. KolourPaint gains the ability to interface with image scanning hardware. Improved handling of the XPS document format in okular. Lilypond export functionality in KTabEdit. More work in the KDE Fonts Manager. The KNewStuff2 framework reaches new milestones in its reworking for KDE 4.


As usual thanks a lot to Danny for the commit-digest which helps reducing the waiting time for KDE 4 :-)

By the way: great to see that my favorite game (space duel) is ported to KDE 4 - thanks to the coder who makes this happen!

By MK at Mon, 2007/02/19 - 6:00am

I concur, Danny. You spend so much time on this thing every week, it really is a great piece...

/me raises a glass...

By Troy Unrau at Mon, 2007/02/19 - 6:00am

Any plans to move KGeography to vector or SVG map formats, possibly by using Marble? They would be far easier and more flexible and offer opportunities for new features. CIA Fact Book and Wikipedia integration might be good too.



By odysseus at Mon, 2007/02/19 - 6:00am

yeah, that sounds reasonable

By matt at Mon, 2007/02/19 - 6:00am

AFAIK, Marble is pixel-based.

By Sebastian Kügler at Tue, 2007/02/20 - 6:00am

No, it's not. It's a combination of vectordata as well as pixel data. And Odysseus is right that it would indeed make much more sense to make use of that data (instead of "drawing" static maps that don't share a coordinate system by hand in a pretty non-standard format).

Torsten - just started to work on Marble again ...

By Torsten Rahn at Wed, 2007/02/21 - 6:00am

Dirk Stoecker committed changes in /trunk/kdenonbeta/pixieplus/app:

Wasn't pixieplus mosfet's invention? I thought it had disappeared in just the same myterious way as mosfet himself. I sometimes wonder what he's doing today.

Fortunately, we now have a new graphics god named Zack :)

By Anonymous at Mon, 2007/02/19 - 6:00am

Yep, one and the same if you check the CVS.

I do agree on the God-like properties of Zack on the graphics front. Very cool stuff comes out of his direction lately!

By Andre at Mon, 2007/02/19 - 6:00am

Speaking of which. Does anybody knows what's made of Mosfet this days.
He did some really cool stuff for kde.

By RandomOne at Mon, 2007/02/19 - 6:00am

2 questions about Dolphin:

1. Is the purpose and scope of Dolphin written somewhere? For example, will it always be a simple(r) file manager, how does it expect to deal with possible added functionality, such as a shortcut for a distro's package installer. And could a "webbrowser mode" ever be added or not? Note: these are NOT feature requests of mine, just want to know which direction Dolphin is going exactly.

2. Will it be possible to use Dolphin in a consistent way instead of Konqueror all/most of the time? For example, I'm using Dolphin on my desktop now (kicker shortcut to it), but most programs will still launch Konqueror when they need a file manager. So I find myself half of the time in Dolphin and half of the time in Konqueror when I actually want Dolphin.

I love the Dolphin layout, but 10% of the time I do use Konqueror though, because of certain added functionality it has. So how does KDE intend to make its desktop more consistent? Another example is the Mac OSX-style taskbar, which only shows menu items for certain programs (I think only the KDE ones, e.g. Audacity and Firefox don't have a menu).

By Darkelve at Mon, 2007/02/19 - 6:00am


> 1. Is the purpose and scope of Dolphin written somewhere?

I think Aaron explains it quite well on his blog: http://aseigo.blogspot.com/2006/12/on-oxygen-on-dolphin.html. On the official Dolphin home page you can find some further informations: http://enzosworld.gmxhome.de. Please also have a look at the 'News' section, where I tried to summarize some things concerning the move to kdebase.

> For example, will it always be a simple(r) file manager, how
> does it expect to deal with possible added functionality,
> such as a shortcut for a distro's package installer.

Dolphin will focus on being a file manager only, which is easy to use. But this does not mean that it will offer less features: if features are requested by users we are open to include them...

> And could a "webbrowser mode" ever be added or not?

... except for the feature of webbrowsing ;-) Seriously: Dolphin does not and cannot replace Konqueror. As Aaron explained on his blog both applications have a different target group of users.

> 2. Will it be possible to use Dolphin in a consistent way
> instead of Konqueror all/most of the time? For example,
> I'm using Dolphin on my desktop now (kicker shortcut to it),
> but most programs will still launch Konqueror when they need
> a file manager. So I find myself half of the time in Dolphin
> and half of the time in Konqueror when I actually want Dolphin.

This is already possible in the KDE3 version of Dolphin. Please check the FAQ section of the Dolphin manual how to configure this. For sure it will be also configurable in KDE4 whether Dolphin should be started as default or Konqueror.

Best regards,

By Peter Penz at Mon, 2007/02/19 - 6:00am

Well, as I said, these were not really feature requests. More like, I'm thinking about my own workflow, and Dolphin fits in there, but webbrowsing, I don't know.

And about features, I understand you will not cut down on features for the sake of usability? I'm imagining over a dozen 'action' icons in the "Information" sidebar. Then again, the Dolphin developers probably are sensible enough to prevent those things :p
Or, in yet *other* words, the reason I like Dolphin is because it's so clean and simple. I hope it stays that way :)

About sharing code with Konqueror, I think I already witnessed that: I've installed mplayer-thumbs on my desktop, and in Dolphin they show as well. Which is very nice B) Personally I use that for my Video folder.

Oh, and thanks for the info.

By Darkelve at Mon, 2007/02/19 - 6:00am

these 'actions' depend mostly on installed .desktop files and services. So cleaning up those will help dolphin, but there isn't much dolphin can do when users install a 100th of these desktop files...

By superstoned at Mon, 2007/02/19 - 6:00am

For a user (God I hate that word) it's his own decision. But I hope the KDE developers won't end up putting dozens of these actions (slight exaggeration) into Dolphin *by default*. Well, not unless they can keep Dolphin clean, simple and efficient.

By Darkelve at Mon, 2007/02/19 - 6:00am

Or distributions, for that matter.

By Darkelve at Mon, 2007/02/19 - 6:00am

i have a question on the whole recueing dolphins. do they go back into the wild?

By chelsy at Tue, 2008/04/22 - 5:00am

Just wondering how do Khalkhi and decibel relate to each other. Do they overlap, can they just live next to eacht other?

From the article "Most applications currently have their support for actions on persons and their state, like email or chat, hardcoded", isn't this what decibel is about?

By Richard Bollinger at Mon, 2007/02/19 - 6:00am

As far as I understand, Khalkhi is a contacts database, while Decibel is a framework for communicating with someone else (typical use case, collaborative editing in kword/whatever between two distant computers), Decibel will (hopefully) retrieve contact information from Khalkhi.

By Cyrille Berger at Mon, 2007/02/19 - 6:00am

Khalkhi and Decibel are suppossed to work together :)

For KDE4 Khalkhi is going to have two aspects: The person data layer and the services. The person API layer is planned to become the successor of KABC, that is, a convenience layer around the data about persons stored in Akonadi, so one has in her code only to deal with classes like Persons, Groups, and lists of them. The services thing is what Khalkhi is basically for KDE 3, the option to offer all possible actions on a person or seeing all states there are plugins for, without needing to know anything about the semantics. So KAddressbook would offer chatting, without really needing to know about it, because the semantics do nothing to the logic of the program.

Decibel would deal with both aspects, too. It has two kinds of data that are stored for Persons, statics like chat address, and dynamic/volatile like the presence status. These data might either be stored and retrieved through the Khalkhi layer, or directly in Akonadi. But that needs to be worked out, discussion is just starting.

Then there should be Decibel service plugins for the Khalkhi services. Programs that need the semantics of chatting or other realtime data exchange would work with Decibel directly. As the Khalkhi service plugins have a "DoNotShowIn=X" parameter Decibel services for Khalkhi and Decibel should never conflict :)

By Frinring at Mon, 2007/02/19 - 6:00am

still, this isn't clear to me. could you elaborate on this a bit more, maybe even with a graph and/or some examples?

By superstoned at Mon, 2007/02/19 - 6:00am

Oha. So I will see to find some time to add some documentation. I was trying to concentrate on the code, because running code and programs should be the best description ;) Might take me up to three weeks, so please be patient.

Could you help and say what is clear and what is hard to understand so far?

Perhaps it also helps to read what got me started into Khalkhi:

By Frinring at Mon, 2007/02/19 - 6:00am

Reading through your blog (I read it before), it sounds very similar to decibel, as far as I know it. Though decibel has a daemon and is more focused on cooperation, your framework seems more focused on managing and accessing the data and contacts, closer to Akonadi, perhaps. It seems to me what Khalkhi does could be done in several ways - it could be a like Khalkhi is now, a 'doorway', easy API around Akonadi, cooperating perhaps with Decibel. But it could also be integrated in Akonadi, or in Decibel, right?

I'm not sure if I got this right, and even if I get it, I'm not going to argue for any of these three roads. Why? I think it's more important to have you on board for KDE 4 - developing stuff, adding ideas (which might be even more valuable) than to have two instead of three API's each dealing with contacts/presence/data/etc from a slightly different, perhaps sometimes overlapping, point of view.

Of course, overlap means duplicate work, and you guys (not just you but also Thobias and the Akonadi dev's) should avoid that. But as it seems to me now, having these three, each focused differently, can only enhance innovation and new ideas. So I urge you to get in contact even more with KDE4, get your stuff in trunk, get it for review, and available for the KDE 4 developers. Working together will ensure possibilities are maximized, constraints are minimized, and more fun of course ;-)

And are you going to FOSDEM? We could have a talk, set up an interview, get this on the dot as a news article or maybe part of the pillars of KDE 4 series (I don't make them but I'm sure Nathan wouldn't mind if I tried to help ;-))

No FOSDEM - still an article could be usefull. Explain the differences, advantages, disadvantages, possibilities, ideas...

By superstoned at Mon, 2007/02/19 - 6:00am

No FOSDEM for me. And an article, once Khalkhi works and is far enough to get into any release, perhaps in the end of march. Until then it stays just one of the halfbaken things around, not ready for consumption ;)

Khalkhi will/should be to Akonadi, what KABC is to the KABC resources. So being the layer around Akonadi for data of persons means integrating with Akonadi.

The difference to Decibel is that Decibel cares for the stuff that has the semantics of realtime (a)synchronous communication/data exchange, nothing more, nothing less (AFAIU). Khalkhi/Akonadi stores everything without looking at the semantics, the data are just blobs, interpreted by handler plugins, the services just actions.

Decibel is kind of an engine that fills the data related to realtime communication with life. Something comparable from Khalkhi's abstract point of view would be the RSS framework Syndication in kdepimlibs. A Syndication demon could/can retrieve and buffer new blog entries from a person. The static data would be the person's blog feed urls, and the volatile/dynamic data the number of new, unread blog entries. There will be programs that make explicit usage of it and access Syndication directly, other will just use it implictly by some Syndication plugin services for Khalkhi ("open latest blog entry", "number of unread", ...) without knowing it, because they don't need to and just asked for all possible services. See the pattern?

There really shouldn't be any overlap between Khalkhi, Akonadi and Decibel. Code should use Khalkhi and Decibel in parallel, they would add to each other, Khalkhi delivering the general data (from the programs POV) and Decibel enriche all that what is needed for realtime communication. But that is future talk, let's see how and when it works... :)

By Frinring at Tue, 2007/02/20 - 6:00am

but can't Akonadi tell you about new data from a person, new blogs etc? (I'm trying to understand it because I'd like to mention Khalkhi when giving my KDE 4 presentation at fosdem).

Maybe you can send me an email, so we can discuss this more properly, maybe even using skype or something ;-)

By superstoned at Tue, 2007/02/20 - 6:00am

I think I understood this, but I may be wrong, I think it works like this

there is two relivent types of data:

People, including groups of people. This is stored in Akonadi

Services, like MSN, ICQ. Probobly stored in Akonadi

And they relate, a person has several services.

Khalkhi is a wrapper around Akonadi, that filters out everything except filters and services.

Decibel is framework that provides the data about people and services to other applications. It also provides the user's prefered way of talking to various people and real time information like, "are they logged into ICQ"? If an aplication wants to open a chat with a person Decibel can arrange it.

Decibel may or may not use Khalkhi to get data from Akonadi. That still needs to be decided.

What I don't know is, what happens to Khalkhi if Decibel goes straight to Akonadi? decibel provides the same data to anyone who asks.

Man thats like another language :)

By ben at Mon, 2007/02/19 - 6:00am

edit, I read
http://frinring.wordpress.com/2006/06/11/its-about-contacts/ and things are a bit clearer.

Khalkhi has more data than phonon wants, so even if phonon goes straight to Akonadi Khalkhi will still be their to provide an easy wrapper for address books and such.

By ben at Mon, 2007/02/19 - 6:00am

I think you meant decibel, not phonon :)

By patcito at Mon, 2007/02/19 - 6:00am

As a Bachelor in languages, I'm very interested in Sonnet.
Did it already pass the revue? If not, is it planned to be
in the series sometime?

By Darkelve at Tue, 2007/02/20 - 6:00am

(and no, I'm not the same person as RideOut) :p

By Darkelve at Tue, 2007/02/20 - 6:00am