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!
Thank you for picking this up 
. will report any bugs if I encounter it.
I never knew there was now a “native” build using python3.
Currently I’m using the Flatpak version, which works, although is a bit “bloated” compared to a native build
Edited to add, will we be able to get native .deb / .rpm packages of this new python3 version of Displaycal? It’s beyond my skillset to try to compile Displaycal from the source packages.
Just found this thread and I’ve tried what README.md said without success.
I run into the issue discussed here https://discuss.wxpython.org/t/compile-fails-in-opensuse-tumbleweed-wxpython-4-2-0/36247/9.
[11/937] compiling with python 3.10 line fails with the same result as tried with python 2.7
This is what works for me on Tumbleweed.
sudo zypper install argyllcms libXxf86vm-devel patterns-devel-base-devel_basis patterns-devel-python-devel_python3 libpng16-devel libjpeg8-devel lzlib-devel libtiff-devel libexpat-devel gtk3-devel gcc-c++ python38-devel
sudo pip3.8 install wheel
sudo pip3.8 install attrdict
sudo pip3.8 install displaycal
With Python 3.10 you’ll run into problems
1 Like
I was able to install it on my desktop (Nobara 36, Python 3.10.8) without any issues. Just warming my displays up now before making a calibration run.
@vato Thank you very much!! It worked indeed! 3+ weeks of trying, you just made my day in 4 command lines
I realise that, but I am mainly wondering about the reason for doing it in the first place. Does the higher degree of familiarity with Qt make it worth it despite the effort that is going to be needed?
No luck trying to install the python3 version of Displaycal in Kubuntu 22.04 based KDE Neon…
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
I think I’ll stick with the flatpak version, as trying to compile from python is beyond me…