Development: Gauging the difficulty of contributing code to an editor

Software
1

I’m curious about comparing Filmulator to other photo editors’ code architecture.

One part of the benefit of open source is that we can steal algorithms from each other, but another is that if you don’t want to start your own project, it’s conceivable to add your own functionality to existing software if you’re so inclined.

Two days ago, in about an hour’s work, I added a new small feature to Filmulator, which is an option to append a hash to every filename on import. While simple as far as features go, it made me wonder what a new contributor would experience in trying to add a feature of the same scale.

In Filmulator, each tab of the interface has its own UI markup file, a Qt model as the backend, and some things access a persistent settings object. So here’s what needed to be made:

  • Add a ToolSwitch (standardized switch UI element) to the Import tab; base the implementation directly on the adjacent “enqueue on import” switch.
  • Add a new q_property “appendHash” to the ImportModel, which entails making a member variable, getter, setter, and signal, and declaring it as a q_property.
  • Add the same to the settings object, but this time the getter and setter are more complicated and access the settings.
  • Add the actual functionality, which involved in this case changing a structure, several function signatures, and actually writing the code that derives base-62 from the MD5 and appends it to the filename.

It’s slightly harder to create a new photo editing tool that doesn’t exist, because instead of adding a settings property you have to actually change the database schema to accommodate.

On the other hand, there are smaller UI features that could be added with no C++ at all, in as little as five or ten minutes, provided you are familiar with QML.

Developers: how involved would it be to add a new tool to your editor for someone unfamiliar?

How complicated does Filmulator sound to you?

2

In darktable all tools – we call them modules – are single shared libraries that get loaded at runtime. To add a new one you would just copy over the skeleton of another module. They differ between views (lighttable, darkroom, …), image operations, lighttable modules, export formats, … but in general it’s not that hard. Then add your new source file to the build system (one CMake file to change) and you are done.

1 Like
3

So it’s much more, well, modular than Filmulator. I guess that’s somewhat to be expected from a more mature project.

Hmmmm…

4

Yes, you can even just delete almost all .so files in the install directory and darktable will still work. Or add new ones later. We don’t provide any stable API or header files for others to link against, but in theory that would be really easy.

5

PhotoFlow is probably kind of half-way between Filmulator and DT.

Each tool is implemented in separate source files, usually one header and one source for the pixel processing, and the same for the UI controls. There is no plug-in functionality yet, although it’s in my plans. In addition, there is an hard-coded database of existing tools where new ones need to be added.

Copy-pasting from an existing tool gives you a decent starting point.

Generally speaking, from my experience the two hard parts of contributing to an existing project are:

  • understand the overall logic and program structure, and find out the pieces of code that can be used as examples
  • add some functionality that was not initially foreseen, and does not fit with the logic of the existing code

For me the second point is the hardest, and sometimes it simply cannot be circumvented.

1 Like