Do you know this one?

Phoronix tested md5sums of ISO images of distributions. The winner was openSUSE, scoring e29311f6f1bf1af907f9ef9f44b8328b, which gave it a noticeable lead before second Slackware (b026324c6904b2a9cb4b88d6d61c81d1), which is quite closely followed by Fedora (9ffbf43126e33be52cd2bf7e01d627f9) and Debian (9ae0ea9e3c9c6e1b9b6252c8395efdc1). The difference between these two distributions, as you can see, is only very small. Ubuntu completely flopped in this test, achieving only 1dcca23355272056f04fe8bf20edfce0, which is surprising, especially considering that its previous release scored a very nice c30f7472766d25af1dc80b3ffc9a58c7. (source).

Ok, that's just a joke, but the sad part is, as somebody pointed out, that it wouldn't be really that surprising if Phoronix actually did something like that. And, probably even more sad, there would be people who'd really take it as if it meant something and started adding comments about how last openSUSE is pretty good, last Ubuntu is so disappointing, and Fedora and Debian are not really that different.

So take this from somebody who has already done a lot of performance work: Benchmarks, on their own, mean almost nothing if you don't understand them. Especially if they are seriously flawed (I mean, testing filesystem performance by doing CPU-intensive tasks? Hallo? Probably even FAT16 could provide the same results in those tests on an SSD.), but even if the results are useful numbers, it is still necessary to understand what the numbers actually say. I think I wouldn't even have a big problem forging a "benchmark" where KDE would get better (and correct) numbers than LXDE by finding a scenario that'd be twisted enough.

And even then, it is still necessary to keep in mind what is compared. Comparing the default setup of Fedora and openSUSE means also comparing GNOME and KDE, which you may or may not want, but if you compare the distributions this way, it is affected by differences between the desktops, and if you compare the desktops, it is affected by the differences between the distributions. And in either case, it may or may not apply to another distribution or another desktop.

Yet one more thing to understand is what is measured and how it affects performance as a whole. Ages ago there was a Dot article that also mentioned performance improvements to be brought by Qt4 in some specific areas, yet even now there are numbers of people seriously disappointed by KDE4's performance only because they thought that since Qt4 improves in some areas, KDE4 will get exactly the same improvement, regardless of how much these improvements matter for the whole of KDE4 or how much of KDE4 was rewritten when porting from KDE3. When I fixed Exmap to work again and did a little benchmark as a part of it, there wasn't really much more to it than to show that Exmap works again and that it is very easy to lose a lot of advantage by a simple mistake, yet people had no problems drawing all kinds of strange conclusions from that. Since making right conclusions is unexpectedly difficult for most people when it gets to benchmarks, I really need to remember not to just post numbers again without also saying what it means.

And, finally, there is still the question of other costs and whether it is worth it. Various KDE components often have resource demands, but then they are also often worth it. I mean, we all could still use TWM, or, heck, Windows 95, but seriously, how many of us really would? This, ultimately, is always about what works the best for you.

With only a few hours a week to work on Konsole, I often view the logs and other reports for simple issues to investigate. The compile warnings were fixed sometime ago. Most of the simple Krazy and Apidocs issues were also fixed. The remaining Krazy issues would require some heavy duty changes.

Recently I've been trudging through the -Weff++ logs. I coded a simple Ruby script to parse them as Qt generates a ton of warnings. Currently there are around 300 issues. The vast majority of these fall into 2 categories:

1. ... should be initialized in the member initialization list
2. ?class ...? has pointer data members
   but does not override ?Class(const Class&)?
   or ?operator=(const Class&)?

These 2 can be fix easily enough.
1. Add them to the constructor watching the order of the initialization list
2. Add these to the private section of the .h file:
   // Disallow copy and assign
   Class(const Class &);
   Class & operator=(const Class &);
   If anyone tries to use the Copy or Assign, it will fail at build time.

Thoughts on these 2 issues?

I did manage to get the Apidocs to generate the class hierarchy in graphic form which is very helpful. Although I'm still struggling with using valgrind for memory issues (and unfortunately, valgrind doesn't work on Mac Snow Leopard).

Today I'm leaving Tokamak 4, so I thought I'd write a post about what I've been up to while I've been here.

The first day or so I spent getting my machine sorted out as trunk was causing some issues with my graphics driver leading to a hang in the DRI layer of the kernel. I also had a chance to triage some ksnapshot bug reports and look over some patches.

The next day was largely taken up with talks about the current status of the various parts of plasma, kwin and related technologies. We got a little hacking done but not much as it was more important to make sure we're all coordinating our development.

The remaining days became a bit of a blur, so in no particular order:

• I refactored the plasma javascript scriptengine to make it easier to use it with QScriptEngines that are created externally. This is required before we can integrate things like QML.
• Worked out what is required for QML integration to be implemented in a way that is compatible with our existing javascript bindings etc. This will require some small changes to the API offered by Qt for QML, which may be a problem. If we don't get those changes then QML is likely to be trapped outside the main engine which will reduce what it can do unless we write
  another set of bindings.
• Made some fixes to the webslice applet to improve error handling.
• Started work on an idea I've had in the back of my head for a while, I won't say too much about it here, but I'll include a pretty picture to whet your appetite:
  
  
  

  In addition to this I've taken part in lots of discussions on topics ranging from activities/contexts, scripting of animations, silk and more. I'd like to thank Will and the rest of the openSuSE team for making this such a pleasant and productive sprint.

No, Locus OS concept design, has apparently no association with MS.

"This interface was designed before iPhone 3.0, Palm Pre, Android etc, making the ideas original at the time :)"

Is the last sentence true at all?

A topic that I've not mentioned in any of my blog posts is threading, not because I have anything against it, simply because a simple use-case hadn't come up. Today I was coding something easy to describe, where using threads was a good solution, so let's take a look at it.

The problem I needed to solve was to calculate cryptographic hashes of files that could be very large - for example 4 gigabyte DVD isos. As with any graphical application it is very important to ensure that the GUI remains responsive while this work is done. Since the problem involves very little communication between the part of the application calculating the hash, and the rest of the code a worker thread is an ideal solution.

The code that actually does the work is very simple, it uses the handy QCryptographicHash class to do the work (stored in the variable hasher):

HasherThread::HasherThread(QObject *parent) :
    QThread(parent)
{
    hasher = new QCryptographicHash( QCryptographicHash::Sha1 );
}

void HasherThread::run()
{
    QFile f( filename );
    if ( !f.open(QIODevice::ReadOnly) ) {
        emit error( QString("Unable to open file %1").arg(filename) );
        return;
    }

    hasher->reset();

    char buffer[16*1024];
    qint64 count;
    do {
        count = f.read( buffer, sizeof(buffer) );
        if ( count == -1 ) {
            emit error( QString("Read error") );
            break;
        }
        hasher->addData( buffer, count );
    } while( !f.atEnd() );

    emit completed( hasher->result().toHex() );
}

The code opens the file to be hashed, then reads through it in 16K chunks which it passes to the hasher. If this code were executed in the application's gui thread then this would cause the interface to freeze until the hash was ready, but the code lives in a class that inherits QThread.

One important feature to note about the code above is that the communication with the rest of the application is via signals (the error and completed signals to be precise). This is very important as it means that when we use the class, we can simply use it like this:

    hasherThread = new HasherThread( this );
    connect( hasherThread, SIGNAL(error(const QString &)),
             ui->resultEdit, SLOT(setText(const QString &)) );
    connect( hasherThread, SIGNAL(completed(const QString &)),
             ui->resultEdit, SLOT(setText(const QString &)) );

The special thing in the code above, is that we didn't have to do anything special - Qt just solved our inter-thread communication issues for us. What I mean, it that if our code had simply tried to output the result by calling ui->resultEdit->setText() directly then we would be attempting to access the GUI from outside the GUI thread which would most likely cause our application to crash. Instead, since we're using the default type of connections 'AutoConnection', what this means is that Qt will spot if the thread in which a signal is emitted is different from the one in which it is received and handle the necessary synchronisation for us - nice!

Some of Akonadi's resource agents (usually just called resources) work on local files, some on files containing more than one data object, some on directories containing one data object per file.

For example the "VCard Resource" has one vcf file to work with which in turn contains any number of vcards, i.e. contacts.

Those single file storage containers have a couple of things in common so of course we want to share as much of code between their respective resources as possible.

Unfortunately the data inside the different files is formatted quite differently, so the parsing and creation of C++ objects is rather type specific.
Another difference which can make common code difficult is the expected size of the files and each of its entries, i.e. a VCard file will most likely just contain a couple of dozen contacts, maybe in the lower hundret range while an MBox file can easily reach several thousands of entries and each of its entries (emails) is usually larger than one of the contacts.

So code that works well for contacts or calendars does not necessarily work well for messages and vice versa.

While thinking about possible ways to improve our situation I had the idea of using the same level of abstraction we are already using in Akonadi, i.e. generic "Items" which hold the type specific data as their "Payload".

In other words, if we had an "Akonadi Item File" we would get Akonadi items out if it and not have to care about whether those items transport contacts or emails.

This would still leave us with the problem of different file and item sizes. Again I decided to use concepts already proven useful in Akonadi: payload parts and gettings things on demand.

Payload parts refer to a concept where allow for a payload (remember that could be a contact or an email, etc) be split into parts that make sense for the respective data type, e.g. splitting an email into "Headers", "Body" and so on.

Getting things on demand refers to get whatever parts of an item you are interested in at any time, e.g. only getting headers when listing a mail folder and getting the rest when displaying a selected one.

In Akonadi we do this through jobs and telling those jobs what we expect them to return to us.

The respective Akonadi code would look similar to this:

const Collection collection = someModel->selectedCollection();

ItemFetchJob *job = new ItemFetchJob();
job->fetchScope().fetchPayloadPart( MessagePart::Header );

connect( job, SIGNAL( result( KJob* ) ), this, SLOT( collectionListed( KJob* ) );

with collectionListed() doing something like that

ItemFetchJob *job = dynamic_cast( job );

const Item::List items = job->items();
// fetch the first item as a whole

job = new ItemFetchJob( items[ 0 ] );
job->fetchScope().fetchFullPayload();

connect( job, SIGNAL( result( KJob* ) ), this, SLOT( itemFetched( KJob* ) );

In order to do something similar with files I came up with a concept I called the Akonadi Filestore.
The main interface looks like this (omtting some of the methods not important for our example above)

class StoreInterface
{
  public:
    virtual Collection topLevelCollection() const = 0;

    virtual ItemFetchJob *fetchItems( const Collection &collection, const ItemFetchScope *fetchScope = 0 ) const = 0;

    virtual ItemFetchJob *fetchItem( const Item &item, const ItemFetchScope *fetchScope = 0 ) const = 0;
};

Assuming we have an implementation that operates on a file which contains messages, e.g. an MBox store, we can implement the example above quite similar to the respective Akonadi code.
(note: all jobs are named like the ones from Akonadi but live in their own namespace. Collections, items, fetchscope are directly the classes from Akonadi)

// lets assume mStore is of type StoreInterface* and has been
// initialized properly with an MBox store implementation

// lets list the mails in the stores top level collection
ItemFetchJob *job = mStore->fetchItems( mStore->topLevelCollection() );
job->fetchScope()->fetchPayloadPart( Message::Header );

connect( job, SIGNAL( result( KJob* ) ), this, SLOT( collectionListed( KJob* ) );

with collectionListed() doing again something like that

ItemFetchJob *job = dynamic_cast( job );

const Item::List items = job->items();
// fetch the first item as a whole

job = mStore->fetchItem( items[ 0 ] );
job->fetchScope().fetchFullPayload();

connect( job, SIGNAL( result( KJob* ) ), this, SLOT( itemFetched( KJob* ) );

As you can see we get on demand, payload part fetching with the only type specific thing being the name of the header payload part.
In Akonadi resource this difference would removed because Akonadi forwards the payload part from the client requesting it, so the resource does not have to know any of those identifiers itself.

This is already quite nice but it gets better
- We no longer require the items to be of the same type, say a ZIP file containing contacts, calendars and emails (or like an Outlook PST file)

- We can include metadata that is not part of the common payload formats, e.g. flags of email messages if the store's format supports that (or if it is actually working with more than one file, e.g. KMail is saving this things into index files it keeps alongside the actual mail files).

Neither design nor implementation are fully production ready, I consider it a testbed for the concepts mentioned above.
You can find it in PIM Playground (to get correct paths either checkout playground/pim/akonadi or create a directory "akonadi" into which you checkout "filestore")

In my ongoing distraction from working on the Akonadi Exchange resource, we released OpenChange 0.9 today.

Release notes:
Improved portability, including a focus on supporting FreeBSD, OpenSolaris and other systems that do not use GNU libraries / shells; and portability fixes for use of the Intel C Compiler and Sun Studio compiler. 64 bit architectures should be better supported in this release.

Preliminary support for Exchange 2003/2007 specific protocols (EcDoConnectEx and EcDoRpcExt2) was added, and redirection support was implemented. This should fix the ecWrongServer (0x478) error that some users encountered while running openchange based software in a clustered Exchange environment. Note that OpenChange is regularly tested with Exchange 2003 and Exchange 2007.

Support for encrypted communications between client and server has been added.

Exchange 2010 has been only lightly tested, and there may be some problems. To use a default Exchange 2010 installation (which requires encryption), you must add --encrypt to the mapiprofile command line options at profile creation time.

New libmapi functionality in server operations, properties and in convenience functions. The following Remote Operations were added in this release:

* ReloadCachedInformation
* GetValidAttachments
* TransportNewMail
* CloneStream
* WriteAndCommitStream
* SetPropertiesNoReplicate
* HardDeleteMessagesAndSubfolders
* HardDeleteMessages
* LockRegionStream / UnlockRegionStream
* OpenEmbeddedMessage

Bug fixes for various libraries and utilities, and improved tests.

Reworked exchange2ical utility (from Ryan Lepinski's Summer of Code project), which improves interoperability with other ICalender tools.

Improvements for the OpenChange proxy server (mapiproxy).

Improved documentation, including enhancements to the API documentation.

Improved python bindings.

Improvements for the OpenChange server - now works properly with the current (alpha10) release of Samba4. [Note: The server is not fully functional in this release, this is a developer preview].

For a full list of changes, please consult the complete Changelog.

The OpenChange Core Team would like to thank the following people for their contributions to this release:

* Alan Alvarez
* Arnout Engelen
* Brian Lu
* Erik Hovland
* Girish Venkatachalam
* Kamen Mazdrashki
* Johnny Jacob
* Paolo Abeni
* Ryan Lepinski

I've been working on the next OpenChange release (0.9), and it is getting quite close.

So where are we up to:

• Merge of Ryan Lepinski's Summer of Code project (on converting Exchange calendars to the ICal format) is done.
• Did some more testing with Exchange 2010.
• Julien Kerihuel added support for encrypted connections, which are required in a default install of Exchange 2010.
• The server provisioning works again. (Note: Server is pre-alpha. This is a developer preview only, not intended for any kind of other use.)
• More documentation tweaks.

I'm pretty happy with where we're going on this release. It has been a bit slower than we'd expected, but there are also some useful fixes that are about to go in, especially one related to how recipients are handled, which is a nasty problem for many users.

Unfortunately I've introduced some regressions with the merge of the Exchange / Ical stuff, including failure to build on FreeBSD 7.2 (although FreeBSD 8.0 is fine) and a case where some kinds of appointments cause crashes. The problem on FreeBSD 7.2 relates to use of the "timezone" variable (in time.h). We also still have quite a few problems with Exchange 2010, although some of those are places where Microsoft changed the server behaviour, so the underlying Exchange RPC method simply can't work. However the problems shouldn't take too much more work to knock into shape, and the buildbot setup is good for catching some of those problems.

I've also grabbed a slot for a BoF (Birds of a Feather - informal get together) session at linux.conf.au 2010. You can find the details of the BoF on the wiki (Thanks to Andrew for pointing out that I originally had grabbed the slot during the closing ceremony, and sorry for anyone that can't make that time - unfortunately with so many great presentations, there isn't a "good" time).

The OpenChange project is also actively looking for potential sponsors for hosting (servers, connectivity, or both) and for more people to get involved in the project. Here is the mailing list post that Julien made:

Background:

      * OpenChange has:
        
              * main website: http://www.openchange.org
              * wiki: http://wiki.openchange.org
              * ticket management system: http://trac.openchange.org
              * websvn: http://websvn.openchange.org
        
        
      * The main website has not been updated since April 2009. This
        unfortunately demonstrates that the core OpenChange team was not
        able to find the time requested to manage the website properly
        or add entries on a regular basis.



      * Our main server starts to show some bandwidth and resources
        limitations due to the large number of visitors.
        
        

Recruitment:

The OpenChange project is looking for new team members and contributors
who would endorse:


              * Community Manager role:
                
                      * manage the overall website
                      * coordinate the editing effort
                      * review the blog entries (technically and
                        grammatically)
                      * be actively involved in OpenChange project life
                        (follow development, related projects etc.)
                      * be actively participating and contributing to
                        the list
                        
                        
                        
              * Regular Contributors roles:
                
                      * contribute to the OpenChange website
                      * submit blog entries such as:
                        
                              * experience with OpenChange code
                              * tricks and tips
                              * code samples / snipset
                              * desktop recording / screencast
                              * technical documentation
                              * final-user documentation
        
        

Services Providers:

Infrastructure is important for the project to grow from a "sourceforge"
size project to a major project. We have some issues that are probably
common with many projects, and some unique things that we'd
like.                        
The key things are that we have a supportable, sustainable
infrastructure that allows us to get the project done. 

        
        
              * Candidates for services should provide:
                      * high bandwidth (100Mbits)            
                      * high availability                    
                      * access for openchange team members to
                        configure / update as required
                
                
              * Rough indications of bandwidth usage (websvn, svn
                checkouts, website usage) to potential providers:
                
                      * minimum is 52Gb and max is 87Gb per month
                      * "roughly 60/70Gb month"
                      * Further details can be provided on request
                
                
              * List of services and servers for the upcoming
                infrastructure:
                
                      * Server 1:
                        
                              * Trac
                              * SVN read-only mirror (primary repository
                                for non-team members)
                              * WebSVN
                                
                      * Server 2:
                        
                              * Main Website
                              * Wiki
                                
                      * Server 3:
                        
                              * Main Website mirror
                              * Wiki mirror

The lack of reliable services has held up development on a few occasions, and we really don't want that to continue.

Also, like most projects, we're always looking for more contributors. So if those descriptions don't sit well with you, but you have another interest, please get in contact with us. IRC can be a useful place to get started - we're usually in #openchange on FreeNode.

I have self-backed policy of not mentioning competition if not really necessary, let it be G or M. So as a minimal effort I just quote these carefully selected bits (bias included!) instead of commenting the recent story:

[..] I think there is no reason to work on another package which is equivalent to Qt. If you want something like Qt, use Qt.

  --Richard Stallman, September 5, 2000 about then-disappearing need for creating Qt replacvement (aka project Harmony) after GPLing Qt

[..] We evaluated writing a free Qt replacement, but reimplementing an API would most likely result in less efficient software and would have taken too long to implement. GNUstep, Wine and LessTif were other projects that had attempted to reimplement a proprietary API and just had a limited success after a long development history.
  --Miguel de Icaza, ~2000 mentioning that the story of reimplementing proprietary APIs in FOSS did not start just with appearance of mono & moonlight

As much as I love Gtk+ and the Gnome desktop, our contributions for our desktop applications and for Gtk+ come mostly from from folks developing on Linux for Linux (with a handful of exceptions). And we are a small fraction of desktop developers.

In my mind what is interesting to me about building applications with Silverlight is that we can create an ecosystem of free software applications that run on all three major platforms: Windows, Linux and MacOS.
  --Miguel de Icaza, November 12, 2009 on "next generation API for building GUI applications"

I think we can congratulate Trolls that the Qt/Windows, Qt/*nix and Qt/MacOS products and communities are vital and have been for so many years, and also congratulate the KDE community as a whole that the KDE/Windows and KDE/Mac projects are well established.

[..] The most important piece of news from last week's PDC was Microsoft's decision to turn Silverlight into the universal platform for building cross platform applications.

  --Miguel de Icaza, November 23, 2009 after visiting MSPDC09

He is apparently quite excited with capatibilities of .net+silverlight as "Universal GUI toolkit", and advertising it for needs are already covered by long available Free Software offerings like Qt and KDElibs.

The story about "replacements" proposed by Miguel does not end with replacing GUI toolkits or C++/Java with C#, there are his nice words about replacements for the OpenDocument format and Sourceforge - all this is syndicated on the Plant G and that is, I feel, exactly what's been criticized by RMS.

Not really a KDE related post, but instead one about the OpenChange project.

OpenChange is a project to implement the Microsoft Exchange / Outlook protocols, and we're creeping up on the 0.9 release. For those not familiar with it, the aim is to be wire-level compatible, so that you can use a FOSS client (such as Evolution or an Akonadi client) with an unmodified Exchange server.

OpenChange depends on some underlying Samba4 libraries, so we normally work with the Samba project to get releases that basically match up - we don't want to rely on building bits of Samba4 from the git repository, and we don't want to depend on really on versions of Samba4. Not too far ahead, and not too far behind. Just right...

The next release of Openchange (0.9 "COCHRANE") will rely on Samba 4 alpha9. So the main thing to do is to make sure that we can work with the current state of Samba 4, to provide patches to Samba for stuff that needs to be fixed on the Samba side, and to have changes for OpenChange ready to go.

We expect to release within two weeks of Samba 4 alpha9, but OpenChange 0.9 will be released when it is considered done.

We anticipate a 0.10 release in early 2010, and probably a subsequent 0.11 release prior to 1.0.

I've gone through the trac tickets, and moved anything that can't reasonably be achieved for 0.9 to a 0.10 milestone. Large changes have to wait for 0.10 - it is getting very late to risk destablising libmapi.
So what we still have left:
- integrate exchange2ical work from Ryan Lepinski into trunk
- ensure that OpenChange works with FreeBSD/OpenBSD
- ensure that OpenChange works with OpenSolaris
- libmapi/Samba4 API updates
- mapiproxy/Samba4 API updates and association group API evolution
- a couple of tickets that may not be too hard to fix, related to pkg-config support
- a ticket related to Free / Busy time support that has a crash.
- a patch that checks some return values that we current don't handle.
- some documentation stuff.

Details are on http://trac.openchange.org.

Known problems:
- openchange development server will not be working "as it is". Resolving this requires revision of the OpenChange schema updates (to match Samba4 changes). This may not be resolved for 0.9.

If I've dropped a patch, or there is something you really need for 0.9, now is your chance to make yourself known. Probability of a patch being applied is inversely proportional to complexity, and also inversely proportional to how close I think the release is. That is, simple and soon is good.

Once again, its been a long time since I blogged. I have been doing a bit of OpenChange development though.

Mostly its been minor bug fixes, cleanups and so on. This weekend I decided to take on something a bit more substantial. Email rules handling between Microsoft Outlook and Microsoft Exchange are pretty sophisticated, and OpenChange didn't do too much of it. I ended up having to get all the way down to the unmarshalling data structures from the RPC calls to understand why things didn't work. Its starting to come together now, with the condition part of the rule mostly under control (although not complete) and the actions part of the rule hopefully not too hard once I get conditions sorted.

I'm a long way from done, but the current diffstat:

 exchange.idl             |   97 ++++++-----
 libmapi/conf/mparse.pl   |    4
 libmapi/emsmdb.c         |   10 +
 libmapi/mapidump.c       |  384 +++++++++++++++++++++++++++++++++++++++++++++++
 libmapi/property.c       |  152 ++++++++++++++++++
 utils/openchangeclient.c |   84 ++++++++++
 6 files changed, 686 insertions(+), 45 deletions(-)

Most of the IDL changes are just reorganising the order of things. The hard bits were in libmapi/property.c.

OpenChange is a library, so there aren't nice GUI screenshots. However I can show the results of a new openchangeclient operation, to list the rules on a mailbox folder:

bradh-dev@saxicola:~/openchange/oxorule$ ./bin/openchangeclient --ruleslist
[10] "which is an Out of Office message" (0xE1FCF59014000001)              
        rule provider: RuleOrganizer                                       
        state: 0x00000011 ( ST_ENABLED ST_EXIT_LEVEL )                     
        All of the following are true:                                     
                Content of PR_MESSAGE_CLASS_UNICODE matches (case insensitive) IPM.Note.Rules.OofTemplate.Microsoft                                                                                                                 
                All of the following are true:                                                                    
                        PR_MESSAGE_SIZE is greater than 12288                                                     
                        PR_MESSAGE_SIZE is less than 20480                                                        

[11] "where my name is not in the To box" (0xE2FCF59014000001)
        rule provider: RuleOrganizer                          
        state: 0x00000001 ( ST_ENABLED )                      
        All of the following are true:                        
                PR_MESSAGE_TO_ME is equal to false            
                Comments contain 4 tagged values:Unknown tag: 0x60000003 (1), Unknown tag: 0x00010102 (<>), Unknown tag: 0x0001001f (priority@example.com), PR_DISPLAY_TYPE (0),  Restriction present:                      
                        PR_SENDER_SEARCH_KEY is equal to <>                                               
                All of the following are true:                                                                    
                        PR_FLAG_STATUS is equal to 2                                                              
                        Unknown tag: 0x802a001f is equal to Call                                                  

[12] "test user1 or foo@example.com" (0xE3FCF59014000001)
        rule provider: RuleOrganizer2                    
        state: 0x00000001 ( ST_ENABLED )                 
        Any of the following are true:                   
                Comments contain 4 tagged values:Unknown tag: 0x60000003 (1), Unknown tag: 0x00010102 (<>), Unknown tag: 0x0001001f (test user1), PR_DISPLAY_TYPE (0),  Restriction present:                                
                        PR_SENDER_SEARCH_KEY is equal to <>                                               
                Comments contain 4 tagged values:Unknown tag: 0x60000003 (1), Unknown tag: 0x00010102 (<>), Unknown tag: 0x0001001f (foo@example.com), PR_DISPLAY_TYPE (0),  Restriction present:                           
                        PR_SENDER_SEARCH_KEY is equal to <>                                               

[13] "'Old project' or 'Really old project'" (0xE0FCF59014000001)
        rule provider: RuleOrganizer
        state: 0x00000011 ( ST_ENABLED ST_EXIT_LEVEL )
        Any of the following are true:
                Content of PR_SUBJECT_UNICODE contains (case insensitive) Old project
                Content of PR_SUBJECT_UNICODE contains (case insensitive) Really old project

[14] "Project X" (0x15B3492E12000001)
        rule provider: RuleOrganizer
        state: 0x00000001 ( ST_ENABLED )
        Content of PR_SUBJECT_UNICODE contains (case insensitive) Project X

[15] "'Viagra' or 'herbal'" (0x14B3492E12000001)
        rule provider: RuleOrganizer
        state: 0x00000011 ( ST_ENABLED ST_EXIT_LEVEL )
        Any of the following are true:
                Content of PR_SUBJECT_UNICODE contains (case insensitive) Viagra
                Content of PR_SUBJECT_UNICODE contains (case insensitive) herbal

[16] "Administrator" (0x16B3492E12000001)
        rule provider: RuleOrganizer
        state: 0x00000001 ( ST_ENABLED )
        All of the following are true:
                Comments contain 4 tagged values:Unknown tag: 0x60000003 (1), Unknown tag: 0x00010102 (<>), Unknown tag: 0x0001001f (Administrator), PR_DISPLAY_TYPE (0),  Restriction present:
                        PR_SENDER_SEARCH_KEY is equal to <>
                PR_IMPORTANCE is equal to 2

That mostly converts the data structure into something intelligible (although there are a few things that I'm not able to sensibly represent in natural language yet, as you can see. There are other variations within the outlook rules, and my code cannot yet do them all. It isn't too hard to complete, but I'm trying to make sure I have test cases for each case before implementing. If you have a really sophisticated set of rules within outlook and would like to share them, feel free to export them and mail it to me.

While sipping from a Vignes de Nicole and nibbiling on some Heukäse, I am thinking about Wine. Not the liquid version, but the software project.

As a reader of Linux Weekly News, I noticed that the Wine project makes very frequent releases. I looked up its release history and saw that Wine has made a developer release every fortnight for the last four years. The 11 years before that the releases were approximately monthly. Each of these development releases comes with an announcement with a long list of the changes that happened in these two weeks. This dedication is due to Alexandre Julliard who has made all of those releases.

Releasing so regularly is a sign of health. Still, within the Wine team, people were dissatisfied with the occurance of regressions in their code. So patchwatcher was written. Patchwatcher is a set of scripts that do pre-commit checking of patches. There is a good overview that explains the design of the system.

The system picks patches from the patch mailing list and tests them. The results of the tests are available publicly and the maintainer will only commit a patch when no tests fail due to the patch. This conservative approach pays off. Not all developers are subject to this regime. If they introduce a regression, git bisect is used to find the problem.

The rigor of Wine development is inspiring. I will browse the Wine developer wiki more often.

The main openSUSE users' mailing list are a demanding bunch who know what they want. Over the last few months the KDE group have been asking them what they still miss from KDE 3 in KDE 4, and one of those things has been the ability to add a submenu of the main app launcher, whether Kickoff or traditional, to the panel as a button in its own right.

I thought Chani's recent blog about a generic app menu dataengine for KDE 4 could be useful in reimplementing this feature, so I sat down for a quick Friday afternoon hack. However, after a while I realised that I could do better than just hacking up another menu applet implementation. I realised that we already have all the code needed for building the menu tree, drawing the menu, handling the clicks, and configuring the menu in the existing launcher menus ('start buttons'). Looking at the code, it just came down to changing the point in the menu used for the menu's root. So I added a way to enable the context menu for submenus, identify the path of the submenu, then tell the panel or the desktop to add a new 'simplelauncher' applet using the original submenu as the menu root. The changes were only a few lines of code to the existing applets so we have a nice minimal yet fully-featured solution.

That didn't take too long so I even had time to make a movie:

OGG Theora version

Flash version

There has been some confusion about Google data capabilities around the KDE 4.3 release.

The 4.3 Feature Plan has an entry for that and it is marked as "Completed".

What it meant is that the Google Data resoures by Adenilson Cavalcanti would be available at the time of the 4.3 release, however it got, understandably, interpreted as being part of KDE PIM in 4.3.

Lesson learned: don't put features which are not part of the main modules on the feature plan.

Anyway.
The Google Data resources are currently developed and maintained as part of KDE's extragear effort, basically a "third party" module hosted on KDE's infrastructure.
Applications in there follow their own development and release cycles, though I think it is possible to put tags on certain versions to indicate which version will work best with the newest KDE release.

In case of the Google Data resources, the original plan of releasing simultaniously with KDE 4.3 got scrapped in favor of an urgent fix in one of the two resources and, IIRC, in the Google Data access library used by both.

Since neither the maintainer nor any of us from the KDE PIM had previous experience with extragear style releases, we seem to have failed doing a proper release announcement or doing it at the proper channels.

The source archive for the resources can be found here, depending on the libgcal version 0.9.2 which can be found here.

We might decide to move their code into the main KDE PIM module (kdepim-runtime actually) at a later version. For now the extragear style has the advantage of allowing a fast paced development with released in between KDE releases.

Once in a while we come across rumors, urban ledgends and myths about all kinds of things.

For example you might have read, heard or otherwise encountered wild claims about Akonadi's dependencies, maybe even as ridiculous as "depends on KDE".

Don't get me wrong, I don't have the slightest problem with stuff depending on KDE, but one of Akonadi's goals is to be a viable option for all PIM applications and a dependency on KDE would make that quite hard.

So I spent a couple of days updating my Java skills by writing a proof-of-concept Akonadi client in pure Java (re-using the Unix socket adapter written for the Java D-Bus bindings).

Granted, it is not an extremely impressive client. Its functionality is to "walk" through the Akonadi collection tree, print collection properties to its console output and list each collection's items.

The output for each collection is formatted like this:

Name
    identifier (remote identifier)
    list of possible content MIME types
      item identifier (item remote identifier) item MIME type

On my test system the Akonadi folder structure looks like this

In the output of the demo app it looks like this:

Creating Akonadi data connection at /home/kevin/.akonadi-test/.local/share/akonadi/akonadiserver.socket
Birthdays & Anniversaries
    5 (akonadi_birthdays_resource)
    application/x-vnd.akonadi.calendar.event
      72 (b19) application/x-vnd.akonadi.calendar.event
      73 (b29) application/x-vnd.akonadi.calendar.event
      74 (b52) application/x-vnd.akonadi.calendar.event
      75 (b55) application/x-vnd.akonadi.calendar.event
      76 (b64) application/x-vnd.akonadi.calendar.event
      77 (b65) application/x-vnd.akonadi.calendar.event

Search
    1 ()

akonadi_googledata_resource_0
    6 (google-contacts)
    text/directory
      78 (http://www.google.com/m8/feeds/contacts/abcd%40gmail.com/full/0) text/directory
      79 (http://www.google.com/m8/feeds/contacts/abcd%40gmail.com/full/32b8b2c80dd7cb2d) text/directory

std.ics
    3 (file:///home/kevin/std.ics)
    text/calendar
    application/x-vnd.akonadi.calendar.event
    application/x-vnd.akonadi.calendar.todo
    application/x-vnd.akonadi.calendar.journal
    application/x-vnd.akonadi.calendar.freebusy
      2 (KOrganizer-874394642.152) application/x-vnd.akonadi.calendar.event
      3 (KonsoleKalendar-1123156469.102) application/x-vnd.akonadi.calendar.event
      4 (KOrganizer-313723522.982) application/x-vnd.akonadi.calendar.event
      5 (KOrganizer-1709699137.995) application/x-vnd.akonadi.calendar.event
      6 (KOrganizer-756482139.219) application/x-vnd.akonadi.calendar.event
      7 (libkcal-598331247.452) application/x-vnd.akonadi.calendar.todo

Kolab
    15 (akonadi_kolabproxy_resource)
    inode/directory

    demo.kolab.org/kevin.krammer@demo.kolab.org
        16 (7)
        inode/directory

        My Data
            17 ( 8 )
            inode/directory

            Calendar
                20 (10)
                inode/directory
                application/x-vnd.akonadi.calendar.event

            Contacts
                19 (11)
                inode/directory
                text/directory
                application/x-vnd.kde.contactgroup
                  88 (81) text/directory
                  89 (82) text/directory
                  90 (83) text/directory
                  91 (84) application/x-vnd.kde.contactgroup
                  92 (85) text/directory
                  93 (86) application/x-vnd.kde.contactgroup
                  94 (87) text/directory

            Journal
                18 (12)
                inode/directory
                application/x-vnd.akonadi.calendar.journal

            Notes
                21 (13)
                inode/directory
                application/x-vnd.akonadi.calendar.journal

            Tasks
                22 (14)
                inode/directory
                application/x-vnd.akonadi.calendar.todo

std.vcf
    4 (file:///home/kevin/std.vcf)
    text/directory
      8 (2bpus4eE8c) text/directory
      9 (2efjr21aA) text/directory
      10 (2uun8V066z) text/directory
      11 (3abf3YIm3w) text/directory
      12 (4w20Vzaqu) text/directory
      13 (566ynkrpNY) text/directory
      14 (5JBqjwr9D4) text/directory

demo.kolab.org/kevin.krammer@demo.kolab.org
    7 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/)
    inode/directory

    Inbox
        8 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX)
        message/rfc822
        inode/directory
          80 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX-+-1) message/rfc822

        Calendar
            10 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Calendar)
            message/rfc822
            inode/directory

        Contacts
            11 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Contacts)
            message/rfc822
            inode/directory
              81 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Contacts-+-1639) message/rfc822
              82 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Contacts-+-1640) message/rfc822
              83 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Contacts-+-1641) message/rfc822
              84 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Contacts-+-1643) message/rfc822
              85 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Contacts-+-1649) message/rfc822
              86 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Contacts-+-1651) message/rfc822
              87 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Contacts-+-1652) message/rfc822

        Journal
            12 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Journal)
            message/rfc822
            inode/directory

        Notes
            13 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Notes)
            message/rfc822
            inode/directory

        Tasks
            14 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/INBOX/Tasks)
            message/rfc822
            inode/directory

    shared.common playground
        9 (imap://kevin.krammer@demo.kolab.org@demo.kolab.org/shared.common playground)
        message/rfc822
        inode/directory