Inkscape developes have hired a developer, for a few months, to port their software to GTK4.
As of today, this port is not still 100% working due to many bugs especially on Windows and Mac. For Linux the situation is much better since this platform is much more tested.
Perhaps, some features of darktable will be dropped or improved due to this massive change to GTK4.
Needless to say, it will take months to succed, because the work to be done is huge.
Just my opinion, of course (not a developer here…)
I leave it up to the developers and maintainers to decide what they can keep and what is no longer viable to keep. I have no problems with the responsiveness of the DT interface. I have setup my own module tab layout so anything that is bloat to me is hidden.
But what is bloat to one person may be a standard module for another. To me filmic is bloat, lets get rid of it because we now have AgX. Hmmmm…I can imagine how well that suggestion would go down.
There are probably very few modules that are truly bloat. The reason we all like DT is that we are given choices and options of what modules we want to use to get the task done.
Again I really appreciate AP’s contributions but it was a shame how he chose to speak to the other developers and ridicule their work. At least now he is not held back by others and can develop Ansel how he sees fit.
It’s not possible to remove processing modules, though they can be deprecated. Most of the things I would get rid of are features unrelated to processing modules, mostly UI stuff. Not going to get in to the list here, but a lot of them are also in Aurélien’s list.
Well now that the devs are working on the GTK4 port, it think it would be less work for them if some really deprecated modules would simply be removed. It is definitely possible to remove modules, technically at least, I myself created such a fork some time ago, but I’m not continuing the work, I am kind of too lazy. But just think how much less work it would be for porting to GTK4.
Yes, that’s the question we should discuss. I mean darktable really has A LOT of modules and they all need to be ported to gtk4 if we don’t wanto break backwards compatibility.
Maybe it would be a good strategy to first create a version of dt/gtk4 that has fewer modules, and then with time also port the other less important modules to gtk4 as well?
As far as I remember that’s not so difficult in theory, having two versions of dt.
Depending on what old means, I have no problems with that. It doesn’t make sense to guerantee an everlasting backward compatibilty. On the long run this is probably simply not maintainable anymore. Why should I keep the edits from 15 years ago. The world moves on and so does darktable.
I think the gtk4 port is more about the building blocks that all the modules use, so I doubt there will be big rewrites of internal module logic either way. It’s more porting darktable as a whole to gtk4 than porting the modules one at a time.
Anyway, this is why I wanted to avoid making this a list of darktable gripes, because this is probably not the thread to discuss that in detail?
Yes, but the gtk code is inside the module’s files, I don’t think that the whole code has to be rewritten but the gtk code is actually not seperated from the rest of the code, there is no seperate gui file. afaik the gtk code is mixed up with the c code and it’s still unclear if porting to gtk4 is even possible. Some guys started to work on it but it’s now known when they will finish it, maybe it will take years. In any case it’s a lot of work.
I also think that dt development has to be frozen/stopped while porting to gtk4 is happening.
There was a time when I felt Darktable to be slow and sluggish. Indeed I got so fed up with it, that I used a different raw developer for a while. When I came back, I bought a new computer mostly for the purpose of speeding up darktable.
As it turned out, I was perhaps a year ahead of the hardware curve. A new computer today (with DDR5, shared with a fast integrated GPU) runs darktable very well indeed. But when I bought one, this was still limited to the high end of the market.
Thus, some problems solve themselves over time. Of course there are other aspects of bloat that do not pertain to runtime performance, which require developer action.
It’s not just about being able to edit, but display and export. If the module code isn’t there, and no JPEG was exported, that edit is gone forever and can’t even be seen in darktable, much less exported.
Remember the second part? It’s a different 10% for each user…
I may have selective memory, but I can’t remember any feedback from AP on the shortcut framework, not at the “design” phase nor when the PR was out there for many months. Not even when I specifically asked if it addressed an FR of his (#1967). So if you can find any instance where I responded defensively, I’m happy to apologize. Or to feedback on any of the other changes I submitted (that were merged). I do like to think that I worked with you (just as an example) constructively. Even if it didn’t make shortcuts part of the 10% of features you wanted. The only remark I remember seeing from him is that he seemed to like the idea of key+mouse move. The vitriol only started after the fork. Maybe he realised he’d now have to maintain something he did not understand at all and couldn’t ask the original developer (who was clearly stupid anyway) for explanations. Yes, the fact there is no documentation within the dt codebase is a large issue. It probably predates all of us and isn’t easy to solve. One can start documenting the piece one contributed, but since there is no standard (so nobody would know where to look for it) and no “requirement” to keep documentation in sync with implementation, it would quickly get out of date. And any programmer knows that documentation that lies is worse than no documentation. Plus, if nobody reviews or gives feedback on PRs, what’s the hope that you’d get feedback on documentation. So you’d be spending time on writing something that you have no idea is going to be of any use to anybody ever.
I agree too; I would have loved that and the result might have been (dare I say “even”) better, but it’s hard to have a discussion when only one “side” engages.
I recognise sarcasm when I see it, but you do realise the port is being done for the most part (so far) by the person who was responsible for most of the overly-complex ui features in the first place…
Have you tried the draft gtk4 PR? It is out there so that everybody has a chance to form an informed opinion. You’d find that most modules already work without problems and the main issues are with generic components, like menus, dropdowns, collapsible sections etc. Quite a lot of work had already been done in the past to make that happen. Some might call it “interdependence”; some might call it refactoring, so that changes only need to be made centrally.
Since dt has no budget or finances, the way this would work is that people would set up a fund raiser with a bounty attached. Or maybe that they’d work with a candidate to get a google summer of code project approved. The result would be a simple (set of) PR(s) that would be submitted and reviewed/merged/adapted as normal. Unless they’d prefer to set up their own (temporary) fork.
So as always, the answer to all the above suggestions consists of two questions; “who?” and “what?”. Who is going to do the work and what is stopping them from doing it now. If your answer to the first part is “well, the developers/maintainers of course” then ask yourself the further question “why are they not as exited as I am about them spending a large chunk of their free time on this particular thing?” Until you’ve really understood that you are probably not in the best position to try to make them. And whether they already largely agree with you or not doesn’t change any of that.
The problem with AP was never really his technical prowless. It was how he treated and communicated with other people, 100%. He failed to influence the project to adopt and implement his ideas because he treated people poorly.
All other talk of what is or isn’t bloat or what is good or bad from a technical perspective is moot when you can’t communicate your ideas in a civil manner.
Wait, the shortcut framework was your idea? Thank you SO MUCH! If you should ever visit southeastern Germany, I’ll invite you to a beer (or something else)! That actually goes for all of you.
Present object of discussion notwithstanding, this is an exceptionally friendly community.
I agree with you about Aureliens behavior, he is full of negative energy, but be careful with judging people, you never know the reasons for their behavior.