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.

Continue Reading →

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.

Continue Reading →

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.

Continue Reading →

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.

Continue Reading →

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.

Continue Reading →

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.

Continue Reading →

Today I’ll be starting on my Summer of Code project for darktable, so I thought I’d start off with a blog post about just what I’ll be doing. This Summer I’ll be focusing on UI improvements in darktable, and I have four separate tasks to complete, in this order.

1. Removing the libglade dependence.

   There are two ways to construct a graphical interface in software: one is to build your interface one element at a time in your source code, and the other is to use a graphical tool to build a description of your desired interface that you can use a library (libglade in our case) to construct when the program actually runs. Currently, darktable uses both techniques. Much of the user interface is provided by libglade, but some elements are also created in code. My first task for the Summer will be to remove this dependence on libglade and construct the entire interface entirely in code. You won’t see any changes in the UI as a direct result of this, but it should make it easier for other developers going forward to make modifications to the user interface.

Continue Reading →

As some of you might have noticed, darktable got accepted for this year’s Google Summer of Code (warning, site doesn’t work with every browser …). Currently we are seeing a few possible students lurking around in IRC, preparing their proposals in our Wiki and getting familiar with the program, code and community. If everything keeps going so smoothly this will be just f****ing awesome. If not we still have the excuse that it’s our first time, so we didn’t know what we were doing.

Continue Reading →