About

"Day of Independence" (2003-07-02)

After more than 2 years of putting up with paint programs that didn't have undo/redo and another one that made it difficult to draw lines, I had had enough.

For GNU/Linux (or any other free UNIX for that matter) to embrace the broader desktop audience, it must at least offer the ability to crop screenshots, draw simple diagrams and edit pictures without hassle.

It didn't matter how good the web browser or office suite was, if the OS couldn't satisfy such a basic use case, it would be irrelevant.

Apart from the need for such a product, there is a significant recreational element: when people first get a computer, they play with the multimedia apps/toys for hours - defacing photos, "finger painting", ...

What was needed was something that hadn't been done before for GNU/Linux: an application that satisfied the ordinary, everyday graphics use cases - not paths, not custom convolutions, not colour models, ...

What was needed was an alternative to Microsoft Paint for GNU/Linux.

With this vision, I began furious development of a paint program that integrated with the most user-friendly GUI for GNU/Linux: KDE.

There was no going back. This day would become the day that KDE users could "declare their independence" from buggy and difficult to use paint apps. Ok, that was a bad pun :) To be honest, it is actually uncertain when the KolourPaint Project started - backups suggest that development actually began in mid-June of 2003, not July.

For those of you who were wondering, the name "KolourPaint" is an ironic statement about the apparent mispelling of "colour" in computerdom in Australia (and the UK). It goes all the way back to me getting annoyed at needing to write "COLOR" in QBasic more than a decade ago.

0.1 Available to the Public (2003-10-11)

After being asked for the source code, I spent three frantic days skipping "Software Construction" lectures, polishing it for the upload.

After importing my home directory into sourceforge CVS, I realised that you should only type "cvs import" after cd'ing into the folder with the source code :)

As the clock ticked over to the next day (for programmers, days start at midnight - not at 9am), I decided to upload KolourPaint to the kdenonbeta modules of KDE CVS instead.

No release was made as just 3 months into its development, KolourPaint was too unfinished to be generally usable.

The next day, on IRC, Kexi founder Lucijan Busch, succinctly describes KolourPaint:

[19:40:15] lucijan tries kolourpaint
[19:43:51] <clarence> lucijan: I hope the Makefile.am's wok [work] for you, fingers crossed
[19:44:08] <lucijan> clarence: which on [one]
[19:44:13] <lucijan> it compiled
[19:44:32] <clarence> lucijan: phew :)
[19:44:35] <lucijan> and i thought i [it] would be some kind of gimp replacement but it is a 1:1 copy of ms paint :(
[19:45:01] <clarence> lucijan: it tries to be a little different to mspaint....
[19:45:21] <lucijan> clarence: i don't see where :)
[19:45:25] <lucijan> it looks exactly the same to me

1.0 "Seagull" (2004-02-29)

Just one week before its historic release, KolourPaint was still missing 2 features (transparent selections, text). After frantically writing them and then constructing the website in just 1 day, KolourPaint was released on the significant day of Sunday 29th February with a full moon (or was it a half moon?) - this happens only once every 28 years (hence the apparent urgency).

By the next day, the KolourPaint website already received more than 6000 page hits - even without a slashdot effect - largely thanks to the KDE Dot news site.

The reaction was surprisingly lukewarm and ranged from users outraged at what they saw as a clone of Microsoft Paint, requests for a KDE port of GIMP and people delighted at the first real KDE graphics app that wasn't an image viewer. There were also those who commented on my grand artistic talent with respect to the tool box icons. As KDE developer, Adriaan de Groot, put it:

... the icons are of a quality like i would draw them myself, ie. ugly ...

In any case, there is no denying that the KolourPaint 1.0 release raised the bar for the quality of KDE graphics editors. Finally there was an app that actually worked for simple users.

Perhaps the major failing of 1.0 was its dependence on KDE 3.2 which had been released less than 4 weeks earlier. I had meant to add a "#MIN_CONFIG(3.0)" to configure.in.in but inadvertently left out the # only to get an "__m4_diversion" error or something like that :) and as a result, gave up. So the configure script did not catch old KDE installations which resulted in many reports of KolourPaint producing compile errors on earlier versions of KDE. And thus began yet another frantic effort - to produce a backport to at least KDE 3.1 before users were disillusioned.

1.0 was codenamed "Seagull", because it was so groundbreaking that it "soars above the rest even though it can't fly."

It is likened to a misnamed, stuffed penguin that can't fly even though it apparently thinks that it can (pictured here, next to his cow friend). [Sorry, this is an inside joke]

"Enter the KDE" (2004-03-05)

As the news item on the KolourPaint site explained:

Following discussion on the kde-core-devel mailinglist, KolourPaint was moved into the "kdegraphics" module to be included in future releases of KDE - including the upcoming KDE 3.3.

Inclusion in KDE would be an effective channel for the distribution of KolourPaint and would also benefit the overall KDE experience.

1.0.1 Supports All KDE 3.x (2004-03-06)

After virtually skipping the first week of the university semester, I hastily released a backport of KolourPaint. I discovered that KImageIO in KDE 3.0 has a major hole in its API and that Qt < 3.2 is a pain to support.

KolourPaint receives press coverage in Linux User (German), Linux Magazine and Linux Format. I have yet to locate the Linux Format article.

In hindsight, the worst mistake of the 1.0.1 release (even compared to the brush tool bug below) was lazily relabelling the icons from CrystalSVG to HiColor (rather than copying them) in order to support KDE 3.0 (CrystalSVG icons were only introduced in KDE 3.1). Then came the unreproducible reports of missing tool box icons in certain GNU/Linux distributions whose broken icon themes didn't inherit from "hicolor." It surely gave some users bad impressions and was not worked around until 1.2.2.

Bugfix for the Brush Tool (2004-03-07)

The speed at which 1.0.1 was released resulted in the inevitable brown paper bag (see Linux 2.6.8 / 2.6.8.1). As the news item said:

Today, it was found that the brush tool draws nothing when set to the size 1x1. This is due to a bug present in Qt 3.0 and 3.1 (specifically, drawing 1x1 ellipses does not work).

The bug affects most users of KolourPaint 1.0.1 (those with Qt 3.0 or 3.1). Users of Qt 3.2 (and/or KolourPaint 1.0.0) are not affected.

Unfortunately, I was too busy with real life to do another full release.

1.0.2 - With New Icons (2004-05-01)

Having stressed over the brush tool bug and 2 thumbnail crashes with Qt 3.0, it was high time to make another a release. Over the bug fixes, the sweeteners were new icons by Kristof and KDE Help Centre documentation written by Thurston (which initially delayed the release by a week).

Sometimes exams/assignments get in the way:

Historical Note: The KolourPaint 1.0.2 source was tagged and packaged on 2004-04-29 but the release was delayed till 2004-05-01 due to non-technical reasons.

This led to a change in the marking of release dates in KolourPaint documentation in 1.2.2.

Distribution of KolourPaint starts to pick up. I discover Checkinstall thanks to Christoph Eckert. Official and unofficial packages are made for Ark Linux, Debian, Fedora Core, FreeBSD, Gentoo, Knoppix, Lycoris, Mandrake, Redhat, SUSE, ... Slax Live Linux picks up KolourPaint as its paint program. Linspire, Lycoris and Mandrake offer KolourPaint on their software subscription services (there are people who are willing to buy software that they can download for free!?).

1.2 "ByFiat Everytime" & KDE 3.3 (2004-08-18)

I spent the entire intersemester break (and then some) rushing to make the KDE 3.3 release freeze (this was the first KDE release to include KolourPaint). Features that needed to be added included: virtually unlimited undo/redo, freehand resizing (much needed), more image effects and save options (with preview).

Unfortunately, time was my enemy (and still is). The July 14 feature and message freeze meant that I had to code features extremely quickly and didn't have time to fix any bugs. In fact, I was even forced to implement features that could be "shoehorned" into bugs during the feature freeze! I hope coolo (KDE 3.3 release coordinator) doesn't find out :) Lesson: Don't ever use KolourPaint from a KDE beta :) To complicate matters, I had 5 local KolourPaint branches, each with major and conflicting changes which resulted in a 2 day merging hell. I was so short on time that I twice needed to exploit the 8 hour time difference between Germany and Sydney to make the freezes.

Memorably, the transparent text code was fixed over "James Bond: Goldfinger" and dithering images on a 15/16-bit screen was investigated while watching "Scary Movie 2". Both of which (the hacks, not the movies) eventually made me realise that the QPixmap/QPainter backend had been stretched to the limit and needed to be thrown out.

Close to the total freeze, KDE translators were rather unhappy about abuses of the i18n() call (such as using it to concatenate strings). Adriaan de Groot described it as "pure i18n musical genius, clearly."

In the wee hours of August 5 (Sydney Time) - the total freeze - I was still up fixing bugs and had so little time that I didn't even have time to increase the version number to 1.2 (which Stephan Binner eventually did with the commit message "Stable per definition ;-)"). I worked until almost 4am in the morning updating the ChangeLog and NEWS files only to forget to update the version number in NEWS. Later, a bug concerning KolourPaint not saving remote files correctly was identified and fixed - luckily before the KDE 3.3 release.

As with 1.0.1, 1.2 was written too quickly to be stable. A late feature addition - accidental-selection-creation-by-dragging detection - resulted in CTRL-copying of selections not working. It is believed that Linspire even retracted an ad they had for updating their KolourPaint package from 1.0.2 to 1.2, when a warning about the stability of 1.2 appeared on the KolourPaint 1.2 download page. The introduction of automated GUI testing was planned for a future release (probably 1.4).

Despite the signficant feature enhancements 1.2 had over 1.0.2, it did not seem particularly successful in terms of downloads compared to 1.0.2. This could be due to the download page linking to an abundance of binary packages (for all the major GNU/Linux distributions) - almost none of which were hosted on sourceforge.net (and hence did not count towards download stats).

The release date is significant because it was the second anniversary of an activity one of the developers once participated in (you'll have to google up which one; a certain bureaucrat also took advantage of that developer's absence to sneak in a new policy but that is another story). Even though the announcement claimed that "KolourPaint 1.2 is also a part of KDE 3.3 (released today)", KDE 3.3 was actually released a day later.

The release name "ByFiat Everytime" is a statement about the undemocractic decisions made in most, if not all, project releases. The release coordinator makes decisions "by fiat" (hence the name) about when to release, what the release will contain and who can help coordinate the mechanics of the release.

The concatenation of the words "By Fiat" is also a statement about the miscapitalisation of "KolourPaint", commonly as "Kolourpaint" (even in the official KDE 3.3 release announcement). I'd also like to point out that "everytime" is not a word (it should be 2 words: "every" and "time").

It has been said that this explanation about the release name is not "BS" :)

1.2.2 & KDE 3.3.2 (2004-12-12)

The 1.2.2 bugfix release has so far been the most delayed KolourPaint release ever. It was even meant to be 1.2.1 but KDE 3.3.1 had to be tagged on October 2 - the 1.2.1 in KDE 3.3.1 basically only fixed a bunch of selection bugs (including the CTRL-copying of selections regression introduced in 1.2). A standalone 1.2.1 version for KDE 3 has never been released.

1.2.2 release was then promised for for 2004-12-11 but 2 factors delayed it by a day:

The first was an update to apbuild that promised to fix binary compatibility issues with SUSE and Slackware (but I don't use these 2 distros so maybe the packages would have worked anyway but better safe than sorry), forcing the recreation of the binary packages - that was binary release 2 (which was also never released).

The second was the discovery that the current tool's options widget was not shown on startup if a filename was specified on the command line and if a messagebox was displayed before the KolourPaint window was shown. Such a serious bug caused some panic (as it would require recreating all the source and binary packages, not to mention spamming about a dozen packagers). Further investigation revealed that it only affected Qt 3.0. Since most people compiling KolourPaint (including packagers) would not be using Qt 3.0, it was decided that releasing a source patch and new distro-independent binaries (release 3) would be sufficient.

Rewinding back in time a bit, after trying to use 1.2 for drawing UML diagrams, a number of issues (such as overly large text selection handles and empty clipboard bugs) were identified and fixed before the 1.2.2 release - as the NT team knew, it's always good to be force-fed your own cake. This testing also revealed problems with the underlying kpSelection class with respect to its inability to antialias text in a box with a transparent background

Longstanding issues such as incorrect scaling/zooming under Qt 3.0 (since 1.0.1 and very serious yet only discovered months after 1.2 was released!) and missing icons in some GNU/Linux distributions (introduced in 1.0.1) were resolved.

Having decided that it took too long to make packages for the last 4 releases, I chose to almost completely automate the packaging process with scripts. The scripts themselves took more than 2 full days to write! This is only anticpated to pay off after 2 more releases.

Other firsts included all KolourPaint documentation reflecting the freeze date, rather than the anticipated release date (which in the event of a delay such as in the case of 1.0.2 and now 1.2.2, would normally require updating the documentation and recreating the packages (but I was too lazy to do that for 1.0.2)).

Also, translations from KDE 3.3.2 to 32 languages were included. Including translations was actually another factor in the delay of the standalone 1.2.1/1.2.2 release - string fixes in response to the i18n() abuses were put into KDE_3_3_BRANCH after KDE_3_3_0_RELEASE so I had to wait for the KDE_3_3_1_RELEASE before I could rely on updated translations.

Other changes included BSDiff and XDelta binary patches being made available for the first time and some packages being uploaded to ftp.kde.org (this also forced me to fill out a kolourpaint.lsm...).

The GNU/Linux distribution independent binaries received much polish and finally became ready for everyday use, losing their "EXPERIMENTAL" tag. Considering how few packagers responded to my call for binaries (probably because I mentioned that KolourPaint was already "in the upcoming KDE 3.3.2"), this was very important.

On the day of the release, my announce message to kde-announce was surprisingly rejected with the following reason:

Please add a paragraph that describes what "kolourpaint" is and resubmit.

No doubt, "kolourpaint" must be a black and white text editor for GNOME. Sarcasm aside, the list moderator did have a point since a short description of the product is standard practice in release messages. I was just surprised that previous announce messages were not rejected.

Download logs thanks to my new Perl/CGI script "redirect" revealed several surprising things (assuming users do not set their web browsers to fake the User Agent and Referer fields):

• About a third of downloads came from users clicking directly on links to source packages from freshmeat
• There were Apple users trying to use the GNU/Linux/x86 binaries (I neglected to mention x86 on the website - this was quickly corrected)
• By far (approx. 80%), the most popular web browser family used to download KolourPaint - a KDE application - was Mozilla, not KHTML!?
• There were KDE 3.3.2 users downloading KolourPaint even though they most likely already had it (KolourPaint 1.2.2 is in KDE 3.3.2)
• Users do not trust my binaries - 50% of the downloads are still source code
• About 50% of users download .tar.gz instead of .tar.bz2 even though .tar.bz2 is smaller (bunzip2 is very widespread now so I don't understand why - sourceforge stats for previous releases support this)

On the December 20, disaster struck. That CGI redirect script (which is basically the only way of downloading 1.2.2_kde3 other than from freshmeat or from the sourceforge project page) gave an "Internal Server Error 500." That could be why there were so few downloads (even reaching single digit levels a few days after the release). It was already unusual that the sourceforge CGI server required world executable permission on the CGI script (normally CGI servers mandate the opposite - no "group" nor "other" permission bits). But now the script worked only if it was also world readable. Did sourceforge change their setup?

Thurston complained that the 1.2.2 download page took 2 screenfuls of scrolling - past the change logs and the binary package ad - before getting to an actual package link. Furthermore, user testing showed that people were unsure of which file to download for their system. In response to this, I spent Christmas and Boxing Day simplifying the download page and factoring out the change log. As part of the fight against clutter, gone were direct links to .gz (.bz2 is better) and .bsdiff/.xdelta (rarely downloaded and require somewhat technical skills to apply) files (they are still accessible from the Sourceforge File List link on the download page). I also highlighted the recommended download link and inspired by the Firefox page, put a quick link to the binary on the front page. Lastly, I got my act together and poured through 16 months of email to pull out some testimonials :)

1.4_light & KDE 3.4 (2005-02-22)

The plan was to work on KolourPaint from December 2004 to February 2005 to bring out the much anticipated (by me mainly :)) KolourPaint 1.4. Unfortunately, a few difficulties (to say the least) arose in finding the time to do this so it didn't happen.

As KDE 3.4 needed to be released, a KolourPaint "1.4_light" was hastily created with almost no new features. The main changes were text antialiasing working consistently, thumbnail modes and Kazuki Ohta's InputMethod support. Various point releases were made throughout 2005 to fix minor bugs. I still have uncommitted patches I would like to clean up and apply one day.

As 2005 Unfolded...

SVN

My limited time became even more limited with the transition of the KDE source repository from CVS to SVN. Not only did it require redownloading maybe 100MB worth of code on expensive 28K dialup but I also experienced a scary number of SVN client bugs and found that it's slower than CVS and even lacks some of CVS' features. The only redeeming features of SVN are: a) changeset-based revision numbers b) offline diff'ing.

No More Standalone Releases

Standalone releases of KolourPaint have always been time-consuming. Website work and packaging are not my core competencies. The KolourPaint release system turned out to be too slow and rigid. Branching and porting the 1.4_light source to KDE 3.0 would have required patching with a diff thousands of lines long. I then would had to have tested it on all major KDE 3.x releases - KDE 3.0, 3.1, 3.2, 3.3, 3.4. Then it'd be a similar story for my generic Linux/x86 binaries. Complicating matters were the unstable gcc C++ ABI (and apbuild not being ready for this), many bugs in the binary wrapper script and a lack of easy common denominators between all main targeted distros (Aug2002 - 2005).

Trying to start a revolution in Linux software distribution - binary packages that run on practically any distro and with no installation or root privileges - turned out to be impossible without free time and when another project ended up copying the technique, pretended I didn't exist and controls significant parts of the media. So I decided that I should leave packaging to the regular packagers for the time being and I'd make no future standalone releases. KDE and related networks of packagers would be left to do the releasing. I retreated back to my traditional programming role.

KolourPaint In Linux Distros

Many people continued to pretend KolourPaint did not exist. Several "user-friendly" distributions (left unnamed) even made a point of leaving KolourPaint out of their KDE install for still unclear reasons. One such distribution appeared to include every single KDE application except two - one of which was KolourPaint. I cannot understand how lay people can do simple editing of images in such distributions. If I ever make a Linux distro, my motto will be "Linux for ordinary human beings" :)

On the commercial front, KolourPaint made more in-roads. Linspire and Xandros, distributions really focused on Linux usability, dumped a longstanding application and instead, shipped KolourPaint. A number of reviewers pointed out the lack of the former application but did not even mention the replacement by name (ironic statement intended).

Web Maintainer

In the mean time, I managed to unintentionally scare away several people who offered to work on the website so I am still the web maintainer :(

1.4_relight & KDE 3.5 (2005-11-08)

KolourPaint 1.4 continued to be delayed. What was needed was yet another maintenance release after 1.4_light: 1.4_relight (during development, it was called 1.4_light2).

The main attractions were new icons by Danny Allen and Nuno Pinheiro and a few tweaks I previously said were "impossible".

2006 - The Road to KDE 4

As promised, I continued to maintain KolourPaint in all stable KDE branches (KDE 3.3, 3.4 and 3.5). Two important bugs were fixed:

1. Printing did not fit the image to the page if the image was too big (Bug 108976)
2. A crash could be triggered by rapidly deselecting the selection after drag-scaling it (Bug 117866)

Interestingly, this crash was the first confirmed KolourPaint crash in years. In contrast, some other projects have entire mailing lists devoted to crashes. This is a testament to quality of the code produced by the debug-driven development approach used for KolourPaint. Having said that, it goes without saying that it would have been better if I had not written the buggy code in the first place.

The Coverity static analyser people offered KDE free scans of their code. So, jumping at the prospect of an ex-Stanford program finding bugs in my code, I applied for an account. The results were rather disappointing and all it found were false positives and bugs in unexecuteable code paths (due to my stubborn insistence on not using Q_ASSERT, which I've now fixed). The fact that it found real bugs in other projects simply proves my point about the reliability of KolourPaint code.

In the meantime, I began work on the KDE 4 port of KolourPaint. I was rather disappointed at the quality of Qt4 and had to submit quite a few bug reports (and still have more coming). I even found a bug in Qt4's fundamental signal/slot mechanism, where objects could receive signals from objects they were no longer connected to.

Some semantic changes in Qt4 made it particularly difficult to port KolourPaint:

1. QRect::normalize() no longer works in all cases
2. QPainter draws rectangles 1 pixel higher and wider than before (and to make matters worse, can no longer draw 1x1 rectangles, if the pen width is 1)
3. RasterOPs, such as XOR, have been dropped
4. QPainter now modifies the mask, unless you aren't using XRENDER - potentially, this means that I now need to have separate XRENDER and non-XRENDER code paths
5. QPixmap::mask() recalculates the mask every time and this is very slow for images with alpha channels

Anyway, after I managed to get KolourPaint to compile under Qt/KDE 4, it was broken again by a massive KAction API change. And after working around that, the Tool Box was then stuck in a horizontal position (and still is).

To make matters worse, the KActiveLabel API changed twice so I had to update KolourPaint twice in response. Evidently to agitate me further :), the class was then dropped! Apparently, QLabel now has the required functionality but I have yet to update the code in question.

I started a major refactor of the KolourPaint source code with the objectives of:

1. Removing difficult-to-read code
2. Using proper inheritance in the tool classes (this was especially motivated by the infamously complex kpToolPen class)
3. One class per file
4. Only using the kpTool prefix for classes that are actually tools
5. A more sophisticated directory structure (for better file categorisation)
6. Encapsulating the paint engine into the new imagelib

The effects of coupling of KolourPaint to the current screen mode and the number of semantic changes in the Qt paint engine finally, finally, finally convinced me that it was time to dump QPixmap/QPainter (which were never really intended for paint programs anyway). The motivation behind the imagelib encapsulation is to allow for a 2007 drop-in paint engine replacement (something similar to the Krita image library).

I also started writing a developer guide to provide a high level overview of the KolourPaint source code, to encourage more people to contribute. It also serves as a useful knowledge backup if I get hit by a bus.

By the end of 2006, all basic tools, except for the selection tools, worked again.

Lastly, I bought the domain name www.kolourpaint.org, which is easier to remember than kolourpaint.sourceforge.net.