GTK as the GUI

[ChrisAbra]

Hi,

Short intro for who I am, feel free to skip if you dont care:

I'm Chris a web and systems developer by trade and photographer by hobby. I was initially introuduced to darktable through a signfiicant distate for subscription/closed software and was kept through great appreciation of the scene-referred workflow, negadoctor and the general approach / respect for colour and tone. Shooting film is an expensive process and great open-source tools can only help that.

The reason I post here rather than darktable is that I like most others here agree that the state of design consideration for darktable has fallen to a kind of 'tragedy of the commons' that does not suit serious people doing serious work.

The Root of the Issues with the GUI

Having studied the discussions around the GUI on darktable, Aurelien's discussions on the matter and other discussions here, I've come to a few conclusions about the issues with Design for the User Interface and believe that root cause is the use of GTK.

I understand why it was chosen, coming from Linux focused development etc., but the key problems ive identified are:

1. It's slow. Image processing is a computationally intensive task. Doing this scene-referred rather than display-referred more so. This is fine but it means the GUI should be as out of the way as possible. A significant number of Aurelien's reasons for this fork are to do with developers pushing GTK too far.
2. The skillset required to write it does not usually overlap with the skillset required to know how to use it well.

The reason, I feel, bad UI/X decisions make it into darktable are because the contributours who develop features in low-level languages like C are usually not ones who specialise in design. This is of course an awful generalisation but can perhaps be more understood from the other direction - those who specialise in UX and UI are much less likely to know how to write performant, well-architected C. I count/admit myself to that category.

This is less of a problem at a company or even large, well managed FOSS projects as the design and implemenation are usually separated concerns. The issue arises at smaller projects such as ansel and darktable where the design, implemenation and backend logic for a feature are usually contributed by a single person.

While Aurelien's work to bring logic and cohesive design to darktable is admirable, there is always going to be a barrier to further contribution from those who can assist in design and UI development, but cannot for example assist in the intracacies of the colour science and C architecture. If this project is to succeed, it cannot be a one-person effort and it needs to attract contributors who know what theyre talking about when it comes to design.

Perhaps this is simply my failing and means I am simply not fit to contribute, but that feeling will and must deter other developers so i've decided to try and open discussion on a) whether a move would even be possible b) if so, what alternatives might be better and c) whether there is any desire in the community beyond myself to do such a thing.

One option I've been thinking might be a good fit is Godot. It has extensive UI features built in (its own GUI is itself design in Godot), is designed to be cross-platform, performant on a variety of devices and is also an open-source project so no black boxes, extensive multi-language support, etc.
There is also a new Extension system for the kind of low-level code required for image processing. In fact there are already projects using Godot for image processing such as PixelOver

[lu-k]

Hey Chris,

I was digging through the wiki of this repository earlier to find the passages, where Aurélien expressed his thoughts about the use of GTK and what to do about it. I couldn't really find concise paragraphs to quote here, so you would have to read it all 😬

But a similar question also came up today in the matrix chat and I will put the question and Aurélien's reply here:
J:

after all your code optimizations you are doing, how difficult could be to implement a new gui for ansel that is more modern/portable (i'm thinking here about mac systems). i think i could help with that

AP:

very difficult, because Gtk stuff is grounded deep inside, even in image processing modules
and frankly, it's not worth it
I have only worked on the final cosmetic layer here
the deeper UI layers are all heavily dependent on Gtk
which is why I was so angry with late GUI design in dt… the cosmetic layer is so bloated and inefficient that it is unacceptable

[ChrisAbra]

I guess this sits with the core tension of wanting to have something usable and free of as much guff as possible today and the ability to maintain into the future.

The GUI and the core image processing stack should be fundamentally separated. I guess with the GPL licenses it'd be possible to port the core code, but again the knowledge required to do so properly sits with a limit set of people. And while far be it for me make suggestions on where to take the project, that seems like the effort which holds the most promise and should, to me, hold higher priority.

[lu-k]

Taken from the Wiki - What is not Ansel:

It is not a hot project : I consider darktable's development (and therefore R&Darktable's [Ansel] one) roughly 90% finished, meaning it's close to feature-complete. We are reaching the limits of its initial design & architecture regarding how much we can still extend it without actively harming performance and stability. The goal right now is to polish existing features, fix the worst usability pain points and the low-hanging fruits, then keep it stable pending vkdt's availability.

[aurelienpierre]

TL;DR Gtk is not great but it's manageable when used responsibly. Problem is it's not. Too many Gtk widgets are forced to be redrawn all the time, and that's 100% programmer error.