The topic that kept us busy the most was success and failure, after a while we concluded that no one want to speak of failure, so we concentrated on what we consider is going to be our main criteria of success, the top mains one are lot of users and lot of developers. Our first step to get a lot of users will be to make it possible for a lot of users to use it (surprised ?), the good thing is that is indeed something that is progressing release after release. Then we will need a lot of advertisement and documentation. When it comes to developers, we concluded that the main problem is not to attract new ones, but to retain the one we have, and one of the key challenge is going to make sure we keep a good ratio of paid developers / hobbyist developers. A key feature of KOffice is going to be interoperability, and ODF is the way to go. Some ODF features are border lines and are not considered to be essential, but if someone is willing to write an implementation, it might be accepted by KOffice if it is good enough (code quality, maintainability and UI). Also an other way to achieve interoperability is with the implementation of import filters. Then the question of whether KOffice is a desktop application or also for use on mobile devices was raised, but this is a subject that require research on how to make the actual implementation. Suresh mentioned that Nokia would need a roadmap to help with their planning, which also require a vision, but writing a vision require an usability expert and the roadmap would have taken us an other day.

Then we continued with listing the missing features in KOffice, Suresh presented us their current work on mobile use of KOffice. And we finished by a discussion about our website, sadly Alexandra who did a wonderful job on planning our current website is now too busy to work on it, so for now I am going to take care of technical aspect, while Boudewijn writes content (expect a last week in koffice !).

The full minutes are fully available on koffice’s wiki.

For the dinner we went to the slowest restaurant, half an hour for the first drink and to order, an hour to get the food…

And now we enjoy the fresh evening, while blogging, sipping wine, hacking and discussing.

This raise the question of how productive we will be, as you can see below Boudewijn and Thorsten are already at work reviewing a patch on loading and saving text on shape, and we started informal discussions:

Now almost everybody has arrived, and is enjoying the wifi, in the garden. With more discussion, blogging, bug hunting, and listening to the history of castle told by Boudewijn.

Albanie, Arménie, Bénin, Bulgarie, Burkina Faso, Burundi, Cambodge, Cameroun, Cap Vert, Comores, Congo, Côte d’Ivoire, Djibouti, Egypte, Gabon, Ghana, Guinée, Guinée Bissau, Guinée équatoriale, Laos, Liban, Madagascar, Mali, Maroc, Maurice, Moldavie, Niger, RD Congo, République centrafricaine, Roumanie, Rwanda, Sénégal, Tchad, Togo, Tunisie, Vietnam

So if you are an artist using free software, a developer implicated in a graphic open source project, and want to make a presentation (in either French or English) at the Libre Graphics Meeting, or if you know anyone from those countries, and that would fit the requirements, please read this email or give this email from the Create mailing list. This is a great opportunity to travel to Bruxelles, and meet other people of the Free Graphics World:

I have been delaying that release because I wanted to make a video of Braindump in action, and have been too lazy to make one until now. On that video I first create new whiteboards, then I demonstrate how to add shapes, manipulate them, and finally the different layout:

I you look at Braindump development history, you will notice that over the past six months the development has been really slow, there are a few reasons to that, the first one is that most of the development is done by other people than me in the KOffice repository, the second one is that I feel that Braindump is already doing exactly what I want, with a few glitches, but as a geek I tend to live happily with those…

That said there is a couple of features I want:

• Search (and replace)
• Tagging, but then someone else (yeah again) is doing the work for me in KOffice
• Auto-growing text shape
• A solution to this problem: (almost) each time I create a new whiteboard, the first thing I do is to add a text shape. So I wonder about either having always a permanent text shape in the background, or always add a text shape when creating a white board.

I am also starting to be curious about ownCloud, since personally I find it to be the right direction of cloud computing, so I would probably be interested in the possibility of storing whiteboards on an ownCloud server. Lets see how it evolves.

If you have other ideas, do not hesitate to mention them, who knows, if I find them interesting, I might go on and implement them !

Download Braindump 0.8.0, this release will work only with KOffice 2.1.x, from now on I will work on porting Braindump to the upcoming KOffice 2.2.

But this focus of Krita is not new. What is new is our willingness to focus on it.

Boudewijn has always said that he started on Krita to make a linux application that makes the most use of his newly tablet, he even said at LGM 2007 that he wanted Krita to be a “corel paint killer”. More recently Vera joined us in the hope of helping us to make a good open source painting application.

Personally I started with a joint interest for drawing and photography, and probably considered at first that I wanted to contribute to an application that work for both use. And this would explain why most photographic specific features were written by me. But when I started to make digital pictures, I thought that one of the main interest over silver film was the post-processing, but I have come to realise that colour and brightness adjustment were all the changes I wanted to do, and that otherwise, the pictures need to be shout correctly, correct framing, correct positioning of objects, this require more work in the composition, but this also give greater pictures than cloning. Meaning, that I have mostly used Krita for drawing attempts.

But some other members joined us for photographic interest, and some people would still want to use Krita for those uses, I hope that we manage to work together and allow them to find their place in the Krita Community, either the new extensions website will prove sufficient, maybe a krita-photographic-extension package will be made available by distributions, or it is even possible to build a different user interface on top of Krita libraries.

This is something we are ready to help with, but what we feel is important is that when a painter starts Krita, he get all what he needs, and nothing more.

Yesterday we went to Amsterdam to meet the Blender’s guys. Since most of us has never been to Amsterdam before, Boudewijn took us for a long walk in Amsterdam’s street (or should I say canal), which started in the overcrowded area around the central station, that we left as soon as possible to walk in more quieter area:

Then at the end of the walk we arrived at the Blender institute:

Where Ton took us on a visit of the Studio, and then we assisted to their weekly update, where all the members of team show what they have been working on, their difficulties and how to solve them. After the meeting, we went to a restaurant, as an opportunity to know each other, and to learn more on how their work, and in hope that one day Krita can be useful for them.

Tomorrow, I will go back home in Göteborg.

Krita is now focused on being a painting application

We have mentioned in our blogs entry (by me in Krita meeting 2010 – day 1 and by Boudewijn Rempt’s blog) on last week-end Krita meeting, that we had now decided for a vision oriented toward painting.

Where does that leave photography ? Well clearly, it is out. And honestly, between Gimp (especially with their work on 2.8) and Digikam, there is not really much room for an other linux photography application to prosper. Since Krita was always more oriented toward drawing and painting, and photographic features were available mostly because “we can”, and there is no high-end application for drawing and painting on linux, the logical conclusion, for us, was to focus on where we can be the best, and the most useful.

Removing photographic-specific features

The logical conclusion is to remove the features that are not useful for painting. This include many of the photographic plug-ins, like tonemapping, bracketingto-hdr, lens correction, noise reduction filters. As well as a set of artistic filters, but that are mostly useful to transform a picture in something that looks like a painting.

And anyway there are better tool for that job, like the excellent Qtpfsgui, in action below on Deventer’s mill:

I started a discussion on the subject on Krita’s mailing list, which triggered a bit of a uproar. Especially from people who have used Krita for photographic editing. Live with it, use Gimp or Digikam, or install the removed plugins from the future extension website, write your own, just do not count on us for that, we are going to be focused on other features.

An extension website

Since it would sadden me to kill forever some of those plug-ins, and also while we do not want to support photographic features, or features that are of no interest for painting, we also do not want to prevent people to have or use those features, they will simply not be part of the default distribution. We are going to setup a new website where those extensions will be hosted, hopefully with “nightly” build (more like regular build) to keep them buildable, and synchronized with git/hg, where a tag would trigger a new release automatically. In essence a revival of the krita-plugins project.