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.