What a protracted discussion! I think people will do what is most practical. Moving to where the most activity is at is probably that. Doing stuff is more important than debating about it.
3 Likes
I donāt think anyone likes that, but as an end users I want my software in the newest version and I want to get that version with the least friction possible. As an end user I donāt care about much else.
3 Likes
@afre, and thatās why running the flatpack version of DisplayCAL isnāt an issue for me. OK, in an ideal world, there would be no issue with running DisplayCAL, as itād be ported to Python 3. But for the moment, it isnāt, so using the flatpak build is the least ādifficultā way forward.
1 Like
One slight issue I have ran into, is the flatpack version of DisplayCAL not having full access to the users file system, it saves into the sandboxed file system at ~/.var/app/net.displaycal.DisplayCAL/data/DisplayCAL/storage
Fixed by
sudo flatpak override net.displaycal.DisplayCAL --filesystem=home
But thatās probably more a flatpack sandboxing issue.
Yes, it is, sort of. DisplayCal generates a .desktop file to load the profiles when you log in. As long as the desktop file points at the right place, it should work.
1 Like
Yes, no issues with DisplayCal loading the profiles on login. However I prefer to apply the monitor profiles using the KDE Colour corrections settings dialogue, so I like all my profiles etc stored in the same place, e.g. /home/brian/ICC Profiles
Should this be a serious question? Florian already answered this - some time ago in this thread - as a direct response to you:
If this were a normal year, and if I would have only focused on getting a py3 version ready, that would probably have worked out alright. But this isnāt a normal year, not by a far stretch. And the main problem that I have is that Iām utterly out of energy, as well as ārecharging the batteriesā being difficult. E.g. the past years, one important way of recharging was going out with friends. Well guess whatās become increasingly difficult if not impossible this year, at least if you want to be responsible. Iām sure Iām not alone in this.
Which part of his answer was not clear enough?
2 Likes
the part where we asked him to publish the latest source so people can work on it as well and where he said he would think about it.
that part
4 Likes
A lot of complaining in this thread without any (proper) solutionsā¦
There are three (realistic) alternatives:
- Someone port the code to Python 3 and get it merged upstream
- Someone make a portable binary archive (not that hard)
- Use a distro that supports Python 2
Problem solved 
1 Like
What, so as a developer, if I donāt jump when they say jump, then itās my problem ?
Where do end user needs come into your evaluation of how application development should work ?
MSWindows APIās have supported Color Management for 20 years, as have X11 APIās. Wayland, the new shiny - not so much.
This is not about Wayland though, its about distros dropping support for python 2.7
1 Like
You are kidding, right? It was announced many years before the deprecation. So devs are taken into account.
2 Likes
BTW, Iām sad reading your reply @gwgill, I had a bit of hope but it seems that indeed I can say RIP to DisplayCAL !
1 Like
Wellā¦ the problem is not immediate, but I think almost certainly long-term. A good analogy may be COBOL. Many critical systems around the world are still based on COBOL, not a āmodern languageā by most definitions. Of course when the software does its job perfectly, itās all good and nothing to worry about. But this is rather short-sighted, because the infrastructure around the software will very probably change. This either requires you to jump through hoops to keep interfacing with the āoldā software, or to actually modify the software itself. Both options are costly. The latter maybe more so, because of an increased risk if your COBOL program is doing some critical process. Nobody wants to touch that for fear of breaking it. Fewer and fewer people understand COBOL too, and those that do can ask a fortune for their services.
Now think of Python 2. Because it is officially deprecated, it will become an āold languageā, similar to COBOL. Trying to keep interfacing with it is certainly possible, but it will become increasingly harder over time. So I would say yes, when the developers of Python say jump (and they already did in 2008, and again in 2015), you should prepare for the jump and eventually jump. If not, you, and by eventual extension, your users, pay the price of stagnation.
Edit: the open source nature of the project probably makes the analogy less than perfect, but the gist is the same I think.
2 Likes
But you can run the flat pack version of Displaycal on Linux?
that flatpak version is just a crutch to keep it alive a bit longer but it still is not the solution. the real solution is to get it ported over.
3 Likes
Yes, itās not the real solution. But for the moment, itās still an option to let the software continue to be used.
The risk is, with continual talk of the software being dead, RIP, that wonāt encourage the author to spend any more time on it, (bearing in mind they probably have a lot on their plate at the moment, due to the global pandemic).
1 Like
The problem is worse than that, I have come across places that are forced to use a binary because the COBOL source code no longer exists.
1 Like
How does it download the corrections for your calibration tool? 