After Version 1.0

User Interface

look and feel

needs a serious overhaul, for a more balanced and uniform look, as sketched in the GuiGuidelines


The whole ui has been refactored into modules so we do not have any single
ui element hard coded into a place, this does however make us to have a structure
of what goes where and we need to settle such a structure.

We do have 2 toolbars top and bottom which each are divided into 3 containers
left, center and right which are aligned to the left, centered and to the right
of the toolbar container.

Each of them should have a rule of what tools go into them, here follows some definitions:

Global tools - a tool that is globally accessible thru all views of darktable eg. preferences
View tools - tools that only make sense to have for the current view
Plug-in tools - tools that are presented by a plugin, like for a example "quick snapshot" button in darkroom ...
Current tools - a tool which depends on what module is in focus for example

Example of layout of toolbar:

| <view tools>       |       <view tools>       |          <global tools> |

| <plugin tools>     |      <current tool>      |          <plugin tools> |  


image compression

to make caches more memory efficient, dxt1 could be used. we have floating point compression in src/common/image_compression.{c,h}, but maybe libsquish (sse optimized) could be better even.

Job queue

We need to have a queue that will be prioritized in favor of the standard job queue so that when darktable core / mipmap cache whatever is working hard the user
started jobs should be prioritized and executed before the core queue is continuing stealing resources while processing ...
Probably this is simplest implemented by adding an additional queue where prio jobs are pushed to, and when workers are picking jobs they should first pick
from prioritized queue if there are jobs available there.

on-demand xmp writing

this should only happen when needed (hash changed or something). the old dirty-bit is too error prone, we need to compute hashes every time, and store the written one in the image cache for example (eviction from the image cache means xmp sync, so no sql needed).


Image selection

Image selection behaviour is pretty strange and can lead to strange results due to
it's fully possible to have images selected in other collections not shown to the end user.
This is error prone if for example someone has a few images selected, and changes
the collection and finds two images he wants to physically delete, he ctrl clicks
each of them and hit delete button and images selected before this two will also
be deleted ... :)

Image grouping

Tobias (Houz) has made a test implementation of grouping of images we need to
discuss and draw the line of how this should be done and functionality in
darktable, whats the use for it etc. ?!

image compression

to make caches more memory efficient, dxt1 could be used. we have floating point compression in src/common/image_compression.{c,h}, but maybe libsquish (sse optimized) could be better even.


similarity branch


abstraction of general processing operations

I think we have at least 4-5 different kinds of blur implementations with varying quality / speed and methods, the last one introduced was with lowpass filter
and it includes both opencl and sse2 codepaths, we need to abstract such kind of commonly used operations for reuse.

The modules using a blur implementations are: bloom, sharpen, soften, highpass, lowpass

image operators modules

- Time to merge modules, for example velvia/vibrance/color correction could be smashed into one module. and there might be others.

simple user interface

We have spoken about this a lot of times and it is all about having the most commonly used controls up front for a standard workflow,
simple ui would be something like its own module group without any modules, just a big panel with stuffed controls ...
I'm not talking about every control from every iop here, just those carefully chosen, the panel would have a label header named
like the groups:

-------------------/ Basic |

[ exposure   |        ]
[ black      |        ]
[ exposure   |        ]
[x] highlight recons.
[ temperature|        ]

-------------------/ Color |
[ saturtion  |        ]
[ vibrance   |        ]

-----------------/ Correct |
[ sharpen    |        ]
[ contrast   |        ]
[ local contrast   |  ]


Live view

It would be a great advantage to have a liveview present on screen, gphoto2 supports it but how many camera models are supported!?
Investigate if it is worth the time now to implement ...

Close-up module

A module showing 1:1 around mouse pointer for close up pixelpeeping to detect bad focus, this might also be something for lighttable.


Also available in: PDF HTML TXT

Go to top