Evolving KDE

Paul and Lydia have blogged about how KDE should and could evolve. KDE as a whole is a big, diverse, sprawling thing. It’s a house of many rooms, built on the idea that free software is important. By many, KDE is still seen as being in competition with Gnome, but Gnome still focuses on creating a desktop environment with supporting applications.

KDE has a desktop project, and has projects for supporting applications, but also projects for education, projects for providing useful libraries to other applications and projects to provide tools for creative professionals and much, much more. For over a decade, as we’ve tried to provide an alternative to proprietary systems and applications, KDE has grown and grown. I wouldn’t be able, anymore, to characterize KDE in any sort of unified way. Well, maybe “like Apache, but for end-users, not developers.”

So I can only really speak about my own project and how it has evolved. Krita, unlike a project like Blender, started out to provide a free software alternative to a proprietary solution that was integrated with the KDE desktop and meant to be used by people for whom having free software was the most important thing. Blender started out to become the tool of choice for professionals, no matter what, and was open sourced later on. It’s an important distinction.

Krita’s evolution has gone from being a weaker, but free-as-in-freedom alternative to a proprietary application to an application that aspires to be the tool of choice, even for people who don’t give a fig about free software. Even for people who feel that free software must be inferior because it’s free software. When one artist says to another at, for instance, Spectrum “What, you’re not using Krita? You’re crazy!”, we’ll have succeeded.

That is a much harder goal than we originally had, because our audience ceases to be in the same subculture that we are. They are no longer forgiving because they’re free software enthusiasts and we’re free software enthusiasts who try really hard, they’re not even much forgiving because they get the tool gratis.

But when the question is: what should a KDE project evolve into, my answer would always be: stop being a free software alternative, start becoming a competitor, no matter what, no matter where. For the hard of reading: that doesn’t mean that a KDE project should stop being free-as-in-freedom software, it means that we should aim really high. Users should select a KDE application over others because it gives a better experience, makes them more productive, makes them feel smart for having chosen the obviously superior solution.

And that’s where the blog Paul linked to comes in. We will need a change in mentality if we want to become a provider of the software-of-choice in the categories where we compete.

It means getting rid of the “you got it for free, if you don’t like it, fuck off or send a patch” mentality. We’d all love to believe that nobody thinks like that anymore in KDE, but that’s not true.

I know, because that’s something I experienced in the reactions to my previous blog. One of the reactions I got a couple of times was “if you’ve got so much trouble porting, why are you porting? If Qt4 and KDE 4 work for you, why don’t you stay with it?” I was so naive, I took the question seriously.

Of course Krita needs to be ported to Qt5 and Kf5. That’s what Qt5 and Kf5 are for. If those libraries are not suitable for an application like Krita, those libraries have failed in their purpose and have no reason for existence. Just like Krita has no reason for existence if people can’t paint with it. And of course I wasn’t claiming in my blog that Qt5 and Kf5 were not suitable: I was claiming that the process of porting was made unnecessarily difficult by bad documentation, by gratuitous API changes in some places and in other places by a disregard for the amount of work a notional library or build-system ‘clean-up’ causes for complex real-world projects.

It took me days to realize that asking me “why port at all” is in essence nothing but telling me “if you don’t like it, fuck off or send a patch”. I am pretty sure that some of the people who asked me that question didn’t realize that either — but that doesn’t make it any better. It’s, in a way, worse: we’re sending fuck-off messages without realizing it!

Well, you can’t write software that users love if you tell them to fuck off when they have a problem.

If KDE wants to evolve, wants to stay relevant, wants to compete, not just with other free software projects that provide equivalents to what KDE offers, that mentality needs to go. Either we’re writing software for the fun of it, or we’re writing software that we want people to choose to use (and I’ve got another post coming up elaborating on that distinction).

And if KDE wants to be relevant in five years, just writing software for the fun of it isn’t going to cut it.

Project Activity in Bug Reports

Project Activity in Bug Reports

Sven Langkamp recently mentiond that Krita had crept up to second place in the list of projects with most new bugs opened in bugzilla in a year. So I decided play around a litte, while Krita is building.

Bugzilla has a nice little report that can show the top X projects with open bugs for certain periods. Krita never is in the default top 20, because other KDE projects always have more open bugs. But let’s take the top 100 of KDE projects with open bugs sort the data a bit and then make top 10 lists from the other columns.

Note, there might be projects where more bugs were opened and closed in the past year, but I cannot get that information without going into SQL directly. But I think most active KDE projects are in the top 100.

New bugs created. This is a pretty fair indication of userbase, actually. A project that has a lot of users will get a lot of bug reports. Some might quibble that there’s a component of code quality involved, but honestly, pretty much all code is pretty much equal. If you just use an application, you’ll mostly be fine, and if you start hacking on it, you’ll be horrified. That’s normal, it holds for all software.

  • plasmashell: 1012
  • krita: 748
  • plasma: 674
  • kwin: 482
  • digikam: 460
  • kmail2: 388
  • valgrind: 274
  • Akonadi: 270
  • kate: 267
  • kdevelop: 258

I have to admit to being a bit fuzzy about the difference between plasma and plasmashell. It looks like our own developers know how to find bugzilla without trouble, given that there are two, three developer-oriented projects in the top-ten. Of course, valgrind is also widely used outside the KDE community.

Now for bugs closed. This might say something about project activity, either development or triaging. It’s a good statistic to be in the top-ten in!

  • plasmashell: -917
  • krita: -637
  • digikam: -615
  • plasma: -479
  • kwin: -391
  • okular: -346
  • dolphin: -263
  • amarok: -255
  • valgrind: -254
  • kate: -249

Not a hugely different list, but it’s interesting to see that there are several projects that are in the top-ten for closing bugs, that aren’t in the top-ten for receiving new bugs. Maybe that is an indication of code quality? Or maybe better bug triagers? If a project is in the first list, but not in the second list, it might be taken to mean that it’s got users, but that development is lagging.

Open bugs. A project can go a long time and collect a huge amount of bugs over that period without having much activity. For instance, in this list, KMail has 880 bugs, but there were zero new bugs in 2014 and only seven bugs closed. I’d say that it’s time to remove kmail from bugzilla entirely, or mark all remaining kmail bugs as “unmaintained”. The same goes, I guess, for the kio component: 550 open bugs, 1 new, 1 closed in a year.

  • plasma: 1449
  • konqueror: 1432
  • kmail2: 1107
  • kopete: 942
  • kdelibs: 921
  • kmail: 880
  • Akonadi: 650
  • valgrind: 580
  • kio: 550
  • systemsettings: 495
  • kontact: 479

Krita has 237 open bugs, by the way, but since we’re working the 2.9 release, that number fluctuates quite a bit.

Conclusions? Well, perhaps none. If bugs are any indication of a project’s user base and activity, it’s clear that KDE’s desktop (plasma, kwin) have the biggest userbase, followed by Krita and Digikam. Maybe that comes as a surprise — I know I was surprised when Sven noted it.

And there’s one more twist — everyone who uses the Plasma shell or kwin can easily report crashes to bugzilla, because they’re on Linux. Most Krita (and I guess Digikam) users are actually not on Linux. Krita’s Windows crashes right now still get reported to a server hosted by KO, which is something I need to work on to change…

Switching between Stable, Nearly Stable and Unstable Krita — a guide for artists

The first thing to do is to open the Cat’s Guide To Building Krita, because  that’s the base for what I’m going to try to explain here. It’s what I use for developing Krita. I usually have every version from 2.4 up ready for testing.

Now — there are very good reasons why you might want to have more than one version of Krita available. Currently, the master branch is frozen, and when it opens up, it’ll be for the Qt5 port. We’re fixing bugs like crazy in the Calligra/2.9 branch, and there’s a ton of cool stuff in there, but if your livelihood depends on Krita, you might want to use 2.8 until, say, we release 2.9.1…

So, here’s how to set that up. On Linux, of course. Building Krita on Windows or OSX is a pain.

First: remove your distribution’s Krita and Calliga packages.

As per the Cat’s guide, setup your environment, but do not create the ‘inst’ dir:

mkdir -p $HOME/kde/src
mkdir -p $HOME/kde/build

Instead, we create different install directories for different versions. Let’s setup 2.8, 2.9 and git master:

mkdir -p $HOME/kde/2.8
mkdir -p $HOME/kde/2.9
mkdir -p $HOME/kde/master

Get the source code (again, check the Cat guide!):

cd ~/kde/src
git clone git://anongit.kde.org/calligra.git

Now, get the git-new-workdir script. Here’s a copy on my webserver. Or  check whether your distribution provides it. We’ll use it to make two new source directories out of the repository you just cloned:

cd ~/kde/src
git-new-workdir calligra 2.8
cd 2.8
git checkout calligra/2.8

And

cd ~/kde/src
git-new-workdir calligra 2.9
cd 2.9
git checkout calligra/2.9

Now you’ve got the source code for Calligra Master in ~/kde/src/calligra, for the 2.8 stabele version in ~/kde/src/2.8 and the 2.9 beta branch in ~/kde/src/2.9.

Get the libraries and dependencies. This wiki page has a lot of details: Calligra/Building. The Cat’s guide’s list is a bit outdated. Here’s the full list of dependencies we need for Krita:

  • KDE (minimum 4.3)
  • Qt4 (minimum 4.6)
  • Perl
  • zlib
  • libpng
  • boost and boost-system
  • openEXR
  • openGL
  • GSL
  • Eigen3
  • Exiv2
  • LCMS2
  • Vc (the 0.7 release)
  • SharedMimeInfo
  • Poppler and Poppler-Qt
  • openjpeg (optional)
  • libjpeg
  • fftw3 (optional, but will make blur much faster)
  • glew
  • openColorIO (optional, for HDR painting)
  • libtiff
  • kdcraw

And you need cmake, make and the compiler, of course.

Now you can setup your build directories. This is different from the Cat’s guide and note that you cannot move your existing build directory around:

cd ~/kde/build
mkdir master
mkdir 2.8
mkdir 2.9

Now download the ‘changeto’ script and put it somewhere where you can execute it. It’s a really simple script: all it does is move around a symlink, like this:

rm ~/kde/inst
ln -s ~/kde/2.8 ~/kde/inst

The script has a couple of commented lines you can enable to setup switching your configuration and settings, too, but I don’t use that myself. There are other ways to setup this, of course. This is simple-minded enough that it works for me… Note: the -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4 is needed on systems like Ubuntu where Qt5 is the default: check whether qmake is Qt4 or Qt5 first.

cd ~/kde/build/2.8
cmake -DCMAKE_INSTALL_PREFIX=$HOME/kde/inst $HOME/kde/src/2.8 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DPRODUCTSET=KRITA -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4

And build and install Krita 2.8. Then execute the changeto script:

changeto 2.9

And do what we just did for 2.9 — the same commands, but replace 2.8 with 2.9. You could do the same again for master — changeto master and build and install the master branch from the ‘calligra’ directory.

For the rest the setup is the same. If you setup your paths to point to $HOME/kde/inst and switch with changeto to the version you use, you can safely use Krita 2.8, Krita 2.9 Beta1 or git master whenever you want. You probably don’t need to ever update 2.8 again and you can keep Krita 2.9 updated as per the Cat’s guide.

Note that Krita 2.8 needs the kbuildsycoca command from the Cat’s guide, but Krita 2.9 doesn’t anymore. Everytime you switch to 2.8, execute kbuildsycoca.

If you run into trouble, join us on irc and ping me — but keep in mind that I am in Europe and enjoy my eight hours sleep every night.

Ten years of working on Krita

October 2003… I had just gotten my first graphics tablet, a small Wacom Graphire, because I needed to draw a map for the novel I was working on, a map of a battlefield. It seemed a good idea, back then, to do that digitally, for ease of adding and removing layers and so on. However, I wasn’t too happy with the way GIMP worked back then, not realizing it was because I wasn’t familiar with digital painting at all, not because GIMP’s workflow was bad or something like that.

So I started looking for alternatives, and I came across Krita. Krita had gotten its start in 1998, when Matthias Ettrich held a presentation at the 1998 Linux Kongress, which was reported by Michael Wiedman. One of the things he wanted to demo was the ease with which it was possible to hack a Qt gui around an existing application, and the application he choose to demo it with was GIMP (back then it was still called The Gimp, I think). About 1100 lines of code hacked together one evening before the congress started that integrated GIMP into KDE by giving it a KDE compliant user interface: toolbars, statusbar, menubar and made it use the KDE standard dialogs. His goal was to show that there was no reason for any duplication of effort, if a complex application like GIMP can be integrated into KDE with so little effort. KDE was two years old by then and Gnome had just started and the mood was incendiary, so the patch, named kimp, caused a something of a flamefest which left a sour taste in everybody’s mouth.

Not satisfied with this situation, people within the KDE project decided to start their own image editor application (although there was some dissension). At that time, there was an application in KOffice called KImage which had been started by Michael Koch, who came up with the name KImageShop, so this can be seen as the earliest forerunner of Krita, was originally written in Qt 1.x, but had been ported to Qt 2.0 in March 1999. The codebase would later be ported to Qt3 and to Qt4!

At the 31st of May, 1999, the KImageShop project officially kicked off with a mail by Matthias Koch. Involved were also Matthias Elter and Daniel Duley (mosfet). Their plans were certainly ambitious! The basic idea back then was to make KImageShop a GUI shell around ImageMagick. (And indeed, until 2004 ImageMagick was a core dependency of Krita.) It was going to be a corba-based application with out-of-process filter plugins, compatible with GIMP plugins, which are also out-of-process, though of course not corba-based. Multiple colorspace support was planned from the outset, though it took until the Krita 1.5 release in 2006 for the project to achieve that goal. (www.koffice.org went through a reorganization in 2009, killing all old content, so this is a link to the svn version of the original announcement.) Some things planned back then still haven’t been realized, such as export support for GIMP’s xcf file format. Even distributed and multi threaded image filter application was already mentioned!

After an initial spurt of development, the mailing list soon became quiet. The main reason seems to have been that Matthias Elter, Carsten Pfeiffer and the other authors were busy getting KDE 2.0 ready and done. KImageShop started to bitrot and it became hard to compile.

In October 2000, John Califf became the new maintainer. He started with an enormous enthusiasm and energy and quickly make KimageShop at least compilable. During his tenure, KImageShop was renamed to Krayon, a name half-jokingly thought up by Sean Pecor. As he (and others) expected, the new name would give problems, but it seemed stick around after Bart Syszka liked it too. During this short period, TheKompany.com, led by Shawn Gordon, was active as well — they had hired someone to work full-time on KImageShop / Krayon. But John Califf’s 54th and last commit was February 12th, 2001, and nothing much happened after that for over a year.

In June 2002, Patrick Julien appeared on the scene. By then, Krayon had been disabled from compilation for legal reasons: a German lawyer thought “Krayon” too close to the name of a German website (crayon.de) which used to sell a series of graphics cd’s. Crayon.de seems to have become a “lizensberater” since then, and von Gravenreuth is no more.

But back then, the first thing that had to be done was to find a new name. The discussion was long, and in the end Krita was chosen. Looking back, it seems to have been an excellent choice. We never had any legal problems since (touch wood!), and after a few years patience, the krita.org domain became available as well!

New maintainer Patrick Julien embarked upon a refactoring of Krita following the Gang of Four’s Design Patterns lead.

And that was more or less the state when I started looking for something to draw maps with, using my little Graphire… The project had stagnated again by then, after the promising refactoring had basically set down the broad architectural lines Krita is still based on.

I didn’t know C++ back then, but neither was I a novice programmer. I’d been earning the daily bread for me and my family for about ten years, first as an Oracle PL/SQL developer, then Visual Basic, then Java. I had written and gotten published a book on Python and Qt, so I knew Qt as well. I had no experience with graphics, though…

In October 2003 it was not possible to paint with Krita: all tools except for the layer move tool had been disabled. The paint tool was the first thing I worked on, and I was very proud when I had a tool that could place squares on the canvas — and the size of the squares was sensitive to the tablet pressure!

And then the ball started rolling again… In 2004, I Patrick Julien handed over maintainership. Many of the people who are still working on Krita were already around by then, and by September 2004 we were ready for the first preview release of Krita! The backend had been rewritten once more (and that would happen at least two, three times again), we had working tools, plugins, filters, color models, wacom support… Get the (apparently incomplete) source code!

Then 2005 arrived, and we were driving ourselves really hard to make the KOffice 1.4 release. Originally planned for the first quarter of 2005, it actually got delayed until June. We had a great feature list (for a brand-new application):

  • Layers (without fixed boundaries).
  • A familiar set of tools — brushes, selection tools and shape tools.
  • Painting with filters.
  • An extensible system for the addition of new color and paint models.
  • Support for pressure sensitive tablets.
  • The ability to read most graphics file formats, including gimp and photoshop files.
  • Exporting to many graphics file formats (but not gimp or photoshop)
  • A complete colour management system based on lcms.
  • A useful set of filters (implemented as plugins, so the set of filters is extensible) including a CImg based image restoration plugin.
  • The ability to use Gimp palettes, brushes, patterns and gradients

Real artists ship, and we had shipped! Champagne was being served, and then compilers were fired up again, because after 1.4, a 1.5 has to follow. We had a sprint at my place in Deventer. That was also around the time I discovered IRC… 24/7 presence is taking its toll these days.

A bit less than a year later, we were still hard at it, and Krita had gained adjustment layers, scripting, 16 bit/channel support, CMYK, an OpenGL canvas… And we released it with KOffice 1.5 in April.

In 2006, we were old hands at hacking and releasing and hacking and releasing. But things were changing. Google’s Summer of Code program arrived, and we had our first students working on Krita and KOffice. We released 1.6, and Krita 1.6 was really a very nice, stable image editor. The first professional users started taking a look at Krita, but still found it wanting. And the long-awaited port to Qt4 got started. Oh… And Krita got the Akademy Award for Best Application!

But that really was the beginning of a time of troubles. Looking back, I’m surprised we never gave up. I had to give up, personally, for a bit of time, when I got burned out, not really because of the hacking and porting, because that was still fun, but tensions in the KOffice community got steadily worse, something that would end with the KOffice/Calligra community split in 2010.

And another problem was that we simply couldn’t figure out how regain stability. The KDE 4 platform was unstable, Qt4 wasn’t exactly as good as it should have been — and we made KOffice go through a huge redesign, where much of what we had learned in Krita about canvases, tools, plugins and more was placed in the core of Calligra, in the flake library. in retrospect, we ported too quickly, and we changed too much, and we got stuck.

So, 2007 and 2008 went past, without a release. It took three years to get to the Krita 2.0 release in May 2009, and that while that release was a huge milestone, it was also completely unusable. None of the KOffice applications had anything like the stability or plain usefulness of the 1.6 release. Looking back, it’s a wonder the project didn’t die. Of course, we still had fun coding, there were Google Summer of Code students, there were Libre Graphics Meetings (the first I attended was the 2007 in Montreal, also the first time I crossed the Atlantic!).

But it was clear that something had to be done. And in December 2009, we all had enough. We had released Krita 2.1 in November, and while we felt we’d made progress and proudly claimed “This release marks the beginning of the user-readiness of the 2.x series of Krita.”, it wasn’t really. We did have our own website, now, though! And the all-new KDE web forums!

It was during a KOffice sprint in the Trolltech offices in Oslo, that Lukáš Tvrdý, a former Summer of Code student, presented his idea: he would have several months between finishing his thesis (about Krita brush engines!) and his graduation, and instead of seeking a job hacking up websites, he would like to try and work full-time on Krita, to get rid of all the pesky bugs, performance issues, all the papercuts, sock-wrinkles and plain-out filthy bugginess. But he needed money to buy bread and pay for his apartment… So the first Krita sponsored development drive was born. Crowd-sourcing avant-la-lettre, it brought in enough to keep Lukáš well-fed and happy hacking.

This really made a huge difference. We got in touch with David Revoy, the French artist who was back then working on Sintel for the Blender Foundation. His timelapse showing how he worked with Gimp and Mypaint on concept art really gave us a kick in the pants — he should have been using Krita!

But we were honest enough to know that he could not have used Krita. So, armed with his suggestions, we went back to work. We had a goal — “make Deevad happy with Krita”, we had received the sponsorship needed for Lukáš, and we were really motivated. Krita was fun again!

We kept on releasing, though: 2.1 was released in November 2009, 2.2 in May 2010, 2.3 in December 2010 and then… The Calligra/KOffice ruckus happened. It took a long time before the first Calligra release was made, numbered 2.4. Krita 2.4 was released in April 2012.. We’d spent all of 2011 on it, and parts of 2012. It was a long release-hiatus, but it was worth it. Krita 2.4 was ready for the end-user, we felt.

At the Krita sprint in Amsterdam in 2011, David Revoy had said of Krita 2.3 that it came close, and was a nice application for amateurs, but not ready for professionals — fun to use, but just too many rough edges, too many things that hampered workflow. Krita 2.4 fixed that. It had taken a year, since 2.3, and in fact, two and a half years since we first put “make deevad happy” as our No. 1 goal, but we’d made it. Which is not to say that we were done…

So, there’s been 2.5, 2.6, 2.7 since then. Every release makes me wonder why we thought the previous release was the bee’s knees — and every release excites me, because there’s so much new, so much fixed, so much polished.

Right now, we’ve got a Krita Foundation which owns the Krita trademark, Dmitry Kazakov will work on Krita full-time for the next four months, there’s a company giving commercial support for Krita, every month the number of users increases. We’ve ported Krita to QML for Krita Sketch and Krita Gemini… We’ve got a shop full of cool swag. And my novel still isn’t finished!

Looking back, I wonder — why did I pick Krita to work on? Probably because I didn’t like to start a new project, and besides — I probably couldn’t have pulled it off. I didn’t know anything about graphics… And Krita was in Qt, promising, but still small and needed so much basic stuff done that I knew I could get into it. Now, in 2013, Krita is over 300k lines, excluding the Calligra libraries. Newcomers have a much tougher time of it! (But don’t let that deter anyone!)

Ten years is a lot of time. In that time, I’ve bought and sold two houses, and am living now in the third. My daughters were at primary school back then, now they are first-year students at University. I went through three jobs, and am now working at a company I’ve co-founded. And I’ve always kept working on Krita…

Ten years is a long time! Here’s to the next ten years of Krita! To an awesome community of artists and developers, to great code and lots of fun, to learning and doing, to coding and painting!

 

Thank you, everyone, Aaron, Adam, Adam., Adriaan, Adrian, Adrian, Albert, Alberto, Alexander, Alexander, Alexis, Alfredo, Allen, Ana, Andras, Andre, Andreas, Andres, Andrew, Andrius, Andre, Andy, Anne-Marie, Ariya, Arjen, Bar, Ben, Ben, Benjamin, Benjamin, Benjamin, Benoit, Bernhard, Bo, Brad, Bram, Burkhard, Camilla, Carlo, Chinkal, Christer, Christian, Christan, Christoph, Chusslove, Clarence, Cyrille, Dan, Dan, Daniel, Daniel, Danny, David, David, Dirk, Dirk, Dmitry, Edward, Elvis, Emanuele, Enrique, Fabian, Frank, Frederik, Fredrik, Fredy, Friedrich, Gary, Geoffry, Gioele, Giovannia, Gopalakrishna, Gabor, Hanna, Harald, Hasso, Helge, Helio, Hoang, Hugo, Inge, Ingo, Jaime, Jaime, Jason, Jakob, Jakub, Jan, Jaroslaw, Jens, Jessica, Johannes, John, Jonathan, Jonathan, Jose, Jure, Kai-Uwe, Kevin, Kevin, Kurt, Laurent, Lauri, Leo, Lukas, Lukas, Maciej, Malcolm, Marc, Maria, Marijn, Martin, Matthew, Matthias, Matus, Melchior, Michael, Michael, Michael, Michael, Mohtaba, Montel, Nick, Nicolas, Olivier, Patrick, Patrick, Pavel, Peter, Pierre, Pierre, Pino, Rafael, Raphael, Rex, Rob, Roopesh, Sahil, Samuel, Sander. Sascha, Sebastian, Siddharth, Silvio, Silvio, Somsubhra, Srikanth, Stefan, Stephan, Stephan, Stuart, Sune, Sven, Thiago, Thomas, Thomas, Thomas, Thomas, Thomas, Thorsten, Thorsten, Tim, Timothee, Tobias, Tom, Torio, Torsten, Unai, Urs, Vera, Volker, Waldo, Werner, Wilco, Will, William, Yann, Yue, Yuri, Manu, Ismail… And everyone I’ve forgotten to mention!

Porting Calligra to Qt5

It was April 14th, 2006, that we ported KSpread to Qt4…

Sponsored by Jolla, who wants to use Calligra as the core for the Sailfish document viewer, me and Camilla spent some time in the past couple of weeks on porting the Calligra core to Qt5.

We’re not done, but… Calligra Words starts and you can type stuff in it:

It was quite difficult, but that’s not because porting to Qt5 is so difficult, it’s because KDE Frameworks 5 isn’t nearly done yet, and because we needed to port to Qt 5.1, not the upcoming (later this year) Qt 5.2.

So what we did was:

  • Create a fake library with all the KDE headers that Calligra uses. Sebastian Sauer was really helpful here since he had already done for his Calligra for Android project.
  • Make everything build with Qt 5.1. That took a bit of search and replace, and in some cases we kept the old KDE class in name even though its obsolete — made it fall through to the Qt class. That’s because we are working in a branch, and we need maximum ease of merging anything that happens in the master branch to the Qt branch.
  • Port the plugin system. Thanks to Sebastian K&uumlgler’s work here, that was pretty much source compatible. Two problems: we had a system where the class that the plugin exported was actually in a shared library. That needed fixing. And we wanted to get rid of the KTrader system and just load the plugins from a known directory. It took a bit of work — Calligra has over three hundred plugins.

At this point, we were mostly where we wanted to be for the Sailfish Document Viewer. That doesn’t need the Calligra desktop gui’s. But we kept on hacking and started replacing part of the fake kde library with the real frameworks from KF5. We’re using the following frameworks:

  • itemviews
  • kcodecs
  • kconfig
  • kconfigwidgets
  • kcoreaddons
  • ki18n
  • kservice
  • kwidgetsaddons
  • xmlgui

We had to make copies of those, unfortunately, because KF5 is such a moving target and we needed to freeze on a certain API and set of libraries.

What’s left? Well, fixing the configuration, resource paths, icon paths and probably much more.

Also, Krita, Karbon, Kexi, Plan and Braindump aren’t ported yet, just Words, Stage, Sheets and Flow. And there are plenty of places where we took horrible shortcuts, too!

Second Calligra sprint, wrap-up

Saturday

Of course, I’d also wanted to blog on the second day of the Calligra sprint,  but we were way too busy… In the morning we had the usual plenary meeting. Among other topics, we discussed an extension to the 2.4 release schedule. In view of the current state of the Quality Dashboard, we decided to have at least one more beta release, which probably will move the release into 2012. At the same time, our release manager Cyrille Berger, who couldn’t join us, had come to the same conclusion.

Then SKF gave a remote presentation to everyone present on how they use Calligra Words in their application. They are developing a modelling and calculation application and using Calligra Words as the report writing component. The main application creates tables, images and plots which inserted in a document in the embedded Words component. The engineer then addes the explaining text. Those generated items are tagged using RDF, which means that if the input data changes, it become trivial to update just those items while the text the user has created remains intact. We got a remote, life demo of their application, event. It’s immensely encouraging for everyone in the community to see Calligra being used in real life!

Then Nokia presented every attendee who didn’t have a Harmattan device yet with one; an N9 or N950! This once again showed everyone how far along we have come, since it contains the Documents application with is built on the Calligra core office engine.

Despite giving many people new toys to play with, the commits never stopped coming in, and also from a coding perspective, the weekend was very succesful.

An extremely nice dinner in , which the seven Indians acknowledged present acknowledged tasted very authentic rounded off the day, or would have, had we not congregated in the lobby of the Radisson Seaside hotel for some more hacking. And playing with the new devices.

Sunday

On Sunday, I spent most of my time in a separate room with Pierre, Pierre, Boemann, Thorsten and Leinir, taking a step back to look at the purpose and problems of a text editing component with a goal of identifying where there are conceptual problems in the current design in Calligra’s text component.

Lunch (the lunches provided by Nokia were awesome!) We also got a presentation by Nokia’s Abishek on Sunday showing us how well Calligra does as the core engine for Harmattan Office — and what could be improved still. It’s amazing that in some areas, like showing embedded charts in spreadsheets, we’re better than Micrsoft’s mobile office on Windows Phone.

Many thanks to Nokia for hosting the sprint in their office building, providing us with lunch and dinner, and to Nokia and KO for sponsoring travel and accommodation!

Back in Helsinki!

Pierre Stirnweiss, Dimitrios Tanis and I arrived together this afternoon in the Nokia office in Helsinki. By coincidence, we’re actually using the same room that we occupied when we first discussed putting Calligra (back then, still KOffice) inside Nokia phones! Kind of historic ground!

The usual suspects are here, but also many new faces, like Smit Patel and Brijesh Patel, who hack on Words and Dimitrios Tanis who is doing documentation and is now turning into a Kexi hacker!

We’ve come a long way since then… We have created at least three different applications based on the Calligra engine. It started with FreOffice, a QWidget-based office application for the FreMantle release of Maemo. The code for this application lives right inside the Calligra source repository. Then came Harmattan Office, which will also be released under GPL. Harmattan Office uses QGraphicsView and MeegoTouch. Having Harmattan Office installed by default on the N9 means that Calligra suddenly has hundreds of thousands of users, since the N9 turns out to be an extremely popular device. And then Nokia sponsored Shantanu to create Calligra Active, a Qt Quick-based document viewer based on Calligra that’s part of Plasma Active.

But now it’s time to go full-tilt for the 2.4 release of the Desktop applications! There’s plenty of cool stuff going on, from discussions about the difference between pre-, post- and ambilactarianism, to new comboboxes for the style dockers, to attempts to get Thorsten to commit his line endings. (We’re in freeze, but those arrows are smooth…) The room is already full, more people have to arrive, it’s noisy, everyone is active — this is going to be a great weekend!

Thanks go to Nokia and KO GmbH for sponsoring travel, accommodation and dinner!

Jiffy Bag Time!

This was one busy weekend! We had the Krita bug day, of course. But that wasn’t the only thing happening: finally the printed comics were delivered! Consquently, Animtim took the train to Deventer and spent the weekend drawing dedications in the pre-ordered comics.

Meanwhile, Irina was busy preparing the list of addresses and printing the address stickers. Then it was time to start stuffing the jiffy bags:

Sort the jiffy bags

And stack them

With a huge stack as result:

Now all that is needed is to get the stamps and send them off, and everyone who pre-ordered a comic-book + dvd pack will get to see the result

If in the coming week or two you do not receive your order, or your order is not correct, please mail me! It’s the first time we’ve done something like this…

And if you haven’t ordered your copy, there are still a few left, so don’t hesitate, and go to the Krita website and press the order button!

One Desktop Summit coming up…

One Desktop Summit coming up…

And I’m coming to Berlin for the Desktop Summit, with lots of colleagues and friends from KO GmbH and from the Calligra community.

And I have been given the opportunity to give two presentations. On Sunday morning (as usual…).

First, I will speak about Calligra Everywhere. Without wanting to put in spoilers, I can say that there are two parts to this presentation.

The Calligra suite of applications has been expanding in the past year in several direction: there are now more applications than ever part of the project, Calligra applications are available on more platforms, both desktop and mobile than ever, Calligra has joined the Active project, Calligra functionality is used in more applications and finally, some of our applications are being used more and more. So what I want to do in the first place is to review these developments, and make clear why they were possible, both technically and socially.

In the second place, the Calligra community has benefited from a long relationship with Nokia. Together with Nokia’s Thorsten Zachmann we will discuss not just what this has resulted in for Calligra and Nokia, but also the lessons we can learn from the collaboration of several commercial partners with the volunteer project that Calligra still emphatically is.

Next it’s Michael Meeks’s turn, who will speak about LibreOffice. It’s a bit like Fosdem all over — where KO colleague Jos van den Oever first presented WebOdf, then Michael talked about LibreOffice, and I finally gave my presentation on Calligra’s technical underpinnings. This time, I won’t put quite so much C++ in my slides!

So… When Michael is done, it’s my turn again. This time I will talk about Krita — in the first place not about Krita the application, not a list of features we created since last year’s aKademy presentation, but rather about Krita the project.

Krita is now more than ten years old, and it has started coming into its own only this year. What I hope you will be interested is in are answers to the questions “Why did it take so long?”, “What went wrong?”, “What went right?”. I’ll use the evolution of the application as a guide to discuss what it takes to create a large application with a diverse team that actually makes artists have fun.

Popular Misconceptions about Google Summer of Code, Google Code In, Season of KDE

And so forth. There used to be programmeerzomer as well… KDE is in again as a mentor organization, which is utterly great! But it’s also a good moment to put some things straight.

Over the past couple of years, I’ve seen a rising number of misconceptions about these programs. One of the most pernicious is that some people have started to think that Google Summer of Code is the only approved way to start working on a cool project.

This is Not True.

But lots of people seem to think it is. It isn’t even true that it’s the only way to get mentored when you start working in an open source project. That’s a related, but just as common misconception. It depends on the project, perhaps, but at Krita and Calligra we are totally prepared to spend the same amount of time on you when you want to get into hacking on our projects no matter what the reason is. People have learned not just our code, but even C++ in our irc channels and on our mailing lists. Everyone is welcome, the year round. The only thing needed is an itch and passion for the project.

Another misconception is that the Ideas page is the sum of all admissable ideas for Google Summer of Code project proposals. It is nothing of the kind. It’s what we came up with that we think would be cool, but if you are passionate and you propose something out of the box, there’s a huge chance that we’ll think it even cooler, and you will get ranked high!

And note that there are generally speaking between ten and twenty proposals per slot. Even if you engage with us, make sure we know you well — there’s no guarantee of selection. But note that you will still be allowed to work on the project, even if Google doesn’t pay you for it! Most project members never see any money for their work.

The final misconception I want to mention is the “it’s a summer job” idea. Nope. Not at all. You write the code, your code goes into a release — and Krita always makes students work with git master, so your code will go into the next release — and then it’s your responsibility to maintain it. And to broaden your engagement with the project beyond the project you coded for. We are looking for people who will stay with the project for many years to come. If you are in it for the three months of paid work, please reconsider.

And now start engaging with us, discuss your cool ideas, start fixing bugs already and make sure we love and trust you before the time arrives for us to rank your project proposals!