Userbase is the wiki for application user information. It fills in a vital gap of information between traditional documentation and the usually too technical developer chatter. For at least KOffice it’s still in need of help, though. We want more tutorials for starters.
People like Anne Wilson have put a tremendous amount of work into userbase and I’m especially happy with the work on KWord she did. Userbase is for and by users, though. So we need help.

Tutorials are in my experience the best way to get a new user starting with the application, get them over the initial threshhold if you may. Its also the easiest way to teach that new useful feature you like to others that may want to use it too. Spread the joy kind of way.
With the Release Candidate of KOffice2.0 out I want to call users everywhere to install the packages from their distro and play around with it. When they find something that they think is a “gotcha”, write about it. Put up some screenshots and write a tutorial on userbase. You can then put them up on userbase.kde.org/KWord under the “Hints, Tips and Tutorials” part.

While its installing, or while your distro is working to get those RC packages to you we still need volunteers that can move and clean up tutorials that have been posted to blogs previously, before userbase became to be. Lets move all the content to one place and make it more useful for all. I put up a list of blogs I found here; Krita Talk

For people that are already quite accomplished in using software it sometimes is hard to come up with ideas on what would be a good tutorial subject. Since if you figure it out, it’s easy to forget how it took you some time to figure out how to do it. We need tutorials for very basic tasks, the kind that users have met and used in other packages, but also tutorials for introducing new ideas and now tools. I always enjoy reading the blog of Solveig Haugland who does write a lot of tutorials for OOo. As she is an experienced writer it would probably be good inspiration, both for content and level.

For an application suite like KOffice having good user support is pretty important. Having great user docs, tutorials etc all together on one place is in my opinion the way to go. For us its clear that userbase.kde.org is the place so all we need now is the more active of users to help us make it happen. For discussions on the topic you might want to go to the forums where developers and users hang out.

In recent years the graphics capabilities of desktops and handhelds have been growing more rapidly than their central processors. This is a revolution that is being accelerated by animating user interfaces. This in turn is based on the fact that you can make more usable and more attractive user interfaces using animations.
Qt has been steadily working on solutions that allow more dynamic user interfaces and animations for core features to actually use this available graphics power. Providing support via a framework like Qt sets a baseline and thus allows developers to create usable apps faster.
In Qt this all started with QGraphicsView and we are seeing a coherent vision progress steadily. And now its time for itemviews to be looked at
Itemviews is the collective name for the widgets that show lists, tables and trees. Qt4 has a solution for these widgets already, which works fine for a large set of usecases. There are also usecases where they lack somewhat. Dynamic and fluid user interfaces are a major part of that.
We have started a research project to address all these shortcomings and provide a solution that makes it easier and faster to make beautiful and usable lists, tables and trees. In this blog I want to give an overview of what we have done and what our plans are going forward. Additionally we have put our research project online for everyone to download and play with.

Who is it for?

At this time of development we focussed on great design, good APIs and making easy the common usecases and possible the complex ones. For this reason there will be missing concepts, broken features and in general things may just fall apart. You have been warned
Who we are looking for are developers that want to kick the tires or our new baby, especially useful are developers that have specific usecases in mind of lists and tables that are a challenge to do in the Qt Itemviews. Having running examples build on top of the ItemViewsNG will help us a lot going forward and it will shape the direction we are going.
The actual repository where we work will be public and so people can just follow our progress as we go but we also encourage developers to contribute their patches back to our main repo.

Design

For the next generation of item views, we choose to use QGraphicsView concepts. The obvious advantage is reuse of concepts and features. If you look at the simple list example the individual list items (each row of text, really) is an individual graphics item (QGraphicsWidget, specifically). GraphicsView has various features that are very useful for us. It is very cheap graphics wise to move around the individual items, for example. This allows animations of individual items to use hardware acceleration automatically. GraphicsView also gives us features like being able to click on an item and that item having code to handle it so you can just use the existing concepts and code for making your individual items be drawn and behave the way you want. For old-graphicsview coders; this mirrors the concept of delegates in many ways.

All this talking about graphicsview may raise the question on how to integrate this with traditional user interfaces with QWidgets. A good question, and we created specific widgets for each of the 3 types of item views with proper defaults and simple to use APIs. These are the QtListWidgetNG, the QtTableWidgetNG and the QtTreeWidgetNG. These widgets come with several replaceable components that make it easy to change the look or the interaction separately and so mix and match to your liking.

Let me focus on the QtListWidgetNG here; behind the widget are various classes worth mentioning;

• The QtGraphicsListView allows customizers to decide how to show the individual list items. The default class uses separate graphics view items which has the advantage that we can cheaply animate them.
• The view decides which items to show by asking the QtListModelInterface. As the name states that is just an interface and thus has no implementation. We provide a simple implementation as the QtListDefaultModel.
• All the communication goes via the QtListController class. This includes things like handling keyboard and mouse input received by the QtListWidgetNG but also things like when the active item in the list is changed for some reason then the scrollbar moves to the correct position.

In the ItemViewNG repository today you will find several implementations of at least the listview which allows for an easy way to customize your list.
Here are some usages;

// Simples case; show a complete list
QtListWidgetNG widget1;
widget1.defaultModel()->appendItem(new QtListDefaultItem("Simple!"));
widget1.show();

// Use an alternative view that shows the items as
// icons in a flow and we also use a custom model here.
QtListWidgetNG widget2;
QtListController *controller = widget2.controller();
// custom model comes from the iconFlow example.
controller->setModel(new IconsModel(controller));
controller->setView(new QtGraphicsFlowView());
widget2.resize(QSize(240, 200));
widget2.show();

I started this blog stating that we created the new itemviews based on the idea that we needed pretty user interfaces, and here I am pasting code and showing really boring and standard widgets So lets show a bit more action; I made a screencast of the photoAlbum example that we made on top of the itemviews.

The demo (source-file) really shows a list of images quite similar to the boring list screenshot above, only instead of using the default QGraphicsListView we use a tweaked one to show the items vertically and almost full screen.
Next to that we changed the controller to a QtKineticController which provides the scrolling and flicklist behavior.

Where is it again?

On gitweb/labs.
You’ll appreciate the API docs too. Both are very clearly unfinished as this is research-in-progress!
Compilation requires Qt4.5 (works fine) or the kinetic branch (for some extra functionality, like the photo album).

Lets see who makes the coolest usage example list based on this

Last week the KOffice development hit a rather nice milestone; we reached a ReleaseCandidate. As usual this means we create a branch for the KOffice2.0 releases and we open up ‘trunk’ to new features.

With this branch point the 2.0 line of releases is naturally not going to stop being maintained so any fixes we make on trunk should be considered to be also committed on the 2.0 branch. And thats where it gets a bit sticky.
About half the KOffice developers have been using git-svn for some time now and at least I would rather like to continue using git and thus have the powerful git features available for moving patches between trunk and the 2.0 branch. The part that is sticky is that the mapping between git and svn is, and can not be, one to one. And the script does have some features for such situations but they don’t really work on an svn repo of KDEs format and size. Or, in short, you need to have a bit more git knowledge to set it up for our usage.

Goal; I want to have the ability to have 2 svn branches that I can update and commit to. I further want to be able to use git to move patches between them.
Solution; make a second git-svn checkout and use git remotes to let one know about the other.

#I assume you have a ‘koffice’ git-svn tree here already with the trunk version. To avoid any confusion lets rename it;
mv koffice koffice21
#Make a new checkout of the new branch;
git svn clone $KDESVN/branches/koffice/2.0/koffice -r 947933
# Again avoid confusion and make version explicit;
mv koffice koffice20
cd koffice20
#we create a remote
git remote add -f trunk ../koffice21

And thats it; now we can go into koffice20 and do things like
git svn rebase #sync with upstream svn
git fetch trunk #make visible new koffice21 commits
git log trunk/master
git cherry-pick trunk/master #get that commit from 2.1 and put it on 2.0
git svn dcommit

Naturally the normal git-svn-rebase and friends are still available on the koffice21 directory just like before it was renamed.

So I had to do some writing today and I thought, lets use KWord 2.0-Release Candidate for that. Eating your own dogfood and all that.
After a day of using the application in its default setup I am kind of pleased with it. Its obviously not an application that is going to replace any concurrence in its current state (the 2.0 release is aimed at integrators and basic users) but the actual typing of text and the usage of the basic features is good. I can write my docs in there.

That said, I had 2 crashes over the whole (10 hour) working day, both fixed in the RC, I fixed some loading/saving issues as well. And my todo list got quite a bit longer

Overall I think that the upcoming KWord2-release candidate is an enormous step forward from the latest beta. A speed of innovation and bug-crushing that I hope to see continue till the actual release (when its ready!). For people that can live without various features we had to omit in the 2.0 release I think the upcoming release will be a very cool basis platform for productivity applications.

ps. Yes, KWord will actually fully save and load the text, shapes etc that you can add in the app, in the upcoming Release Candidate. Finally! I know some of you have been asking about that

Quite some time ago, 3 summers some may count, the plan and work started on what was to become KOffice2.
We are reaching our first major milestone which is the 2.0 release. Minimal application functionality and lots of useful new technology, but most importantly lots of ability to extend and enhance the apps without having to work on the core libraries or applications.

The release of 2.0 will appeal mostly to users that want to play with the new concepts and the power of flake. ODF interoperability is a major drive, and will continue to be. At the cost of some user-level features. So apologies to those that enjoy mail merge. Thats postponed to a later version.
The upcoming 2.0 release will also be a technology breading ground. Combining the power of the Qt libraries with the power of Office applications has been our major goal from the beginning.

I expect that the 2.0 release is out or in its final phase when the Summer of Code of 2009 starts. This gives those students that want to apply a great many creative things to choose from, I bet most are so new or different that people have not really considered them.
So here is a list of things I came up with over the last years;

• use qtwebkit to write a KOffice plugin that allows you to navigate openClipArt.org and download your clipart. It would naturally insert the clipart directly into your KOffice document.
• Write text-shape plugins
  Just to give you some direction of what this implies, here are two examples;
  • A plugin that recognizes (media)wiki type markup and replaces it with KWord style markup.
  • Colorization plugin. For those that publish pieces with sourcecode, being able to colorize text is a really useful tool.
• We have a music shape that was started in a previous Summer of code, but its not nearly reached its full potential.
• The 2.0 release of KOffice lacks the formula component while the 1.x version had a pretty good one. We need to have someone create a formula flake-shape.
• Create a flake-shape that downloads a vector based map from OpenStreetMap. The selection of the area can be done via marble or via qtwebkit and after downloading the flake shape should be able to paint the contents on screen allowing users to easilly insert a map into their KOffice documents.
• Create various borders that can be added to any KoShape. There is a border plugin type that allows you to create any sort of border. No longer just silly lined borders.

On the topic of KOffice2.0 and its upcoming release; userbase.kde.org will be used more as a place to put information that the end user will find attractive. The first step has been the import of the KWord manual into http://userbase.kde.org/KWord/Manual . Big hand goes to Anne Wilson who has put a lot of time into that. As this manual is old we should get some interested people together to update the manual to the current version.

Anyone interested in any of the above things; please contact the koffice team at the mailinglist or on irc.freenode.org on #koffice

If you read any KDE news you will have heard that there was a KDE conference last week in the Americas called Camp KDE. The yearly KDE conference in Europe has sparked interest on the other side of the ocean. With a growing community all over the Americas the idea for having a local conference makes a lot of sense. At QtSoftware we naturally like this, and so we made sure several Trolls traveled to the Caribbean and joined in on the fun.

I talked about locations of Akademy (the European KDE conference) on various occasions. One suggestion we had was to do it way up in Sweden when there was expected to be 2 meters of snow and temperatures that would keep even the most adventurous geek inside. The idea here, naturally, is that with such conditions you will do more actual coding and hacking and less wasting of time on other things.
I’m so happy this never happened since I see that the opposite is even more productive. Geeks going to Jamaica, with sun, beach and parties, are still just geeks. I don’t think I’ve seen any geek spent a long time sunbathing. After not very long of relaxing on the beach, swimming in the ocean geekyness returned. We had BOFs while swimming, programming on the beach and lots of discussions about Qt / KDE coding.

In the end we actually did quite some work; you can find lots of pictures of people leaning over laptops on flickr and Alexandra Leisse who is also with both KDE and QtSoftware had the presence of mind to bring a video-camera. Have fun watching geeks on the beach here

first the good news; for the first time in years KWord is no longer in the top-20 of open bugs!

Over the last month I’ve picked up KWord again and started digging into the code. Lots of love was needed and I ended up writing a ton of unit tests to make it much easier to find regressions when something changes either in KWord itself or in parts it depends on.

Directly after this I started doing a big bug-triage of kword and found that my bugfixing spree allowed me to close about 40 bugs. Whee! I’m very happy to see that the last of the crasher bugs are going down quick and I have high hopes that with the upcoming beta I closed all the known crashers. Ready for new ones to be reported

I sometimes get questions about who KOffice2 is for and if users should take this release seriously.

KOffice2.0 is meant mostly as a base for the platform and while end users will certainly be able to play with it, I doubt it will be a replacement for their day-to-day tasks.
To be more specific here an example; KWord is not going to have some of the features the previous version had; this is mostly about functionality that I think we will start re-adding as plugins. KWord and KOffice as a whole has an extensive plugin structure and just for the text-editing part (shared between all koffice apps) we have several types of plugins. Autocorrect, spell-checking and variables are all plugins in KOffice2.
So the idea is to put less effort into the plugins for the 2.0 release and put all the effort into making the core stable and more complete. The plugins will then be something even people outside of the standard KOffice team can pick up and tweak. And, this is the fun part, they can ship a version of the plugins separately from a KOffice release.

Another group of people the upcoming KOffice2.0 release is going to be very interesting for is for integrators; the companies and communities that make a product for their specific audience. Distros are integrators, but not the most interesting ones. There is a growing business where open source products are customized for a paying customer to do exactly what that customer needs. Using open source is much cheaper and we hope that KOffice will prove to be a very useful platform for such integrators. Distros with specific needs, like SkoleLinux, will probably like KOffice as well and I have had some fruitful talks with members of that community.

Please do find the latest beta (new one every month!) and play around with it. And do report bugs and other issues you may find.

Final score is that I went from 300 open bugs a month ago to some 150 open bugs today.

I’ve been in computers too long, whenever someone talks to me about error codes I think about the very old MacOs releases, or even longer ago the Amiga crash codes.
But I’m afraid you see them still, a dialog giving a very helpful “sorry, error 1234 happened”.

Now, anyone that is a coder knows how difficult it is to handle each and every error with a properly written error message. Preferrably one that actually makes sense to the user. And realistically speaking this tends not to happen. But before now the effect was typically to have useless messages like the above, or use some hacks that might get out of date on refactorings.
If you look at Qt there are several classes that have an error state; QNetworkReply is one of them. This error state is an enum and in C++ enums really are just integers.
In Qt we allow an enum to be more than just a set of integers using the Q_ENUMS macro. The direct benefit for you is that you can use introspection (/reflection) to get the string value of an enum.

So, no more excuses for just printing an integer error message, you can at least print the more readable enum value. Which means that technical people that don’t have the API docs for Qt handy can still figure out what went wrong.

Here is the code to do this;

QNetworkReply::NetworkError error;
error = fetchStuff();
if (error != QNetworkReply::NoError) {
    QString errorValue;
    QMetaObject meta = QNetworkReply::staticMetaObject;
    for (int i=0; i < meta.enumeratorCount(); ++i) {
        QMetaEnum m = meta.enumerator(i);
        if (m.name() == QLatin1String("NetworkError")) {
            errorValue = QLatin1String(m.valueToKey(error));
            break;
        }
    }
    QMessageBox box(QMessageBox::Information, "Failed to fetch",
                "Fetching stuff failed with error '%1`").arg(errorValue),
                QMessageBox::Ok);
    box.exec();
    return 1;
}

In Qt every class that has the Q_OBJECT macro will automatically have a static member “staticMetaObject” of the type QMetaObject. You can then find all sorts of cool things like the properties, signals, slots and indeed enums.

Happy hacking

Today I was reminded of this great TV show that ran when I grew up; it was Hannibal saying “I love it when a plan comes together”.

In this show you often saw the various people on the team do completely separate and often just weird things and in the end you saw how the result could be combined to be a really cool thing. I felt a bit like that today because today Marijn blogged about a big milestone. He managed to get various applications from KOffice running natively on the Nokia n810, a Maemo device.

And this has been a team effort, for sure. The fact that you can use the exact same sourcecode to now run this office suite without code changes on Windows, Macintosh, Solaris, Linux and indeed an embedded device like the Maemo is because there has been an amazing framework we can depend on. Almost all of it available open source. As KOffice itself is as well.
Just for getting a mental picture here, we are talking about having the Linux Kernel, the window system, Qt naturally, KDELibs and last KOffice.

So today I would like to say Thank You to the people that regularly compile and fix issues on all of these platforms. This goes to the people working on Qt but much more really to the people doing the same for KDE and KOffice. You Rock!

For the last 5 years a huge focus of my work has been on fonts and text. You know you went to far when you can tell the difference between a Helvetica and an Arial by just looking at the printed ‘a’.
Its unsurprising that people end up asking me what the difference is between leading and linespacing, why the customer claims we don’t do kerning for that specific font, why WYSIWYG actually fails for most people. I naturally can’t be because I’m the only one stupid enough to claim to know this, right?
I considered claiming ignorance, but then my weird behavior may no longer have any reason, so that would just make me a worse freak. Instead I just wrote an application that shows everyone how text works. And I’ll write a blog or two about what you can see on screen and how that relates to your questions even before you have them. Genius or what?
So, here is an example text;

let me quickly go over the different parts. In red we have the outline, this is the total amount of space that the text takes. This is what is reserved in your user interface for the text. The sizes you see on the right hand side are the major anatomical dividers of a font face. Much like your body has a head and legs (I’m making assumptions about that, work with me). The baseline is the only one that is really interesting to point out. it’s the zero-point for a font. All measurements start from there. So you have a part that’s above and a part that’s below the baseline. I’ll leave it to your imagination to mirror that to your own anatomy.
In blue we have the size taken by the individual characters. But when we are talking about fonts we actually should be talking about glyphs. There are subtle differences, but I won’t bore you with that. Each glyph has its own rectangle as you can see in the blue. This is useful to see since the m is wider than the j, which is useful to know since you position the characters next to each other. The blue little gradients are helpers (called bearings) to position the glyphs better so they visually look more pleasing.

Ok, with the basics behind you here are a bit more interesting things; consider the two following screenshots.

The only difference is that kerning is turned on for the first and turned off for the second. Notice how the blue boxes overlap in the first image and how they are simply placed side by side in the second.
In general you want kerning to be turned on, its on by default in Qt because it increases readability.

Last example; this one is tricky.

Fonts are designed in a way that they can be scaled and reused for any size. Which is a pretty neat idea since it avoids using a crystal ball to figure out which sizes to ship your font in. There is a little problem, though. A font that is printed on paper at 10cm per character needs a lot of detail but if you use the same character at on screen at just a couple of millimeters height, you have problems to make that one look good.
So, font makers ship something called ‘hints’. Which make their fonts look better at smaller sizes then the computer could do automatically. This is enabled per default and is practically speaking exactly what you want.
Except for one problem; if you add all those little adjustments they can add up. So much that if you have a sentence you can have a word that fits just fine when you show the font on screen, but if you then take the same width and same text but on paper, those little adjustments may just move a word to the next line.
In other words; hinting gets in the way of what you see is what you get text-layout. So, in Qt you can turn this off. Allowing you to get the exact same line-breakings on screen as you get on paper.
Look at the following two screenshots. You will see a little spacing between the little blue squares in the one where the hinting is turned off. We call this mode ‘designer metrics’.
if you want to play around with this stuff yourself, here you can find the sources;

svn checkout svn://labs.trolltech.com/svn/graphics/fontAnatomy

For the people that are still here, thanks for sharing the pain! And I’ll answer the question of “why should I care!”. The concepts shown in this blog have good support in Qt4. The point to take home is that the font is the one that specifies all the information. If the font doesn’t have kerning, game over. If the font has horrible sizing information, you are out of luck. With this little tool at least you can see the differences that different fonts make.