Well, you want a “cutoff” - vkdt is it.
1 Like
well yes vkdt certainly cuts off radically… and it’s of course great fun to start from zero and do everything the way one would do it in this day and age.
but it doesn’t solve the data safety issue. i think people’s edits are important. it’s this software engineering thing that the data is more important and longer-lived than the program used to create it. vkdt doesn’t even attempt to load dt edit history.
now unfortunately just discarding dt with the idea “you can keep the old executable” is not going to work for long. and compiling an executable that requires gtk3 (even for command line mode…) is also probably working for some time into the future. i’d expect the need for some constant maintenance though.
6 Likes
Indeed. darktable is much more than a source tree; it’s a community of devs and users, and a history that cannot be arbitrarily discarded.
I know the ‘one-man-band’ thing, that is the community that is rawproc. I’ve broken backward compatibility a couple of times now, and it has given just me such pain… 
. I think there are a couple of folk using rawproc’s G’MIC tool now, haven’t heard angst from them, yet…
4 Likes
I couldn’t agree more. Removing features from any software breaks user-space — always add; never subtract. If you want to remove stuff that you personally don’t want or need… well, that’s what forks are for!
Added the #darktable tag since OP and topic mentions it regularly. Free free to propose or add more to make the thread more searchable.
There are at least two major downsides to this philosophy:
- You cannot know upfront whether something might become obsolete in the future. Not being allowed to take away legacy code becomes an increasing burden of maintenance.
- Feature creep or bloat. If nothing can be taken away, you eventually end up with an application that is a behemoth that neither the users will fully grasp, nor the developers. This is a loss of value.
The easy solution? Make sure older versions of the software remain available for those who need to be able to open their old files. The only snatch here, is when OS’s evolve and it becomes no longer possible to load the old software.
I never said anything about usefulness. However, at first glance and without any experience with the underlying theory, I am doubting whether anybody can understand what kind of results they can expect from all the sliders and buttons in some of RT’s modules. This adds to the perception of a steep learning curve. Edit: and my actual point was that Eddie compares RT favorably to dt in this regard, while I argue that we’re not necessarily better.
2 Likes
That’s fine for processing features. Keep the old code around, by all means. And keep it hidden, so new users aren’t confused by it.
But I don’t think that’s a reasonable strategy for the rest of the UI. So long as most use cases remain viable, please do iterate on workflows and organization. On occasion, it might even be beneficial to break an obscure use case if that materially improves an important one. We do have to break things to move forward sometimes. Remember, darktable is not a CLI tool that is deployed in automated scripts everywhere. It’s a GUI tool used by humans. We can deal with a bit of change. Can appreciate it, even.
Just don’t invalidate old edits.
This is, by and large, what darktable has been doing, already. The UI has massively improved in the last few years, if you ask me. The custom panel, the keyboard shortcuts, the pipeline presets, the expanded Lua scripting abilities, all of those are great, and have made my work tangibly more effective!
There’s also a balance to be struck between catering for new users, versus optimizing for experienced workflows. What with no monetary incentive to attract new customers, Darktable is sensibly leaning towards the latter. This is, frankly, a breath of fresh air in photo editing tools, which seem to be generally drifting towards oversimplification.
All this talk about making things easier for new users reeks of capitalist Stockholm syndrome, honestly. Darktable is, for better or worse, a complex tool for competent users. There are easier tools out there for different folks. Darktable doesn’t have to be all things to all people.
2 Likes
A valid counter argument, indeed; however, I stick by my statement — based on (too many) years of experience, I have found it to be the lesser of both evils.
1 Like
That’s pretty much what I meant — sorry; I should have been more clear.
I completely agree — as long as the legacy stuff can still be easily accessed, of course; there’s little point in keeping it if you can’t find it! 
Only if you’re moving forward without looking where you’re going!
Thank you. This is a much more elegant way of restating on of my main points!
The compatibility mode will let a lot of old simple programs run but not all of them. Some programmers used techniques in the bad old days that Windows won’t allow now, and the compatibility mode can’t patch over.
RT’s “basic” modules are standard and well understood by moderately experienced users and are put in clearly marked tabs by their general function. The more specialized ones are in separate tabs; they complement some basic functions like contrast and color tuning by using a different technology, but they are not replacements/duplicates for them.
There are way fewer modules in RT compared to dt and RT doesn’t carry along all its obsolete and deprecated modules that only muddy and complicate the learning curve. It’s much easier to learn!
Not just compat mode. I’m talking about shims:
These are shipped with Windows, overwrite file system access, replace libraries, patch over individual function calls, and much more. It’s crazy stuff.
I don’t think it’s unreasonable to expect a software to maintain ability to process it’s old operations and ordering.
That said, then there’s also a user responsibility to comprehend these differences over time. I regularly go to open-source* renditions I made years ago, and the first thing I usually do is to change out the processing toolchain to what I currently use to go forward with a new rendition. For example, early rawproc relied on dcraw to do the operations up to demosaic; that still works, but I don’t prefer to perpetuate it…
*open-source: In rawproc, renditions (e.g., JPEGs) have the source file name and the processing toolchain stored in the metadata; when rawproc finds such, it asks if you want to open the rendition, or open the source and apply the toolchain. The latter choice is “open-source”; there’s also a menu selection for it.
2 Likes
This is an interesting discussion but I think you are getting too stuck in your positions. As often happens the truth is a compromise, so continue developing the software (whatever it is) trying to improve usability. Just my opinion.
Regards. Roberto.
3 Likes
I have no ‘position’ on this whatseoever — just offering some insight as someone who’s learned the hard way.
And they ARE BOTH evils. There are no right or wrong answers to this — even a ‘compromise’ is far from an ideal solution, if you think about it logically (everyone has their own opinion of what a ‘fair’ compromise is).
Personally, I’m just forever thankful for everyone who has selflessly given up their own free time to produce all of this extraordinary free software — without whom, there would be no debate, no pixls.us, (and, for me at least, no camera in my camera bag and a lot less happiness in my life).
I will say this, however: this really is an interesting debate, and it’s given me a great idea for an article!
Many of the responses, here, have really helped me appreciate the dilema from both a developer and user perspective - there have been some really excellent cases put forward right across the board!
1 Like
Mea culpa, sorry, I’m not a good writer or good debater! I should have made it clear that I wasn’t referring to the most common, least technical basic modules like crop, rotate, basic exposure, etc. but to the more esoteric ones that mostly deal with color in one way or another.
Even so, that is beside the core of my fuss: due to a totally arbitrary decision dt has acquired a significant amount of unnecessary and even harmful bloat that has greatly degraded its usability, and is on a path to acquire more and more into the future. Even without the bloat dt would be a difficult piece of software but the bloat is just making it worse.
Every operating system and every program in existence could be 100% compatible with all previous versions if users were willing to make the required compromises. dt’s powers-that-be have decided that dt will be and that users will have to adjust, period, end of discussion. Thankfully the developers are doing their best to mitigate the damage with various UI changes but as long as it is on this path dt will never be the lean mean machine it could be, it won’t have the ease of use, the accessibility to all that it could have had. The price of admission will remain very high.
OK, that’s the way it is. A pity. I’ve made my rant and am done.
1 Like
I’m playing with Darktable, and my verdict after a week
Hmm, yes. Well that instantly turns the rest of this discussion to mush. Would you expect to be able to judge Photoshop after a week of laying eyes on it? Any other pretty advanced piece of software? Why would you even …
4 Likes