Posts Tagged ‘Open Source’

How to find where an exception is emited with Qt ?

24 February, 2010 Leave a comment

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.

Categories: KDE, Open Source Tags: , , ,

Discussing Krita, digital painting with David Revoy

6 December, 2009 9 comments

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.

Categories: Krita, Open Source Tags: , , ,

KOffice 2.2 Release Schedule

3 December, 2009 2 comments

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.

KOffice Fall Meeting 2009 – Day 0

27 November, 2009 Leave a comment

So I have arrived in Oslo for the KOffice Sprint. We are gathering in the Trolltech headquarter, currently waiting for people to arrive before going to have dinner in the center. Casual discussions have already started about moving to git, about network issues, graphical user interface, distribution flameware. And also doing some hacking.

The topic of the meeting is mostly about finalizing the KOffice libraries, with API reviews with Qt Developers, probably some bug fixing and unit testing. As well as a few “administrative” discussion, like release schedules.

KOffice 2.1 is released, how user ready it is ?

25 November, 2009 2 comments

Yesterday, we released KOffice 2.1, the first major release in the 2.x cycle. It brings many improvements over 2.0, providing a much more stable and rich full experience, you can read more details in the 2.1 release announcement.

While 2.0 was clearly a developer release for developer, and for testing. For 2.1, we concentrated on fixing bugs, fixing some of the annoying issues, 2.1 is coming with many improvements in the MS Office filters, but 2.1 is still lacking in many area, for instance 2.1 comes with experimental support for displaying tables and formulas, but there is no support for editing them. Also there are still many rough edge in the UI. But the progress from 2.0 are astonishing, helped by the good base libraries (Qt, KDE and koffice), external help (Kevin Otten’s student and now Nokia).

While, in general, KOffice 2.1 is still not recommended for end-users. There are two exceptions, the first one is Karbon, while far to be feature full, is starting to become a very capable vector drawing editor, in 2.1 it get support for filters (only blur in 2.1, more is coming for 2.2). I personally use it a lot these days to create illustration for my thesis work. And Krita has made big progress in stability, with dozens of crash fixes for 2.1, and also include many of the new fun painting operation from Lukas, improvement in brush dynamic, recording of filters to create macro…

The last bit of *magick dependency is now gone from Krita

13 November, 2009 12 comments

Since its birth, Krita has been depending on ImageMagick (or the GraphicsMagick fork). The original idea was to build Krita as a GUI on top of ImageMagick. When the current team (or at least its veterans) started to work on Krita, ImageMagick was only used for exporting and importing files.

But using an abstraction of file formats did not give us enough control on how the files are loaded and saved, so four years ago, we decided to have our own implementation of the most used file formats: png, jpeg and tiff. Then later, tired of having to adjust our code for each releases of ImageMagick, we turned to GraphicsMagick, a fork that claim to have API stability. But the long term plan has always being to remove the dependency, and to have our own implementation of the file formats (or to use libraries when relevant).

Things have been accelerated recently, when we discovered that recent version of GraphicsMagick crashes Krita in a very weird way, so we decide to remove the GraphicsMagick files filter, and to finish implementing the format ourselves. This has started with the PPM filter that was finished yesterday, and now I am taking care of the JPEG 2000 format using the OpenJpeg library. But this might mean that in the near future, some important file format such as Photoshop‘s PSD or Gimp‘s XCF will not be available (but there is a Gimp plug-in to export to ORA which can then be imported in Krita).

Inserting shapes/images in KOffice

21 October, 2009 Leave a comment

A while ago, in a praise of karbon 2.0 I wrote, someone commented on the “lack” of tools in karbon, as opposed to inkscape. And from forum posts, or, it seems to cause some confusions. For instance, there is no rectangle or circle tool in karbon. And there will never be. The reason is that for KOffice 2, the tools are meant for user interraction, and for manipulating object in the canvas. Inserting shapes is done through the “Add shape” docker, which allow to manager your collection of customs shapes, as well as standard shapes, you can then just drag and drop the shape, or select a shape and then by clicking and dragging on the canvas you can select the size of the shape like with a tool. Once the shape is on the canvas you can go to the toolbox and start having fun with your shape.

video of karbon adding shapes

And of course, since the technology is shared, you add shapes to other KOffice application in the same way. To add a text in Krita ? Go to the add shape docker, drag and drop, and enjoy ! To add an image to your presentation in KPresenter ? Go to the add shape docker, drag and drop, and enjoy ! To add a smiley to KWord… you get it !