General Info |
Product Comparison |
This page gives you a behind the scenes tour of the development of KolourPaint.
It reveals the vision that drove me to spend hundreds (if not thousands)
of hours writing a graphics editor for KDE. Read about the highs and
lows, challenges, and significant milestones in
the making of KolourPaint.
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:
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
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,
... 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
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.
The speed at which 1.0.1 was released resulted in the inevitable
brown paper bag (see Linux 2.6.8 / 184.108.40.206). 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
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
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 :)
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
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
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
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)).
translations from KDE 3.3.2 to 32 languages were included.
Including translations was actually another factor in the delay of the
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
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...).
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
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
- By far (approx. 80%), the most popular web browser family used to
download KolourPaint - a KDE application - was Mozilla, not
- 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
- 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.
I got my act together and poured through 16 months of email to pull out
some testimonials :)
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.
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...
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.
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).
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".
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:
- Printing did not fit the image to the page if the image was too big (Bug 108976)
- 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
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
QRect::normalize() no longer works in all cases
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)
- RasterOPs, such as XOR, have been dropped
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
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:
- Removing difficult-to-read code
- Using proper inheritance in the tool classes (this was
especially motivated by the infamously complex kpToolPen
- One class per file
- Only using the
kpTool prefix for classes that are actually tools
- A more sophisticated directory structure (for better file
- Encapsulating the paint engine into the new
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
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,
Lastly, I bought the domain name www.kolourpaint.org, which is easier
to remember than kolourpaint.sourceforge.net.
General Info |
Product Comparison |