You sure know Qt demo. It provides a number of example applications and demonstrations that have been written to provide developers with examples of the Qt API in use, and showcase features found in each of Qt’s core technologies.

Wait. Don’t we have the Qt examples in the source tree to learn the API? Why is Qt Demo there? In my opinion, because it is a great seller: it’s a single and simple application which shows the greatest and best features of Qt. It’s a great tool to to convince your boss Qt is the right choice.

In KDE, we also have examples but we do not have a demo with bells and whistles.

My wish today: step in and create a KDE Demo showing the technologies and applications that make KDE a great platform: KIO, KParts, KAuth, Solid, Plasma, KXmlGui, KIPI plugins, Nepomuk, ThreadWeaver, Sonnet, KNewStuff, Kiosk mode, Kross, KDevPlatform, Phonon (some features are not present in the Qt version), Attica, KWallet, etc.

What would you like to see in a KDE Demo application? Do you think it could be material for a GSoC?

Update April 26th 2011 This idea has been accepted for Google Summer of Code 2011, I am mentoring Jon Ander Pealba this summer!

My last two wishes were a generic version control system library based on git and document-level versioning for Calligra (I’m talking about Calligra here but this applies to many applications, it’s just that Calligra is one where this fits very nicely). Those were the building blocks for this wish: in-document translations.

Say you are a company present in several locations and you want to send a document to your customers. You want to please them, make them know they are loved. One effective way to do that is to write them in their native language.

I don’t know what is your workflow when you have to write a document in several languages but this is mine:

  1. Create original document, generally written in English for proper review by everybody with a say and a vote. Save it as document_english.odt.
  2. Translate to Catalan and save as document_catalan.odt
  3. Translate to Spanish and save as document_spanish.odt

Now when I want to send the document and translations to someone, I need to send several files.

Drawbacks of my workflow:

  • When attaching several documents to an e-mail, it’s easy to forget to send some translation (oh, I forgot to send you document_urdu.odt!)
  • If the original document (document_english.odt) is updated, I need to remember and manually update document_spanish.odt, document_french.odt, etc
  • Oh, and each document has to be translated on its own

Enter my imagination: I want better support for translations in Calligra. It would comprise two parts: in-document translations and automated translation.

In-document translations means instead of having document_english.odt, document_french.odt, etc, we would have a single document.odt that would contain all the translations.

How to do that? By means of the versioning method I wished about yesterday and git branches.

The “master” branch in the document would be the original language the document was written in (say, English) and then, when I want to translate the document to Japanese, I would go to Calligra Words, click on “Create new translation” and choose the language I am translating to. This would create a new branch, essentially a “git checkout -b master japanese”.

Of course it would be better to use ISO 639 codes for the branch names, so that we can show localized language names, i. e. if I am using Calligra in English, I want it to say the translations available in that document are “Original document, Japanese, French” but if I am using Calligra in Spanish I want it to say the translations available are “Documento original, Japons, Francs”.

By using git versioning, it would also be quite easy to introduce some “marks” to know when the original document has been altered and therefore the translations need updating (“git diff” to the rescue :-) )

Changing the language of the master branch should also be possible by adding a “make default language” option to Calligra. The default language would be the language in which Calligra opens the document when several translations are available.

Now, let’s go for the second point of my vision: automated translations.

A bit earlier I said to create a new translation I would go to Calligra Words, click on “Create new translation” and a new branch would be created. In addition to that, we could ask the user if he wants to do an initial translation using some automated tool like Apertium (want to translate from Tajik to Persian? Apertium does), Google Translate, Babelfish, etc

And now the twist: I’m not a native English speaker. After each BehindKDE I write, I go to Jonathan Riddell and ask him to read the interview, spellcheck, make sure the words not only are correct but are in the proper order, etc (and he kindly does and never complains, thanks Jonathan!).

Would you not like to have a Jonathan Riddell in your Calligra Words for English translations, an Irina Rempt for Dutch translations, etc? I sure would!

So the idea is, after the automated translation, a small notification would pop and say “hey, I’ve noticed some supersmart bot has translated your document to Bengali. Would you like a human to review the translation and be back to you in 24 hours?”. That would send the document to some professional translator, for instance to Irina or to Prompsit (the company that develops Apertium), which would charge you their fee and Calligra would receive a commission (5%?).

The automated translation has many nitpicks but they all can be worked out and they could even create a business:

  • What services should be in for free translation? That’s not a problem: essentially, anyone that’s good. There should be a default, which provides translation services for the most used languages and provides good translations
  • What services should be in for paid translation? That could be a problem: in the near future, when Calligra overtakes Microsoft Office, every translator will ask to be in :-) No, really, we’d need them to offer a proper way to submit documents, notify the user they have received it and progress, etc
  • Privacy. For automated translation, I can either submit the document to the public free translation service, or I can pay a small monthly fee and have an private account on Apertium or Google Translate, so that my document is submitted over SSL and I am assured noone would use it for research or anything.
  • … and more

As a bonus point, a “translation mode” UI could be added to Calligra. It would show the document in the original language and the translated document side-by-side and make editing easy, something like Google Translator Toolkit:

In case you think I’m dreaming: no, I’m not. I have had this in mind for more than a year. Last month I talked about it with Gema Ramirez, the CEO of Prompsit (who has been a friend for I don’t know, 15 years?) and she instantly liked the idea. Maybe this could be material for a shared Apertium-Calligra GSoC?

So here is my third wish: let’s make Calligra the reference tool for users needing translations and for companies providing translation services. Your mission: take my 1,000 words essay and make it real :-) I would do it myself but sadly my job and real life leave little spare time for that.

Calligra Suite is an integrated work applications suite based on Qt and KDE. It is a fork continuation of KOffice, and it’s where most of the former KOffice developers have landed. Calligra includes a text processor, a spreadsheet, a presentations application, a database, vector and image editors, etc

Two years ago I made a proposal for in-document versioning for (then) KOffice applications. It would be based on libQtGit, which I wished about yesterday, and a new library tentatively called libQVersioned, which would provide a higher-level API.

This is what I wrote back then, I have added a few clarifications:

I’m working on a more general solution towards document versioning.

First, I’m developing libQtGit, which provides a Qt-like API to use git. Unfortunately, it’s been on hold for three months because I was too busy with real work. The good news is last Monday I started hacking on it again.

Second, I intend to develop a framework (tentatively named QVersioned for now) on top of libQtGit. QVersioned will 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 OpenDocument files (which are already a ZIP file) where nothing special would be needed. For other cases (for instance, a .txt file), there would be a .txtv (meaning “.txt versioned”) which would be a ZIP fiel containing the .txt + .git directory.

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 a checkout, which would provide 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)
  • Clarification: what items 1 and 2 mean is to version an ODF file you would do something like:
    1. mkdir doc
    2. cd doc && unzip document.odt
    3. git init
    4. git add .
    5. git commit -a -m “<comment provided by user>”
    6. zip -9 document.odt .git *
  • 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
    • 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 QFlags 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 X 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.

In addition to file versioning and collaboration, there is another interesting feature (that I will wish about tomorrow) that could be achieved.

 

The news broke in last week in the Qt community: Qt SDK, in whole, has been ported to Android.

Was it Nokia? No, it wasn’t

Maybe Google? Not either

It’s been a Romanian developer called Bogdan Vatra. In his spare time.

I interviewed Bogdan for Behind KDE last week and today the interview went live. Want to know more? Start reading!

Now we only need Android-phone owners to start porting KDE libraries, applications and all the eyecandy to Android. Sadly, I do not own an Android device :-(

First talk in the CrossDesktop room on Sunday: KDE on Windows. I expected no more than 10 people to wake up early in the morning and attend a Windows talk, yet about 40 showed. Lots of problems with the projector :-(

I gave the usual talk (slides) and showed KDE running on Windows 7 and Windows 2008. I had some problems while trying to show KDE applications running through Terminal Services and published with 2X but hey, it works (what you want to know: make sure you do not use graphicssystem raster!)

I insisted a lot on our need for more developers, especially packagers for third-party dependencies. Packaging a 3rd-party library for Windows using emerge is rather easy, it can be done by people with relatively few programming skills and, in any case, it is a good way to get started with development on Windows.

In the Q & A session there were the usual questions and Koen from Emweb made an interesting proposal. I think it deserves its own blog entry.

When I talk to people about the CMake build system, they like the fact that it generates native project files for the tools you already use (which makes possible to use distributed compiling, debugging, etc). Next to that, Visual Studio and autotools users complain about bootstrapping not being possible.

If you are using Visual C++, solutions probably work fine for you and it is a fact they work out of the box with VC++. However, do not even try to move to another platform (Linux, Mac…) or another compiler on Windows because it will not work.

If you use autotools, you generate the configure script on your development machine and your users just run it to prepare makefiles. Only a Bourne-compatible shell is required when trying to build. Moving to Windows, particularly Visual C++ will be quite hard.

CMake is in my opinion one of the best build-systems out there but there is one problem: you need to have CMake in order to build a CMake-based project.

Now add third-party dependencies, which probably use a different build-system, to the mix and suddenly building your software has become time-consuming and complex. In terms of money, that translates to lost revenue because there is a high probability people evaluating your software will give up before they even have something to test.

Nokia solves this by distributing Qt binaries for the most popular compilers (MSVC2005, MSVC2008, MinGW). But there is always someone using a different compiler: MSVC2010, a different flavor of MinGW, Embarcadero C++ Builder

KDE on Windows solves this by having its own “meta-buildsystem” called emerge, which is written in Python, which adds a dependency on Python when you want to build.

Can’t we do better? Can we get all the advantages of CMake yet not depend on CMake being available?

Yes, we can. I tried to do that for Wt and implemented it in the form of winstng. It’s a small batch file for Windows and a Bash shell script (for Unix; I didn’t manage to remove one bashism) which automagically download, build (if needed) and install CMake, all the third-party dependencies, build them, and then download Wt and install it. Everything ends up in a self-contained location which you can move around*. And you do not need administrator permissions. Tested on Windows, Linux and Mac.

*For now that’s only true on Windows, on Unix platforms I have not removed the rpath for some libraries which use build systems other than CMake (namely, OpenSSL).

BTW, if you are at FOSDEM, there is a Wt talk on Sunday, 14.30-15.15: The next desktop is the browser.

Should we call it Kipiopete? :-D

Every time I blog about KSnapshot or KIPI, people comment or even e-mail me asking for the same feature: make it possible to send pictures directly to a contact in Kopete.

I thought I’d need to fiddle with Kopete internals, or even wait until KDE Telepathy would be ready, but no: it turned to be very very easy thanks to the rich DBUS interface Kopete implements. Once more, the best way to implement this turned out to be a KIPI plugin, which means you can now also send to your contacts your photos from Digikam, your pictures from Gwenview, etc. Yay!

Mandatory screenshots:

Wait a second! What was that last screenshot? It looks like KSnapshot works on Windows!? Sort of, more on that soon.

A few warnings, though:

  • Facebook does not allow file transfers but Kopete < = 4.5.4 wrongly reports Facebook contacts as being able of accepting files. If you try to send a picture to a Facebook contact, the transfer will fail. This is fixed in Kopete 4.6 (i. e. the KIPI Kopete plugin no longer shows Facebook contacts).
  • For some reason, Pidgin does not accept several files at once. It seems Kopete tries to send them too fast, or something like that. KMess, on the other hand, has no problem accepting all my photo collection at once via MSN Messenger.

Ubuntu Jaunty reached end of support life last October and apparently packages have been removed from Launchpad PPAs too.

Given that it is impossible for me to build binary packages for Jaunty in the Wt PPA due to missing packages, the Wt PPA will no longer provide new packages for Ubuntu Jaunty. The last stable version of Wt for Jaunty is 3.1.6.

On April 2011, Karmic reaches end of support, and Hardy reaches end of support for desktop (support for servers will be available until April 2013). I will provide Wt packages for those distributions while Launchpad supports them.

Packages for 3.1.7a are already available for Ubuntu Maverick, Lucid and Karmic, as usual. Packages for Debian Lenny (in the Wt OBS repository) and Ubuntu Hardy packages will be ready in a few hours. Source packages for Debian Sid are available from mentors.

The screenshots.debian.net site is a public repository of screenshots taken from applications contained in the Debian GNU/Linux distribution and its derivates like Ubuntu.

It was created by Cristoph Haas to help people get an impression of what a certain software will look like on your desktop before you install it. Everybody can take screenshots and upload them through the upload form. So far there are about 3100 screenshots, which is actually a small number if you consider Debian Squeeze contains about 15000 source packages

After I hacked a bit on KSnapshot, the KDE snapshot tool, Sune asked me to add an export to screnshots.debian.net command. I had not thought of it before but that looked like a great idea, it would make the process or taking-screenshot, visit-upload-form, upload-each-screen so much easier!. So I started to develop my first KIPI plugin.

Here is the resulting Debian Screenshots plugin, as you would use it in KSnapshot:

Being a KIPI plugin, it is available not only from KSnapshot but also from Digikam, Gwenview and the other applications which support KIPI plugins:

Which makes me think: what about having a debshots (the software powering screenshots.debian.net) installation over at kde.org and have screenshots for all the KDE applications? What do you think? Promo team? Sysadmins? Setting it up shouldn’t be difficult: I’m no Python or Pylons expert (I’m more of a Ruby and Wt C++ guy :-) and got it running in a VM in an afternoon, even solving some SQLAlchemy 0.6 issues.

When I blogged about the freehand region capture feature I added to KSnapshot a couple of weeks ago, it caught me by surprise that post quickly turned into a wishlist for KSnapshot. I didn’t expect people missed anything in our good old KSnapshot after so many years of development.

Some of the feature requests were very difficult to implement (antialiasing in freehand capture; drop me an e-mail if you know how to do without redrawing the whole selection polygon)[DONE thanks to kdepepo, will be in 4.6] but most of them are pretty reasonable, in my opinion: include mouse pointer, annotations, send to mail, send to Facebook, print, etc.

I quickly started looking into how to e-mail the picture, how to print it, how to send to Facebook, etc, which seemed quite some work. And then Aleix pointed me to a very easy and quick way of getting all those and more in KSnapshot: the KIPI plugins Gwenview, Digikam and others are using.

This is the result:

Now you can send you ksnapshots to Facebook:

Or print your screenshot: