I want a widget that is the combination of GtkComboBoxEntry and GtkEntryCompletion that can display a tree of options in a nice, indented way without the expanders (but with the rows expanded). Basically, a search box with a drop-down and hierarchical entries. I think I'm going to have to write my own, thought it sounds like something that might be more widely useful than just my application.


Visited nixwilliams and daniel_bethany for a cup of tea, which become lunch (which was delicious) which became more tea, which became waiting out the rain and watching Nicholas Crane trip over a lot. Got wet going home anyway. Now waiting out the rain again before going to the shops. It's a good thing that I like rain; though mostly I like wearing a giant, warm jumper while it rains outside.

> Read More... | Digg This!

It has been a few weeks now since Aq and I started doing our new podcast, Shot Of Jaq. What a crazy few weeks. As some of you will know, we did LugRadio for four years, and we really got into the habit of the LugRadio formula. Four year and 2million downloads later, I am proud [...]

> Read More... | Digg This!

Winter is here, the snow is falling, the frost is crisp each morning and it get progressively harder to break the ice for the day's canoe.

Fortunately Kubuntu has just the thing to keep you snug in these cold months. From the davmor2 knitware shop comes the Kubuntu jumper range. Available in a selection of colours including beige with blue, beige with ligher blue and beige with cyan, it has been carefully crafted by designer extraordinaire Sue Morley over many months of hard work. Order one now, it's the perfect fashion item to impress that special someone in your life for Christmas (possible 6 months waiting time from ordering).

Hugs to Sue for being the best knitter I know.

> Read More... | Digg This!

The Smoke based QtScript bindings are progressing well, and are now called 'JSmoke' in the style of 'JQuery' the JavaScript library or 'JScript' the .NET JavaScript implementation. In KDE promo-like words, I hope this will 'raise the brand recognition' of the state of the art KDE Smoke dynamic language bindings technology.

The project now has 24 QtScript plugins for the following libraries:

qtcore
qtdbus
qtgui
qtmultimedia
qtnetwork
qtopengl
qtsql
qtsvg
qtuitools
qtwebkit
qtxml
qtxmlpatterns
kdecore
kdeui
kfile
khtml
kio
knewstuff2
knewstuff3
kparts
ktexteditor
kutils
plasma
solid

There is a common 'libjsmokeruntime' lib that the plugins share. For running scripts there are two executables 'jsmokeapp' and 'jsmokecoreapp' for GUI and command line apps respectively. 'jsmokeapp' loads the qtcore and qtgui plugins and starts a QApplication. There still needs to be a 'jsmokekapp' which will start a KApplication, load the base KDE plugins, and run a KDE based script. Today I got a half Qt/half KDE app working. Here is the code:

qs.script.importExtension("jsmoke.kdecore");
qs.script.importExtension("jsmoke.kdeui");
qs.script.importExtension("jsmoke.kio");

function MainWindow(name) {
    KMainWindow.call(this, name);

    this.setObjectName(name);
    this.setCaption("KDE Tutorial - p3");

    var filemenu = new QMenu("&File", this);
 
    var openAction = new QAction("&Open", this);
    openAction.triggered.connect(this, this.fileOpen);
    filemenu.addAction(openAction);

    var saveAction = new QAction("&Save", this);
    saveAction.triggered.connect(this, this.fileSave);
    filemenu.addAction(saveAction);

    var quitAction = new QAction("&Quit", this);
    quitAction.triggered.connect(QCoreApplication.instance(), QCoreApplication.instance().quit);
    filemenu.addAction(quitAction);

    var about = "p3 1.0nn" +
                 "(C) 1999-2002 Antonio Larrosa Jimenezn" +
                 "larrosa@kde.orgttantlarr@supercable.esn" +
                 "Malaga (Spain)nn" +
                 "Simple KDE Tutorialn" +
                 "This tutorial comes with ABSOLUTELY NO WARRANTYn" +
                 "This is free software, and you are welcome to redistribute itn" +
                 "under certain conditionsn";
    helpmenu = this.helpMenu(about);

    var menu = this.menuBar();
    menu.addMenu(filemenu);
    menu.addSeparator();
    menu.addMenu(helpmenu);

    var hello = new QTextEdit(
            "<H2>Hello World !</H2><BR>This is a simple" +
            " window with <I><font size=5><B>R<font color=red" +
            " size=5>ich </font><font color=blue size=5>Text" +
            "</font></B></I> capabilities<BR>Try to resize" +
            " this window, all this is automatic !", this );
    this.setCentralWidget(hello);
}

MainWindow.prototype = new KMainWindow();

MainWindow.prototype.fileOpen = function() {
    var filename = KFileDialog.getOpenUrl(new KUrl(), "*", this);
    var msg = ("Now this app should open the url " + filename);
    KMessageBox.information(null, msg, "Information", "fileOpenInformationDialog");
}

MainWindow.prototype.fileSave = function() {
    var filename = KFileDialog.getSaveUrl(new KUrl(), "*", this);
}

window = new MainWindow("Tutorial - p3");
window.resize(400, 300);
window.show();

QCoreApplication.instance().exec();

Today I also got the code working with Qt 4.6 pretty much. There is still a problem with setting QObject properties, although reading QProperties works fine. This is unfortunate because most of the examples set QProperties, and don't work with Qt 4.6. You need to build all the smoke libs in the trunk kdebindings, before you will be able get all the plugins to link. To build with Qt 4.5, you will need to disable the KDE plugins and QtMultimedia.

What is there still to be done? Well, loads of things. But I feel the bindings are starting to be useful, as they now have pretty complete coverage of Qt 4.6 and the KDE 4.4 kdelibs classes. The names and general structure of the project are in place, and it is now a proper KDE project - you are very welcome to try it out provide feedback, and help finish it off..

> Read More... | Digg This!

Five years ago today, one of my heroes was murdered. Dimebag Darrell, guitarist from Pantera, Damageplan and Rebel Meets Rebel was shot while performing in Columbus, Ohio by Nathan Gale, a crazed fan disgruntled with the split of Pantera. The metal world and beyond was devastated by the news. In such a tight-knit and almost-tribal [...]

> Read More... | Digg This!

In an attempt to follow up on my blog about Akonadi porting xplained I am going to write about Akonadi migration.

It is basically the data storage related cousin of porting:
Porting is, as we learned, about adapting applications to a new way of handling data.
Migration is about adapting data to new ways of being accessed.

The last couple of months I unfortunately had too little time for development on either KDE or Akonadi so I spent the available time on thinking about mail migration.

You see, mail is a special case when we talk about migration because it has a couple of key differences when compared to other data types:

- amount
- location
- state/properties

The difference in amount of data is the most obvious one. Most users will have more messages in mail fodlers than contacts in their address book, messages will on average be a lot bigger than contacts, e.g. due to containing attachments.
It is actually very likely that the amount of mail data is several orders of magnitudes greater than that of contact data.
For example I have probably around 100 contacts in my address book and probably around 100 000 messages (if not more), consuming several Gigabytes of disk space.

The different in location of data is referring to the likeliness of messages being stored on a server vs. other data types like contacts.
Recent developments like Google Contacts have shifted that somewhat but it is still more likely to encounter a setup with contacts being locally and mail being remotely stored.
Due to this almost inevitable remote storage any migration process will have to deal with local caching of some sort, e.g. in the case of KMail the maildir used to cache mails of KMail's "Disconnected IMAP" account type.

The difference in data state or properties is a lot less obvious than the other two.
Even in the most basic usage scenario we have the message state changing from unread to read but it is highly likely that messages have additional properties attached such as "important" or "you have replied to this one".
This alone wouldn't be a problem if it would be part of the message or at least part of the file the message is stored in. However not all on-disk formats support that so applications like KMail had to find alternative ways of storing this additional information, e.g. "index" files.

Lets have a look at a couple of scenarios to see how these influence the miration process.

For comparison we'll take migration of a local address book:
- get location of address book file (e.g. KDE's std.vcf)
- create Akonadi storage handler for a VCard file
- point it to the location of the file
- done

A similar approach will work for a local maildir directory:
- get location of the maildir root directory (e.g. $HOME/Mail, $KDEHOME/share/apps/kmail/mail)
- create Akonadi storage handler for MailDir
- point it to the location of the file
- done

The messages stay right where they are, so amount of data is irrelevant. MailDir can encode most of the state data into the file name, so not an immediate problem either. Storage is local, no server involved, no caching to deal with.

Now have a look at another form of local mail storage: mbox
- get location of the mbox file (again rather trivial)
- create Akonadi storage handler for MBox
- point it to the location fo the file
- done

Done? Not quite. Doing it that way we'll lose state data in a way that's probably not acceptable to our users.

So what could we do?
One option would be to make the Akonadi storage handler for MBox understand, e.g. KMail's index files, but that is quite ugly, involved maintaining old code (at least the reading part) and is KMail specific or requires the Akonadi MBox resource to understand all kinds of such additional files.

I'll get back to this later but lets have a look at another example first: mbox file within a maildir tree
- get location of the mbox file (again rather trivial)
- create Akonadi storage handler for MBox
- point it to the location fo the file
- done

Since this shares the same problem as stand-alone mbox, I'll skip the related problems.
However, we have some additional issues here, one being that the Akonadi MBox resource will create a top level folder in Akonadi, thus "moving" the mail box folder out of the tree while keeping the file in it.
One possible solution would to have a resource which can handle mboxes inside maildir trees, but since mbox folders and maildir folders behave differently (e.g. mbox folders need to be "compacted" to really delete mails) we don't consider this a proper solution unless we run out of alternatives.

To not forget about the server location problem, lets finally also look at disconnected IMAP:
- get server connection values and login credentials
- create Akonadi storage handler for IMAP
- tell it about server and user
- done

As an attention paying reader you already know that we are not quite done yet
So what is it this time?
Can't be state of message, everything is on the server. Can't be the resulting folder locations, IMAP servers have always been treated separately.

Obviously it has something to do with the "disconnected" part, so lets have a closer look at that.
It means that KMail has a maildir tree somewhere that is more or less a copy of what's on the IMAP server.
More or less because it is like synchronizing between a remote and a local directory, i.e. changes on either side are not immediately visible on the other side, they are applied at resychronization times.

This leads to two complications for the migration process:
- the users will be very angry if we have them download all those message again
- some messages might have been added or deleted locally and the respective changes have not been synchronized yet

Again a possible solution would be to make the Akonadi IMAP resource understand this local cache and transaction logs, but again this is not a very clean solution.

I am sorry that this is already quite a long blog but maybe you are still interested in some of my thoughts on how to make this work nevertheless.

If we treat the process more like a form of importing instead of simply reattaching different storage handlers, we gain the possibility to change format and locations in a way that allows us to inform the users about these changes and most likely also allow for an advanced mode for people with really specific needs.
So instead of silently doing things in the background, KMail2 could bring up a GUI saying that it has detected a KMail1 setup and lets you choose between ignoring that, importing that the way it sees fit or letting you switch to an import GUI for customization.

Our scenarios above can then be handled like this:

MailDir: no difference there but potentially allowing a customized import routine to move the messages to a new base directory

MBox: top level mbox files can be handled by the Akonadi MBox resource, the importer can be KMail specific and understand the index files, attaching the additional information to the resulting Akonadi message items.
MBox files in side the maildir tree can be read by the importer and added as a new folder to the top level folder managed by the Akonadi MailDir resource, potentially allowing a customized import routine to move the mbox file and treat it like a top level folder instead.

Disconnected IMAP: similar to the "in-tree mbox" case, the importer can be made to understand KMail's form of caching and transaction state handling. However, differently to the "mbox -> maildir folder" conversion, we do not want the Akonadi IMAP resource to add the messages on the server, most of them will already be there.

Again my main idea is to let the importer understand what it is actually importing, in this case how the message is addressed on the server, and attach this information to the message when adding it to a folder managed by the Akonadi IMAP resource.
The IMAP resource will therefore only have to be extended to understand this additionally attached information, not how that used to be stored on disk.

I hope to have some time during the Chrismas holidays to experiement with some of the ideas.

> Read More... | Digg This!

Yesterday a package arrived on my doorstep. Not just a package, but a big one, and I had not ordered anything that big to be delivered. Lo and behold, said package had my name on it and the sticker said it was from Pete Graner, who is my colleague at Canonical leading the kernel team. [...]

> Read More... | Digg This!

Thanks to the awesome Nathan ‘nhandler’ Handler, we now have a daily builds PPA for Lernid. This means you can run the unstable, daily, crack-of-the-day version of Lernid and have it delivered automatically right to your desktop. Currently it is built for Ubuntu 9.10 Karmic Koala, and you can suck in the goodness by running: sudo [...]

> Read More... | Digg This!

Nice to see that the Japanese community has started a project to translate the OpenSolaris Bible. Ken Okubo is leading the effort. Check in on g11n-ja-discuss if you want to contribute.

> Read More... | Digg This!

Sriram Narayanan posted some nice updates to advocacy-discuss the other day (here, here, here, here) from FOSS.IN in Bangalore. It's excellent when people post mail like this to the community list when they are out at conferences because it leads to discussion around the world and helps generate ideas for the future. Connecting communities globally is just as important as building them locally.

Here are some FOSS.IN images from Kumar Abhishek. See the Bangalore OpenSolaris Community here. And, of course, the BeleniX distribution goes here. I couldn't make it to FOSS.IN again this year. Bummed. Maybe next year.

> Read More... | Digg This!

Hi all, just weighing in with another update on my pet project – Lernid. I have added a bunch of new features this week to Lernid: Notifications – events that are shown in the event list will now appear in the notification area. A notification bubble will pop up 10 minutes before an event begins to remind [...]

> Read More... | Digg This!

Today we enjoy 11th anniversary of disclosure of Microsoft's best business and development practices:

The concept has been reportedly in development since early 90-ies:

The practical and consistent extension of that achievement is introduction of the MSOOXML format:

• It is not compatible with ISO standard Office Open XML
• But those that use MS Office exclusively and upgrade frequently do not really care; moreover it is not a problem even for them to hear the mistyped OpenOffice XML name from time to time
• Office Open XML unlike MSOOXML has no implementation so far
• It is not clear whether Office Open XML is even implementable because of contradicting parts
• There is no something like MSOOXML specifications, instead there is something like "report from the current state of implementation", which has already been updated at least once and will be again for MS Office 2010
• MSOOXML is advertised as a dump of the binary DOC/XLS/PPT formats into the XML layer, and thus is a great advantage according to the creators
• The advantage is so big that as authors suggest, breaking XML principles is not a big problem (there is no known attempt to address the issues)
• Since MSOOXML, unlike ODF, was created behind closed doors, there was no planned or possible harmonization between the two; now since it is too late (there are implementations of ODF and MSOOXML) "interoperability" term is the new modern buzzword, but at least in Poland noone knows what this word really means (and yes, this is an apparent advantage)
• For making the binary->XML dump extensive documentation of the former was needed; so since finally Microsoft created docs, and the binary formats got declared as obsolete anyway, publishing is a double PR win ("we are so open", and "we're now OK in court cases")

The binary DOC/XLS/PPT formats are now somewhat documented in the public but this is not the end of the story. I've been mentioning this before and I'll trow this chair again: there are still MS Access file formats, as closed as in 1992, except for the huge work of never finished reverse-engineering. The current attitude is as follows:

When will Microsoft release the binary specs for Access MDB files?

Q: I need to be able to access these files on Unix / Linux and possibly mainframe based computer systems. Read access is all that is required. I need official Microsoft documentation or as an alternative routines written in C++ that can b used to compile on a Unix platform and access the MDB files.

A: Currently, we do not have any plans to document the Access MDB file format, or the SQL Server MDF file format.

more...

EOT. Assuming nobody like a bigger government player or European Commission is interested in openess of the format (our data!), it can still be kept as closed forever.

> Read More... | Digg This!

Alessandro is the TV star of Qt. Great stuff here.

> Read More... | Digg This!

Now that we have moved to XWiki, we should go about the business of localizing more of the OpenSolaris website. This is going to take a while and it will require work from the community and from the website engineering team. It may also require that some people from Sun and the OpenSolaris community get directly involved in the XWiki community, which could prove interesting as the communities benefit from each other's contributions. It's a big opportunity all around, and hopefully we'll be able to build more OpenSolaris development communities around the world by simply speaking more languages on our website. There will be multiple steps involved to localize everything, but here are the big three buckets:

1. Auth

Auth is already localized into 17 languages thanks to the contributions of the OpenSolaris community using the Sun Open CTI tool. In a few weeks, we will update auth, and then after that the community will be able to update the localizations for auth as well. The process of localizing auth is well known now, and we'll just move ahead as we have in the past. Auth is most important in this process because the more languages we can localize auth.opensolaris.org into the more languages we can offer on our implementation of XWiki at hub.opensolaris.org. Remember, hub is integrated with auth and part of that integration means that language preferences are set in auth.

2. XWiki

XWiki currently supports 21 languages. So, if you go to the OpenSolaris website and edit a page, you will see the following text in the right navigation bar:

Document translations
You are editing the original document.
Translate this document in: cs de en es fr pl ru zh

Here's what it looks like in a screen shot. Those eight languages represent the intersection between localizations supported on auth.opensolaris.org and those supported by the XWiki application. It`s important that we build out that intersection so we can enable more languages on hub.opensolaris.org for the community to localize more general OpenSolaris content. When you click on a language code in that nav, certain elements on the screen will immediately change to that language, and the URL will change to language=[whatever language you chose]. After you translate and save the page, the right nav bar and the top right side of the page will display the language code of your new language (among all the other translations) with a little flag icon. That tells users that the page is localized into any number of languages.

Now, here`s the challenging and/or confusing part: hub.opensolaris.org is not a wiki where anyone can edit and translate anything. The site is split up into many applications and and spaces but the content basically fits into three big sections:

1. Common Content: Sun's Website Team manages the common content on hub.opensolaris.org. This content includes the front page, project overview, FAQ center, roadmaps, site map, downloads, Collectives navigation, navs, header and footer spaces, style sheets, etc. Requests to update and translate this information can be made on website-discuss. Contact info here.
2. Collective Content: Leaders of Collectives (Community Groups, Projects, User Groups) are responsible for managing their own content. Contact info here.
   
3. Subsites Content: The website is made up of multiple applications, sometimes called subsites, that provide services to users and developers, and each subsite has an owner. The site map has details. Contact info here.
   

So, you can only translate content where you have privileges to edit in the first place, and the site gets all that user access data from auth, which is set up to implement the structure of the community as specified in the OpenSolaris Constitution. It`s actually not as complicated as it sounds. Here are the Roles and Collectives we built into the new site, and that should be enough to explain the structure without having to read the entire Constitution. Basically, if you have edit privileges to your areas on the site, then go translate content. Just do it. But if you want to translate content in an area of the site where you don`t already have edit privileges, then you should contact the Leaders in those areas and ask them if they would be interested in having their stuff localized and if the would give you the appropriate privileges to do that work. Can you imagine people saying no to that request? I can`t. And the manual process of going out and talking to people will only increase the number of interactions community members will have with each other.

3. Subsites

The subsites should to get localized at some point, too. This can be accomplished in three steps: First, the website engineering team will build a backend web application to serve all the common graphical elements of the OpenSolaris website to all the subsites, so that includes the headers, footers, wordmarks, logos, icons, etc. This way, the entire website can have a common look and feel (as much as possible given that there are many applications involved). Also, the benefit of this concept is when we have to update common elements of the site or add new translations then all of the subsites will be updated as well. Second, the OpenSolaris community can localize all the content for that web application via the Open CTI tool (this will be a future project) so even embedded text in icons can be translated. Third, OpenSolaris community members can contact the subsite owners and offer to translate content, which can then be uploaded to each subsite.

Contribute Right Now

So, to sum up a bit, here`s how you can contribute to this crazy website localization effort.

• Localize content in the areas that you already have privileges to edit. You can do that right now.
  
• Ask other Leaders in other Collectives if they would like you to localize their content. You can do that right now.
  
• Ask the Website Team if they`d like the common content on the site localized. The answer is yes, by the way. You can do that right now.
  
• Add more languages to auth via Open CTI by translating the auth resources file. Ask questions on i18n-discuss (subscribe here, archives here, forum here, blog here). A new auth resources file is coming soon.
  
• Add more languages directly to XWiki at l10n.xwiki.org by translating the XWiki ApplicationResources file. NOTE: WE NEED A JAPANESE TRANSLATION! I am talking with the XWiki community about this as well (see thread beginning here, about 15 messages). Currently, XWiki does not support Japanese (ja) among its list of 21 supported languages (it supports Japanese language text on pages, of course, but not at the application resources level with menue and icons and the URL). Subscribe to the xwiki users list here. You can do that right now.
  

What do you think?

> Read More... | Digg This!

Another quick Lernid update. So far, Lernid has merely provided a streamlined interface to the common components in Ubuntu Open Week or Ubuntu Developer Week. I have just completed some work which starts bringing unique value to Lernid as a user interface for these events. I have been wanting to have a means of providing a structural [...]

> Read More... | Digg This!