Planet KDE

The other hat I wear around these parts besides Printing is Calendar Systems (just don't ask how I got interested, a long story...), and I've found a bit of time to put some more work into them, as well as the plasma Calendar and Clock widgets.

I've posted previously about giving the plasma Calendar and Clock widgets the ability to set what calendar system to display.  This is now in trunk for people to play with, so I thought it was time to add to our already supported list of calendar systems that people can display on their desktop.

My first target was the Indian National calendar, the official government calender for India, albeit one apparently not widely used (the Gregorian is the common civil calendar).  While the various Indian religious calendars might be more useful in daily life, unfortunately these require various astronomical calculations that we don't yet support, or local observations that we may not be able to support.

The Indian National calculations on the other hand are fairly straight forward as it is very closly linked to the Gregorian calendar, with there being a fixed 78 year difference in the year numbers, a fixed 80 day difference between the start of the respective years, and synchronised leap years.  One interesting feature is that the first year in the calendar is Year 0, which required some changes to the base class to support as none of our current calenders have one.

The big problem though was that our exisiting Gregorian calendar class copies QDate in only actually doing Gregorian calculations after 15 October 1582, before then it uses the Julian calendar calculations.  Any earlier dates in the Indian calendar would be calculated wrong if I used that, so I first had to implement a 'pure' version of the Gregorian calendar to use as a basis.  And while I was at it I thought it would be remiss of me not to do a 'pure' Julian calendar, which may be useful for members of some Orthodox Christian churches.

The end result you can see below is full support for the Indian National calendar, currently from 0000-01-01 through to 9999-12-30.

Yes, I realise that the week numbers are wrong in the year 0, that's an existing bug in our ISO week number code for all years < 1 that I have to fix.

Could I ask all our friends in India to have a play with it and let me know if there are any glaring errors?  Just update trunk kdelibs and kdebase then run "plasmoidviewer calendar" or "plasmoidviewer digital-clock", go into the widget settings and change the Calendar to Indian National.  It passes the tests I have here, but they are not yet comprehensive.  

The other thing I need to ask is to confirm the month and weekday name transliterations I have used from the net are 'correct' (i.e. current best practice), and that the short forms I have invented are OK and not something rude :-)  Is there a standard set of 3 char abbreviations I should be using?

The month names I've used from Wikipedia along with my made-up abbreviations are:

1. Chaitra  -  Cha
2. Vaishākh  -  Vai
3. Jyaishtha  -  Jya
4. Āshādha  -  Āsh
5. Shrāvana  -  Shr
6. Bhādrapad  -  Bhā
7. Āshwin  -  Āsw
8. Kārtik  -  Kār
9. Agrahayana  -  Agr
10. Paush  -  Pau
11. Māgh  -  Māg
12. Phālgun  -  Phā

The weekday names I've used from somewhere are (starting from Monday):

1. Somavãra  -  Som
2. Mañgalvã  -  Mañ
3. Budhavãra  -  Bud
4. Guruvãra  -  Gur
5. Sukravãra  -  Suk
6. Sanivãra  -  San
7. Raviãra  -  Rav

TIA!

So our supported list of calendars is now:

• Gregorian
• Hebrew
• Hijri
• Indian National
• Jalali
• Julian

Note that the 'pure' Gregorian won't yet be offered as a choice to users as I'm concerned about the possible confusion from seeing Gregorian twice in the list, and with inconsistencies arising with anything using the existing Gregorian or QDate stuff.  However, it is there for apps to use if they need to.

Now, I'm a strong believer in our translation and localisation being one of our greatest strengths and selling points, not only something that could see us 'winning' in markets that the big players just can't be bothered with, but also helping bring the benfits of computers and the net to people who might not otherwise be able to access them.  Providing as many local calendar systems as possible is part of that.  So how do we compare at the moment to the competition?

OSX 10.5 lets you choose any of the following:

• Gregorian
• Buddhist
• Hebrew
• Islamic
• Islamic, Civil
• Japanese

As the only OS to currently support the Buddist calendar, I suspect Steve Jobs was behind that feature :-)

Windows Vista and 7 has a real brain-dead scheme when it comes to Calendar Systems.  Want an English desktop and the Hijri or Hebrew calendar?  Sorry, no can do!  You have to choose Arabic or Hebrew as your language, then it lets you choose which calendar system to use.  It restricts what calendar(s) you are allowed to choose from based on first your language and second your country, which while good for choosing default values seems seriously restrictive for no good reason.  And their desktop 'Gadget' will only display the global calendar.  Fail.  Anyway, according to MSDN the supported calendars are:

• Gregorian (6 different localised varieties)
• Japanese Emperor Era
• Taiwan calendar
• Korean Tangun Era
• Hijri (Arabic Lunar)
• Thai
• Hebrew (Lunar)
• Um Al Qura (Arabic lunar) calendar

Actually, I'd better be careful with throwing the insults Microsofts way, because Gnome I'm sorry to say apparently gives you even less choice.  Far as I can tell, Gnome sets all your regional settings based on your chosen language and gives you no way to adjust any of the settings: date formats, number formats, calendar system, nothing.  You can manually edit the locale file but that's it.  So far so Gnome, that's just their way.  But I've tried poking around gnome.org and Googling to see what other calendar systems they support, but can't seem to find anything.  Reading the code of Glib's GDate and Gtk's gtkcalendar.c would suggest however that they only support Gregorian as the system calendar!  That can't be right, surely?  Can anyone set me right?

So it looks a real mixed bag of supported systems with Windows having the lead, but it's something I'm determined we will lead in by KDE 4.6.

Next up is the Bahá'í calendar and possibly the Ethiopian calendar before the 4.4 feature freeze, then some bug fixing on the Jalali and Hebrew calendars and a new test suite for all the calendar systems.  Then for 4.5 I hope to get around to the astronomical calculations required for lunar based calendars like the Chinese, Islamic religious, Indian religious, etc.  I think I'll need to do some astronomy night classes before then :-)

If you do have a local calendar system that you use daily and would like supported, and it doesn't rely on astronomical calculations (new moon, sunset, etc) then drop me a line and I'll see what I can do before 4.4.

I’m searching for possible ways to improve the user experience of Palapeli’s puzzle table. Problem: I do not know which features would help the users. Solution: Ask them (i.e., you).

After all, Palapeli is about replicating in virtuality a game that exists in reality. Everybody who plays a jigsaw puzzle on his PC will automagically try to use the same techniques and tactics which he uses to solve jigsaw puzzles in reality. For example, it is very common to search for edge pieces first.

Do you have other techniques? If yes, please don’t be shy, and leave a comment. I want to map as much as possible of your techniques to convenience features in Palapeli.

Update: A first summary. Most people say that, apart from searching for edges, they’re looking for pieces with similar colors and by level of detail. As one commenter puts it, “it all boils down to divide-and-conquer”.

Also, there has been quite some feedback on the puzzle table. Because quite some stuff occurs multiple times, I find it easier to answer them once here:

• People are concerned about how zooming is implemented, and how pieces are limited to an certain area. I’m concerned, too. It’s becoming more and more obvious that we need a better solution, and I’ll see what I can do about this.
• An annoying “feature” of Palapeli is that pieces are spit out randomly at the beginning, and one has to clear a part of the puzzle area to get some space for the actual image. I’ve made a quick hack-style fix for this: The pieces are now distributed only on one half of the puzzle table. A better solution will appear when the zooming stuff improves.
• Some people would like to change the background texture. That’s possible: Right-click on the puzzle table. As you see, this is extremely non-obvious, I’ll put this interface into the Settings menu very soon.
• The request for rotating pieces has occurred quite often. I’m generally positive towards it, because it gives a nice and easy way to introduce a difficulty parameter.
• Some want a preview of the picture. I have a nice idea for this, but this will strongly correlate with some other features which I cannot add before KDE 4.5.

Thanks for your input. I’m currently collecting input from various sides (the kde-games-devel mailing list is also quite active currently), and evaluating possible solutions to your requests.

Posted in Palapeli

This post comes a bit late, so some of you may already have heard the news: KDE Edu will ship a new application in 4.4: Cantor*.

Cantor is an application that lets you use your favorite mathematical applications from within a nice KDE-integrated Worksheet Interface, and offers assistant dialogs for commonly used functions like solving equations or integrating/differentiating a function. It currently has support for three Backends Sage, Maxima and R.

It is aimed to fill the gap, most free software math packages have, compared to proprietary systems: an intuitive to use graphical interface.

Some of it’s most important features are:

• View of plotting results inside the worksheet or in a separate window
• GetHotNewStuff integration to upload or download example worksheets
• Typesetting of mathematical formulas using LaTeX
• Backend aware syntax highlighting
• Tab completion and integrated syntax help

This is how it looks:

* It is named after mathematician Georg Cantor, the creator of Set Theory http://en.wikipedia.org/wiki/Georg_Cantor

Up until today, the furthest south I had been in pursuit of Free Software was Abuja, although that was just a touchdown. I have practiced Free Software in Kano (12.1N) and in Bangalore (13.0N). Today, that barrier gets smashed as I head down to Latinoware in Foz Do Iguacu (25.5S). So that is four continents and the subcontinent (India has a special place in my heart); I have my sights set on Australia this winter, but the Antarctic will probably just not happen.

So, Latinoware. South America’s largest Free Software conference? Eight parallel tracks? I’m tremendously honoured to be giving two talks at the conference. One with my blue hat — KDE — and one with my green hat — FSFE. That’s a technical and project plan talk about what KDE is doing and where it is going, and a project management and legal talk about how Free Software projects can be run. Both topics close to my heart, and I’ll likely talk about what the FSFE does for KDE in the KDE talk and use KDE as an example in the FSFE talk. Hats can be so confusing.

In the meantime, I expect to be slightly out-of-sync with goings-on in Europe. I hope, nay, expect, the network to be better than at some conferences I’ve attended, though. See you soon (Helio, Mauricio, and others).

I'm sure many of the dot readers are avid Krusader users. I have used it myself only in KDE 3 times, but I clearly understand the need for such a tool for power users. Luckily there is now a KDE 4 version, Krusader 2.0, released a few months ago.

Krusader, you ask? Ah, yes, some people do NOT know it. Well, let's use the description it's developers give:

Krusader is a simple, easy, powerful, twin-panel file manager (commander-style) for KDE and other *nix desktops (All POSIX, All BSD, Mac OS X with macports.org, and experimental port for Windows).

The Krusader Krew is looking for new developers eager to see a much better Krusader.

Since the Krusader team has lack of free time to write new code due to many private and professional obligations, we need developers to continue Krusader development.

Skills: C++, Qt, KDE

But I'm betting new developers can get up to speed with some help from the Krusader team...

Source code can be found here.

Please contact Frank Schoolmeesters for more information

I’ve been interviewed again, and this time the resulting article is published in Turkish, in the Pardus E-Zine. There must be a theme that I always post links to interviews when only parts of the audience can read it. One day, I’ll get you all. The photo’s are universally legible, though. They’re also proof that I’m the most relaxed hacker in the world, an important thing if you ask me.

On Sunday night, I went to Utrecht to see Nouvelle Vague, a French band performing in Tivoli. It was a nice concert, musically on a very high level and with a good portion of fun. The girls, Melanie and Celeste, were both entertaining and charming (how cute can you be, performing the Dead Kennedy’s song “too drunk to fuck“?), playing some kind of new wave version of good cop, bad cop with reversed dress colors, which gave the concert a very nice touch.

Because I was futzing around with Samba yesterday, I installed smbmount (a shell wrapper around /sbin/mount.cifs). I needed to (briefly) mount a network-based NAS in order to move some files to it. I’ll reconfigure the NAS later to take either FTP (unsecure, but it is on a local wired network) or NFS — although I’m not sure it actually supports NFS. Anyway, apt-get install smbfs on a Kubuntu 9.04 box. So, who’s to be surprised when this happens:

$ /sbin/mount.cifs Segmentation fault

That is, shall we say, not an ideal response if there are mandatory parameters that have been left out. Good thing it’s Free Software, so you can see the source code and realise that the check for argc < 3 is a little late and that mountpoint = argv[2] might not be a good idea if no arguments are given. Hey, it’s worth a bug report, patch — and then hope for a release faster than when fixing Windows 7 SMB bugs

Though Google Chrome for Linux is not yet officially announced, people have been working to make Chromium, the open-source version thereof, available for different popular distributions. I wrote before about CrossOver Chromium, but not only this is just a hack, it is also not up-to-date at all. The easiest way for OpenSUSE 11.1 users is to use the package from Contrib.

Though for veteran OpenSUSE fans, the steps to install Chromium are obvious, here I write down the idiot-proof version. Go to http://software.opensuse.org/search, type Chromium and click the Search button, wait for a moment, find the entry from openSUSE:Factory:Contrib/openSUSE_11.1, then well, click on the 1-Click Install button there. Follow the usual installation guides (mostly just agreeing and confirming some stuff), then in few minutes you will get:

Who says installing software in Linux is difficult? :)

A long time ago I started hacking on a library I named libQtGit. As you’ll deduce from the name, it provides a Qt-like API to git, the stupid content tracker.

I had a vision for libQtGit: it was not an end in itself but a piece of a more ambitious framework/library tentatively named QVersioned or libQtVersioned.

QVersioned would provide QVersionedDir and QVersionedFile classes (amongst others, but those two are the most important). Those classes would essentially have the same API QDir and QFile have. QVersioned would open ZIP files and store a .git directory inside. There are cases, like ODF (which itself is a ZIP file) where nothing special is needed. For other cases (for instance, a .txt file), there would be a .txtv (meaning “.txt versioned”) which would be a ZIP file containing the .txt + .git directory (why ZIP? because it’s supported natively by Windows XP and newer and Mac OS).

Now, how did I intend to implement ODF versioning, which was going to be the “this thing works” case?:

• The .git folder would store the uncompressed contents of the ODF file, i. e. XML, images, etc. This is needed to avoid duplication, allow diffs, etc
• There would be also a full copy of the latest version (XML, images, etc) in the ZIP file, just like any ODF-capable application not supporting QVersioned would expect (these applications would just ignore the .git directory)
• When a QVersioned-capable application opens an ODF file, it compares the XML, images, etc to the latest version in git:
  • If the diff is empty, last save was by a QVersioned-capable application, no action needed at moment
  • If the diff is not empty, last save was by a QVersioned-incapable application. A new “git commit -a” is performed. Yes, we probably have lost “versions” of the document in between this commit and the former one but something’s better than nothing.

By using libQtGit and QVersioned, it would also be possible to add collaboration features such as “send me an update” (i. e. send me a diff which transforms my outdated document into your latest version), collaborative editing (send diffs back and forth) and more things I cannot think of right now.

In case you are interested in the libQtGit API (remember QVersioned will offer a higher-level API), this is the signature of the method you would call:

Git::Repository::Commit* Git::Repository::commit ( const
QString& message = QString(),
const Commit* c = 0,
const QString& author = QString(),
const CommitFlags cf = DefaultCommitFlags,
const CleanUpMode cum = DefaultCleanUpBehavior );

That’s equivalent to “git commit -C commit_id -m “message” “.

CommitFlags is a QFlag and CleanUpMode a QEnum:

enum CommitFlag {
DefaultCommitFlags = 0x0 /*< git commit */,
OverrideIndexCommit = 0x1 /*< git commit -a */,
SignOffCommit = 0x2 /*< git commit -s */,
AmendCommit = 0x4 /*< git commit --amend */,
AllowEmptyCommit = 0x8 /*< git commit --allow-empty */,
NoVerifyCommit = 0x16 /*< git commit -n */
};
Q_DECLARE_FLAGS ( CommitFlags, CommitFlag )

enum CleanUpMode {
DefaultCleanUpBehavior = 0x0 /*< git commit */,
VerbatimClean = 0x1 /*< git commit --cleanup=verbatim */,
WhiteSpaceClean = 0x2 /*< git commit --cleanup=whitespace*/,
StripClean = 0x4 /*< git commit --cleanup=strip */,
DefaultClean = 0x8 /*< git commit --cleanup=default */
};
Q_ENUMS ( CleanUpMode )

For the "git commit -a -m "Save latest unversioned version on ODF document opening" ", we would use:

// Assuming 'repo' is a valid Git::Repository object

repo->commit ( "Save latest unversioned version on ODF document opening",
0,
"(The application would probably take the
author's name from the product registration)",
Git::Repository::OverrideIndexCommit );

So, how is libQtGit doing? Well, the API is there for git add, commit, init, mv, rm, checkout, clone, branch, revert, reset, clean, gc, status, merge, push, fetch, pull, rebase, config, update-server-info and (partially) symbolic-ref.

When I say “the API is there” I mean “all the QFlags, QEnums, methods, classes and its translation to git parameters is done”. It’s just a matter of implementing the QProcess part, parsing output, etc. Boring and
time-consuming but easy.

Given that I’m busy with other stuff, and some people have been asking for the code for a long time (sorry Riccardo!), I have just published what I have now. It’s unfinished, barely tested and yet to implement in many places. But it’s a starting point. It’s available now from Gitorious: http://gitorious.org/libqtgit/libqtgit

As for QVersioned, nothing is done yet.

If you read around the KDE Techbase, or if you develop KDE applications, you may have heard about KDE’s KConfigXT. This is an extension of KDE’s KConfig, and can be used to generate nice configure dialogs with multiple pages with minimal effort, also taking care of saving and applying settings. In short, something really neat! But there are problems when using it with interpreted language bindings (such as PyKDE, which is the one I use):

• KConfigXT requires an XML file and an INI-like file to be compiled by kconfig_compiler in order to produce C++ files
• There is no such a tool (at least to my knowledge) that does the same job for bindings

So what to do? Either give up on the niceness of KConfigXT, or work around the issue. I chose the latter.

Bypassing the kconfig_compiler limitation

What kconfig_compiler does is basically generate the KConfigSkeleton sublcass needed for KConfigXT. So, we can create our own subclass by hand: a little more work is involved but nothing too hard. The following snippets, taken from a GPL application I’m working on, will demonstrate how to do it.

from PyQt4.QtCore import * from PyQt4.QtGui import * from PyKDE4.kdeui import * #UI stuff - see later from ui_generalpage import Ui_GeneralPage class Preferences(KConfigSkeleton): """Class to handle preferences.""" def __init__(self, *args): super(Preferences, self).__init__(self, *args) self.setCurrentGroup("General") self._danbooru_boards_list = QStringList() self._danbooru_boards = self.addItemStringList("danbooruUrls", self._danbooru_boards_list, QStringList())

Here we set up a KConfigSKeleton subclass. The first thing we set up after that is the config group we want to use: we can have several, for example “General”, “Services”, and so on. Of course an empty group makes nothing, so we populate it, in this case with a QStringList configuration item (see the API docs (KCoreConfigSkeleton, but KConfigSkeleton is a subclass of that) for more types you can use). You’ll notice that we assign an empty QStringList to a variable, which is then used in the addItemStringList call later. That’s because KConfigSkeleton (in C++) wants a pointer to the type of content, and since in Python we don’t have pointers, we pass a reference (and by binding it to our class instance, we make sure it won’t be garbage-collected).

The addItemStringList (and other addItem*) methods use three parameters: a string with the name of the option (remember this!), the reference to the item, and a default value (in this case an empty QStringList).. Once we’ve set the options, we call readConfig() in the initializer to make sure the values are read from the config (or default values created).

I set all the attributes as “hidden” to prevent direct manipulation. To access them, I set up properties (following the example of minirok, another PyKDE4 application).

@property def boards_list(self): return self._danbooru_boards.value()

As you can see, the value of the configuration items is accessed via the value() function. Once tihs is done, we’re done with regards to the KConfigSkeleton part.

KConfigDialog

Of course now we want to create the config dialog. We do so by subclassing KConfigDialog. First, though, we must create the page contents. We do so in Qt Designer. We first create a widget, and then we place our configuration widgets on it. It is essential that the widget that will store our configuration details have the name kcfg_CONFIGOPTION, where CONFIGOPTION is the name you specified as a string in the KConfigSkeleton initializer. Once done, we save the ui file, compile with pykdeuic4, we set it in the imports of our preferences file and we’re good to go.

The following is an example of a general configuration page widget (the UI_* is the pykdeuic4 generated file):

class GeneralPage(QWidget, Ui_GeneralPage): def __init__(self, parent=None, preferences=None): super(GeneralPage, self).__init__(parent) self.setupUi(self) self.kcfg_danbooruUrls.insertStringList(preferences.boards_list)

As you can see, we pass the preferences instance in the initializer, so we can populate the widgets (which are indeed named kcfg_danbooruUrls, just like the config option I set earlier) . Of course you can connect signals and whatnot to slots in case you want to do something with your widgets. I didn’t have the need, so no need to.

And once we have this set up, we can finally create the KConfigDialog!

class PreferencesDialog(KConfigDialog): def __init__(self, parent=None, name=None, preferences=None): super(PreferencesDialog, self).__init__(parent, name, preferences) self.setButtons(KDialog.ButtonCode(KDialog.Ok |KDialog.Apply | KDialog.Cancel)) self.general_page = GeneralPage(self, preferences) self.general_page_item = self.addPage(self.general_page, 'General')

In the initializer, we pass the preferences instance, the name (used later to determine if a page is already open, since KConfigDialog is non-modal), and of course, the parent widget. We then set the buttons (using bitwise ORs) we want to show. Finally, we instantiate our page widget and add it to the dialog, specifying a name that will appear on the side. Using the setIcon method you can also set an icon for your page. In case you want to perform checks and other things, reimplement slotButtonClicked in your subclass with (self, button) as parameters. But dont’ forget to call the original KConfigDialog.slotButtonClicked(button) in that case.

Wrapping it up: calling KConfigDialog

Finally, how to call your dialog? First of all, you need to instantiate your preferences object, for example in your main window application code:

self.preferences=preferences.Preferences()

Then, in your code, you do something like this:

if KConfigDialog.showDialog("Preferences dialog"): return else: dialog = preferences.PreferencesDialog(self, "Preferences dialog", self.preferences) dialog.show()

The first if ensures that if there is already one dialog open, it won’t open another. If that’s not the case, we instantiate the dialog, passing it the name (which must be the same as the if above), the parent, and the preferences instance.

Voila’. In the end, you’ll get something like this (slightly different):

I know my own UI sucks here, but it’s something I’m still experimenting…

For this tutorial, thanks go to Pino “pinotree” Toscano, who pointed me to the “minirok” project, which makes use of KConfigXT, and Adeodato Simò, the author of minirok.

This Sunday, I gave a presentation at UbuCon 2009, the German Ubuntu Developers and Users conference, held at the wonderful historic town of Göttingen, in northern Germany. The conference covers a variety of distribution development topics, with about 250 participants, and a 5-track presentation schedule (!). The talk I submitted was about a topic that fascinates me a lot lately - the convergence of Free Software desktop technologies under the hood, which makes Qt developers get in touch with GTK based technologies more and more, and vice versa, and about our experience at KDAB with developing such technologies. It was called "Qt for GTK Developers", purposefully slightly on the provocative side, with a smirk. After all, I am used to working in areas with unusual risk conditions, so why the heck not? Also, this comes not even close to the stress levels created by parenting. The talk was about how Qt and GTK are both used for developing base desktop services, which toolkit dominates in what areas, and what our guesses are on what the future brings. The central part was an overview of Qt technologies and practises, presented in contrast to GTK. The talk consisted of four sections dubbed "Everything was better in the old days", "Everyone does what he wants", "Qt is not what it used to be", and "This is as good as it gets". There were quite a few good laughs between the audience and me. Read on for more details.

Everything was better in the old days
It started out with a flashback to the GCDS, and how the Gnome and KDE communities collided and formed a new sun of creativity. Are Tracker, Soprani, Strigi, and Nepomuk all doing the same thing, and does it really make sense to run two separate indexing services in the desktop to be able to use the KDE and Gnome infrastructure? Is DBus a Gnome, a KDE, or an obsolete technology? The user wants similar desktop styles, do we have to duplicate them, then, always? Will Evolution and Kontact store, index, and syncronize the same information of the user's data, or two independent copies? The discussion culminates in uncomfortable questions - does the desktop have an identity for the regular Linux user? Are KDE and Gnome converging into one user experience were both the distributions and the user mix and match whatever applications, window manager, and workspace they please? What do the lofty names for the core technologies actually mean in the long run? There is, of course, no ready made answer for these questions.

Everyone does what he wants
In more detail, the current situation was discussed. GTK and Qt use rather different ways of development and packaging, GTK being more of a bundle of technologies, which combined make up the user experience. Qt integrates its modules into one (huge) package. The similarity in the development model is obvious - Qt being developed by a single company, while in GTK, multiple smaller companies specialize in developing individual GTK technologies, potentially backed by the larger GTK using companies, funding their development efforts. The differing license models of Qt and GTK were discussed, which a focus on what difference those make today, and how they influence new software projects when the GUI toolkit is selected. This was about as much abstract reasoning a human being can take at a time, so the next section had some code. Some.

Qt is not what it used to be
It was an overview of what Qt is today, and how it changed from a GUI toolkit to a comprehensive application framework. Qt is still mostly seen as purely a GUI toolkit by those not using it, so I presented which modules it consists of, and which tools, and also what programming practices it facilitates. The fact that Qt has fully dynamic integration of DBus, for example, took many by surprise. The XML modules (and the fact that they are written as part of Qt, and tend to not break with the next Qt version), the Webkit implementation, the SVG renderer, QtScript, all these are obviously much unknown outside of the Qt developer's world. Then I presented an overview of the Qt development tools, both the fully flegded GUI applications, and the command line tools that are part of the build process. The resource system lifted a few eye brows ("Could I use that to link some resources, and access them from a GTK program if I write a wrapper to get to the files that uses Qt? Sure.") I explained how Qt starts to be used for defining platform APIs as well, but at the same time integrates with glib. It is amazing to see how the different technologies go in circles around each other. I demonstrated a few bits of Qt code, starting, of course, with "Hello World". I showed a demo of QGraphicsView, and the QUnitTest-based QThreadPool performance test I also used at the DevDays (me being me, there had to be some multi-threading in the presentation). It is apparent that the ease and the straightforward way in which such examples can be written in Qt did surprise some in the audience. I did point out that the fact that platform APIs are developed using Qt does not automatically mean that the KDE guys get their way, this seemed comforting, in a weird way of shared misery.

This is as good as it gets
The outlook and summary wrapup is probably the part where I made the fewest friends, so to say. I explained why I think that natively compiled languages will dominate desktop applications for quite some time to come. The inefficiency of running many small desktop applications in (J)VMs seems to impede the use of Java for the kind of applications we develop. I declared Mono to be a bad idea (tm), because the Free Software world is trotting behind Microsoft. It means we are re-implementing the idea of how they think future (Windows?) applications should be developed, again. That must be a waste of Free Software engineering resources, we are innovators, not followers. To be precise and to avoid misunderstandings, I did not criticize C# as a bad programming language, but the process of how the .NET API is developed further and extended. And then I said I think Vala is a bad idea as well, because I find it highly improbable that a couple of people, no matter how brilliant, could define a strikingly better programming language in a few weeks than whole research departments in a community process over many years. Even more doubt is cast by the fact that it was invented solely to get rid of C, without admitting that C++ would have been a better choice. As expected, these statements started an interesting and somewhat heated discussion. No animals or humans have been harmed in the process, and I made it out safely to the train station. Overall, this was a very interesting encounter. The organizers of the conference did a very good job, with a weekend flatrate for food and drinks, this is a really great idea. The slides will come up on the conference site in a few days.

First things first, first: set off the day 8. of November. Then we will arrange a bug-day dedicated to Phonon, to clean up duplicates, close fixed bugs not marked as such, and generally try to make it easier to file new bugs and fix bugs. More information should be forthcoming. I’m trying to get as many developers who know anything about Phonon to set off the complete day, so there should hopefully always be someone active who are familiar with Phonon.

So if you’re either someone who has used Phonon, worked on Phonon, likes Phonon, likes bug triaging, or simply want to lend a hand, please show up on #kde-bugs the 8. November.

Screenshot of Filelight 1.9

I’m also very close to releasing my KDE 4 port of Filelight, I think I’ve fixed all regressions from the KDE 3 version in SVN now. Yes, yes, I know it has taken almost a year now (if not more), but I hope I can compensate with a very solid first release.

If you do know of any regressions, please tell my ASAP (either file a bug at http://bugs.kde.org/ or ping me on IRC (`sandsmark` on Freenode, IRCnet and EFnet).

We’re also soon finished with arranging Norway’s largest cultural festival (UKA), only 6 days left. After that, I hope to have more time for free software and Phonon in particular, so far this fall it has been mostly administrative tasks, and getting to know the rest of the multimedia stack in Linux.

In System Settings / Regional / Date & Time we allow users to customise the Date and Time fomats used throughout KDE, a handy feature.  Problem is the configuration is not very user-friendly, have a look at what I mean:

So we have some editable combo's allowing the user to either select from a few standard layouts or to type in their own layout.  But what are the valid componants of a layout that the user can type in?  It's not immediately obvious, and there's no help available I can find.  I had to go look at the source code to find out.  OK, we could fix that with some tool-tips and help doco, but it's a process still prone to error, the user is allowed to type in anything no matter how invalid or incomplete and it just gets treated as display text.  It's how Windows still does it, surely we can come up with something simpler and more usable?

Well, as you might guess, Apple did.  Have a look at their Date format 'editor':

All you do is drag some Elements around (those blue 'bubbles'), type any text you want in between and you're done, no knowledge of format codes required.  They have something similar for time formats.

I would love to have a generic widget that does this in KDE for use in the Date and Time formats in System Settings and in the panel clock settings.  Where else could we use something like this, any ideas?  Problem is, I haven't a clue how to do the gui for this, I'm a plumber, not a painter, if you catch my drift.  So anyone want to have a crack, or at least give me some pointers where to start?  Anyone know of an existing widget I could adapt?  We already have the KWin buttons editor which does something similar, but it lacks the line edit functionality.

The generic widget would combine a special Line Edit widget and a Pallette widget.  The Line Edit would allow any text to be entered and edited and validated exactly as a standard KLineEdit.  The Line Edit could also be a combo if we wanted standard formats available for easy selection.  Element 'Bubbles' can be dragged from the Pallette onto the Line Edit and dropped in position, or dragged off to remove them.  Once in place in the Line Edit, the Element Bubble would be treated exactly as any other glyph, i.e the cursor moves around them and they can be deleted or backspaced to remove them.  API would allow the client to add Elements to the Pallette as required, setting the Element Label text, Element Example text (as goes in the Bubble), and Element Format text.  Calling text() would return the contents of the Line Edit with the Element Bubbles replaced by their Element Format text equivalent.  Accessability would require that either each Element has a key shortcut to insert it in-line, or that typing in the Element Format magically changes it into the Element Bubble.  This makes me think that what the Line Edit requires is code to recognise when a particular text substring has been entered and replace that textual display with a graphical 'Bubble', and an API to give it the Example and Format text pairs.  The drag-and-drop action would then be simply to insert the required format text and the Line Edit would convert it itself.  I'm guessing the hard part is displaying the Bubble in place of the text and getting the cursor to treat it has a single entity. 

In System Settings and the Clock widget, we could then simply have the current format displayed read-only with a little Wizard button next to it to launch the widget, keeping the config guis nice and clean and simple too.

Any suggestions / volunteers?

Or can someone come up with an even more user-friendly way than Apple?

I’ve always really quite liked Magnatune, ever since (I guess) about 2005 when I first became aware of it. However, back then browsing and listening to the music was not that easy and – as far as I got around to exploring – there wasn’t really that much of the music that really appealed to me. As I remember, I bought a few albums, liked the try before you buy approach and the fair revenue splitting (half to artists), free format downloads (Vorbis and FLAC) and then pretty much forgot about it.

Since then though, Magnatune has changed in a few ways. Firstly, they’ve brought in the stream and download subscriptions that give you access to a whole heap of music at very competitive prices – and with the download membership you get to keep your downloads even if you end your subscription. Secondly, the store is now fully integrated in Amarok (work sponsored by Magnatune) which gives you access to the entire catalogue right from Amarok. If you have a membership then there are no interruptions to streamed tracks and you can download your albums in your preferred format from within the user interface. They’ve also expanded the music catalogue and (in my opinion) enhanced its quality too. The thing that really got me noticing this was listening to my Recommended Radio from Last.fm (another service integrated in Amarok) and checking out a few previously unfamiliar artists that I liked, realised they were on Magnatune. So I bought a couple of albums but then realised it would make a lot more sense just to have a membership. It’s only been a couple of months so far, but I’m pretty impressed and have been exploring whole genres I wouldn’t normally even look in to and finding interesting stuff there too.

Incidentally, one of the Magnatune artists that first caught my attention was Beight, which (courtesy of Magnatune) you can listen to below. It requires flash (though one of the free alternatives might work) but alternatively you can check it out by grabbing the playlist from the site or in Amarok.

File In Rhythm by Beight

I had the pleasure of talking to some fellow state machine enthusiasts at DevDays in Munich. Here are some of the topics that were brought up, in randomized order:

Verification. How can you check that your state machine is sane, or rather, how can you disprove that it’s criminally insane? Currently there isn’t a way to do that. We tried to design the API so that many (most?) semantic errors will be caught at compile time. But that doesn’t get us all the way, unfortunately; what happens if you forget to specify the initial state of a compound state, for example? The QStateMachine::error() signal is there to report such cases; if the state machine detects a semantic error at any stage of executing its algorithm, it emits the error() signal. But maybe it would be nice to have a function that can run a set of standard sanity checks before the machine is started?

Performance. We currently implement the SCXML algorithm more or less exactly as it’s specified. I don’t yet know how well it scales wrt number of states and transitions; well, I have one benchmark where the running time grows exponentially, but there are many different configurations that need to be investigated (flat vs nested state machines, sequential vs parallel states, custom events and transitions vs built-in ones, etc.). Is anyone out there creating state machines with thousands of states, and if so, are you seeing performance issues?

Lazy population of states. For large compound states, it can make sense to only create the contents of the state when (if) the state is actually entered. To do that, you need only create an initial state, and reimplement QState::onEntry(). You need to create the initial state because the state machine will request it _before_ the compound state is entered (and QState::initialState() is not virtual…). In your onEntry() implementation, use a flag to check whether the state is being entered for the first time, and if so, create the remaining child states and add transition(s) to them from the initial state, as appropriate. The state machine actually does similar kinds of lazy initialization internally; the signal associated with a QSignalTransition is only connected when the transition’s source state is entered, for example.

Debugging. There’s no straightforward way to debug state machines in Qt 4.6. What’s needed first is a “debugger client” interface that the state machine can use to deliver notification of e.g. state changes. This interface would then serve as the basis of debugging tools. It would be nice to have a visual representation of the machine (tree view?) highlighting the current state, be able to “step” the state machine execution, set breakpoints on transitions, inspect the event queues, and so on. P.S.: If you’re building Qt from sources, there’s a QT_STATEMACHINE_DEBUG define that you can enable in qstatemachine.cpp; this will cause the state machine to spew out a log of everything it’s doing. This output can be difficult to parse humanely, though, especially when your machine has nested states.

Why QtCore? Couldn’t the state machine framework be in a library of its own? Yes, it could, but we chose to put it in QtCore so it can easily be used anywhere, without introducing new dependencies. The QtCore library grows by about 5% (150K) due to the state machine classes. Note that it’s still possible to remove the framework from compilation by using the qconfig tool, just like you can with the animation framework (also part of QtCore) and several other features in Qt.

Multithreading. How do you use state machines with threads? Well, there are a few things you should know. Firstly, the state machine classes are reentrant, meaning you can have multiple state machines running at the same time (one per thread, say). Secondly, the QStateMachine::postEvent() function is _not_ thread-safe, meaning that it’s not safe to call postEvent() on the _same_ machine from different threads; you’ll have to manage the synchronization yourself if you want to do so (but maybe QStateMachine::postEvent() should be made thread-safe, like QCoreApplication::postEvent()?). Thirdly, if you’re using signal transitions, there is no restriction on whether the object emitting the signal lives in the same thread as the state machine or not; the state machine will always create a connection of type Qt::AutoConnection, meaning that the connection will be queued if the object lives in a different thread. This means that the state machine can be processing events in its own thread concurrently with the signal being emitted in another thread, without you having to worry about synchronization.

See you in San Francisco, maybe?

Nepomuk, which is KDE’s semantic desktop framework is a very interesting new technology, and has the potential to move many applications forward. Nepomuk needs an RDF store to save and retrieve semantic information, such as data from your filesystem indexer, tags, ratings, and other, much more complex bits. Up until now, there were performance problems. There were two possible ways to store your information: redland and sesame2. Redland is written in C++, but is very simple and by far not meeting the performance requirement we need for Nepomuk’s use-cases. The Sesame2 backend is a lot better in terms of performance, though still not quite up to the task. What is more, it requires certain Java files which have licensing problems — in the end many distributors just omit shipping this backend. That way performance of Nepomuk goes from bad to worse for many users.
Sebastian Trueg, KDE’s main developer of the Semantic Desktop is of course aware of this problem, so he has been working hard to find a solution for the RDF storage part which is both up to the task in terms of performance and stability. This solution is Virtuoso, and Sebastian has now a working backend for Soprano (which is the Qt-style storage interface for Nepomuk). This means that the Redland or Sesame2 storage mechanisms for Nepomuk can now be replaced by the much faster Virtuoso store. For the user this has important advantages: faster search, tagging, rating and longer battery life on mobile devices.
So my project for tonight was: Switch the Nepomukserver on my development machine to Virtuoso. And apparently, I succeeded.

Here’s my quick walkthrough if you want to do the same:

1. Download Virtuoso 5.0.12 or later here
2. ./configure --prefix=/home/sebas/kdesvn/install (or whereever you install your KDE trunk) make -j3 make install
3. install libiodbc2-dev (on Kubuntu or libiodbc-dev on Debian)
4. rebuild kdesupport/soprano (possibly delete CMakeCache.txt), make sure Virtuoso backend is built
   -- Found iODBC 3.52.6: libs - /usr/lib/libiodbc.so; includes - /usr/include -- Performing Test __SOPRANO_HAVE_GCC_VISIBILITY -- Performing Test __SOPRANO_HAVE_GCC_VISIBILITY - Success --------------------------------------------------------------------------------------- -- Soprano Components that will be built: * Sesame2 storage backend (java-based) * Virtuoso storage backend (Run-time dependancy: Virtuoso) * Raptor RDF parser (including TriG parser) * The CLucene-based full-text search index library * D-Bus server/client support -- Soprano Components that will NOT be built: * Redland storage backend * Raptor RDF serializer
5. Rebuild kdebase.
6. Edit ~/.kde{4}/share/config/nepomukserverrc and put Soprano Backend=virtuosobackend ins the [Basic Settings] section. Mine looks like:
   [Basic Settings] Configured repositories=main Start Nepomuk=true Soprano Backend=virtuosobackend

   Obviously, the virtuosobackend line is the important one.

7. That’s it for the setup. Now you need to restart the nepomukserver.
   // Check which backend we're currently using luna.sebas(~): qdbus org.kde.NepomukStorage /nepomukstorage org.kde.nepomuk.Storage.usedSopranoBackend sesame2 // Stop the nepomukserver luna.sebas(~): qdbus org.kde.NepomukServer /nepomukserver org.kde.NepomukServer.quit // Start the nepomukserver luna.sebas(~): nepomukserver // Make sure the Virtuoso backend is used luna.sebas(~): qdbus org.kde.NepomukStorage /nepomukstorage org.kde.nepomuk.Storage.usedSopranoBackend virtuosobackend

   You’ll notice that it automatically starts converting your data from sesame2 (or possibly redland) format to the new Virtuoso format, this will show up as a job in your plasma notification area, and it might take a long time, depending on how much data you have. Go get a coffee now.

This worked for me. I was glad to find information on The Other Sebastian’s blog and on techbase.

Please leave a comment reporting your findings.

hello everyone
i’m blogging this one because i really fell off the chair laughing when i read it.

so, short introduction: i admit that it’s really a while that i’m not blogging, and because of that 99.9% of the comments on the blog posts are just mere spam. Most of the times it’s just uninteresting russian or brute force porn links, but this one is so amazing i think it’s worth sharing. Only important note: this was on the page where I blogged about the mockup of the battery plasmoid

okay, the introduction is over, this really speaks for itself:

Hi,

Thanks for writing such an interesting article. Its really good to know about the batteries in detail. Seriously do we realize how many things in your house that need batteries? Let’s count it, from the flashlight, cell phone, iPod, cameras, and many more. Knowing it should make us realize on how essential the presence of the batteries in our daily life. However, with that so many kinds of battery, which is generally different between one to another, sometimes we have some difficulties in finding the desired type.

Find the right batteries supplier is not hard if you check out  *REMOVED LINK* because this website provides the widest selection of batteries and you can choose the right battery based on the categories. You can get the procell batteries which available in several sizes and voltage. You also can find Duracell batteries that divided into duracell plus batteries and duracell ultra batteries. All of the batteries come with cheaper price because this website provides the discount batteries in bulk, wholesale, and retail quantities.

Thanks,

- Andrew Morales

yes, amazing.

- roophie (which is going to have more kde news to blog about)

(and, oh yeah, i have to fix blockquote…)

Everything is in the title I have uploaded Qt 4.6.0 beta 1 packages to Debian experimental. Amd64 and i386 packages are built (unfortunately, alpha and s390 architectures failed to build).If you wonder if KDE 4.3.2 is working with these packages, the short answer is yes.

While looking to install smbclient on my laptop this morning to talk to some devices on my home network, I was pointed at a security advisory regarding SMB2. It’s about a known defect the SMB2 implementation on Windows 7 — kind of interesting to have pre-release security defects publicised already. The FSFE’s statement is here, and you can find English-language Heise coverage here.

The intermediate work-around — isolate Windows machines from the Internet with a good firewall — is good practice anyway. Do not let SMB traffic escape from your local network.

Day 2 ended with some hacking and adapting stuff to the API changes we did. I worked on Mailody and implemented support for contact groups. That are groups of contacts, also called distribution lists. In the address book within the composer you can now see them and when you click on it, the individual members of that group get added to the recipients list. I never had group support within Mailody and adding it while using Akonadi was not more than like 40 lines of code.

After that I worked to get the manual expunge code, which I explained on Friday. The DBus interfaces were added by Kevin and I adapted Mailody to use them. So that was one of the last goals I had for the meeting. In the meanwhile Thomas McGuire yelled that his rewrite of the pop3-resource was pretty much complete and passed his unit tests.

Day 3 was somehow a bit more relaxed than the other days. We briefly looked over the last bit of API we had to review. It was coming from the KMime library. KMime is a library that has been around for ages and was written with the intend to replace mimelib which is used by KMail. But that never happened.

KMime is the library that is responsible for creating the actual message after you press the send button in an email composer, but also deals with extracting the different parts from a message to display them, extracting the plain part, the HTML part, maybe some attachments, but also dealing with all kinds of encoding and decoding problems which are used to send the actual mail in.

When I started Mailody, I first tried to do that all on my own, but I soon realized that was not something I wanted to do, and Volker pointed me to the – at that moment unused – KMime library. After we removed the dust, we discovered some bad API and for KDE4, we removed most of the ugly API (like methods returning QList* (yes returning pointers to a list with pointers). Mailody then turned into a happy user with KMime. With the akonadification of KMail, it is needed that KMail also used KMime internally. Akonadi delivers the messages in that form to KMail, so it needs to. Andras Mantia has been actively working on this conversion for KMail. I’ve big respect for that work. I know it is a big task and probably not the most fun to do.

That also mean there is a new user of that stuff, and that means some API changes are wanted. We are still not completely happy with existing API, so that makes the extensions to that API somewhat less critical to get absolutely perfect. This is one of the candidates for a rewrite for KDE5. Still reading? Sorry to be a bit verbose on this stuff, just want to make sure you get a feeling why an akonadified KMail is not available yet. From one big monolithic application, it is being teared down to separate components, which will make the codebase a lot easier.

You have to have bad api’s to realize the value of good API’s.

After this mandatory part of the meeting, we quickly went over to the other mandatory part and did the Group Photo. I’ve not seen it yet, but I’m sure it will appear on the Dot or Planet soonish. There were a couple of discussions between various people. It’s fun to see that the base of Akonadi works nicely for a lot of people and we are slowly arriving at the phase were we can extend it further. Hot Topics in that area are:

• Search. You can basically split up two types of searches. The first one is in the messages within Akonadi. We will use Nepomuk for that. Especially now Virtuoso back-end for Nepomuk seems to be performing nicely, we can go ahead and implement them further. The ground work is already present; Akonadi supports creating virtual search folders, containing links to messages in other folders. Also each message passed into Akonadi is being indexed by Nepomuk. Just need to finish up that work as far as I know, like creating a user interface for creating such a search folder. The second type of searches are server side searches. Take IMAP. It allows you to search for messages directly on the server. We need to support that too.
• Filtering. Basically you have the same difference. There is a local filtering of messages, which is implemented by a summer of code student. It means that a special type of resource gets the messages before it gets added to the final destination folder. That special resource can filter it to another folder for example. This should all be finished, but it’s not completely ready yet. There is also filtering on the server side. For example IMAP filtering is (and should) be done on the server side, for example with Sieve. Volker and I briefly brainstormed about the possibility to create an application which can deal with that. Should not be too much work if we can base it on the work already done by the SOC student.

I briefly brought up Google Wave. I think Akonadi can easily provide a resource for it, although there wasn’t much interest from the participants of the meeting to work on it, so we probably will not work on it ourselves. Of course if the resource is created, you’d still need an application to edit the waves. So if anyone wants Google Wave integration into KDE, please use Akonadi as base. We can help you with the stuff, we just don’t have time to do it ourselves.

That pretty much concludes my coverage from the meeting. I know there will be a dot story outlining more stuff that has been done during the meeting, outside the little box I have lived in. It was fun to be there again.