Module Group Improvement Mockup

Two questions,

  1. If a non-dev wanted to submit a mockup what would be the proper process? As an ‘issue’ in github?
  2. I hear the ‘write your own code’ argument a lot in response to suggestions. Assuming say, 8hrs a day study, how long would it take someone comfortable with Linux/FOSS software, image editing, and an intermediate level of colour science, but no coding knowledge, to learn GTK+ and C (or any other combination, say QT and C++) to the point where they can actually create a workable GUI similar to the current sophistication of darktable?
1 Like

Absolutely not. darktable doesn’t go to a graphic illustration program. It’s a raw editor and darktable just try to make it the most advanced one.

1 Like

I suppose many years if you don’t have any previous experience in any other language on top of some background technical schooling (maths, physics and so on).

I, for one, know only a bit of Python and SQL and it took me many months to reach a very basic knowledge of their ins and outs. Yep, maybe I am not the smartest kid on the block but it really takes a lot of time…

If I may crack a joke, all in all, it is much more convenient for you to pay someone to do the job and avoid long years of studying (with the consequent lack of an income in the meantime…) :slight_smile:

1 Like

Introduction to programming:
Common Lisp: A Gentle Introduction to Symbolic Computation

Introduction to GTK+ 3:
GTK+ 3 Tutorial for Lisp

If additional help is needed, one can consult these:
The Common Lisp Cookbook
Object-Oriented Programming in Common Lisp

One can understand the basics quickly this way - give it 1 month or more (depends on the person). Lisp languages have much simpler syntax. One could try loading a JPG file and GMIC as a library and performing some changes, for starters. This should be enough to understand GUI programming to a certain degree.

Speaking of Darktable, the current fuzzy search implementation is quite comfortable to use. Perhaps common operations could be named in layman terms (keywords, tags) and when the user types what one wants to do, one gets suggestions. E.g.:
“vivid” / “rich” → velvia, color balance, vibrance, color brightness saturation, …
“brightness” → exposure, color brightness saturation, …

1 Like

Hello @subliminal

One could try loading a JPG file and GMIC as a library and performing some changes, for starters. This should be enough to understand GUI programming to a certain degree.

Yep. But if you want to contribute to Darktable as a programmer, in my view, you also need to learn how to read and understand the other code from the other Darktable developers. On top of this, you need to know how to debug their code, write unit tests, know how GIT works (to pull your requests and so on) etc etc.

In my view, as long as you stick to writing some very basic program, for yourself, to learn the ropes, it is not much diffucult and time-consuming. However, contributing to a software as complex as Darktable (GTK 3, C, C++, , CSS etc ) is a very different stuff, in my opinion (unless you are already a programmer by trade…)

Well if you read what I wrote, I was referring to painted raster masks. That you can paint with a wacom, like you can in an illustration program. And that’s happening afaik.

Absolutely @Silvio_Grosso

However, one could make interactive mockups that use existing libraries.

I guess it would be here to get scrutinized and pass the court of public opinion. If that happens then github would be the next step. You could do it immediately on github if it’s a small change or a fix for a bug.

I think aurellien said it took him 5 years to be able to do what he does in DT (with all that it implies) and he has done an engineering uni. So it’s quite hard. I know a few languages but I still cannot write C. I’ve tried but if I’m not using it regularly for my job etc I just don’t learn it. I start learning it, then after a few weeks I forget it b/c I need to learn yet another stupid javascript framework and don’t have time for C.

That said I’m learning Rust atm. I hope DT would accept something written in it but who knows.

But this is only one par of the coin, understanding at times very complex math and color science with best practices and such is a whole another problem that has to be mastered. It’s easy to give up when one considers all of that.

So when they tell you “program it yourself”, don’t worry, they just don’t understand that they are not humans, they may be demigods, aliens or even mutants idk. :crazy_face: :crazy_face:

1 Like

These books should help you understand the basics of C, C++, data structures and algorithms:

To create something like Darktable, you’ll need domain-specific knowledge (maths, physics, etc). But if you want to work on GUI only and not the underlying algorithms (which would take good many years to learn), then learning C / C++ and GTK should allow you to create what you want (a different interface).

Nope. I tell you a secret. In reality it is way much more simpler then that…
It is a “coded sentence”, which means “mind your business”. It is usually reserved to some, most likely Windows users, who are pestering the developers too much with their constant requests. Since coding require many years of learning they are sure you will be busy with this learning process and you will leave them alone :slight_smile: :slight_smile:

joking aside, in my view, if some “layman” wants to do some contributions to Darktable he is right now blessed with the option to write some LUA scripts. There are already many of them and by simply reading them you can get started.

From a psychological point of view, there’s this:

I haven’t really seen the manifestation of Dunning-Kruger that often. Usually those people give up quickly b/c competence is what you need to achieve the result in the end. I’d say DT devs are very competent. People that tend to stick around usually are. Each with it’s set of interests that is.

I know you’re joking, I also have the feeling that everyone who has said that, did not mean it like that (maybe a tiny bit).
But for everyone trying to contribute something it very well feels like that.

In that regard it’s good that you pointed out LUA scripts, which for many is a more viable route to contribute more. :+1:

If you have any aptitude for coding, learning a language shouldn’t take 5 years (I did a university-level course that took you to a basic level in about 1 year or less, with a lot more than just coding in 1 language), @anon41087856’s 5 years contained a lot more than just learning to code in C.

But just knowing the programming languages isn’t enough to contribute to a complex program like dt, you also need to understand at least the basics of the structure of the program you want to contribute to. That takes time as well (and can be rather frustrating in the beginning).
Then you have to know how to deal with the infrastructure (Git).

All in all, knowing the coding part is a necessary start, but not enough.

That said, depending on where you want to contribute, you don’t always have to know the ins and outs of colour science, or advanced maths. There is quite a bit of other domain-specific knowledge involved in dt (e.g. metadata, database, interface design, …).

And indeed, Lua might also be an interesting starting point (but then, I don’t know Lua at all, I’m more into C++)

I have started looking at learning Lua. So far, it has been very easy to understand.

Also, I use the Awesome window manager, which uses Lua as its configuration language. Even before starting to learn Lua, I had no problem making changes to it.

Are you aware of Picture WIndow Pro 8?? CHeck it out if you are on windows. It is an updated version of a program that has been around for a long time. It has some quirky interface elements and some elegant ones…its uses a tree like image preview that allows reordering splits and branching and bypassing all of which can be saved as a script…THe creator is Jonathan Sachs of Lotus 123 fame. Its a cool model and it can be displayed on a second monitor so for example you can develop duplicate images in the same edit with a branch…take them so far in a common one and then branch say trying a different approach for the rest of the edit. He is just updating the raw camera support currently. It has all kinds of masking and other elements but the overall application of modules ie transformations in his terminology is a lot like what you are asking for I think. In this way developers could package a defined pipeline and still allow full customizations…it is not open source but it is free with no strings so you can take a look at it…its a neat concept…explained here https://www.dl-c.com/Documents/Picture%20Window%208%20Tutorial.pdf

Well, I have successfully been deterred from that undertaking, haha. If it is going to take years I would need more security about where I’ll be in life a few years from now to know its worth working towards, which I don’t currently have. But I thank those who answered and provided learning resources. I made note of it all, and should my circumstances change, may take it up at a future date.

You make a good point. When I have more money :laughing:

I don’t think this is such a joke, haha.

I am using darktable for at least 6 years now. Maybe I simply adapted to it but never felt these points to be relvant issues, but this is just my opinion and other user may feel different about it.

Nevertheless, let’s take a look at the recent improvements regarding the organization of modules. You can basically create as many or less groups as you like and place any module in any group. Modules may occur redundantly in multiple groups or not, it is completely up to the user.

Just as an example: This is my current configuration of module groups (still evolving, but seems to work most of the time):

The “base” group contains the modules, which I use regularly and which are sufficient for most of the time. The “secondary” group contains some modules, which are rarely used or I intend to play with. The third group is targeted to processing film negatives. Hence if I was focused only on digital photography I would probably only have two groups.
Nevertheless, the group for negative processing illustrates the benefit of adding modules redundantly. Crop and rotate for example is pretty important in general and in particular for processing negatives. The idea is to switch between these tabs as rarely as possible, when editing scanned negatives or digital photos. And here I enjoy being able to change module parameters right in place with short ways and adding new instances quickly. Maybe there are some inactive modules in-between, but I configured darktable to only open one module. Hence these are not in the way and not too much scrolling is required. And I think the scrolling is an acceptable price for the benefit of having all my modules ready at hand, instead of having to select them again and again for each image (unless I copy/paste them).

If I want to focus on the actually active modules in my current pipeline, I can simply switch to the respective tab. I rarely do this however.

Regarding module discovery: IMHO, the best and most efficient way to discover modules is the manual. Whenever I read such usability discussions, it feels to me like a manual is considered as some kind of outdated way to explain users how things work. In fact if it is a good manual like darktable’s it is extremely efficient and the direct and simple way. So a very good onboarding screen might be a big and fat “RTFM” “RTEM” (Read the excellent manual).

In my opinion, it is not a strong argument to refer to other applications and what they do or don’t do. But anyway: I have been playing a bit with Capture One during the last days in a Windows VM (what a PITA to download a test version).
One thing I noticed: The way the “tools” (not exactly the same concept as modules in dt) in CO are organized appears to be pretty similar to darktable’s current approach. Like in darktable, you can add and remove tool tabs and you can place any tool in any tab. Also redundantly. Tools, which are removed from all tabs appear to be effectively hidden, but can simply be added back.
Same in darktable. Even if a module does not appear in any group, it can simply be added (even without entering the group editing tool. Simply do a right click on the group icon and add the missing module… another quick access next to the search). Therefore I don’t think that darktable hides features more than CO does.

4 Likes

Also, in darktable there are reasons to hide some or even many of the modules.
Some of those modules are legacy modules, but have to be kept around so old edits stay valid. But you don’t want them polluting your interface. And perhaps they shouldn’t even be selectable (like the “deprecated” group) …

Some duplicate (more or less) functionality that is present in other modules. You’d want to keep one (or two) of those around in your setup, not all of them.

And some might just not fit in with the way someone works, or you don’t have the knowledge/experience to use them (Lut and colorzones would fall in that category for me). Again, no need to have those clutter your interface.

Why change a perfectly well known acronym? Everyone should read the fabulous manual :stuck_out_tongue:

1 Like

While I agree that the manual is great, I don’t think it’s “flashy” enough to have just a big fat “RTFM” on the onboarding screen. Users will most likely interpret that as being toxic.
Also, yes, onboarding is a more immediate matter than the module groups which work completely fine but could be much better imo.

And it’s easier to propose a new feature than to modify something that the users are already used to. Even if it might be for the better.