darktable article lede image
Introducing the darktable app store
houz

Introducing the darktable app store

Today we are happy to announce a big new feature that we will not only ship with the big 2.0 release later this year but also with our next point release, 1.6.4, which is due in about a week: even more darkroom modules!

One of the big strengths of darktable has always been its varied selection of modules to tweak your image. However, that has also been one of the main points of criticism: too much, too many and too complicated to grasp. To make it easier for the user to deal with the flood of tools darktable has had the “more modules” list since many years. It changed its appearance a few times, we added module categories, allowed to select favorite modules, and all of that has proven to be useful. Thus there have always been people that approached us with great new ideas for new modules, especially since we moved to GitHub a while ago with its powerful Pull Request system, yet we couldn’t accept many of them. Some were not that great codewise, some didn’t really fit our product vision – and then there were some that looked nice and certainly benefited some users, but we felt it wasn’t generic enough to justify polluting our module list even more. Of course this was a bad situation, after all these people invested quite some time into providing us with a new feature that we turned down. No one likes to waste their time.

![In the default state the new dialog doesn't clutter the gui](screenshot01.png "In the default state the new dialog doesn't clutter the gui")
In the default state the new dialog doesn't clutter the gui

After initial discussions about this topic at last year’s LGM in Leipzig we started working on a solution later that year and now we feel confident to present you the new module store. Think of it as an in-game app store (for all you gamers out there), or Firefox' Add-On system. Instead of bloating the list of modules shipped with darktable you can now easily browse for exciting new features from within the darkroom GUI, installing new modules on the fly (or uninstall them if you don’t like the result), and even see previews of the module’s effect on the currently opened image. We are certain that you will like this.

Who will also like it are module developers. Writing new image modules has always been quite easy: clone the darktable sources, create one new C file and add it to the CMake system. But that was only the first part, after all you wanted to allow people to use your work in the end. So you either had to convince us to include your module into the official darktable release (with the problems outlined above), or provide a patched version of darktable for people to compile themselves. In theory you could also have provided a binary package or just the module compiled into a shared library for people to just copy to their install directory, but we have never seen anyone taking that route. With our new module system this will become easier. Instead of creating a patched version of darktable you can now make use of our Module Developers Package which contains all the required header files and a CMake stub to quickly compile your module into a shared library that can be used with a stock installation of darktable. And since we will release these files under a LGPL license you could even write non-free modules. Once you are happy you can submit your code for us to review (this step is still manual to prevent malicious code being shipped) and once we approved it everyone can install the module.

![Currently there is just the one module in store. More to come!](screenshot02.png "Currently there is just the one module in store. More to come!")
Currently there is just the one module in store. More to come!

All of the things described until now are implemented already and will be part of the next releases. Once it has proven to be working reliably we also plan to allow developers to make some money with their work as an incentive to attract more and better developers to our community. We are currently evaluating what payment models would work best, at the moment PayPal looks like a strong contender, but we are open for suggestions.

In case you are curious how it’s implemented, it is based on the GHNS system that is already used by KDE and others, and might eventually also be merged with the styles you can find on https://dtstyle.net/. On the server side there is a continuous integration system (Jenkins in our case) that recompiles everything whenever something got changed, taking care of the different target architectures and operating systems with their dependencies. And if you don’t want to wait for the release just try a development build, the code is merged and ready to be tested. As a first example we moved the new “color reconstruction” module from the regular darktable installation to the store.

PS: Thou shalt not believe what got posted on the Internet on April 1st.

Filed under: announcement blog development upcoming feature
These are comments from the old website, archived as static HTML
  1. This is really awesome. I'm excited to see where this goes. One question - I know that the order that the moduels are applied in is set by darktable and cannot be changed (the pipeline), so when are these new modules applied in the pipeine? Or does the module developer have control over that?
  2. Carl Morgan on Wed Apr 01 07:31:22 2015:
    Nice 1th April joke
  3. Currently the author has to hard code it. It would be nice to allow something more dynamic but that has to be discussed and designed first.
  4. Hey, I bet this is an April Fool's joke.
  5. but really, what would be cool is some sort of integration of dtstyles.net into darktable (sorted by most downloaded, but split into bw vs colour)
  6. Awesome!!

    I think the darktable team should implement a system to undo (ctrl + z)
  7. [And since we will release these files under a LGPL license you could even write non-free modules.
    ....
    Once it has proven to be working reliably we also plan to allow developers to make some money with their work as an incentive to attract more and better developers to our community. We are currently evaluating what payment models would work best, at the moment PayPal looks like a strong contender, but we are open for suggestions.]


    To me the plugin method seems nice (but i wouldn't call it a store), but this way it doesn't sound good... a donation system would be imho nicer, but always for free software plugins, not closed source and nonfree modules.
  8. Oh wait... I really thought this was an April Fools' Day prank :/

    Are you really saying that the best open-source raw developer on Linux is going the way of Windows Store, Apple Store, Google Play and other crapware distribution stores? I believe the reason most people use Linux is to escape precisely that.
  9. Hey I thought this is a 1. April joke too. But if this is true, I am excited about it. I find it good that people can earn money from it; there is nothing against that idea.

    For the payment part, I would only pay per PayPal. Nothing else at current time. I pay with it nearly on a every second day routine.
  10. I love the concept guys, and look forward to seeing what it brings.

    That said, is this a step toward monetising the project? Is that such a bad thing? I am not sure.

    Do you think in the future we might see better masking control in DT? Snapseed (now googlised) uses 'control points', that are pretty neat mask tricks.
  11. free software can also be paid. It is a way to attract people. But if you pay from a module with free software license, you can send the code of module to your friends or all comunity
  12. Really this is a joke?

    Fuck my life
  13. So, can someone clarify? Is this real? The news page does not show version 1.6.4, but I have it installed.
  14. See the "PS" that was added :)
  15. Interesting concept. Pity that this was the 1 April joke. Still good luck with this one!
  16. Too bad it's a joke. A nice thing.