RIP DisplayCAL ?

Software
1

With Python 2.7 being officially and entirely deprecated since January 1st 2020 , all the distros released in 2020 have removed it from their repositories. However, Python 2.7 is a hard dependency of DisplayCAL in rather convoluted ways: while it’s still possible to self-compile Python 2.7 and fetch most of the required packages, the blocking dependency is Python-wxWidget which needs a script (“wheels”) to be built for the relevant Python version. I never managed to make it work on Fedora 32.

Bottom line, by 2021, most people on Linux will have no way to profile their screen. Sure, ArgyllCMS works in command line, but let’s be realistic here : we are talking about display management for artists. Please, git people, calm down.

The DisplayCAL’s dev, Florian, has given his latest proof of life in January 2020. Nothing has happen on SourceForge since then, no new release, and no news of migration to Python 3.x and he didn’t take any help offer, back in 2019, to migrate the code.

My experience with migrating Python 2.7 to Python 3 is it’s usually a matter of running the official 2to3.py script, manually fix a couple of slang changes, and done. However, DisplayCAL heavily relies on bindings with C libs and such, so I have no idea how convoluted it is inside.

Bottom line… Does someone has news about the state of the project, the migration status, and such or should we bury/fork that beautiful piece of soft ?

[rant]Python 2 deprecation was only planned since 2008, first for 2015, then pushed to 2020 in 2014. Almost nobody saw it coming…[/rant]

8 Likes
2

Florian Höch | DisplayCAL last post is just two months old …

3

More like last week.

4

how did a comment on the forum help with the fact that the python 3 port is still pending and that more and more distros will drop displaycal.

A more relevant link would be #17813 (Feature Request) Migration to Python 3? | DisplayCAL , which saw the last change from Florian is 1.5 years ago.

1 Like
5

IIRC this only applies to DispCalGUI. The command-line displaycal program continues to work, and can still be used to calibrate and profile screens.

3 Likes
6

I ran into the same problem myself recently. OpenSuse 15.2 still has DisplayCAL in their repositories, Tumbleweed dropped Python 2.7, so no DisplayCAL available on the rolling system.
What helped me, was this article using cli to calibrate/profile the monitor.
As I am just a user without deeper knowledge here, at least I can say, that I ended up with a display-profile, that seems reasonable (selecting it on and off shows sane color changes) and works under Plasma (single display setup).

I was wondering, if an appimage could be of a help here. If Python 2.7 gets statically build into the package, shouldn’t it become independent of the distributions sources? Would that be a workable hack until python 3 is implemented? Besides the technicalities, are there security concerns thinking that way?

3 Likes
7

Shouldn’t this be more a matter of asking @fhoech how we can help move displaycal to py3, instead of proclaiming its death?

15 Likes
8

Well, I don’t know what your plans are, or whether you want to declare DisplayCAL dead or not. Truth is, there hasn’t been a new release in a long while, and this affects Linux users (macOS and Windows people have no reason to care, as the current version just continues to work fine, like the infrastructure surrounding it, and I put the necessary work in to make sure this continues to be so). It matters little for my own plans (which do involve Linux still, but obviously not a priority).

The more interesting question is: How long can you hold your breath? For myself, I don’t consider a year a particularly long time. But that’s just me. Also, given the state the world is in right now, should the availability of a piece of software for a particular platform at this time really be such a big concern?

I do realize me kind of saying “so what?” is probably not the response you were looking for, but it is what it is.

Ask away if you have any questions.

4 Likes
9

Yes. Artists, who tend to work freelance, are badly hit in the face right now and they need their tools to work so they can maintain what little income remains, and stress about getting the job done, not about getting the tools working. There are no unessential jobs in a global economy of taxpayers providing budget for healthcare systems, and if you can’t work, might as well take the opportunity to sharpen the tools so they are ready for when things reboot.

One year without calibrating a screen is a long time and there are no other software providing the same functionality . I wonder what you need to migrate to Python 3, how difficult it should be and how much time do you think it would take. And in case you are not interested, if you would be ready to delegate the task to the community while providing guidance and advice.

Thanks !

9 Likes
10

You have my sympathy, believe me.

Python 3 is not my only concern. I’ll have to sleep over a more elaborate answer.

2 Likes
11

Sometimes a blunt instrument works? You should know by now how Aurélien speaks. Provocatively, I would say. In any case, glad that we are having this discussion as this is important to many.

1 Like
12

The reason I replied was because I was tagged by paperdigits :slight_smile:

2 Likes
13

Then they should use a platform where their tools are still supported. Ubuntu 18.04, CentOS 7 etc…

The community could also contribute and make an AppImage or a TAR where all the depends are included.

Just saying :wink:

1 Like
14

You mean use 3 years-old software ? You think we are running servers here ?

5 Likes
15

This discussion shows that if you want to go to a serious production job, you should not rely on some bizarre updating of dependencies by the operating system.
The way to go is to use bundled builds (appimage, flatpak…)

2 Likes
16

I wouldn’t quite call 6 years of heads-up (12 if you were diligent) and then actually pulling the plug “bizarre”.

We did not want to hurt the people using Python 2. So, in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020.

Seems like a fair amount of time to make “production” quality software…

4 Likes
17

Sorry, I was not speaking about python that seems aware of its users.

I just wanted to emphasize that if you want to use a sw for serious production, the usual Linux way for applications to rely on some system wide dependencies libraries with bizarre (uncontrolled) updating is NOT the way to go. It’s as faulty as not to do backup.
If you run a Linux server, you install a few SW that you control under configuration management ( controlled updating of all components, thorough testing…).
for dektop apps, a much safer and easier way is to use bundled packages like appimage, flatpak including all dependencies.

If some dev still want to use python 2, they have to get a python 2 development environment and have to package their app bundled with python 2 in appimage or flatpak. It should run on recent LINUX. I don’t understand why Python team should be concerned by that.

Remark: Displaycal will still run for a long time on my W10 system even if it uses python 2.

18

I have a friend who, I think, would recommend running NixOS to avoid that kind of problem.

19

Even on Windows, Python2 is abandoned; there will be no more update.
On Linux one could still compile python2 and all DisplayCal dependencies to get something working. But it would probably be a better idea to just dig into the DisplayCal code and port it to Python3.

1 Like
20

Yes, indeedy! I’m picking at the last tasks of issuing rawproc 1.0, and between lensfun-fun, LittleCMS fast-float (it is indeedy speedy!) and keeping up with the Libraw-dashians I’m going to just support a 64-bit Windows installer and a Linux appimage, both with the best versions of each library statically linked. And then, maybe quarterly dot-builds, mainly to keep up with new cameras in Libraw. I’m eventually going to test a distro-based source build, but I’m not going to provide a lot of (any?) support for it.

I wouldn’t mind others finding a place in their toolbox for rawproc, but I wrote it mainly as a teaching tool. And, being the only developer, I’ll arrange as much support as my semi-retired state will allow…

2 Likes