The deadline for accepting student proposals for Google Summer of Code was reached an hour ago, which means we are not accepting any new proposal and students cannot modify already-submitted proposals.

I have skimmed over the list and I am impressed: 8 proposals were received for 5 of my “wishes“! :-O

There was 1 proposal for libQtGit, 1 proposal for single applications for KDE Windows, 3 proposals for a new KDE Windows installer, 2 proposals for KDE Demo and 1 proposal for KDE Dolphin “Previous versions” support.

Not bad! It’s a pity I didn’t start this series earlier, because I still have a dozen more “wishes” waiting.

Mentors: go to Melange and vote, and also follow the instructions Lydia sent to kde-soc-mentor.

CMake is a unified, cross-platform, open-source build system that enables developers to build, test and package software by specifying build parameters in simple, portable text files. It works in a compiler-independent manner and the build process works in conjunction with native build environments, such as Make, Apple‘s Xcode and Microsoft Visual Studio. It also has minimal dependencies, C++ only. CMake is open source software and is developed by Kitware.(taken from Wikipedia)

But you already know that because CMake is the build system we use in KDE 🙂

When I started to use CMake at work to port a large project from Windows to Linux, I needed to write a lot of modules (“finders”). Those modules had to work on Windows and Linux, and sometimes with different versions of some of the third-party dependencies. Parsing header files, Windows registry entries, etc was often required.

If you have ever parsed text, you know you powerful regular expressions are. If you use old software, you know how great Perl Compatible Regular Expressions (PCRE) are because you do not have them available :-).

Read More →

Microsoft Windows has supported a feature called Shadow Copy since Windows Server 2003, using Windows 2000 or newer as the client.

Shadow copies, better known as “Previous versions”, by many users are kind of snapshots of a filesystem (“drive”, for Windows users) taken every so often. It is not a replacement for backups or RAID, just a convenient method to access old versions of your files. Thin of it as a revision control system for any file, save for “revisions” are taken at time intervals instead of evey time there are changes, which means not all the changesets are “captured”.

Samba implements the server part of shadow copy since version 3.0.3, released in April 2004, and makes them available to Windows clients.

On the Unix world, you can get more or less the same features, albeit only locally (not for NFS or Samba shared folders), by using filesystems such as ZFS, HAMMER (apparently, only available on DragonFly BSD), Btrfs, Zumastor and many others. The main problem being adoption of those solutions is marginal, and not available through the network (“shared folders”).

Sun (now Oracle) implemented a “Previous versions”-like feature for ZFS snapshots in Nautilus in October 2008:

KDE once had something like that but for the ext3cow file system. It was an application called Time Traveler File Manager (user manual, interface design and details) by Sandeep Ranade. Website is down and ext3cow is effectively dead now.

By this time you probably have guessed my wish for today: implement “Previous versions” support for Samba, ZFS, etc in Dolphin, the KDE file manager, or even better: in KIO, so that it is available to all KDE applications.

When Stephen Elop announced Nokia was adopting Windows Phone 7 as its main development platform for the future, many of us felt a mix of fear for our jobs, incredulousness (are they committing suicide?), anger for betraying open source, then curiosity. What’s this WP7 about and what’s up in regards to development?

The canonical development platform for WP7 consists of Visual Studio 2010 and managed applications developed in .NET 4 using C# as the programming language and a WPF for the user interface. If you are not into .NET, you may be a bit lost now.

Windows Phone 7 is an embedded operating system by Microsoft. It is the successor to Windows Mobile 6.5 but it is incompatible with it and it is targeted at mobile phones.

Visual Studio is Microsoft’s development environment, including IDE, compiler, debugger, profiler and much more. In my opinion, it is one of the finest applications Microsoft has developed. It is many years ahead of QtCreator, KDevelop, Eclipse or anything else.

.NET is a framework Microsoft started more than a decade ago. It includes libraries, a language independence infrastructure, memory management, localization and many more features. Applications can be compiled as native code (for x86 or x64), or as managed code (bytecode). .NET also includes a bytecode JIT compiler. You can target the .NET platform in many languages, including but not limited to, Visual Basic .NET, C#, F#, C++/CLI (it’s NOT the C++ you know!), etc

Interestingly, you can also compile normal C++ to .NET but it will have unmanaged code (i. e. code where memory allocations/deallocations are performed by you instead of the runtime, and pointers). WP7 requires that all code that runs on it be managed. This means that Qt cannot run on WP7, even though it may be compiled targetting the .NET platform and it would run on desktop operating systems.

C# is a multi-paradigm programming language developed by the father of Delphi. It is very powerful and looks a lot like C++2011. When I was learning C#, I couldn’t but think what the actual implementation of C# features were behind the scenes, in C and C++.

WPF is Windows Presentation Foundation (formerly known as Avalon), the technology (library) used for the GUI. In plain terms, it’s a library which provides accelerated everything for Windows applications: widgets, 2D, 3D, scalable graphics, etc

When developing UIs in WPF, you can either use C# code:

// Create a Button with a string as its content.
Button stringContent = new Button();
stringContent.Content = "This is string content of a Button";

// Create a Button with a DateTime object as its content.
Button objectContent = new Button();
DateTime dateTime1 = new DateTime(2004, 3, 4, 13, 6, 55);

objectContent.Content = dateTime1;

// Create a Button with a single UIElement as its content.
Button uiElementContent = new Button();

Rectangle rect1 = new Rectangle();
rect1.Width = 40;
rect1.Height = 40;
rect1.Fill = Brushes.Blue;
uiElementContent.Content = rect1;

// Create a Button with a panel that contains multiple objects 
// as its content.
Button panelContent = new Button();
StackPanel stackPanel1 = new StackPanel();
Ellipse ellipse1 = new Ellipse();
TextBlock textBlock1 = new TextBlock();

ellipse1.Width = 40;
ellipse1.Height = 40;
ellipse1.Fill = Brushes.Blue;

textBlock1.TextAlignment = TextAlignment.Center;
textBlock1.Text = "Button";

stackPanel1.Children.Add(ellipse1);
stackPanel1.Children.Add(textBlock1);

panelContent.Content = stackPanel1;

or use XAML, which is an XML-based language for WPF:

<!--Create a Button with a string as its content.-->
<Button>This is string content of a Button</Button>

<!--Create a Button with a DateTime object as its content.-->
<Button xmlns:sys="clr-namespace:System;assembly=mscorlib">
  <sys:DateTime>2004/3/4 13:6:55</sys:DateTime>
</Button>

<!--Create a Button with a single UIElement as its content.-->
<Button>
  <Rectangle Height="40" Width="40" Fill="Blue"/>
</Button>

<!--Create a Button with a panel that contains multiple objects 
as its content.-->
<Button>
  <StackPanel>
    <Ellipse Height="40" Width="40" Fill="Blue"/>
    <TextBlock TextAlignment="Center">Button</TextBlock>
  </StackPanel>
</Button>

 

More or less, WPF is to .NET what QML is to Qt.

Ouch. This WP7 is completely different to what we are used to. Maybe we can make them less different?

People tend to believe WPF and XAML are the same thing. They are not. XAML is one of the languages (which happens to be used by 99.99% of the people) to write applications in WPF but it is not the only one. You can write WPF applications in C# code (it’s not unusual to mix XAML and C#, what we call “code behind” in WPF parlance), or you could create your own XAML-equivalent language.

Or you could make my wish for today true: create a compatibility layer for QML to be able to develop WPF applications in QML, effectively replacing XAML. It is technically possible. This will also require a glue-layer for C#, similar to what we have now to bridge QML and C++. This would make porting applications from C++ and QML to C#, QML and WPF a relatively easy task, and may provide realistic path to convert Qt applications to WP7 withouth a full rewrite.

Update Fixed XAML vs C# code, thanks ‘aa’. Also, please note using C++ with QML WPF would be straightforward

April Fools’ passed, it’s safe to blog again 🙂

My last wish was born when Koen Deforche (one of the best software developers I know) made an innocent comment at my talk at FOSDEM talk this year.

Koen happens to be the guy who created Wt (pronounced ‘witty’), a C++ library and application server for developing and deploying web applications. The API mimics Qt‘s: it is widget-centric and offers complete abstraction of any web-specific application details. Where Qt has QObject, Wt has WObject; where Qt has QPainter, Wt has WPainter; both provide a very similar Model-View architecture, both have signals and slots (Wt’s being based on Boost), both provide an OpenGL widget (WebGL in the case of Wt), both allow for language translations, and in fact you can combine Qt and Wt code thanks to the wtwithqt bridge.

If you know me, you know I love Wt. Developing webapps like they were desktop apps (thinking of “widgets” instead of “pages”) is very powerful. In fact, I gave up on Rails after I discovered Wt because Rails has become a spaghetti of Ruby, Javascript, CSS, HTML and whatnot, with so many conventions that make it very difficult to follow the code unless you know very well every library involved (not to speak of performance and memory consumption, where Wt beats everything).

Wt is not without its problems, though. In my opinion, the main needs of Wt are more widgets and an IDE. Today I’m going to talk about the IDE.

Read More →

This is another idea that has been in my mind for months, and I’m so thrilled that I added it to the KDE Google Summer of Code 2011 KDE Ideas wiki: a new installer for KDE on Windows.

Currently, KDE on Windows can be installed using either emerge or the end-user installer. The installer is Cygwin-like, which means it is very different from the normal InstallShield, NSIS, MSI, etc installers Windows users are used to:

Have you seen Apple’s Mac App Store?

Read More →

Recently I have been appointed “Verification Leader, Core Foundation Team” whatever that means. Essentially it translates into taking care of functional testing. Ah, testing, well regarded, often ignored, always controversial.

Testing” usually means “unit testing” to developers. Code is what we understand (I can’t speak Russian but I can speak C++ 🙂 ) “I’ve kept my API stable but I’ve optimized the internal implementation. What did I broke?” With proper unit testing, you can go for a coffee and when you are back answer to the question is on screen: “oh, after optimization I forgot about corner case X, I’ll fix it”.

So the code is right. As Knuth would say “Beware of bugs in the above code; I have only proved it correct, not tried it”.

Try. That’s the key. The user does not care whether the application is implemented in C++2011 using lambdas, concepts, variadic templates and throws exceptions across shared libraries, or in plain old Visual Basic 6. Does it work? Does it load the file when I click File -> Open? Will it show a computer when I click and drag the computer icon from the palette to the canvas? That’s what matters.

In KDE we have unit tests in kdelibs (in fact it’s a requirement to get code in) and there are a few UI tests for the KDE User Interface module, which contains essentially widgets for use with your KDE-based application.

What about applications? What about Amarok, Gwenview, Kexi, Okular, etc? How do we know they work fine? How do we know they actions do what they should do and the application renders as it should? Correct me if I’m wrong but I think currently we rely on the input from our users: when they report something’s misbehaving, we oblige.

Can we do better? Yes, we can. UI testing has been there for decades and even the venerable expect can help with that.

There are many tools for automated GUI testing. Some are open source, like Xnee or White, others are closed-source, like Froglogic Squish and SmartBear TestComplete, which also happen to have the best support for Qt-based applications.

Are those tools useful? Why, yes, they are. For instance, there is a well-known bug in KDE Windows which makes Digikam on Windows show empty context menus when the Qt style is set to CDE (the default; if you use the Oxygen style everything looks fine). This kind of bugs can be easily detected by simulating user actions, then OCR‘ing the text of the popup menu. Or even just telling the automatic UI test to take a screenshot of the popup, then comparing pictures. Same for PDFs that render oddly in Okular on some Linux distribution due to fonts, FreeType configuration, an old version of Poppler, etc

The tool I am most familiar with is TestComplete, which suffers a bit with alien widgets (you need to build Qt without accessibility support). I have been told Squish is much better but given that there is no freely downloadable version and it does not support WPF (a requirement for the project I’m working on now), I can’t try it.

Here is a wish for KDE users who want to join development but have little or no programming skills: go to SmartBear’s website, download TestComplete and record/write a few UI tests. Let us know (in the forums, in the mailing lists) how far you got. Maybe we can make UI testing -a must in the corporate software development- part of the KDE development and release process.

Update: apaku says froglogic provides free licenses for KDE, see the comments

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.