Sorry to disappoint you, but you won't see the now famous "KDE 4.0" banner on this blog entry ! That said congrats to the KDE developers for the release.

Back to the point, since a while I have been thinking about automation in Krita. In facts we are often told that Krita doesn't make it easy to redo the same action twice. I have added quiet a while ago the possibility to save a filter configuration, but I wanted to go even further, and be able to record every actions made by the user. And to replay them.

Unfortunately it's still a long road before all actions are correctly recorded. But two of the main most important actions are now recorded : painting (only freehand but the hardest part was made, other drawing tool should be easily done now) and filtering.

From digiKam mailing and from blog entries over the web, a reccurent question is always ask : why my new Camera witch can provide RAW file is not supported by digiKam...

To this question, the response is simple: digiKam use our libkdcraw C++ interface including a fully tested version of dcraw program. This dcraw version can be an older release, depending of backport progress done by digiKam team. And of course this version support a dedicaced list of RAW camera files witch can not include the most recent RAW camera devices.

To clarify the situation, i have implemented a small dialog available in help menu to list the RAW camera list supported by digiKam...
read more

Currently, i'm working on a new tool that users have been waiting for since a long time: a time-line...

Work in progress come from this KDE bugzilla entry. Code still on my computer and is not yet available for testing.



From this screenshot, the new Time-Line widget have been added into the Calendar view for testing. This is not the right place of course, and my vision is to create a new tab in Date View from right sidebar called "Timeline".
read more

A new year, a new digiKam release plan : 0.9.4...Today, i have added to svn a long work from KDE bugzilla about a new feature to show count of items into album folder views.



The number of items contained in virtual or physical albums is now displayed on the right of album name. If a tree branch is collapsed, parents album sum-up the number of items from all un-displayed children albums.
read more

Like digiKam 0.9.3 have been released for Christmas time, it's time to start next 0.9.4 release plan... and of course the time has come to find the ideal splash-screens to go with it. Now is your chance to join the ranks of the precious few who have had their artwork associated with a release of digiKam!

SplashScreen is a simple way for users to contribute to digiKam project. The pictures must be correctly exposed and composed, and the subject must be choosen using a real photographer inspiration.
read more

From time to time, there is someone who comes on KOffice channels asking whether it is possible to do something that for a long time we considered to be completely useless in the 21th century : reducing the number of colors of an image. But in fact, there are still a couple of use case. And after some time, I thought it could be fun, especially the palette creation phase, as I got the bright idea to use a genetic algorithm, that's how you make a 20th century feature, a fun feature to write.

Bellow is the result of the image with an "optimized" palette:

Dear all digiKam users,
the team is really proud to deliver just in time for Xmas the final. The tarball can be downloaded from SourceForge. Don't forget to update Exiv2 to last stable release 0.15 for digiKam to compile successfully.Many, many thanks go to Gilles, Marcel, Arnd, Mik, Fabien and all the others who worked hard to create this great new release. This release sends a big parcel of useability improvements under your Xmas tree: If it was not already, organizing and navigation have become a snap now with the quick filters, drag&drop and GOTO features on top of an optimized lightable.

As for all my blog entries, this is my personal opinion about one of my hobbies. And it is neither the official position of the KDE project, KOffice project or Krita project on the subject.

I have been thinking to write that blog entry for a long time, I am often pointed out that I am duplicating effort made somewhere else, while this is sometimes true, this is not always the case, and some other times, it is even intentionally. But giving the reason over and over is really annoying, so now I will simply be pointing to this blog entry.

Four reasons to either develop a new library, subsystem or plug-ins, from scratch, while there are solutions that allready exists and look similar :

Getting closer to a release are exiting times, all pieces start to fall together in place. Now is time to time to start finishing the features I have been working on.

I can't remember when I started working on the panorama plug-in, probably something like a year and half ago. But I barely spend any time on it, except one out of every few months. And this week-end was one of those few time.

Last time I had worked on the panorama plug-in, I had left the code working, but in a pretty bad shape, and nearly all lines of code were assuming that there was only two images in the panorama. So I spend some times adjusting each lines to allow more images, which was very tedious, because one mistake in one line and the process completely fails.

DISCLAIMER: this is a blog entry, this means this is the personnal opinion of the author.

There is a lot of buzz currently around on how KDE and KOffice are blindly rejecting OOXML, and Gnome and Abiword/Gnumeric are blindly embracing it. I think this is a complete misunderstanding, and that the position of both projects isn't that different, but due to some amplification effects, both position are seen as "extreme" in one or the other direction.

KOffice position is that ODF is and should be supported to be the standard for interoperability between office suite. So, the effort is concentrated on improving the specification, the implementation and ensuring that documents created by KOffice is correctly opened by other Office Suite (and vice-versa). KOffice position concerning OOXML is that, in its current version, it shouldn't be made an international standard. The main reason is that OOXML isn't build on pre-existing standard (like ODF for instance, or SVG or even dates...), which result in a huge specification.