KOffice Sprint Oslo 2009 – Day 1

After a short night (for my taste anyway) we had and ok breakfast at around 8 o’clock in the morning at the hotel. After that we gathered together, bought tickets for the public transport and went to the Nokia offices. There we’ve settled in a conference room in the 6th floor where the sales and managing people have their offices. The actual engineers are sitting a floor below where we are not supposed be. But there is enough space here anyway so that is not a problem.

Then we started to have some presenatations and diskussions on various topics like library reorganization, moving to git, a nice presentation from Suresh about Nokias effort to build the office viewer application for the N900 and an also nice presentation from Olivier about library design and source/binary compatibility.

For lunch we had some selfmade sandwiches at the cafeteria, using food bought by Thomas before. Soda and coffee/hot chocolate was also free to take so that was taken care of also. In the cafeteria there is also a table tennis table where some people tested their skills. I also did that and had a very nice game with Inge which is a very capable player table tennis player.

After lunch we had some more disussions/presentations and then some people already started to hack away at their stuff.

In the evening at around 6 o’clock went out for dinner at a nearby pizza shop. We had to wait a couple of minutes though as we were quite a lot of people which did not had place all at once first. But after some short time we got a couple of tables were all people fitted in. We decided to order a couple of huge pizzas. Nokia kindly paid for the food and the non-alocoholic drinks again. Thanks a lot!

After dinner people went back to the office to get their stuff, some people went off to a pub, others were going back to the hotel where a Krita coem together took place.

All in all it was a very densily packed day with lots of information to process and lots of fun too.

KOffice Sprint Oslo 2009 – Day 0

I arrived at the airport at around one o’clock and waited half an hour for Dmitry who arrived only half an hour later. We took the express train to the city and went straight to the hotel. Checked in, dumped our belongings in the hotel room and then we were off to do some sighseeing of Oslo.

Great things is that almost all the sighseeing highlights of the city are in walking distance, so we had seen most of them. Bad things was darkness arrived early so at four o’clock in the afternoon it was almost dark. But then the city was nicely lightened so we did some nice photos. At the city hall there was a small christmas market were we had something hot to drink and eat a german style sausage (“Bratwurst”) which was sold there at a german market stall.

Then we want back to the hotel waiting for Thomas to notify us where to meet for dinner. It turned out to be a chinese restaurant “Taste of China” were we finally met all the other guys and gals attending the sprint at the weekend.

After dinner we planned to go to a pub but then almost all people wanted to go back to the hotel and Thomas and Olivier wanting to go to a concert. So only four people ended up at the pub. I had two beers which costed a fortune, but it was quite ok there anyway.

Later back to the hotel, we met Jos and Jos and Sven Langkamp. The later I share the hotel room with. Up in the hotel room we noticed that there was very loud music palying on the street which made it quite difficult to get to sleep. Fortunately i brought a pair of ear plugs with me, so I got around that.

WTF

Came across this fine MSDN documentation snippet at work:

CFileDialog::OnFileNameOK

Override this function only if you want to provide custom validation of filenames that are entered into a common file dialog box.

virtual BOOL OnFileNameOK( );

Return Value

1 if the filename is not a valid filename; otherwise 0.

Notice the return type, the function name and what value is returned if the filename is invalid.

SVG Filter Effects

While most of the KDE developers enjoyed the sun and the ocean at the GCDS, KOffice people are working hard as always. 🙂 Some monthes ago Cyrille our restless Krita hacker and KOffice release manager posted a patch on reviewboard which implemented a proof of concept for filter effects in flake. Unfortunately it didn’t found the attention it deserved and such got forgotten a little (I blame myself as part of this).
Luckily Cyrille added filter effects support to the feature plan of the upcoming KOffice 2.1 release, so I stumbled upon it again and decided to do something about it. So some days ago we had a nice IRC discussion about how we would tackle the problem and how we would go about implementing it in the flake library. The decision was to have filter effects as plugins which get loaded when a shape with effects gets loaded from a file or a to be written tool for editing effects is activated.
As you might have already guessed from my boring introductory text, we’ve got a first version of a filter effects plugin working. The filter effect that was choosen to be implemented is the blur effect, because it is possible the effect most used by artists.
First step was to produce a simple svg document with a blurred shape (used Inkscape for this) and to implement the stuff needed to load the filter effect and attach is to a flake shape. The seocnd step was to actually implement the filter itself and the painting of the filtered shape. The third step was to implement a tool which can add a filter effect to a shape, remove a filter effect from a shape and as well as change properties of a filter effect attached to a shape.
A filter effect plugin does provide a corresponding configuration widget which is shown inside the tools docker widget and can be used to edit the filter effect properties (see bottom right of the screenshot below). Thus the filter effects tool only has to know about the common properties of the filter effects, the custom properies are all handled via the plugin provided configuration widget.
As a reward for those reading all the way down to this paragraph I show you an actual screenshot of Karbon with blurred shapes.

What is missing still is the code to save filter effects back to svg. Also polishing of the filter effects code is still to be done. But at least it is a nice start which already produces some nice results.

Another Arch User

Seems like it is in that people are comming out as being an ArchLinux user. So I might as well do that too. Since some months I have arch installed on my laptop and I am quite happy so far. I even have submitted some packages to AUR (the ArchLinux User Repository) which is dead easy.
My first two packages were spacenavd and libspnav which I needed to maintain the spacenavigator device support for KOffice (see corresponding blog post).
My last arch package I submitted was the libwpg package which is needed to compile the Word Perfect Graphics (wpg) import filter for Karbon. This filter was implemented by Ariya Hidayat in a GSoC projects some time ago. What triggered me to create the package now was that I fixed compilation of the filter and a bug causing the filter not to produce valid xml files. Now it works nice again:

WPG file opened in Karbon

Doing the wpg package finally triggered my motivation to update the spacenavigator packages, as there were new versions available on sourceforge.
Now the spacenavigator plugin does also work with the new xorg-server I installed recently with a system upgrade. One thing to note is that I needed a hal fdi file so that the xorg-server does ignore the spacenavigator device when plugged in.

Krushing bugs

Just to have some other topic than the wonderfull KDE 4.2 release, I am posting some notes about the recent KOffice Krush Day this last Sunday. I certainly had some fun working with the awesome KDE bugsquad. They definetely know their work.

And while they found bugs and glitches, I started fixing them as they rolled in. As of now, the most things reported for Karbon on the techbase page are fixed or at least have some related commits. It always feels good, striking out items from a todo list.

Managing guide lines

Some Planet KDE readers have probably noticed some KOffice soft-freeze anouncing blog entries (1, 2). I want to jump on the bandwagon and write about a feature from the feature plan I just finished today.
It started already some days ago when I brought back dragging guide lines from rulers to the current open document of a KOffice application. As that was done in KOffice shared libraries all applications benefit from that after adding a few lines enabling it. The next thing I did was adding support for snapping to these guides lines when e.g. moving objects on the canvas. This was relatively easy as I only had to add a new snapping strategy to the existing snapping framework in the flake library.
As dragging guides lines to the canvas and snapping to them is only a nice start but not the whole thing, I worked the last 2 days to further improve the guide line support. So I implemented a guide line tool which is activated when the user double clicks on a guide line just dragged to the canvas. The tool helps in easily selecting single guide lines, moving them around, adding new lines, deleting existing ones and specifying exact guide line positions by using an input field. This makes it really a joy to manage guide lines in an interactive manner. And the best is that all KOffice applications are supported for free. I love code sharing!
And for those readers asking themselves what the hell I am talking about here is a short screencast demonstrating some of the things i just explained.

SpaceNavigator support in KOffice

Some time ago 3DConnexion donated 3 SpaceNavigator devices to the KOffice project. Some days later i got one of these cool little devices. That made me responsible to do something with it regarding integration into KOffice.
First thing was to make the device working under linux. There are two options to achieve that:

1. The original driver from 3DConnexion.
2. An free alternative called spacenav.

I didn’t bother trying the first one but just installed the second one which worked without a hassle and is additionally compatible with the manufacturers software.
Hans Bakker who originally kicked off the whole thing had already flying some code around which i used for inspiration. After looking at Hans’ code and at the sample applications provided by the spacenav project it appeared that the device has 6 degrees of freedom: x,y,z position and rotation around x,y and z-axis. Additionally 2 buttons which trigger press and release events.
So now i got to the question on how to best intergrate it into the existing KOffice libraries (mainly Flake). We already have a pointer event class for handling mouse and tablet events. But these are standard input devices with well supported by X11 and Qt so we actually get input events from the event loop. The goal was to keep the device specific code neatly concentrated in a single place without scattering it all over the place. And as i am mostly a lazy person, i wanted to support the device without rewriting large parts of existing code.
Thomas Zander had the idea to extend the existing pointer event class in Flake to have some more properties needed to support the device and then sending this event forward like these generated from mouse or tablet events.
To accomplish the first goal i created a new type of Flake plugin: device plugins. The spacenavigator plugin is the first of these plugins that can bring support for various non-standard input devices. The plugin simply polls the spacenavd device deamon for device events. These get translated into pointer events which then get send to the currently active tool. This makes it easy to keep all the device specific code in a single place.
The tool then can use the event to do certain actions dependent on the tools purpose and context. The pointer event has a notion of getting accepted or ignored by the tool it is send to. So when the tool does not do anything with the event, it (the event) gets ignored otherwise accepted. That makes it possible to accomplish something what Hans and me discussed on IRC: having some standard actions done when the active tool is not using the event. We agreed that the standard actions are panning and zooming the whole document.
So after sending the event to the active tool and noticing that it was not used the event is then used to navigate the document by panning and zooming, dependent on the reported device positions. That means by pressing the device to left, right, up, down the document gets panned accordingly. Pulling or pushing zooms the document.
But there is more than navigating to use the device for. So last Saturday i sat down and implemented support for the spacenavigator handling in the default Flake tool. The default tool does selecting and transforming (moving,rotating, shearing and resizing) of flake shapes. After extending the tool it is now possible to move selected shapes similar to the panning of the document, rotating the selected shapes by twisting the device or resizing the selected shapes by pulling and pushing the device.
This worked out quite nice and it is really fun playing with the device and navigate through the document or manipulate shapes with it. It is really intuitive to use as you use the device like having a real object in your hand. So thanks again for 3DConnexion to send us these device to play with!

Karbon on Windows

Maybe you have read the posts of this guy about KOffice applications running on Windows, but wondered why Karbon wasn’t mentioned. Well he asked me to blog about it on my own. So now you know, Karbon is also running on Windows now due to SaroEngels efforts in the last days. And i even have a screenshot which i got mailed to prove it:

So it seems that KOffice 2.0 once released will also run (albeit probably not perfectly) on the other operating system too. I think that would have a positive effect on adoption of KOffice as a serious office suite.

Simple Text Shape

In flake there already is a text shape using the kotext library for displaying all sort of text boxes. But as Karbon is a vector drawing application there are some special needs which are rightly not implemented in the default text shape. One of these special cases is text on path support, i.e. having a text line flowing along a given path. So I recently started to implement a new simple flake text shape which renders the character outlines using QPainterPath. Having the single chars as path objects makes it pretty easy to move and rotate them around so that they can follow arbitrary curves as their baseline. And i must say with the path classes from Qt4 that is amazingly simple.
Additionally having the path based text makes it automatically possible to define the stroke (outline) and the fill with the default stroke and fill tools. So you can have dashed outlines and gradient fill in your text for example.
Below is a screenshot showing the path based text shape in action. The basic features already work quite nice. But it is still somewhat slow as there is some infrastructure work still required within flake. That is needed so that the text is automatically updated if the attached path it flows on is changed.