Archive for February, 2010


Krita Meeting 2010 – Day 1

Today was the first real day of the Meeting, we met again in the basement of the Church to be in a place without any possible distraction, and to discuss the vision of Krita, and what we want Krita to be.

We decided to focus on painting, sketching, comic books and texturing. As well as making an application for high-end painters. The question of how much the digital painting should mimick real-world painting, and based on our experience of watercolor in 1.6 that was so advanced that it would simulate the drying itself, we decided that real world should be an inspiration, but that there is no point to make digital painting exactly like real world, if you want real world, you can just take a real brush and paint. But it does not mean that we should take inspiration in real physics, when it makes sense, like for color mixing.

In the end, it took us more than two hours to define the following vision:


Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.

Fields of painting that Krita explicitly supports are concept art, creation of comics and textures for rendering.

Modelled on existing real-world painting materials and workflows, Krita supports creative working by getting out of the way and with snappy response.

It does not mean you cannot use Krita for something else, or develop plug-ins that solve a problem that does not fit the vision. But it means that we are going to be focused on implementing that vision, and that the default of the application will be oriented toward that vision. And when we have to make choices, we will look at the vision and see which decision makes more sense for the vision.

After the lunch, we took a digestive walk in Deventer streets:

Then we discussed about finding GSoC ideas, that would help to implement our vision, and concluded that a new transform tool and a good UI to access ressources was the two main ideas we needed. Then everybody went back to his computer, to fix bugs, to discuss UI ideas, and just to make Krita “the best application ever” (Vera’s tm).

Abstract Flame

Krita Meeting 2010 – Day -1

Today right after breakfast with Lukas and Boudewijn and one of his daughter, we got an electricity cut. So when Dmitry arrived from his hotel, despite heavy rain, we decided to go out for a walk in the city, to discover the charm of the city under rain:

Boudewijn explained us about the past of the city, and also which building was going to be demolished, and what nice house has been replaced by an ugly one. We walked a long many nice streets like this one:

Below is a church that was build by the city inhabitant that were denied access to the cathedral, now it is used as a concert hall:

Then we arrived at the market place, where a krita developer took a picture of a krita developer taking a picture of an other krita developer:

Upon our return to Boudewijn’s house the electricity was not back, but Vera had arrived, so we headed to the nearby Church basement which had electricity but no Internet connection. I first tried to work on making OpenGTL’s API nicer to use, while Lukas worked on importing ABR brush from recent photoshop version with the help of Vera, Dmitry worked on layer stack recomposition, while Boudewijn tried to fix a thread bug that seems to only happen on Vera’s computer.

Now electricity is back in the house, Peter and Sven have arrived, and we are finally connected again, and are planning to go in a pizza restaurant in the evening. And now Adam has arrived too. So we are all there now.

Krita Meeting 2010 – Day -2

After being blocked for three hours at Göteborg’s airport due to bad weather condition with heavy snow fall. I was genuinely impressed by KLM paying us a meal and give us a reduction for the next ticket, which covers almost a quarter of the price of my ticket, while they clearly weren’t at fault on the delay. After we managed to take-off, the remainder of the travel went smoothly. After arriving in Deventer, a cute little town east of Amsterdam, I tried to make good use of N810’s GPS to find my way to Boudewijn’s house, but never got a fixed and had to rely on my orientation sense. Now we are waiting for the arrival of Dmitry and Lukas.

When an exception is thrown and not catched in a Qt application, it get catched by Qt’s event loop, and the following message is displayed in the console:

Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc

In other situations, std::bad_alloc is replaced by the name of the exception. The problem is that if you now want to know where it happens in your program, the backtrace points to where the exception is rethrown by Qt’s event loop, which is not where the error happens.

I first had this problem a few days ago when implementing multi-layers support in EXR, since the exception name was specific to OpenEXR, I just grepped the code and deduce where the error occurred. But this is not very convenient when the error is generic, like std::bad_alloc which can be thrown just anywhere. And as it turned out by Qt itself in ‘qBadAlloc()’. The solution suggested by Maelcum on IRC is simply to set a breakpoint in the function __cxa_throw, which is a function of the C++ standard library that is actually doing the job when the keyword throw is used (at least with the GNU stdlib++, no idea if it is valid with other standard library implementation). And then you get a backtrace that point to the problem.

I thought I would share this tip in case, in some day, you find yourself with an uncaught exception in a Qt application.

Powered by WordPress. Theme: MyMotion by Cyrille Berger as a modification of Motion by 85ideas.