A reset

The triggering reason of the new name is indeed the consequence long time disputes in the community. We tried hard to solve them. But it was two visions of how the project should be conducted, and of its aims, that could not be conciliated, so at the end we concluded that it would be best to part and follow different paths. Unlike what I have seen on identi.ca, it is not exactly true that we hide that in last night announcement. It might have been the trigger but it is not the driving reason. I think that when the discussions around the split started, the majority was in favor of keeping the KOffice name, but slowly, the idea of changing took over in our mind.

First of all, the KOffice name itself has a lower value that it might seems, it is often associated to the office suite that has potential but does not deliver, it is hardly known outside the KDE world, it is not such a good name, and above all, KOffice includes applications that are not traditionally associated with office applications. Also a new name is a good opportunity to get a new start, and from what I have seen, it has boost energy inside the project, and it is fueling the enthusiasm of many people, and I am confident that it has helped us to leave the past behind, and focusing on making the future of Calligra. And I am thankful to Jos Poortvliet for advising us for a new name.

After long discussions, we have settled for a new name, Calligra, based on the word Calligraphy. It might not be my favorite of our choices, but I think it is a good name, it refers to “Writing” and “Beauty”, which are two main aspects of our suite of applications, meaning that it makes all our applications feel at home.

Present

Actually our present is to work on the release of the version 2.3 of KOffice. In my view, the renaming was poorly timed, since it happens slightly before a new release, and quiet far away from our first release. But we did not have full control of the agenda either, especially since last week-end the project moved to git, and it is simply more convenient to point people to a repository that will stay for a long time than to ask everybody to switch in six months. And also the split precipitated the events.

The future

There is a lot of speculation about the future, between Mobile and Desktop. Several person have presented Calligra as being mobile oriented. Lets be clear, it is not true. Calligra is focused on developing technologies related to office and creativity applications, on top of those technologies, the Calligra project is delivering a set of desktop applications and mobile applications (and maybe tablet, in the future). All of it is build over the KDE technologies, using the Qt toolkit, which makes it potentially available to an incredible range of devices and operating system: Linux, Windows (desktop and mobile), Mac OSX, Symbian, Meego, Haiku (and maybe Android, iPhone, WebOS…), using a desktop computer, a laptop, a mobile phone, a tablet, your TV… And all with an user interface that is most suitable for your form factor.

Well of course, Qt and KDE being available on a platform is not sufficient to make Calligra available, it needs more work. The majority of the volunteers are working on linux and targeting the desktop, Nokia is supporting the mobile phone and Meego efforts. And anyone is welcome to come and give us a hand with their favorite platform and form factor.

Personally, I find those goals very exciting. Since it pretty much in line with my vision of where computing should be in 10 years, I do not believe in web applications, or thin clients, I believe in web servers as a storage space, while the intelligence remains on the actual device, and collaborations goes through peer-to-peer solutions, using open standards such as ODF.

On the organization level, we want to build a community where every contribution is regarded equally, where people’s work is properly acknowledge, where discussions remains friendly. Where maintainers are facilitators.

I hope this answer a few question, we are also preparing a FAQ, so if you have more questions, you can ask them on this blog, on our irc channel (#calligra on freenode), on the calligra-devel mailing list or in the calligra forum.

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.

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.