darktable for MacOS needs you

Software darktable
1

Dear users!

As everybody knows, darktable is a community-driven project.
One particular area that is always everyone’s not-first choice
is maintenance. Especially, maintenance of the darktable as
a whole, on a particular platform.

As it happens, @parafin has been a person solely responsible
for maintaining, and packaging, darktable on OS X
for the last 10 years.
We would like to thank him for all of his efforts!

Everything has it’s limit, and presently, it has been indicated
that @parafin wants to end that tenure, and pass on the mantle.

At the same time, there is a big roadblock on the OS X side:
currently, as requested by @parafin, the minimal required
XCode version is XCode 12.4 (LLVM10-based),
and with LLVM16 about to be released in ~April,
that puts us to 7 (sic) LLVM versions to support,
in addition to currently supporting three GCC releases.

Not only is this support matrix unsustainable,
not having a path forward makes it impossible
to someday make use of the compiler (and library)
features introduced in later compiler versions.

In summary, unless someone steps forwards and commits
to the role of OSX maintainer, we will be forced to
fully and completely stop supporting OS X,
after the next minor release (4.2.1).

If you are interested to help, please step forward.
We really need a long term dedication to solve this.
An Open Source software can only offer what
the community can work on.

Roman, Pascal.

7 Likes
2

@Pascal_Obry @parafin I’m out this weekend (FOSDEM) but I can try to contact you next week via IRC to understand the procedure, requirements and needs to try to help.

What do you think?

4 Likes
3

I’m not an IRC guy :slight_smile: And note that I know nothing (really nothing) about MacOS.

I see two main points to make the situation better right now:

  • Handle MacOS specific issues by following darktable GitHub
  • Make a MacOS release twice a year (.dmg) for people to be able to install it.

AFAIU, there is different way to build on MacOS - using homebrew or not.

The current MacOS specific issues/PR opened:

I’m not saying those are all correct, it needs some more insight and maybe some may be closed.

Hopefully you’ll not be alone, I do really hope that we’ll find at least three people to team together to make the MacOS situation better.

EDIT: I hope @parafin will have a bit of time to help you on this.

2 Likes
4

Unfortunately I am not too experienced in all that. But I would definitely support as much as I can. With this I will for sure be able to gain more experience and then over time be able to take over more tasks.

6 Likes
5

Same for me as well, I would be glad to help as much as I can.
I’m building darktable on my Mac using Homebrew.

4 Likes
6

I am hiding MacPorts for that.

7

building the macos packages is no rocket science due to the well maintained build & packaging descriptions in darktable/packaging/macosx at master · darktable-org/darktable · GitHub provided by the maintainer.
So an essential job for a macos maintainer is keeping the whole build environment (description, macos specific stuff in darktables makefiles etc.pp.) up to date. So at least a deeper know how on building stuff for osx is important …

6 Likes
8

You are not interested in a new job? :slight_smile:

2 Likes
9

I did Mac dev/admin work about 17 years ago and in the last six months had Mac dev/admin work dumped back in my lap at the office so I’m getting re-antiquated with it. Not sure my Mac specific skills are up to snuff but I recognize some of words in your post. I’ve been primarily a Linux desktop user for about a decade now but I did start off using darktable on Mac.

I am crusty and prefer ports to brew but I also have access to test Mac hardware so setting up a “this machine just builds darktable DMG” might be doable.

10

FWIW, it would be really good to do that via public automation (github actions), at least eventually.

2 Likes
11

Github is another thing I don’t really know much about as I’ve self hosted git and CI for the last decade but my org is forcing me into that world now. I’d like to help but I’m afraid I’d be in the way more than anything else.

12

I really like darktable, have only been using for about a year, but think it’s great. I started digital photography editing with traditional “layer-based” (PS style) application and have no “fixed-pipeline” (LR style) application experience. But darktable seems to offer the best of both worlds. I also like the technical fundamentals of unbounded, linear, large color space, GPU processing then fitting to output constraints.

That said there have been a few things that have made me wonder if I am swimming upstream trying to run darktable on a Mac, and if I should just sell it and move to the primary darktable environment Linux (new environment for me).

I was initially confused about the status of OpenCL on macOS, especially after an accident with a cup of tea :cry: forced me to a new M1MacBook. While this is resolved for now, it still seems like a rug that could be pulled out at any future release.

Secondly, I am still not clear how the double/redundant darktable and macOS-ColorSync color-management resolves. Even after a fair bit of investigation into the color management of darktable, GTK/GDK, cairo, code and macOS APIs. I still only have a cursory understanding, that is a lot of code.

Finally, it seems to me that Apple has a renewed interest in the mac product line, likely having saturated the other device markets. I suspect there will be more changes like the screen extension to other devices iPads/Macs which will break the underlying layers (GTK/GDK, cairo) as the “preset menu bug”. I get the basic idea behind MacPorts but am not familiar with the process and amount of attention/support they get and might be required in the future.

Not trying to be negative, just understand the problem statement and where how to apply my time/energy. While a software engineer (latterly Windows), I was a manager () and now retired. So, I am out of the loop with new tools, and never in the loop for FOSS code, and macOS APIs.

It seems like it would be a waste of resources to have everyone do everything rather than focus on be proficient in a smaller area. I would be keen to have a solid darktable on mac but not willing to give my budding photography hobby for coding to get there.

I would be interested to hear @parafins thoughts on my concerns above three items. Also, the changing build/environment mentioned by Pascal which I have no idea of the difficulties/implications and where a reasonable cutoff would be for a very small team. Thx

13

I understand the critical resource scarcity, and the writing has been on the wall for some time now. It would be a pity, though, to forsake MacOS completely as it has a huge user base among photographers (granted, Adobe reigns there, but people can be enticed… I sure was). Unfortunately, I don’t have the skills to contribute to porting. Have the maintainers of the macports darktable port (Marcus Calhoun-Lopez, mascguy) expressed any interest in carrying the project forward?

14

See information given by parafin : [Meta-bug][WONTFIX] Please resolve OSX packaging situation · Issue #13509 · darktable-org/darktable · GitHub