Philippe Fremy: Can you present yourself? What are you doing when you are not working on free software?

Lauris Kaplinski: I am 32 years old, living in Tartu, Estonia with my wife and 3 children. I am working at a local biotech startup, writing software tools for genotyping and related analysis, mostly Windows programs.

Other than coding I spend my time in the garden (we are living in my grand-grandfather's mansion with large old park), learn Japanese (fell for Japanese pop-culture some years ago, still haven't got over it), read, draw, try to fix our house (it is old and likes to eat whatever money we happen to have). Ah and, of course, 3 children mean that you don't have to bother, how to spend free time (don't have any 'free' time to start with ;-)

Philippe Fremy: What does Sodipodi do? How long have you been developing Sodipodi? Why did you start it?

Lauris Kaplinski: Sodipodi is quite usable as generic vector drawing application and more specifically, as SVG creation tool. It is nothing near in quality or feature set to big commercial programs, but people have used it to design icon themes, posters, business cards and much more. Most expected features are there - basic shapes, bezier paths, gradients, bitmaps, transformations, transparency, grouping and so on. One interesting feature is direct access to the SVG document tree, so users can hand-tune elements if the UI does not support certain feature.

The first ChangeLog entry in Sodipodi was from September 1999, but the project started about a year earlier as an experimental fork of Gill's codebase. Gill was Raph Levien's project trying to build a SVG editor on top of the DOM library. Back then the hopes about DOM were high in the Gnome core team, but there never emerged a usable implementation, so it was abandoned eventually. Sodipodi dropped full-featured DOM support, but kept the basic program logic, that is, a semi-independent XML layer at the bottom of the document tree.

Philippe Fremy: How does Sodipodi integrate with the Gnome Office framework? What Gnome technologies are you using?

Lauris Kaplinski: As far as I know there is currently no serious Gnome Office framework, despite it having been discussed many times. Major Gnome Office components (Gnumeric and Abiword) are mature projects with dedicated (but separate) development teams, and thus not easy to bring under single umbrella (Abiword is written in C++, gnumeric in C, Abiword is cross-platform, gnumeric gnome-only). Also the politics around OpenOffice affected the Gnome Office team 1-2 years ago quite seriously, slowing down overall development.

Sodipodi dropped all mandatory gnome dependencies during migration to Gtk2, mainly to make a Windows port possible. There is still a compile time option to support gnome-print. So currently it is aiming to be a cross-platform, reasonably self-contained application, that integrates with as many environments as possible (and reasonable).

Philippe Fremy: What Desktop Environment are you running? What do you think of the latest versions of KDE and Gnome?

Lauris Kaplinski: Currently I am running KDE 3.1. Before that it was Rox Desktop, before that KDE and Gnome2. I have relatively modest needs in a desktop environment - basically just a decent panel and well-behaving, unobtrusive window manager. Application-wise I am running mostly Konqueror, Evolution, XChat and Emacs.

I think KDE 3.1 is usable (that is why I use it, after all). There are of course areas where lack of polish scratches an eye, and there are still things I cannot configure, but overall it does make working reasonably comfortable :-)

Gnome2 is much harder to judge. It is like MacOSX - one either loves it or hates it, but few are indifferent. For me, like for several other people, Gnome1 was a hacker's desktop (and we loved it), but Gnome2 is a corporate desktop (and we do not feel comfortable with it).

Philippe Fremy: Who are your users? Do you have any enterprise users? Are your users mainly KDE users or Gnome users?

Lauris Kaplinski: Difficult to estimate. I do not know about any enterprise deployment (neither do I think Sodipodi is ready for that). Most feedback has come from hobby artists, coders who need some vector images, teachers using it for students...

The biggest percentage already is, or soon will be, Windows users judging from downloads... Others are really difficult to estimate, but I think Gnome may be somewhere near 2/3 and KDE 1/3.

Philippe Fremy: What was the goal of this KDE integration? How does it work? Did you look at other libraries to achieve that? Was it difficult to do some C++ development? How hard was it to write? Is your work reusable?

Lauris Kaplinski: I am doing C++ development at work and starting to love it, so maybe there will be more C++ parts in Sodipodi in future...

The primary goal was to make Sodipodi to feel as natural as technically reasonable for KDE users. Freedesktop standards and shared themes definitely remove many lower-level differences between look and feel of different application platforms. What still remains (and scratches an eye) are some higher-level things, like printing system - if everything else on the desktop prints through KDE-print Sodipodi shouldn't be the exception - and file dialogs (Gtk+ file dialogs look very foreign under KDE).

If Sodipodi is compiled with KDE support, it creates a KApplication (in addition to initializing Gtk+) and KDEBridge object. The latter implements timeout and guiThreadAwake slots that call the Gtk+ event loop while Sodipodi is spending time inside the Qt/KDE event loop.

If Sodipodi wants to display a KDE dialog (all these are modal currently), it simply calls the relevant static method, like KFileDialog::getOpenFileName, and lets KDEBridge to manage keeping the Gtk+ windows updated. For actual printing it is as easy as writing some glue code to output Sodipodi-generated RGBA stripes to KPrinter.

Writing the KDE bridge was relatively easy (I really admire Qt/KDE reference documentation ;-) Of course, it did take some time to simply get the big picture (MOC, anyone ;-), but overall it was not harder than starting with any other unknown library.

The code is quite usable, as long as printing and file dialogs are everything you need. But it remains a hack, that should be written correctly one day... I'd like to use the real main loop integration, but the only reference I found was QGtkWidget by Bernhard Rosenkraenzer, and this unfortunately was not ported to Gtk+ 2.0.

Philippe Fremy: Isn't it contradictory to develop a Gtk app and integrate it into KDE?

Lauris Kaplinski: I was 'enlightened' by an email from a devoted KDE user about year and a half ago. That guy kept installing Gnome development libraries each time a Sodipodi release came out, only to compile Sodipodi. And at that time Sodipodi depended quite heavily on Gnome libs, so finding correct libraries was not always an easy task.

So I decided to make the program for an as wide as possible audience. Unless there is clear winner in the desktop wars, a similar approach may be the way to go for the foreseeable future. Of course, many things will probably be integrated into a common (freedesktop) layer eventually - but if you want to deploy an application now, and you want to maximize potential usage, instead of using it as a weapon in the desktop wars, you better try to integrate with whatever the user prefers.

To be honest, I got the idea from Qt/Win32, which AFAIK can use Windows native file and print dialogs, if requested. There is also definitely a certain 'because you can' attitude involved - such tricks make programming enjoyable. But I hope to extend KDE layer some day to make it loadable module (so we can distribute single Sodipodi binary) and add KIOSlaves...

Philippe Fremy: If you have a wishlist to make such integration in the future easier, what would it be? What do you think of current KDE/Gnome cooperation?

Lauris Kaplinski: The usability of such multi-desktop integration 'hacks' depends heavily on the general cooperation between the different desktops. Currently there is no choice - if I want to give user access to all KDE printers from Sodipodi, I have to link with KDEPrint myself. But if there emerges some standard for printing on the desktop, this may be the way to go.

My biggest wish is easy main loop integration between Qt and Gtk+. It is probably relatively easy (both are modern cross-platform toolkits), but it needs someone with good knowledge about the internals of both...

KDE Gnome cooperation is definitely nice, but I do not think it is top priority in making Linux viable desktop platform. In my opinion interoperability between different versions of the same toolkit/desktop may become a more serious problem. Applications written for Windows95 still look like relatively good on WindowsXP. Programs written for Gtk1 feel clearly foreign in the latest Gnome (don't know about KDE/Qt).

Philippe Fremy: Anything else you would like to add?

Lauris Kaplinski: Everyone is speaking about Linux on desktop, but sometimes I think, whether this really is, what we want. Are the online communities ready for dealing with massive financial interests in their field of interest? Are we planning to move on to next partisan platform to enjoy pure coding freedom? Anyways, let's keep the train going for now ;-)

[Note from the Editor: You can help the train with a donation!]

<  |  >