The fundamental Idea is that while keeping compatibility the dependencies get better and safer at the same time, with the only development effort on the dependency side. Not a bad design idea! In reality this has some smaller usability downsides, but that’s another story.
Here we encounter a case were compatibility between Python 2 and 3 is not given and thus this elegant approach fails. I don’t think containering everything is particularily good. Windows Installs get bloated that way, stay working (that’s a pro), but are potentially security horror-nightmares from hell(!).
Regarding the concern of not being able to calibrate one’s display: GNOME has an integrated calibration tool. Actually when I plug in i1 Display Pro, the settings dialog pops up and offers to calibrate the display. Of course it’s not as versatile as DisplayCal and not everyone uses GNOME. Just wanted to point out there is another graphical calibration tool available.
W10 is an OS that takes 50 GB and way too much RAM for simply booting and spies on you just because it can (and apparently, paying for the product now still makes you a product).
You might confuse rolling-release distros with regular distros. The whole point of a distribution is to get system-wise consistency between libs. Problem here is an app using 12 years-old dependency.
Besides distro-hoping, which is not a hobby for the vast majority of people, migration to spyware, or switching to Gnome half-baked soft, what options/roadmap do we have to make DisplayCAL enter the 2020’s ? (aka actually solving the problem).
In my opinion, most probably the only way that DisplayCAL will be updated to python 3 would be if several developers get their hands dirty and help @fhoech to do that (if he even wants this).
In the meantime I vaguely remember reading in this forum a workaround: get a live distro with DisplayCAL built-in and profile your monitor with it. After that you can use the newly created icc profile in your preferred Linux OS.
Not ideal, but I have my live distro ready just in case…
I don’t know maybe I am carrying owls to Athens (I did not read all posts in this thread) but I think Displaycal can be run from source easily. I already mentioned this in a different thread. At the moment I am on Arch and Displaycal is still in the repo but I am pretty sure I ran it from source on Ubuntu and Debian. Some dependencies had to be installed, that’s true, but they were available. Also I must admit I probably did not test it on Fedora lately.
What I’m using is pipenv (just installed via pip) with a simple Pipfile that tracks all of Displaycals dependencies. With this setup it is just a metter of copying the Pipfile into the Displaycal directory and running “pipenv install” and the magic happens.
Afterwards I just run Displaycal within the environment by using “pipenv shell” followed by the starting of Displaycal itself.
I’m pretty sure the whole process could be packed into a small script for people who are not comfortable with the command line…
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020.
Please upgrade your Python as Python 2.7 is no longer maintained.
pip 21.0 will drop support for Python 2.7 in January 2021.
More details about Python 2 support in pip can be found at
https://pip.pypa.io/en/latest/development/release-process/#python-2-support
pip 21.0 will remove support for this functionality.
Also, I tried to compile Python 2.7 for Fedora 32 and get the mandatory packages, that worked for all except python-wxWidgets. That one has no wheel and can’t build one. Stuck there.
Then I tried Anaconda with 2.7 env, and it failed somwhere else.
@anon41087856
Clearly you are a quite brilliant developper but I see you never managed computer systems for a firm.
Your reasoning is flawed. You can have several solutions to a problem: short term solutions and long term solutions. I fear that conversion of Displaycal falls in the second case and will not solve users problems quickly.
Managing stuff for big firms and for single users environments are two different beasts. On big firms you can get away with legacy stuff for a long time, mostly because big changes are expensive and because you can dilute the cost of not upgrading into a the users (who you are paying to, so they have to adapt to what they have).
Exactly, for multiple reasons but here also big changes are expensive, exactly time expensive and good dev are not so numerous and users are waiting. So sometimes, you have to keep old things working for some times. And in this case, making a bundled package (with pyton2…) that can be distributed, can be an interim solution waiting for the “actual solution to the problem” if it ever happens.
I just wanted to make a suggestion, but I see there are some “Linux resistances” so I stop to post here.
Way back (before machine learning became a thing), I learned enough python2 to play around with some of the math and image packages. Then v3 came out, slowly gaining features. It was different enough from v2 that I wasn’t motivated to adopt it. I think this is a part of the story of where the code gap began. Moving forward many years to today, it seems not much has changed. In fact, we have so many more languages floating in the ether…
This is a “bundle” that I created with PyInstaller, it should run out of the box: just unpack it and run the displaycal script. Created on a Ubuntu 18.04, tested on a Ubuntu 20.04 VM without Python2, seems to run fine (I didn’t try calibrating/profiling from the VM, just starting it up). It doesn’t contain argyll, but that should be no problem.
The SHA256 checksum is 2f92824ceca72b572a15f0bb11872c69aece7b6c43bc75920c23c489e930528f.
I created it to have a sort of backup plan in case I need to upgrade OS before the porting to Python3 is done, but maybe this is useful to somebody else…
No issues installing Displaycal & the required Python 2 dependencies.
It was not possible to install the required python 2 depencies on Kubuntu 20.10 though.
Perhaps a DisplaycalGUI appimage / flatpak would get around the issue?
However it’s not too difficult to run the displaycal command line program to get a calibration. Sometimes quicker than starting up the Displaycalgui. It’s always possible to create a launcher in the application menu of your desktop environment to run the command line version of displaycal.
I think that’s one of the advantages of running LTS based distros, more chance of required dependencies still being available, compared to point releases. e.g. no issues installing Displaycal & python 2.7 dependencies on Mint 20 (based on Ubuntu 20.04), compared to e.g. Ubuntu 20.10 based distro.
While I did manage to get DisplayCal (and python 2.7 dependencies) installed on Manjaro, I just have a fear about rolling distros!
Artists that use free and opensource software must learn to handle with everything, even with convoluted commands on the terminal. This is the trade-off when you use free and opensource software otherwise there are plenty of commercial software and OSes that makes your life easy while lock you down on their ecosystem.
We are still far from the perfect balance from both sides…
I wouldn’t say entering a command into the terminal to run dispcal, is particularly laborious, or it’s always an option to add a launcher to the panel or desktop environment menu with a command e.g. "
dispcal -d 1 -t 6500 -b 160 -g 2.2 -yl -v -o MONITOR1" where MONITOR1 is the display name of your screen.
After all, we are all using open source, free software. A little bit of command line use is acceptable in my opinion.
