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.
For the next releases of Krita, we decided to pick up a specific artist, with a specific work flow, and to implement and fix the issue that he needs. For 2.2 (and probably 2.3), we have chosen David Revoy who has come recently to fame for his involvement in the durian project of the Blender project. Since he lives in Toulouse, and since I still live in Toulouse for the next two weeks, we felt it was a good opportunity to met and to talk about what is Krita, and to get a feel of what he needs.
On Tuesday, after work, I went to his apartment. First he showed me a bit what he needs, especially in a patch to the Gimp that brings much needed feature for him, like the brush that mix its current colour with the content of the layer, or the flow setting (that is similar to krita’s “wash” and “build up” modes, except with a fuzzy settings, while Krita is binary). We also discussed the performance issue, especially comparing to Photoshop. Most digital artist would draw their image at a higher resolution than needed, for instance, if you need an image of 1000×1000, then you will draw it at 2000×2000 or even more, which means that you also scale the brush you use, which means that the brush engine needs to be efficient. While more polishing, like more clever shortcuts and easier setting of painting parameters is a must, efficiency is clearly the biggest issue we are facing in Krita, and the one that will need the most work, the good thing is that we already many solutions that will help us to improve that.
Then I installed Krita on his computer (using the ubuntu KOffice backport, I do not know if I missed something, but I found it extremely hard to add the backport to Ubuntu’s software installer). And I showed him the different paint engine of Krita, especially the new one from Lukas, and I talk to him about the goal of Krita, which is clearly focused on digital painting, and image creation. This is where we can have a clear separation between the different 2D graphics application in the open source world, with Gimp having a focus on image manipulation, mypaint being a scratchpad for quickly drawing, and Krita being focused on digital painting. This does not mean there should not be any features overlap, like Krita having a set of filters for image enhancement. It is just that the focus of the user interface and of the development is different.
This led us to discuss on what he can do to help use make Krita the application he would want to use for his artwork. What we need most (a part from more developers ) is testing. While 2.1 is a nice release, it is still far from bugs free, but what is also important is testing of the user interface and of the features, we need to know what is lacking. As a developer, when I draw I tend to bend myself to what Krita can do, while it should be the opposite, it is up to the application to fit the work flow. We already have two artists running the development version of Krita, but more is always welcome to get more diverse opinions.
We also talked on funding development of open source software, one area where the Blender Foundation is very successful is to make movies with Blender, this is very good for advertising the product, since you can show awesome end-results. But it is also very good since developers and artists are working together on the movie, the developers fixing bugs and adding needed features, while the artists provide feedback. The Krita pledgie is one step in that direction. David was thinking that targeting windows users could boost the fundraiser campaign, as apparently many artists are having remorse on pirating proprietary software and might be interested in helping a cheaper alternative, but it is clearly not the primary focus of Lukas work, first we have to make Krita ready on Unix, then other platforms will come.
One of the outcome of the meeting in Oslo was to take the final decision on the KOffice 2.2 release schedule. Following the current trend of a six months release schedule, therefor the 2.2 RC1 is planned for April, 27th 2010.
We have also decided to experiment with a shorter release schedule for 2.3, which is likely to happen four months after 2.2. This will be made possible with the use of Git, and if we manage to keep the release branch in a releasable state at all time, meaning no tests failures, and that features are only merged when finished.