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? 
I happen to make them myself. 
But point taken, thanks.
@fhoech Today I found an AppImage on the openSUSE build service:
Unfortunately, I was unable to run it:
kofa@eagle:~/digicam/colour-management-profiles$ ~/dl/DisplayCAL-0-Build1.7.glibc-x86_64.AppImage
DisplayCAL.pyw 3.8.9.3 2019-12-14T12:16:22.165507Z
Ubuntu 21.04 hirsute x86_64
Python 2.7.18 (default, Mar 9 2021, 11:09:26)
[GCC 10.2.1 20210306]
ImportError: No module named faulthandler
┌──────────────────────────────────────────────────────────────────────────────┐
│ Traceback (most recent call last): │
│ File "/tmp/.mount_DisplatqdheI/DisplayCAL/main.py", line 451, in main │
│ _main(module, name, applockfilename) │
│ File "/tmp/.mount_DisplatqdheI/DisplayCAL/main.py", line 95, in _main │
│ from wxaddons import wx │
│ File "/tmp/.mount_DisplatqdheI/DisplayCAL/wxaddons.py", line 10, in │
│ <module> │
│ from wxfixes import wx, GenButton, PlateButton, get_dialogs │
│ File "/tmp/.mount_DisplatqdheI/DisplayCAL/wxfixes.py", line 27, in │
│ <module> │
│ import wx │
│ ImportError: No module named wx │
└──────────────────────────────────────────────────────────────────────────────┘
Warning: handle_error(): ImportError: No module named wx
And it hung at that point. Any advice, please?
1 Like
I also tested the AppImage. I get this:
simon@anna-ms7c96:~/Downloads$ ./DisplayCAL-0-Build1.7.glibc-x86_64.AppImage
XDG: [Errno 2] No translation file found for domain: xdg-user-dirs
Not starting another instance.
However, I also have the Flatpak installed, maybe that’s the problem.
Btw, looks like the dev is trying to create the AppImage.
Yes, I can confirm that after the failed AppImage, I was able to install and run it as a FlatPak: Flathub—An app store and build service for Linux
1 Like
I am not sure why the dev wants/wanted to create an AppImage. The Flatpak is functional and I think it exists since a few months already.
No expert on this, but Appimage does not require any background services to run on. Just change the permission to run it and go. In a way a less complicated but more universal way of distributing software (with all disadvantages in comparison to a managed package as well).
Many pieces of software I use come as AppImage, sometimes even exclusively
1 Like
For the moment I have found the following workaround on Gentoo:
python 2.7 can still be installed from the repo but not most of the dependencies (notably wxPython), so I created a virtual python environment using virtualenv
virtualenv --python=/path/to/python2.7 $PATH_TO_VENV
changed into the virtual environment with
source $PATH_TO_VENV/bin/activate
installed the following dependencies (pip can install almost everything that’s listed under dependencies for using the source code on the displaycal homepage but don’t install pychromecast as this pulls in zeroconf and then displaycal stops working…)
pip install dbus-python && pip install numpy
downloaded wxPython https://netcologne.dl.sourceforge.net/project/wxpython/wxPython/3.0.2.0/wxPython-src-3.0.2.0.tar.bz2
tar xvf /path/to/wxPython-src-3.0.2.0.tar.bz2 && cd wxPython-src-3.0.2.0
./configure --prefix=$PATH_TO_VENV --with-gtk=2 --enable-unicode --with-opengl
make install
cd wxPython
source $PATH_TO_VENV/bin/activate (not sure if even needed)
python setup.py install
and finally added the following line to the $PATH_TO_VENV/bin/activate script
export LD_LIBRARY_PATH=$PATH_TO_VENV/lib:$LD_LIBRARY_PATH
Now I can simply change in the virtual environment with
source $PATH_TO_VENV/bin/activate
and then start Displaycal from its folder (you have to download the source tar-ball and extract it somewhere, the file to execute is called DisplayCAL.pyw) - not a very elegant solution but at least it works and as I don’t need it that often it’s more of a problem to remember the location of the virtual environment and displaycal executable…
Maybe this can be used on other distros as well - at least as long as you can install python 2.7
Hope this proves useful for someone else…
1 Like
Hi there,
check out Erkans repository at GitHub - eoyilmaz/displaycal-py3: DisplayCAL Modernization Project
He managed to make DisplayCal run with Python 3.9 on Linux.
No packages provided, but installing is a piece of cake.
15 Likes
This thread recently got bumped for other reasons, but I did come across this claim.
That is definitively NOT true. My former employer was forced to keep an ancient machine around running NT4 more than a decade after it was EOL to continue to run an application that wouldn’t run in Win2k or newer. We had to keep a Win2k instance around here for years because Xilinx dropped support for a chip in newer versions of ISE, and their old version of ISE wouldn’t work on recent Windows versions. (Eventually a workaround for the incompatibility was found, but it took a massive amount of effort to do so). One of our vendors just had to completely change file formats because Microsoft EOLed one of their database drivers years ago - the vendor dragged their feet and was forced to move to sqlite on rather short notice because a vulnerability was discovered in the driver. Said vendor now has to pop up a security warning every time the old format is opened.
Perhaps, you might be able to argue, “Windows doesn’t leave working software behind as long as you don’t care about security at all”, but any company that is trying to comply with ISO 27001 is going to wind up in the position our vendor wound up in.
1 Like
My claim started with “for the most part”, implying that I was referring to the overall trend. I don’t doubt that there are exceptions.
That is interesting, thanks for sharing. Currently I’m using the flatpack build of Displaycal, but it’d be good to have a “native” version suitable for distros which no longer provide Python 2!
Hey Patrick thank you,
For all the people curious about this topic, please visit my GitHub repository: GitHub - eoyilmaz/displaycal-py3: DisplayCAL Modernization Project
to get the Python3.8+ version of the DisplayCAL 3.8.9.3+
I’m working on this project very actively (apart for the last 5-6 days where I have been tackling with Covid-19).
DisplayCAL should be working properly under any recent Linux distro, and there are people using it with MacOS and as far as I know Patrick is done some work to make it work under Windows. But please try it and please report any issues you come across so we can fix it.
This project is not only to make DisplayCAL work with Python 3.x but also modernize and optimize the code and hopefully add more features to it.
I requested to be the next maintainer for DisplayCAL from Florian Höch, but he has yet to answer my request.
Cheers,
37 Likes
Congrats for undertaking this large project!
4 Likes
Yes, thank you!
I am slightly curious about this item from the roadmap:
- Try to move the UI to Qt. This is a big ticket. The motivation behind that is that I’m much more experienced with Qt. In fact, I have zero experience with
wxPython.
It does sound like a large undertaking, to the point that I wonder: would it not take possibly less time to get familiar with wxPython instead?
Yes it is a large undertaking, and I acknowledged that by saying This is a big ticket. Currently DisplayCAL is working with wxPython and we are going to use it until we have solved some other big issues, like the aged build and setup system and introduce more structure to the code and organize it, we are not going to focus on this at all. Also, it is probably going to happen in its own branch, and it will progress behind the scenes.
7 Likes
Thank you for stepping up to work on DisplayCal to get it working on recent distros. While the flatpack version works, a native build is always better!