Marty's typepad

So you want to keep the URL of downloaded file eh?

This weekend I was in Brno at Red Hat Developer Conference, attending Fedora's KDE SIG meeting. Besides helping these super-awesome folks getting KDE Telepathy into Fedora, I had this idea of storing the download URL of a file that you have downloaded, so you can check where you downloaded the file from. KDE Workspace already provides all that is needed to make this work. Yes, of course it's Nepomuk :)

So I pinged Vishesh Handa about this idea and we got down writing the missing bits. The idea was to simply monitor the browser downloads and add the download url to Nepomuk once the download is completed. I had no prior experience with browser plugins/extensions, but initial research showed that the best way would be to write a NPAPI plugin, which is supposed to run in all browsers, that would mean one code to maintain. However that proved rather difficult (please let me know if you have experience with this and if you think it would be better way to write) so I went the way of less resistance and I wrote Firefox extension, which is based on Plasma-notify extension. While in the process, I made the Plasma-notify work with latest Firefox too ;) Edit: This is apparently not needed anymore, in "about:config", you can set "browser.download.manager.showAlertOnComplete" to true. Thank 'theghost' for the tip.

Anyway I finished the extension while Vishesh wrote the Nepomuk part in the meantime. We decided to do this in two parts, so that the Nepomuk utility can be reused by anyone/anything else. The extension just calls the binary utility, which takes file and URL as parameters and adds the URL as ndo:copiedFrom into Nepomuk. You can then view the download URL in Dolphin's sidebar.

 

 

Without any more prolongs - here is Firemuk -- http://dl.dropbox.com/u/6761102/firemuk.xpi

Keep in mind it's version 0.1 ;) There seems to be problems with regular downloads sometime, I have no idea why. At least not yet. I plan to publish it on addons.mozilla.org once it's more tested. And for you Chrome/Chromium users - yes, I will write the extension for you too. Just hold on :) And as for Konq/Rekonq - it should be super-easy to implement this in these browsers (if the devs could contact me or Vishesh, we'd be more than happy to help). I can see this also working in KGet. KGet already does exactly this. Awesome.

Go ahead and test it and let me know how does it work for you :)

KDE Telepathy now depends on Telepathy-Qt4 >= 0.9 (also - how to report bugs)

(Can someone make Planet KDE not show my old now-edited articles on top? Thanks)

Today our whole KDE Telepathy project was ported to Telepathy-Qt4 0.9, which is not backwards compatible. That means that for all KDE Telepathy code cloned from master today onwards, you need to update your Telepathy-Qt4 library to version 0.9 or newer first, otherwise it won't compile.

The released version 0.2 on the other hand needs Telepathy-Qt4 < 0.9, it won't work with version 0.9 and newer. So before posting bugs about not being able to compile our software set, please check if you're using the correct version of Telepathy-Qt4 library.

Some more about bugs and how to properly report them for KDE Telepathy. Our small project is still to be considered somewhere around alpha quality. There are bugs. Quite often we receive bug reports like "I can't connect". This really does not help us to see where the problem is. When you have connectivity issues, we need to know _exactly_ what's going on inside your Telepathy installation. And it's very easy to provide us with such info.

Here are the needed steps:

1. Disconnect all accounts
2. Disable all accounts in System Settings and leave only the one failing
3. Make sure no process named telepathy-* is running, if it is, kill it
4. The following step is different for different accounts:
   • If you're using Jabber, GTalk or Facebook chat, put this line in terminal:

   GABBLE_PERSIST=1 GABBLE_DEBUG=all /usr/lib/telepathy-gabble 2>&1 > ~/gabble.log

   • If you're using MSN, AIM, ICQ, Yahoo! account or others, use this:

   HAZE_PERSIST=1 HAZE_DEBUG=all /usr/lib/telepathy-haze 2>&1 > ~/haze.log

   
   If it says that the file does not exist, please find your telepathy-gabble/telepathy-haze and replace the path with it. This will create the log file in your home directory, named either gabble.log or haze.log.

5. Now connect.
6. After you have obtained the log, please check it for sensitive data. If there are none, provide it to KDE Telepathy developers (either attach it to bugzilla or use paste.kde.org and post the link to developers in some other way)

So before you go to file a bug saying "I can't connect", be sure to have one (or both) logfiles ready and attach them with as much info as you can provide - which account is failing (the network name is enough, eg. gtalk, icq, yahoo etc), does it fail to connect every time (try connecting 10 times in a row), what are you using to connect (plasmoid, contact list etc) and which error exactly are you getting. Also very helpful is including your telepathy-* packages versions. These things will help us enormously to pinpoint your problem very quickly and possibly fix it.

Very useful is also checking our FAQ and troubleshooting guide if you have any problems.

As for other news from KDE Telepathy land - 0.3 release is quite near, it still won't have Nepomuk integration (but this is closer than ever), quite probably no audio/video call features (but there's still hope) and maybe (just maybe) also chatting right from Plasma!

We could still use some hands, so if you find yourself bored and with nothing to do (like, if you've finished Skyrim), just storm #kde-telepathy on freenode and we'll get you started (and you don't have to know C++/Qt4).

Update on telepathy-kde-contactlist: Repo back online!

So the sysadmins fixed the gitolite bug which prevented from creating new personal clones, that means, that you can grab the contact list code now. But be warned, there are dragons ahead. Well in fact, there should be dragons ahead, but there are not. Yet. We're still at basic functionality only (ie. listing contacts, starting text channel [for which you need the chat handler] and setting yourself online/away/offline [for which you need to have some Telepathy accounts configured {for which you can use the Telepathy Accounts KCM}]). Anyway, here you go:

git clone \
kde:clones/telepathy-contact-list/mklapetek/telepathy-contact-list-new \ 
telepathy-contact-list

(make sure you have set the prefix rewrite rule as in the KDE Git manual, I also had to break it like that so it could fit to the blog's template width)

cd telepathy-contact-list
mkdir build && cd build

For 32bit systems:

cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` \
-DCMAKE_BUILD_TYPE=debugfull ..

For 64bit systems:

cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` \
-DCMAKE_BUILD_TYPE=debugfull -DLIB_SUFFIX=64 ..

Then simply do

make

and after a while you're done. You can then run it without installing (make install), just do

./telepathy-kde-contactlist

from the build/ folder (if you're not there) and there goes your new contact list.

One note for those of you who previously tried the code; we're no longer working on branch mck182, but we're on master now ;)

Stay tuned for more updates!

 

What's cooking with the telepathy-kde-contact-list?

Part of my diploma thesis agreement with Red Hat was to blog about my work for the KDE Telepathy team. I'm currently taking care of the contact list (CL) component. There was a discussion about what the CL should be able to do and what not. For the first KDE Telepathy release we decided to implement it as a moreless full featured app, like kopete. After that it may be taken down to parts and reintegrated elsehow in the desktop environment (though the CL will still exist and will be used, just some features may be moved elsewhere). But let's not discuss this just yet, it's way to early for that. Instead, let's see, how is the CL coming.

So far, the basics are almost all in place. We have a working contacts model, working presence setting and you can also start a text chat. And that's pretty much it now :) But don't worry, there's a loooong todo list of features waiting ;) Let's look closer on some of the things.

Contacts model

I started to implement my own model at first, based on telepathy-call-ui (the KDE part for making voice calls). This was really just a basic tree model with only few features. Though working, it still needed fair amount of work. Then David Edmundson showed me Telepathy-Qt4-Yell project, which has pretty solid and full-featured model already done. So I dumped the old model and adapted a new one, based on this project model. Thanks to the great architecture of Tp-Qt4-Yell (and the CL too :P), it took only a few hours to get this up and running. So this is now under the hood. There's still need for filtering/sorting proxy model, groupping model, hiding-offline-contacts model (some work has already begun on this) and a few other things. Bottom line is that we have a fully working contacts roster (with avatars and everything), but unsorted (by status nor by name).

Contacts view

The view is based on QTreeView and though it works like a tree (you can expand/collapse groups), it doesn't and won't look like a tree (in filemanager for example). When there is a support for metacontacts, which will group several contacts under one, the sub-contacts will then be padded, but no guiding lines will be painted. I just don't like the kopete-filemanager-look. It feels cluttered and over-lined. So the aim is to keep it visually simple, nice and appealing (UI artists wanted!).

One feature I particulary like about the view are the delegate overlay buttons. I borrowed the idea from digiKam, where it was implemented by Marcel Wiesweg and based my code on that. It's basically about showing buttons (KGuiItem) on mouse-hover and hiding them on mouse-away. These buttons are used particulary for starting text/audio/video channel or sending a file. They should be a context menu replacement in a way (don't worry, context menu will still be there with all you'd expect ;) It also hides those buttons (capabilities), that the contact doesn't support. It nicely fades in and paints itself under the user name (see screenshot around). Another cool thing is, that if there is a status message present (below the username), it is faded out first, so these two UI items wouldn't overlap. On mouse-away the status message of course fades back in and the overlay fades out.

Another thing done in the view are system messages. For example when there's a error or you're disconnected etc. There are two types of messages - info and error. Info messages will fade out automatically after few secs and they are blue-ish (probably will apply theme's color later). The error ones will stay until you close them (making sure you read what's wrong) and these have light-red color. Both slides up from the CL bottom edge, see the screenshot. Although indicating the "Connecting..." and "Connected" will be done differently in the end.

At the CL bottom, there are buttons, which I call AccountButtons, and these take care of setting the presence of particular accounts. You can see it on the first screenshot. How many accounts you have, that many buttons will be there. I'm also working on a simple way to shield user from so many buttons and introduce a way to set all your accounts online at once. But I haven't given much thought to this yet.

TODO

There's a plenty of things left to do. For example the part of finding/adding new contacts, dialog for editing your own account information, way of joining rooms...and of course the filtering/sorting/offline-hiding proxy model with search capabilities. Later also integration with nepomuk is planned, but that's rather distant future now. Simply put - plenty of work left to do :)

Where to get it?

Currently I have a problem with my git account and my personal clone repo, so the code is not available at the moment, but I'll post a blogpost right when it's ready again, please be patient ;)

By the way, is there some simple Qt/KDE method for painting shadows beneath pixmap? If you know of any, please let me know in the comments. Also sorry for the need to log in to post comments, this is a TypePad restriction for free blog version (and I don't have enough money to pay 9$/month :P ), so please just use OpenID or Google account or something like that to log in. I like TypePad very much, it has nice features and such, but this and no per-tag-rss are really missing..

School, digiKam & Telepathy (aka What's keeping me busy and other thoughts)

My school exams are finally over for this semester and now I've got a few days off. Thanks to some excessive preparation for these exams, I haven't had much time for any real coding. And frankly, I miss it :)

My to-do list still lists some digiKam coding stuff. I'd like to focus on some minor useful features for digiKam, which will make everyday users more happy. That's one thing I love about open source - you miss something, you sit down and code it. And let others benefit from your work. One such idea came with "pluginising" KSnapshot for 4.6. It almost asked itself for a kipi-plugin for imagebin.ca service (fast image sharing). I started working on that plugin, but shortly after that, the site has been down. And it's down since, so this pretty much killed my motivation (and chances) for finishing it. Although when I was looking in the ways the plugins are coded, I kind of stumbled upon the fact, that there is no Generic/Dummy plugin, template or some other documentation/tutorial on how to create one. So this is now also on my to-do list - write a tutorial on how to get started with new kipi-plugin. Hopefully this will make broader sharing services support :)

After only few months of working on the digiKam I did learn so much about KDE developement (and developement in general). Be it coding styles, C++ techniques, CMake scripts etc. It really gave me A LOT. DigiKam has great community around with some awesome contributors. And I really admire the amount of work Marcel and Gilles are putting in it. They are doing really tremendous work. One thing I'm particulary happy about is how the (whole) team handles Bugzilla. We usually respond within a day to most of the bugs, some of them are closed the next day (well, truth is, that these are either libs mismatch or reported with some old version of digiKam and updating to a newer version usually resolves it, but still :P ). I think I can proudly say, that we're doing a great job. And by this I'd like to encourage all other KDE teams - pay attention to your bugreports! Even the smallest reaction (change the status, asignee or something) gives the reporter a good feeling, because he knows, that his bug has been viewed/read and hopefully taken into mind. (Now I'm talking to you, Gwenview guys, 252693 has been reported in September as major, 4 months later and I still got no reaction from you!) Otherwise they will get feeling, that reporting bugs is useless. And we all know it's not, it's one of the things that makes all our products better.

And although I'll still stick around digiKam and help here and there, I'm now also joining the KDE Telepathy team as part of my diploma thesis about Telepathy I'll be doing for Red Hat. This project, still without official name, is progressing quite nicely and a preview version looks to be soon released. I'm very happy to join the team and make use of all my experiencies I got with digiKam to bring Telepathy integrated into KDE Workspace. With the help of others, I'll be starting with Contact List coding, so if you have any good ideas or requests, now would be the time to let me hear them ;) Either leave a comment here, or catch me on freenode, I'm in several channels (mainly #digikam and #kde-telepathy) as mck182, so just come by and ping me.

My classes timetable for the next semestr is pretty crazy, many subjects overlap themselves and if I add my job of Android news writer and all the KDE coding, this is going to be a test of my time management skills. But I'll always find time for a good glass of cold beer, if anyone wants to buy me one :P

KDE Imaging Coding Sprint 2010 - Aix en Provence

Last week, from 27th to 29th August, developers of KDE Imaging group met for their third coding sprint organized by digiKam lead developer, Gilles Caulier in his hometown, the beautiful southern French city Aix-en-Provence. The time was shortly after the end of Google Summer of Code, in which digiKam participated this year with three students. It was therefore a perfect timing for us GSoC students to get to know our mentors in person and get to work with them side-by-side.

On Thursday morning, I met Andreas Huggel, who flew down from Malaysia. Andreas is Exiv2 developer and is working closely with Gilles on metadata support for digiKam. We went together for lunch during which we found out that it was the first event like this for both of us. A few hours later, we met two indian guys having absolved a 24 hour flight, Aditya Bhatt and Kunal Ghosh. Aditya is a GSoC student working on face detection and recognition for digiKam and Kunal is a Summer of Kode developer integrating an ECMAScript support into digiKam.

In the Thursday evening, we met Michael G. Hansen and Marcel Wiesweg at the Maison des Associations Tavans, where we attended local the Linux User Group's meeting, watching Gilles giving a talkabout digiKam. Shortly after that, Gabriel Voicu, another GSoC student working on geotagging features for digiKam, was dropped by bus near Aix-en-Provence, no idea about his whereabouts, he sent us his GPS coordinates and we looked him up using Google Maps, so Gilles could pick him up by car.

On Friday morning, we all met at hotel Paul's breakfast. We could finally put real faces to all the email addresses and IRC nicks. Any social barriers were very shortly overcome and chatty discussions were started, about cultural and national differencies, about our lives, school, work and of course KDE and digiKam. A very lively discussion continued during our way through the really nice city back to the Maison des Associations Tavans, which was also our "coding place". Friday was very hot and dry in Aix. But also very fruitful- in terms of work as well as in terms of awesome fruit markets.

Kunal was working with Gilles on improving the scripting support in digiKam. The main idea is to add a new script interface for digiKam, based on QtScript API. This interface will provide a simple way to manage a list of custom scripts, dedicated to add new tools in Batch Queue Manager. The digiKam API will be exported and available to customized scripts. A settings widget have been designed by Kunal to setup scripts in Batch Queue Manager. Gilles and Kunal have reviewed GUI and current implementation to patch Batch Queue Manager with a new script view, assignable to items to process. This will be available in the upconimg 2.0 version.

Aditya was improving the face detection/recognition stuff, together with Marcel and Michael a discussion about ways to store face tags in metadata was begun. Aditya then worked hard with Marcel on polishing the face detection, debugging the database code, implementing the use of using internal tags, which are not visible to users, for storing face scanning related data. We also checked how other projects work, especially Apple's iPhoto with Andreas' MacBook. Aditya then also discussed the possibility of having a unified batch task manager. "Currently, most of the batch jobs in digiKam run in the GUI thread and make the UI slow, such as the fingerprint generator, metadata read/write, etc. We should have proper multithreading for this (my batch face detector partially implements this), and have a nice unified batch task manager, as one place to control all batch jobs.", he adds. Last but not least, Aditya did a lot of bugfixing in libraries used by face detection/recognition in digiKam - libface and libkface. All the code was then stress-tested on Gilles's whole photo collection. "It works pleasantly well, but also giving us a few directions for debugging (read: crashes)" says Marcel.

In the noon lunch-break, Gilles' wife and son joined us and we all enjoyed a fine French cuisine with Gilles explaining to us what food is what. "Then came the surprise, a menu card which I couldn't read and the menu which consisted of mainly non-vegetarian food. Well my bet on the lunch order paid off and I had a pleasant meal and also identified food I should keep away from :)", says Kunal. As work was waiting for us, we didn't stay too long and soon headed back to coding.

Andreas, besides a lot of coding on Exiv2 project, also discussed with Gilles support of new types of metadata for video files. Then with Marcel he analysed an issue with the algorithm to distinguish images and also got a first-hand update of the current metadata process flow in digiKam. "It was interesting to realize how pronounciation of words becomes important when you talk to each other face-to-face as opposed to exchanging emails and how much a bit of gesturing and scribbling on the black board helps to convey a message.", says Andreas.

Friday evening was in the light of italian cuisine with the menu in Italian (not that it would make much of a difference from French to me). This was a great evening with great amount of talking about KDE and related stuff, but also Gnome, Linux, Microsoft, Android, computers, phones...and all that what you would expect from a bunch of developers. Also Laurent Espitalier, who drove down from Isére, France, joined us that evening.

Saturday we started again at hotel Paul with breakfast, during which we again discussed everything and nothing. Me and Aditya were stoked on FotoWall's animated GUI and we discussed some animation possibilities inside digiKam. We both agreed, that digiKam could use some more "live" UI. I've already started looking into Qt Animations framework and I have a few places in digiKam in mind, which were like directly created for animations. But first things first.

I continued my work on image versioning support for digiKam and managed to extend the functionality of the 'Revert' button in the image editor. Now you can revert to the last saved version, and if this is a subversion of some original image, you can then revert to the original as well. With Marcel we solved hiding/showing all image versions except the current version using internal tags, we redefined the versioning concept a little bit and solved lots of bugs too. I found out, that even though it works ok on my computer, Gilles had some rather severe issues with it on his computer, so this brought me to lookup through the whole code, do lots of cleanups and create a simpler and more flexible design.

Michael worked together with Gabriel on improving the new search UI in the map views. During discussions with Marcel, these three seemed to solve the question of an intuitive workflow for searching, selecting, filtering, zooming and panning on the map, a functionality currently exposed by 12 buttons in a row. Together they came to a UI mockup and an intended workflow where a click willl usually do what the user may expect and images do not disappear, but are greyed out if filtered or unselected. "We're pretty confident that we found a good solution, so Gabriel and I talked about implementation details and Gabriel started coding on it.", says Michael. He also added two new things into GPSSync - a split map view, which shows off the model-view capabilities and a new configuration dialog. With Gilles, Michael got into discussion about how sidecar files should be handled.

In Saturday's noon-break, we went to discover the local markets, with plenty of colorful fruit and vegetables, beautiful flowers, crispy bread and baguettes, souvenirs, and piles of other stuff too - old vinyl and cassette music, historic newspaper from 1894, bars of soaps, silver cutlery, glass, dresses, hunting knives...you name it. During our walks through the city, we all took many pictures of this really beautiful city and its offerings, which you can find on flickr. After quick lunch, we headed back and did more coding and polishing. Luckily it was quite windy that day, so the temperature wasn't as high as friday.

Laurent Espitallier uses and promotes digiKam at his work with one French government agency, where they use Nikon Project software for managing photos taken by team of photographers and which are later used in documentations. With digiKam, he's working on database import from this Nikon software, but also from applications such as iPhoto, Picasa or Aperture. Laurent and Gilles also discussed the importance of XMP sidecar files support for all read-only image formats, for example RAW files. With Nikon Project to digiKam migration, the goal is to be able to patch digiKam database with all Nikon keywords tree-view and all virtual folders created (in Nikon, Tags and Virtual folders are separated concepts). Only the first feature can be easily achieved when pictures are back-ported without a need to write a specific Nikon database parser. The images are just exported from Nikon collection using right options and then imported in digiKam.

During the day, we had a refreshment in form of the famous Czech beer, which I brought with me and for which Gilles provided proper cooling. Also I can't forget the great French wines we tried during dinners. The Saturday's dinner was really great. We settled in a small quiet and very nice restaurant and as everybody was really enjoying it, no one felt any need to go back to sleep even though the time has advanced very close to the midnight.

I was leaving on Sunday, shortly before noon, so I didn't have much chance to do any coding, but the rest, except Gabriel, who already left during the night, stayed and kept working. It was hard to say goodbye to such a great team after all that awesome time we spent together. I am really glad and very thankful that we could meet each other in person, for which I'd like to use Andreas' words: "It will make future team work easier and more fun". It is most certainly true and this would not be possible if it wasn't for KDE and especially KDE e.V. The most biggest thanks to the e.V. for making this happen. Thank you!

GSoC: explaining digiKam's non-destructive editing concept

Published on digiKam's blog and Planet KDE  

Hi digiKamers, hi KDErs, hi planet,

few days ago I blogged about the progress of non-destructive editing in digiKam. According to your comments, I take it that there is some misunderstaning in the whole concept. So let me explain it to you :)

The non-destructive editing will be done in such way, that if (and only if) you do some edit to some image, there is automatically created new file, which is a copy of the original with applied changes and with list of edits you've made saved in metadata. Next edit you do, is again applied to the same already-created version and the list of edits in metadata is updated. This is done for example for you to be able to edit the edited file with some external app, let's say GIMP. If there would be only the list of edits stored somewhere, you wouldn't be able to edit it with nothing else until you'd export it from digiKam.

However, when you do some non-reproducible changes, like using some effect, which uses random values for initialization, we need to preserve this exact output, because it can't be reproduced in the same way (thanks for the randomness), so this gets saved again to the same file, but next edit you'll do, will need to go to new file. This will still be presented as one version in digiKam. But there is some ideas about adjusting the nondeterministic filters in such way, that even those could be reproduced when the proper values are stored. This approach would be much better, but I'm not sure if that could be done. But we'll definitely look into it.

About the "Originals" folder. As I wrote, this is supposed to be fully customizable. Think about some photos you take, you pull out the card from your camera, stick it to your PC/notebook/netbook/whatever, do some changes in your digiKam and then you want to fly away with the card to give some presentation. But you want to show only the better versions (the edited ones) and not go through three almost-same pictures in presentation again and again. That's why there will be this option, to move the originals into some other folder, so you can still have them present, but they won't get in your way when not using digiKam. Also think about mobile phones. You connect your phone to your PC, do some changes and then you want to show your friends some photos you take, but again, you don't want to show the originals, you want to show only the better versions. Think about having 100 pictures and that you'll do some edits (autolevels for example) to 50 of them. Then you would have 150 images in your mobile gallery and you would show every second picture twice. Again, that's what the "Originals" folder is for. And again again, it will be customizable. Or optional if you want. So you can just turn it off completely and your images will stay all in the same place.

Then there is the version management. Every edit you do to the original file, will create another version. If you edit the already edited version, the it's simply saved to the already created version file. Only when editing the original you'll get a new version. Or you'll have a possibility to 'fork' it to manually to create a new version. So for example you do several crops to your images. You simply open the original, do one crop, new version is there, saved, ready for other operations. You switch back to the original, you do different crop and another version gets created, again, every other edit you'll do will be saved in this same file with updated metadata. No one-effect-one-file-thing. Then you should be able to display all your versions along. Something like virtual album. So you can see all your cropped images next to them. But not only cropped, imagine you do some color changes or some other effects. Then you can see all your versions next to each other and pick up the best.

Next thing is GUI. There will be some kind of indicator, that you have more than one version, or that you have done some edits and you're able to revert them. The looks of this is not clear yet. But we're open to any proposals or mockups you may have. Also, with every opened version, you'll see a list of changes you've made and you should be able to remove any edit in the list. It would be cool if you could simply change the edit's values and have it reapplied, but that will probably take some more time to accomplish. But I'd like to see that happened.

And if you're thinking about buttons in the editor GUI, Save As... definitely won't disappear. Probably Save button could go away as it will be automatically saved after each applied (meaning you click Ok) effect. Instead of Save button there could be a Fork button, which would create completely new version (copy of the current edited version). Other changes in the UI haven't been decided yet. I'm focusing on the foundation right now, GUI will come later (but soon;)

That's basically how the non-destructive editing will be done in digiKam. Hopefully it's much clearer now to all of you :)

Marty

GSoC: update on digiKam's non-destructive image editing

Published on digiKam's blog and Planet KDE  

Hi all,

little update about the progress that has been made. So far, there are no visible changes to the user yet (if you don't count tons of new debug stuff on console), all work has been done under the hood. The good news is, that the basics for non-destructive editing has already landed in the codebase. You can now use Brightness/Contrast/Gamma tool and the Autolevels tool in such way, that it will automatically create new version of the edited image, apply the changes on the new version, move the original version to "Originals" folder located in original image's path (will be fully configurable) and save the new version as {originalImageName}_v1.{originalImageFormatExtension}.

There is no GUI yet, which would be able to manipulate with versions and used filters on them, but that's all on plan and I believe, that some basic GUI for reverting the image to its original state could be done at the end of next week. You will find it as a next tab in the right sidebar in digiKam's Image Editor, although the exact appereance of this UI is still a work-in-progress. But as soon as there will be something usable, I promise to bring you some screenshots ;)

Stay tuned,
Marty

Oh yeah and to answer the question "What about editing done with other programs?" - well, this is kinda tricky. It will definitely be possible to revert back to the original image when you edit some of the versions and not the original itself, it should also be possible to just revert this one change. But if you edit the image, that has no version present (and thus not backuped the original, ie. you edit THE original), there's no way to revert back unless we duplicate all of your images, which is rather unwanted. It could be possible to do so, when you open the image in some external app from digiKam, but most probably not if you open it directly.