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.

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.

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

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.

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.

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!

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.

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.

Long time no update on Karbon development. But i have a new dose for all of you waiting desperately for news. It all started with a dicsussion on IRC in #koffice. A guy named “frob” asked about the state of the wmf import in karbon because he wanted to compare the support of the wmf format in some open source applications. Karbon in the stable Koffice series has not changed much, if at all, so i told him there is no improvement. And the filters in development branch are all disabled from compilation.
So i thought i should start to do something about the filter status is trunk and began porting some import and export filters for Karbon.
Lucky as i am, the wmf import filter is a rather simple one, good to start the porting effort. It worked out rather easy porting the actual filter, after i digged through the details of the Koffice filter framework.
Some days later i got the wmf import and export, the png export and today the svg export filters working. Now i can use Karbon to work with other file formats than Odf, which is now the default file format. Here are some obligatory screenshots proving my work on the file filters:

Today was one of these occasions where i see someone on the street and think by myself: you know that person from somewhere. But often enough i do not remember at which place or event that was. That makes me trying for some hours or even days to find out who that person is. Normally i won’t remember and forget about that as i do not get to see that person again.
But it was different today as i saw that particular person twice some days before on my way to/from work. So to make a long story short, it was our very own KDE hacker Daniel Molkentin.
Some days before i actually had an idea and looked at the web for a picture of him and immediately recognized his face. So today i just approached him at the bus stop and we chatted a little. Then later at work he invited me by mail to have lunch together with the Berlin Trolltech crew at the nearby university cafeteria. The lunch was nice and the trolls asked if i wanted to see their office. I happily accepted and at the office i got to meet the one and only Matthias Ettrich. Yes that one!
We chatted a little and then played with their soccer table for some minutes. I have to say that Daniel and all the trolls where really nice and i completely forgot the time while there. All in all it was a very enjoyable get-together and i plan to meet them again (and improve my table soccer skills ).