For my final GSOC 2011 task, I set out to build a levels module for darktable, which would behave more or less like the levels tool in GIMP and similar image editors. The user sets a white point, black point, and middle grey point for their image on a histogram, and the tool adjusts the image to match the chosen boundaries. In my git branch, I now have the levels module functional.

For my third GSOC task, I’ve replaced darktable’s old bottom-bar colorpicker with a new one one that acts as a module in darktable mode. The new picker adds some features over the old version, which some of you will hopefully find helpful. Specifically, we have four new additions:

• You can now choose point or area color picking modes.
• I’ve added a simple storage system for color samples.
• The big new addition is live samples, which will allow you to mark an area or point in your image and keep updated as the color at that location changes.
• When picking, the image histogram will only display the area or point that you have selected.

Now, lets take a quick tour of the new interface. This is more or less what you should see initially.

It took longer than I expected thanks to some unforeseen twists and turns, but the new keyboard accelerator system is basically finished. There may still be some need for minor bug fixes and string changes (in particular, the new translation system needs to be tested out), but by and large everything that needs to be in place is, and next week I plan to start working on changes to the color picker module. Now that the accelerator interface is stable, lets take a little tour of it.

I’m about a week in on my work on darktable’s keyboard input system, and I’m hoping by the end of this week to be more or less done.  Here’s a quick look at where I am and where I’m going.

The Current Status

If you check out my git branch (it’s called bieber), you’ll find that so far I’ve removed all of the explicit calls to darktable’s old accelerator registration system, and replaced them with calls to gtk_accel_map_add_entry and gtk_accel_group_connect_by_path.  These functions create an entry in a global accelerator table, linking an accelerator to a path that looks something like, for instance, /iops/clipping/commit, rather than a specific keycode.  Other GTK function calls will later give us the ability to change the actual key mappings for these paths at runtime, so user remapping will be a breeze.  If you compile and run darktable from my branch at the moment, you’ll see a file called “testkeys” pop up in your current working directory.  This is what the GTK keybindings file looks like, at this point just auto-generated from the default key mappings specified in the source code.  Soon you’ll be able to modify this file (either directly or from an interface within Dartable’s preferences) to change your shortcut key mappings.

As of last week, the removal of libglade from darktable is functionally complete. The gladefile has been deleted, along with all references to libglade in the code and the Cmake files. Some refactoring may still be ideal, and I’ll be rearranging some code in my free time, but the task is basically completed. Now it’s time to move on to handling keyboard shortcuts.

My plan is to make all keyboard accelerators in darktable application-wide, so that the user won’t have to worry about the current focus when entering a shortcut. There will be mode-specific shortcuts, but nothing module specific. Instead of entering the specific key to use for the shortcut, code registering shortcuts will now instead make an entry in a table with a name for the shortcut and a default key to use, which may be remapped by the user. Remapping will be handled in a tab of the preferences dialog, in similar fashion to the keyboard shortcuts dialog in GIMP.

I’m now a week into my first task of removing darktable’s dependency on libglade, so here’s a quick look at my progress so far. In the first week I started out by diving in and figuring out how to instantiate all the widgets I would need, starting with the lowest levels and working my way up. It took a little while, but with a combination of the Gtk documentation and some guesswork aided by autocomplete I’ve more or less figured out all the function calls that I need to create widgets, modify their states, attach them to containers, and so forth.