Are you still with me?

I’ve taken a long break from The Road for some time, but fear not, I haven’t forgotten about my initial goal. But since it’s been so long, maybe you have? Let’s start this step with a short recap:

• Step 0 – At the beginning of the summer 2009, I started my journey to “KDE Devland” to become a KDE developer. By sharing my experiences I hoped that I could motivate others to do the same, and leave behind useful tips for those who wanted to walk the same path. The first step was mostly an introduction.
• Step 1 – Before going on a journey, you should be prepared. In this step I shared useful links for soon-to-be developers and wrote about my plan and which books I would use.
• Step 2 – I started with C++. This post went through pointers, something I found hard to understand in the beginning.
• Step 3 – Talking about my temporary workspace and which applications I use to write the code.
• Step 4 – At this point I finally had some screenshots to show. In this step I showed my achievements after the summer and wrote a little bit about Qt programming.

I feel fairly comfortable with Qt now, and try to learn some specific parts of the toolkit when I find the time and motivation. Right now I’m struggling with the Interview framework – I think I understand the theory behind it, but I need to get a feeling for how to actually use it.

In this step I’ll show you some of my own applications I’ve done to familiarize myself with Qt. If you still remember the last step you’ll recognize some of them, however they’re actually all made from scratch. First one out is the smallest application, but also the one giving me the most trouble.

TextSync

Description

TextSync is an extremely simple text editor. Rather than loading and saving text files, it “syncs” to a user-defined text file (from now on referred to as the original file; synced text is the text shown in the application):

• Original file modified – TextSync reloads the synced text
• Synced text modified – TextSync saves the new text to the original file

TextSync in all its glory

The idea is to make a plasmoid version of TextSync. It would behave pretty much like the Notes widget in the sense that you don’t have to think about saving and loading the text, but with additional benefits:

• You know where the text is saved and can easily make backups, for example
• TextSync can be used to display logs by pointing it to a log file and set it to read-only
• You can easily sync text across computers with services like Dropbox. This combination will let you use TextSync as a synced Notes widget, or you can turn it into a basic chat widget by sharing the synced file with a friend

I want to stress, however, that TextSync is not meant to be used as a collaborative tool.

By the way, TextSync is just a semi-temporary name, like the names of the other applications – I might rename it sometime in the future if I find a better name. Maybe “TextView”, similar to the FolderView widget?

What’s next

There are still some things I need to iron out before porting it to Plasma. For example I currently use QFileSystemWatcher to monitor the source file, but I don’t know if it’s a good idea performance-wise.

Also, TextSync only saves the text every n second (currently set to 5) when the synced text is modified to avoid excessive write to disc, so I have to decide how to handle the following two situations:

• Synced text modified (unsaved), original file modified – At the moment TextSync simply reloads the source file, discarding any changes you’ve made during the last 5 seconds
• Original file modified (not loaded), synced text modified – This is less likely due to the use of QFileSystemWatcher, but can still happen

I want to avoid using dialogs – the user shouldn’t be aware of the whole loading/saving mechanism. I’ve been thinking about using something like diff to merge the two texts, but I’m not sure about this approach yet; even if I was, I don’t know how to implement it.

The easiest solution would be to do what TextSync currently does – discard any changes made in one of the texts, preferable the synced text.

What I learned

TextSync proved to be good lecture on how to structure your classes. In the beginning I had everything in two classes, TextSync for the main application and SettingsDialog for the settings.

Soon I found that QFileSystemWatcher wasn’t flawless. When I modified the source file with vim, it would stop monitoring the file – the next time the original file was modified, TextSync wouldn’t reload it. To workaround this, I had to readd the path whenever QFileSystemWatcher noticed that the file had been changed. This was not as easy as it may sound, as it didn’t work to simply add it immediately.

This extra code didn’t really belong to the main application, so I moved it to its own class, FileWatcher. Now TextSync can use the new class in a very similar way to QFileSystemWatcher, and it doesn’t have to know that FileWatcher attempts to readd the path.

I’m in the progress of doing a similar thing with the loading/saving functions – move everything to a separate class. Since these functions are tightly connected to the QTextEdit widget (the text box), it makes sense to derive the new class from QTextEdit and add the extra loading/saving functionality to it.

GridView

Description

GridView is a reimplementation of the spreadsheet application I did in the previous step. As I wrote back then, I found the spreadsheet example far from easy – by making a similar application myself, I hoped I would understand some parts I didn’t before.

As the name implies, GridView is meant to view grid files (*.grd). In a previous summer job I worked a lot with these files, so I thought it would be nice to make an application to view and edit grid files.

GridView displaying a small 4x4 grid

The files themselves are very easy to read, the grid above looks like this:

DSAA
4 4
0 4
0 4
1.8 9.9
7.5 6.3 2.0 0.7
9.9 5.8 1.8 3.0
8.2 5.7 8.6 7.4
7.6 4.4 4.2 2.3

What’s next

For now, GridView is mostly an empty shell – most functionalities need to be implemented. The UI was made with Qt Designer in contrast to the spreadsheet application, which was mostly made in a text editor.

This is mostly a test application, something I won’t spend time to improve and polish. Once I’ve added the features I want, I’ll leave it at that. But I’m sure it’ll be useful as reference for future applications.

What I learned

Not much yet. Since the application isn’t really needed, I don’t feel much motivation to work on GridView. When I’m back home again I’ll look at the source code of the spreadsheet application again and add some basic features to GridView.

Quiz!

Description

So I only planned to do two applications for this step. But one day when I was generating random dates “manually” (with a random number generator) I realized, “Hey I can make an application to do the hard work instead”. And thus Quiz! (I couldn’t find a good name – the current one is inspired by Qalculate!) was born.

Quiz? No, Quiz!

Now I don’t have to check if my answers are correct in a calendar either, since Quiz! does it for me. Quite a handy little application.

Quiz! can be used for other questions as well – you just have to derive from AbstractQuestionGenerator and implement the generate() function. I’ve only made two question generators so far, the one shown above and one for a math quiz:

A different question generator

As you can see, I also played around with HTML in QTextBrowser.

What’s next

The application works fine for me now, and since I don’t plan to release it, I don’t think I’ll work on it much more. For now you have to change a line in the source code and recompile to switch question generator. It should be very easy to add a feature to change it at run time, however.

Right now the date quiz only asks for dates in 2009, but I have to change it to 2010 now. When I’ve become better I’ll make it generate a random year in the 21th century.

What I learned

Quiz! was very fun to code. It’s small, yet something I know I would find useful.

When working on this application, I came to appreciate object-oriented programming more and more. One good example is the use of QDate to handle dates. Writing a function to generate a random date isn’t hard, but it’s not a one-liner either – you have to take into account that the lengths of the months are different, and with random years you need to remember leap years as well.

With QDate I generate a random month (1-12) and day (1-31) and use the bool QDate::setDate(int year, int month, int day) function in a do while loop. If the date is invalid it returns false and a new date is generated, otherwise it returns true and exits the loop.

As a bonus, QDate offers a dayOfWeek() function to easily check the weekday for a specific date. Thanks to this class, the source code for my date quiz generator is very short and straightforward.

Next stop: The land of yellow cashews

For now I’ve only worked with C++ and Qt, but hopefully I can write a little bit about working with the KDE Platform in the next step. The plan is to first port TextSync to Plasma. There is another plasmoid I want to do – I’ll write more about it the next time if my first step into Plasma land is successful.

The end of summer

Whew, long time no see! After the summer vacation I’ve had my hands full, so I never found the motivation to sit down and write this. Sorry about the delay.

This step marks the end of summer and will show you what I’ve achieved in these two months. But first something about Qt.

The start of Qt programming

To start off, I need to say this:

Qt is easy.

When I was a child, I made some GUI applications in Visual Basic. It was very easy to get started with – you place some widgets on a form, double click on one (e.g. a pushbutton) and write some code to be run (e.g. when the pushbutton is pressed). Simple.

Even with my limited knowledge of Visual Basic, I could do pretty much. The code was usually awful – I preferred to store values in (invisible) textboxes instead of using variables, just to mention one thing – but they actually worked.

Now, I would argue that Qt is harder to get started with, probably because it uses C++ (yes I know that Qt has a lot of bindings for other languages). It’s easy to lay out widgets in Qt Designer, but it’s far from obvious what to do afterwards. The workflow is probably clearer if you use Qt Creator, but I haven’t tried it yet.

To my aid I had my books, and I soon found that I was able to do a lot in Qt that I didn’t know how to implement in Visual Basic. The Qt layout system makes it easy to lay out widgets and takes care of the position and size of widgets when you resize the window. To make an application with menubar and toolbars, you derive from QMainWindow and add a few objects and functions.

Derive. That’s something you’ll do a lot in Qt. An excellent example of object-oriented programming.

If you want an object A that have the same properties (talking about general properties, not Qt specific) as object B, but further specialized, you can derive A from B. For example, I want a cat that can play Go. Most cats can’t do that, right? A normal Cat is not enough. But I don’t need to create a new Cat from scratch, I can make the new class inherit from Cat (i.e., it is derived from Cat):

class  GoCat : public Cat
{
    Q_OBJECT

public:
    GoCat(QWidget *parent = 0);

private slots:
    void playGo();
};

This is just standard C++. Q_OBJECT is included because we want to make use of Qt’s meta-object system, including signals and slots (read more here).

In a similar fashion, we can build GUI applications by using the classes Qt provides. A Main Window with menubar, toolbar and system tray? No problem, QMainWindow takes care of it. If we want to make a custom widget that consist of two Qt widgets, for example a QSlider that’s connected to QLCDNumber like in this tutorial, we simply derive from QWidget.

MyWidget(QWidget *parent = 0); is a typical constructor declaration for derived classes. We then pass the parent pointer to the base class (the one we derive from) in the constructor:

MyWidget::MyWidget(QWidget *parent)
     : QWidget(parent)
[...]

In this example  (taken from tutorial) MyWidget is derived from QWidget, as you can see.

(Qt’s parent-child mechanism is out of scope for this article. I touched upon the subject in step 2, when I wrote about pointers in Qt).

Result

As promised I’ll show you the two Main Windows (derived from QMainWindow, of course) that I’ve done by following my two Qt books.

In The Book of Qt 4: The Art of Building Qt Applications you create a simple text editor in chapter 4. The GUI is done in Qt Designer and the final application looks like this:

CuteEditor

I liked this application. It’s simple – most of the functionality is already in QTextEdit. You need to setup the actions in the toolbar and menubar and implement a few functions functions, such as loading and saving files. Oh, and don’t forget the status bar. That’s pretty much it.

This chapter gave me a good understanding of how to create similar small applications. However, I found the part about the dock window (“Templates” in screenshot) somewhat vague and incomplete. The code wouldn’t compile for me at first – I need to look into it and see if it’s a mistake from my part.

The application in C++ GUI Programming with Qt 4 is more complex. You build a spreadsheet, completely from a text editor (chapter 3 and 4). Well, for most parts at least.

Spreadsheet

The reason I said “for most parts” is because you create some of the dialogs in Qt Designer in an earlier chapter. It’s very nice that you get to reuse them to create your Spreadsheet application and learn how dialogs work. Completing the application was also a big motivation booster – “woah, I could actually make this application”.

That’s unfortunately also the bad thing about this example – to me, it was a bit too complex and it was easy to get lost in details. Yet it’s listed under “Basic Qt”, which I find somewhat amusing.

Another thing I didn’t like was that I couldn’t compile it until I was finished. I prefer to take it in smaller steps, to be able to see what I’ve accomplished after a while. In hindsight, I should have copied example files from chapter 4 (included on CD) to test the application.

Overall I get the feeling that C++ GUI Programming with Qt 4 assumes the reader has more prior knowledge in C++ than The Book of Qt 4: The Art of Building Qt Applications. In my opinion Daniel Molkentin, the author of the latter book, gives a more expanded explanation on some topics, such as memory management (stack vs heap) and how to use Ui files created in Qt Designer. On the other hand, I also appreciate the insight Jasmin Blanchette and Mark Summerfield (authors of C++ GUI Programming with Qt 4) provides and their elegant code.

To summarize, I don’t regret getting both books – so far, I think they work pretty well as complements.

Johan Thelin has been kind enough to send me a review copy of his book, Foundations of Qt Development - thanks Johan! It’s still at my parents’ place but I’ll pick it up the next time I visit them. I’m looking forward to seeing what this book has to offer.

Final words

Everything above (mainly referring to “The start of Qt programming”) is my interpretation. If you find any errors in the text, please don’t hesitate to correct me.

Next time I’ll show you the applications I recently started working on. Simple small applications, very similar to the ones I showed above (but rewritten from scratch). I do, however, have plans to eventually turn one into a plasmoid later.

My lectures have started again, so I’ll have even less time to learn about KDE Development. That also means less frequent steps, which in unfortunate. I’ll try to keep you updated as often as my time (and motivation) allows.

Project Setup

This time I’ll just tell you about my project setup. You already know which books I read, but what other tools do I use to reach my goal?
First, however, I want to give attention to the following blog posts:

• thinkMoult -  The Road to KDE Devland (Moult Edition) #0
• veracity – The Road to KDE and Qt Development

It’s nice to hear about other people who walk towards the same goal, but not necessary the same road. Looking forward to hearing more from them, and I also hope to see more “The Road to …” series emerging.

Where do you hack?

To start off, here’s my temporary working environment:

Yes, that’s a Microsoft mouse. I don’t consider a mouse important enough to bring my own, so I just use an unused one I found lying around.

The netbook is a Samsung NC10, which I’m very happy with. I can’t get compositing to work when using the external monitor, but I guess that’s a limitation in the hardware. Otherwise most things work out of box with Arch Linux, the distro of my choice.

As you can see, Tux is currently on vacation. I’ve borrow Micaiah from my little brother as a temporary hacker mascot.

The tools

Let’s take a closer look at my screenshot:

In my experience, IDEs are more troublesome than helpful when it comes to small projects. In an introduction to C++ course in high school, the teacher recommended us to use CodeWarrior (we were writing applications like “Hello World”). What a mess. Most problems my classmates had seemed to be IDE-related rather than related to code. I used a trial version of TextMate and compiled from the command line instead. When the trial was over, I switched to gVim (and made a friend who was tired of CodeWarrior switch too).

On my own computer, I preferred to use Kate. I tried KDevelop briefly, but I didn’t think that all the extra features it offered was needed. KISS, right?

As you can see, I now use Vim as my text editor. I’ve used Vi/Vim for a pretty long time (vim foo; a; <navigate around with arrow keys and enter text>; escape; :wq), but I haven’t really learned how to use Vim until now. If you want to start with Vim, I highly recommend vimtutor (enter it in the command line).

I’m still far from a Vim master, but I find it very nice to work with. Here are some scripts that make my life easier:

• SuperTab – allows you to use the tab key to do all your insert completion
• EnhancedCommentify – switch lines between commented and uncommented
• FSwitch – switch between source and header file
• snipMate – TextMate-style snippets for Vim

To fix syntax highlighting for Qt, I followed this blogpost.

The other application you see in the screenshot is Qt Assistant – a very helpful assistant, indeed.

Despite everything I’ve said about IDEs, I recommend you to check out Qt Creator if you like these kind of tools. Personally I think I’ll stick to Vim for a long time, and maybe try to get Vide working again. Someday.

As seen in the screenshot, I’ve started with some Qt by now (after about 3 weeks of C++). I’ll write more about it in the next step. Now it’s time to go to my other hacker place – bed. I’ve only dreamed about code a few times, but those dreams were quite pleasant; it felt like I finally understood some things.

Can anyone give me some pointers?

After one week with Sams Teach Yourself C++ in 21 Days, it feels like I have the basics of C++ down: constants and variables, functions, some operators, loops, if and switch statements etc. Object oriented programming was introduced surprisingly early (Day 6), and the memory discussion at the end of Day 5 took some time to digest, but other than that everything went smoothly.

In the second week, the book takes up a topic that I’ve found pretty hard: pointers and references. In this step, I’ll write about some of the things about pointers and references that confused me. It’s assumed that you already know the basics of pointers/references.

Why pointers?

Pointers are introduced with some silly examples that doesn’t make much sense – why manipulate a variable using a pointer instead of directly assigning a value to the variable? Soon, however, the book tells you why pointers exist. (In this case, I think I would’ve preferred the other way round – first present the problem, then talk about the solution(s). It’s probably the way Accelerated C++ approaches the subject, although I haven’t come to pointers in that book yet).

If you’ve studied some C++, you have probably come across the stack and the free store (the heap). Local variables (and function parameters) are declared on the stack, and go out of scope when the function returns. Variables on the heap, however, remain until you free the memory manually or when the program ends.

In C++, you allocate space on the heap with new. new returns a pointer, which is how you access data on the heap. I like the analogy in Sams Teach Yourself C++ in 21 Days: let’s think of the memory address as a telephone number, say, to the local pizza store. Since you eat pizza all the time, you program your phone to call that number when you press a special button. You don’t have to remember the phone number anymore, and you don’t need know where the pizzeria is located – you can still access it by pressing that button on your phone.

Now back to programming. You can think of the pizzeria as being on the heap (it’s “somewhere”). Isn’t it good that our phone has this handy button? You probably know where I’m going – that button is our pointer to the pizzeria. In a similar way, you can access variables on the heap just by using pointers!

Another use of pointers is to pass variables by reference to functions. A classic example is the void swap(int a, int b) function. If you pass two variables to the function, you’ll notice that they aren’t swapped at all! This is because the function receives copies of the values, not the actual variables. One way to solve this problem is to pass pointers to the variables instead: void swap(int *a, int *b). This way the function can access the original variables and do the swap.

Pointers vs References

If you want to use the swap function from the previous section, you have to pass it the address of the variables (on the stack) using the address-of operator (&):

swap(&first, &second);

In the swap function body, you have to dereference the pointers with *:

int temp = *second;
*second = *first;
*first = temp;

Quite troublesome, isn’t it? (Here, we’ve even skipped to check if the pointer is a null pointer). Fortunately, you can accomplish the same thing with references. A reference is an alias for an object. If we pass references to our function, void swap(int &a, int &b), we can do everything the “normal” way since a and b in the function body are aliases for the variables we pass into the function (and not copies!).

Seeing how easy it is with references, pointers feel kind of, well, pointless. So when should I choose to use pointers instead of references?

The rule of thumb seems to be:

Don’t use a pointer when a reference can serve the same purpose.

With that said, there are a few situations when you want to use pointers according to Johnny Bigert (Swedish):

1. If it’s possible for the object to be null. Sams Teach Yourself C++ mentions that some compilers support null references, but recommends to avoid them; instead, you should use a pointer, which can be assigned to null (0).

2. If you want to change the object being pointed to. References can’t be reassigned, so you should use a pointer in this case.

klebezettel posted a link in the comments that explained the standpoint of Qt Software:

“Most C++ books recommend references whenever possible, according to the general perception that references are “safer and nicer” than pointers. In contrast, we at Qt Software tend to prefer pointers because they make the user code more readable.”

See the link for more details and also Karellen’s comment.

The use of * and &

If you look at the swap example, you see a lot of * and &. If the function prototype looks like void swap(int &a, int &b);, should you also prefix the arguments with * or & when you call the function?

This is how I thought in the beginning, and obviously it was not the right approach. What I did was to confuse the address-of operator with the reference operator, and the same for *. The compiler can see the difference from the context, but how do you do it?

It’s very simple, really. You declare a pointer by writing the type followed by * and finally followed by the pointer name, for example

int *pointer;

Personally I think it makes more sense to think that * belongs to int, to declare a pointer to an int. The problem is that if you write it like

int* pointer1, pointer2;

you would expect two pointers, but what you really get is only one pointer – pointer2 is an int. How the whitespace is placed varies from programmer to programmer.

When you use the dereference operator (*), you don’t have a type in front of the *, for example

someFunction(*dereference);

It’s the same for & when declaring references (type &ref) and using it as  the address-of operator (&variable).

Now back to functions. When looking at a function prototype, I now think: “what kind of arguments does it expect”? Let’s say it looks like this:

void increment(int *var);

The function takes a pointer to an int. I can pass it a pointer, or I can use the address-of operator (&) to pass it  the address of an int:

int i = 1;
increment(&i);

If the function takes a reference,

void increment(int &var);

I just think that the function, if properly written, will adjust my variable in some way.

There are times when you don’t want to modify the original variable, but still want to pass by reference. This has to do with performance – when passing by reference the function can access the original variables and doesn’t need to make a copy. When passing an int, it won’t make a big difference; but when it comes to big classes, you can gain a lot by passing function arguments by reference.

What you want to do is to tell the function, “OK I give you access to my variable, but don’t you dare to touch it!”. You already know how to do the first part, and the second can be accomplished with the const keyword. References are always “constant” (they can’t be reassigned), so const together with a reference is always intended to make the object referred to constant:

int const &a = …; // correct
const int &b = …; // correct
int &const c = …; // not valid

as litb pointed out. However, this doesn’t apply to pointers:

const int * pointer1; // pointer to constant int - the value pointer1 points to can't be changed
int * const pointer2; // constant pointer to int - the object pointer2 points to can't be changed


Of course, you can combine the two:

const int * const pointer3; // the object pointer3 points to and the value can't be changed


The trick taught in Sams Teach Yourself C++ is to look to the right of const. In the first example, the int (pointed to) is constant; in the second, pointer2 (the pointer) is constant.

Finally, just a few words about the cute -> operator. If you want to access members of an object using a pointer, we would have to dereference the pointer first:

(*pointer).anotherFunction();

Since this is something we’ll do quite often, C++ provides the -> operator for indirect access. That means that we can as well write it like this:

pointer->anotherFunction();

Pointers in Qt

You’ll see -> being used a lot in Qt – in fact, almost all widgets (pushbuttons, labels etc.) are created on the heap in a way similar to this:


QPushButton *okButton = new QPushButton("OK");

Why aren’t they created on the stack? That’s something I wondered for a long time, and The Book of Qt 4: The Art of Building Qt Applications by Daniel Molkentin finally cleared it up for me. In C++, you have to remember to delete objects on the heap. Qt makes memory management easier by providing a parent-child hierarchy for objects. All objects derived from the QObject class can benefit from this; when a parent is deleted, it also deletes all its children. If a child acts as a parent for some other widgets, it also deletes its children, and so it goes on until all descendants are deleted.

If I understand Daniel Molkentin correctly, objects have to lie on the heap to take advantage of Qt’s memory management. illissius commented that “that’s sort of backwards”, make sure to read his whole comment.

When you create a new object, you can specify the parent:

QWidget window;
QVBoxLayout *mainLayout = new QVBoxLayout(&window);

In this case window lies on the stack, since it’s the top-level widget.

When using some functions, for example mainLayout->addWidget(okButton), the widget gets automatically added to a parent-child hierarchy. Here, mainLayout‘s parent (window) assumes parentage of okButton. mainLayout is not a parent of okButton, as one might think.

Phew, this was one quite long step. Remember, however, that there are much more to learn about pointers and references – I’ve only picked a few areas that I’ve found hard. For example, I skipped the topic of dangerous pointers entirely  – something you shouldn’t do if you’re studying C++.

I hope to keep the next steps shorter, to only report my progress. I’ll blog again when I’ve finished my Sams Teach Yourself C++ book and started with some basic Qt (yay, screenshots?). Now, I’m waiting for the obligatory comment…

In case you’ve missed it, the series starts with step 0.

Preparations

When I became interested in KDE development some years ago, it wasn’t very easy to find out how to start. I found a KDevelop tutorial and learned a little about C++, but that’s pretty much it. Soon other things in life took over, and I returned to just watch KDE’s progress through the Dot and Planet KDE.

This summer, when I finally have a lot of free time, I want to start over. This means that “The Road to KDE Devland” series should suit you even if you don’t have any prior knowledge about C++ or programming in general.

Starting point

Nowadays there’s a natural starting point for soon-to-be developers:

techbase.kde.org

Here are two articles to get you started:

• Contribute
• Becoming a KDE Developer

Planning

From the first link, you can read “KDE is mostly written in C++. If you are not familiar with C++, you should do at least some work on it” and “To become proficient with KDE coding, you should understand the Qt toolkit”. Although other languages are supported, I’ll only focus on C++/Qt.

So the plan is simple: first I’ll learn C++, then Qt and ultimately get familiar with KDE coding. When you come to Qt, make sure it’s Qt4 and not Qt3 as there are some major differences. I think most people would highly recommend to skip Qt3 and start directly with Qt4.

Online Resources

There are a lot of useful links in the two TechBase articles I linked to earlier. Here are some additional links that you might find useful:

C++

• C++ Language Tutorial
• C++ Made Easy
• C++ Programming Language on Wikibooks

Qt

• Qt Tutorial – For unknown reasons, this tutorial isn’t listed anymore. I think it gives you a good introduction to Qt, and the final application (a game) is pretty cute.
• An Introduction to Design Patterns in C++ and Qt 4 – Free online version
• Learn Qt – Relative new site with tips and tricks, tutorials etc.
• Qt4 tutorial for absolute beginners – I haven’t used it myself. If you aren’t afraid of screenshots from Windows, maybe it’s worth a try

Personally I prefer real books, even if there are free e-books available. Which brings me to the next section…

Books

There are a lot of good C++ books, so I won’t list them all – a Google search should get you on track. As for books on Qt, you can find a list here.

Below are the books I use. They are by no means the “best”, they just happen to be the ones I choose.

• Sams Teach Yourself C++ in 21 Days – Seems like a good introduction to C++
• Accelerated C++: Practical Programming by Example – Takes a different approach to teach C++, which I thought sounded interesting. Instead of introducing language features with examples, it presents problems and doesn’t hesitate to use the Standard Library to solve them
• C++ GUI Programming with Qt 4 – The official Qt book
• The Book of Qt 4: The Art of Building Qt Applications – Hopefully a good complement to the first Qt book; more about it below

(Note: I own the 5th edition of Sams Teach Yourself C++ in 21 Days and 1st edition of the other books).

When skimming through C++ GUI Programming with Qt 4, I found that it picked up pace and soon left me in the dust with the spreadsheet example. For that reason, I wanted another Qt book as a complement. I also considered getting Foundations of Qt Development, but bought the other book instead because of some good reviews.

If you have your own tips (online resources, books etc.), please share them in the comments section.

Now, the journey has truly begun – in the next step, I’ve hopefully started with the actual programming. See you then!

Introduction

Want to start to develop for KDE? Sure do. But how, and where do I start? Is it even possible for me to do something this complicated? The question are many, but it’s not always easy to find the answers.

I’m just another person who wants to walk the path to “KDE Devland” – but I also want to leave something behind. Footsteps. Footsteps that other hikers can follow if they want, footsteps to show that anyone who’s motivated enough can walk this road.

Summer of Code

There are mainly two purposes of the “Road to KDE Devland” series:

1. To see how much I can learn about KDE development during one summer
2. Document my progress as a motivation for others who want to develop for KDE

To avoid getting off route, I’ve set up a goal to reach within a time frame. I think I’m much more effective this way, and it’s also a great motivation to get you started. Do you know about the “100 pushups in 6 weeks” site? I’ve never liked to “train for the sake of training”, but I gladly accepted this challenge – just because it sounded like fun. 100 is a nice number, and while you know it’s likely to take more than 6 weeks, it still gives a rough idea of how much time you have to put into it.

My goal is to write a KDE application – probably a plasmoid – by the end of summer. It’s going to something very simple, but you have to start somewhere, right?

I’ve already mentioned the time frame: a summer holiday, which is about 2 months. That’s also why I’ve decided to call this “my” Summer of Code project, an obvious rip-off of Google Summer of Code (which I hope to participate in sometime in the future).

Kudos to the Oxygen artists for the icons. And sorry about the pixelate sun, but the svgz file was about to kill my netbook.

Some last words

This isn’t going to be a guide about how to become a KDE developer. There are many roads leading there, and I’m just going to write about the path I walked.

In the same way that you don’t do pushups 24/7 in order to reach the goal of 100 consective pushups, I won’t sit in front of the computer the whole summer. On avarege, I plan to spend a couple of hours a day on this.

Due to some circumstances, I wasn’t able to blog about this until now in the middle of summer. Just remember that the posting dates aren’t in sync with my actual progress.

And lastly, if you’re not interested in programming this isn’t for you. Fortunately, there are a lot of other ways to contribute to KDE! Since I didn’t see BugSquad on that page it gets a special mention.

Next time I’m going to write about which books I’ve equipped myself with, and some online resources I found useful as a starting point.