In the week of November 2nd I travelled to a little village in Italy called Orvieto. The reason for going to this lovely town is two conferences in a row.
The first one is the OpenDocument plugfest. The second is the openOffice.org conference, both of which were new experiences for me.

The ODF plugfest is a meeting where different implementors of a standard come together and come up with user scenarios and test how well they port between the implementations.
So you’ll see a document created in KWord being opened in OpenOffice.org and Microsoft Office and investigations started when the resuls are not as expected.

I did a presentation at the event of the progress made in the Qt (QTextDocumentWriter) and KOffice implementations of ODF and naturally the Maemo Office reader and last mentioned the Nokia sponsored officeshots.org node we are preparing.
The next day I had another presentation where I showed an interoperability issue with right-to-left languages. Several bugs were found in OpenOffice.org and MSOffice and a discussion followed to share the concepts of right-to-left text and (visual) text-alignment. These are tricky things so its important to all have the same ideas on how it should work.

The event had lots of talks, essentially making is clear we are not the only ones doing ODF and showing whats going on in this space. It was interesting to see how far MSOffice has come with ODF, and at the same time how much we need KOffice to become the big second implementor. MS said several times that for optimum interoperability they choose a solution that works better with OOo and not what the specification says it should do. Having a second independent implementation will benefit us all by keeping the standard authoritative, not the most popular implementation.

The event consisted of several interoperability scenarios, essentially manual testing of making a document, saving it in your app and adding it to the wiki. Then loading everyone else’s document and checking whats broken. Followed with an investigation how you can do better. Its a good way to keep the developers focussed so they don’t spent all their time on one feature and being bad overall. KOffice did pretty well here, except for the areas that were already marked as experimental anyway (like change tracking, which is work-in-progress).

Joining the OpenOffice.org conference was making me a bit uneasy, on going there I felt like I’m a spy in the opposite camp. How wrong I could be! The conference was indeed called OpenOffice.org but essentially is a collection of people interested in the open document format as well as the main implementation. There were lots of people from governments and other stakeholders that made clear they were just as interested in KWord as in any other ODF implementation.
This is a stark contrast to the usual events I go to where the majority of participants are volunteers or students. For I went through my business cards quite fast and wished I had brought more.
As usual I get a lot of good energy from these conferences, so many friendly faces, good talks and this being Italy, I had quite good food too

I’m always happy to get a face to a name I’ve been emailing with and nothing works better than a conference in a country where wine is as cheap as water during dinner.

KOffice2 is still a fresh set of office tools. We released the 2.0, called platform release, just 3 months ago and work continues to make the suite more stable and to add the minimum set of features people should be able to expect.

All KOffice community members are continuing to do an awesome job with many bugs being closed and lots of love going into all the applications. This means that the 2.1 release will already be much closer to being ready for the big crowds.
We got a little help now too. Nokia has packaged KOffice for Maemo 5 environment with a new UI for Maemo 5!, This means that KOffice can run in the new Maemo device(N900) . Just to clarify, this is not a commercial product of Maemo but is a contribution by Nokia to Open Source. The developed application will be made available for download in a typical release-early release-often. Bugs will likely exist in this version.

This is exciting news as KOffice will be available to a huge audience and Nokia has been helping to fix bugs and make MS-Office document support more robust.

Nokia has created a document viewer for the Maemo 5 platform (Fremantle) based on KOffice and uses the KWord and KPresenter applications to load and display word processor and presentation documents. The application uses a custom user interface specifically designed to fit in with the Maemo 5 style.

Part of the projects goals is to help KOffice mature its loading and rendering of MSOffice documents.

It is important to point out that all contributions to KOffice have been made directly inside the KOffice subversion repository. The KOffice document viewer for Maemo 5 will be shown for the first time at Maemo Summit in Amsterdam between October the 9th and 11th. This release is a bit unfortunately timed as the official KOffice2.1 release will likely be one or two weeks later making the Fremantle office use the release candidate at first.

I think its very exciting to have the hard work of all the KOffice community members be rewarded by having the document reader be based on our hard work. I’m very thankful to be working on the project and I’m looking forward to continued cooperation between Nokia and the KOffice community.

Its been some months since we released KOffice2.0.0, the first official release for the new platform KOffice2.
For common and certainly for advanced office users we made clear that 2.0 is missing features for them. What then, you may ask, is 2.1 going to change for them?
Well, here is what we are working on and what has been integrated into what will become the 2.1 release in a month or two.

Tables
Releasing a word processor without tables was pretty daring, and for 2.1 we did a lot of work to correct this. As part of the GSoC project we got Elvis Stansvik working on this for the whole summer. As this is part of KWord, I was the mentor and near the end we also got help from Casper Boemann. The end result is that KWord can show a huge set of tables based documents correctly. Its important to point out that this is ongoing work; creating new table cells or modifying the shape and look of a table is currently not possible.

Change Tracking
While editing a text document you can always undo your changes and get back to the way your document looked before. But what if you want to show the actual changes made right inside the current document? Or even better, being able to see what your colleague changed in the document over the weekend. This is what change tracking offers and this has been integrated just last week and it looks like we’ll have most of the expected features available in 2.1 thanks to the work of Pierre Stirnweiss. The most exciting part is that this lays the foundations for projects like collaborative editing.

Improved image handling
This has been detailed in another post already, so I’ll keep it short. For 2.1 the images handling has been made faster and we now are much smarter with memory usage so its possible to have image-heavy documents showing just fine even on memory constrained systems and devices.

Continued improvement in OpenDocument Format (ODF) support
ODF is still a huge specification and during the 2.1 time-frame there have been various teams working on testing and improving KOffice to become both better at writing correct and full ODF as well as reading other applications ODF documents. As ODF is a way to inter-operate between different application suites so its obvious that the way to get better ODF support is to collaborate on this front with others.
KOffice has been working at the front-lines with the industry big names for some time now. A recent example is the plugfest in The Netherlands last summer and the upcoming plugfest in Italy where KOffice is well represented.
An exciting initiative is the officeshots which renders an ODF document in all available office applications and shows the output. KOffice has been working with the OpenDoc Society to provide hardware and software support and make sure KOffice interoperability can be verified by everyone.

KFormula major improvements.
The formula editing component in KOffice has seen many upgrades since the 2.0 release. This means that all KOffice applications can now display and directly edit formulas. The GSoC project by Jeremias Epperlein has seen improvements specifically in rendering the formulas much more pleasing to the eye and the editing of a formula is well integrated into KOffice and quite easy to use.

Windows™
At the tagging of the beta1 all of KOffice compiled without problems on visual studio 2008 which significantly lowers the barrier to developer and end user adoption of KOffice. We are still looking for enthusiastic packagers and naturally developers on this platform to help improve the experience for end users.

MSOffice support
Still quite important for many is the ability to open MSOffice documents correctly and the major painpoints are one by one being addressed. Major things like importing text correctly, importing tables and importing images in presentations have been added for 2.1.

Having a picture in your text document is one of the simplest things you should expect a word processor to do. Having good looking images in your presentations, same thing. You should expect that to just work.
The fun begins when you take a look at that “just works” means. For instance, I can have a 1000 page document with one or more photos on each page. Those photos easilly take some 10Mb in memory if they are meant for printing. So obviously the simple solution of just having QImage objects is out.
Another problem that we see is when a user inserts a photo from his camera into the KPresenter presentation. Then scales it down to only be half the screen width. This means that we’ll effectively be showing the picture at some 15% of its original size. If we want to keep the viewing and moving of things around very nice and snappy, we can’t just scale the image on every repaint, that would be way to slow.

After a couple of weeks of coding we have a quite nice solution in KOffice. I added a KoImageData class which stores the actual image data and is able to dynamically create a scaled down version of that. The actual data we store is in many cases stored in a temporary file on the filesystem and transparently loaded when needed.
This has the directly noticeable effect that if you load a document with loads of images it will be much faster done, and with less memory used. The KOffice applications will no longer parse the image data on load. That will happen later.

My personal usecase is this; I would love to make a collage of loads of pictures of my friends and holidays. And I’d like to do that digitally. Now, when I create a new document in Krita or the Gimp that is full printing resolution of an A4. Then start loading the pictures as layers, it very quickly makes them crash or just get unusably slow.
My ideal solution is that I just start a KWord document where I insert a lot of these images into and I can scale, rotate and move them around very quickly. With hardly any suggestion that I’m manipulating huge amounts of data.
At printing time I’m printing actually to high-resolution images and the resulting PDF can be shown to the printer whom can print it at wanted resolution.
Expect this work work just fine in KOffice2.1

Likely I won’t make my second favorite feature for 2.1, this is to allow me to select an image and monitor it. So if I have an image in my KWord document that is using a file in my homedir called “photo.jpg” I can start my favorite application and change the image to be, for example, more saturated. On saving the image KWord would automatically show the updated image. Should be easy enough to add

This year again a gaggle of geeks went to Akademy from the Qt/Troll office, most of them flew there on Friday in a too-long 14 hour travel trip (office to hotel). For next year we should really choose a location that is easy to reach for the majority of our contributors.
But this is where the complaining stops, I’ve been having a great time. I saw various thought provoking keynotes and spent hours talking to old and new friends.
I loved that the lunch-breaks were long, so you could walk to a new restaurant every day and try out all the great food. I think the worst food I had here was a bit-too-simple spaghetti with only a red sauce. But it still tasted good

This is a conference of geeks and naturally this means lots of talking. And a good percentage of that about computer stuff. I’ve been talking about git migration with various people and noticed I should really get more people to help out perfecting vng.googlecode.com

For instance I opened a discussion point about kDebug() which taught me a lot. So, the assumption I always had was that kDebug (and qDebug() )will completely be gone in end-user versions of my software. Which means that I can add as many debug statements as I want and it will not have any negative result on the size or speed of the final shipped executable.
To my big surprise distros like Suse have always shipped binaries where the debugs were still executed but by default just went to /dev/null
This means that when I added a kDebug() in a loop and printed some QRectF all those floats are still converted to strings only to be discarded and slowing down execution. Which is a sad surprise as my users will see the software being much slower than it could be.
In KDE4.2 this behaviour has been committed to kdelibs as the upstream default, whereas in kde3 only distros patched it. The good think is that it lead to the discussions. The end result is a much better awareness of the issue and how it affects apps. Last I heard was that Andreas is looking into fixing all issues using an updated kdebug macro. \o/

I spent a total of 9 days at Akademy at it was very tiring, but also quite satisfactory. I didn’t blog much as I use identi.ca, follow me there for more details. I still have to go though my notes and todos which I’ll get to in the coming days. This year no KOffice core developers were there so the couple of KOffice-libs discussion points I prepared didn’t get attention.

The internet connection was not great, just too many people for wifi to handle (bug in the protocol?) which had the upside that nobody felt all that guilty just wandering into town or sitting down on the beach with our great green Qt towels discussing code and community. I think that discussing code and technical stuff is only a small part of what makes these conferences successful for a community. The part where you get to know the people you work with in face to face chatter is at least as important. Its just easier to see that name on IRC or in email as a real person if you know his background and hobbies.

Random thoughts;
Its been too long since I walked on flip-flops. My toes got hurt after just one afternoon.
It took me only one day to get used to the colder (~20C) Norwegian weather. Its compatible enough in my mind
Spanair may be part of the SAS group, its not the same quality. Legspace is…painful.
Git seemed to have gotten a lot of support. The people that don’t support it are mostly in the “haven’t actually ran it” camp. (did I mention vng?)
Free software conferences gather the smartest people whom are always up for some fun discussion topics. Even after my bedtime

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