RIP DisplayCAL ?

[afre (Alan)]

@fhoech

Heck I won’t be reading through all this

I would say so. Thanks for your patience.

[rasimo (Simon Frei (imsodin))]

Can we move the generic “is linux unusuable for non-command-line-geeks” discussion to a separate topic please. There’s some constructive discussion directed at the current situation of DisplayCal and it’s at risk of drowning in all the noise.

[garrett (Garrett LeSage)]

In DisplayCAL-related news: @hub is awesome and has been working on packaging DisplayCAL for Flathub:

Hubert Figuière (hfiguiere)

Here’s what the metadata looks like for the package: Add net.displaycal.DisplayCAL by hfiguiere · Pull Request #1999 · flathub/flathub · GitHub

And it looks like he’s working on making the buildbot happy with tests.

It looks like we may have a test build pretty soon!

[paperdigits (Mica)]

@Mister_Teatime

My impression is that those who will happily blame users for difficulties they encounter are, more or less covertly, happy to have an ecosystem for themselves. It gets them bragging rights, they can feel superior for using the OS for the smartest people, and by keeping newbs out, they can keep it that way, and still claim underdog status! win-win-win!

You’re making an aweful lot of speculations about a lot of people. I’d ask that you stop.

[gwgill (Graeme W. Gill)]

@garrett

All of these calibrators work well with DisplayCal (with varying speeds of calibration). I tried, out of curiosity, as I saw they were supported.

To be accurate, they all work with ArgyllCMS, and DIsplayCAL (and any other GUI front end) gets the benefit of it.

[hub (Hubert Figuiere)]

There is a test build now for x86_64. I includes argyllcms.

But: I haven’t test the whole calibration workflow so I don’t know if all the bits are in place to be useful yet. Working on it, I need to locate my ColorHug.
Also I need to “export” the other utilities.

[gwgill (Graeme W. Gill)]

@PhotoPhysicsGuy

I think all your posts, which I mostly understand, come back to this root problem. Python v2 to v3 happened without a legacy mode, it broke compatibility. I think we all know why this sometimes must happen, but of course everyone would be happier without it happening.

As a lone developer, deprecation of API’s and other sub-systems is one of the most depressing and frustrating things. A large company may have the resources to keep re-writing code over and over again, but for an individual it’s a lot of tedious work for no return.

[Brian_Innes]

dispcal (the command line tool) is installed when you install ArgyllCMS.

So you can use it, even without DisplayCal (the gui app) installed.

However one of the risks of using rolling release distros (e.g. OpenSuse Tumbleweed, Arch, or Manjaro etc) is that software may get updates, which remove dependencies.

There is a lot to be said IMHO for a long term support based distro for production use.

[PhotoPhysicsGuy (Bob)]

I fully agree. It’s like pulling away the ground that you stand on.

[darix]

and on the other side of the spectrum you have developers who complain that they have to maintain support for really old libraries because of long term support distros and that they can not remove old stuff.

and especially in the case of py3 this grace period was very very long. even the announcement that py2 will really be killed 2020-01-01 … had like 1y heads up.

[darix]

so … @fhoech when can we expect a repo with the current code, there is a christmas break period coming up and people might have time to help you with porting to py3 and your other goals. but it would be unfair to volunteers if they started working on the current state in the releases or sf.net if your local changes would make it hard to merge their work in the end.

[Mister_Teatime]

@Brian_Innes

dispcal (the command line tool) is installed when you install ArgyllCMS.

So you can use it, even without DisplayCal (the gui app) installed.

Thanks fo the heads-up! I had been looking for any package starting with “display”, but that explains it, then.

[Brian_Innes]

Yes, a bit confusing having the gui app, and the command line app having very similar names

[Mister_Teatime]

@garrett

Flatpak is installed and works by default on most Linux distributions these days.

It might be an isolated incident, but I’ve had to install it to get Signal for desktop installed, and it has caused nothing but trouble on my end.

Desktop integration was not working at all, and neither was the GUI, so I had to install everything from the CLI, and launch the apps using its silly Android-inspired naming scheme (“/wherever/flatpack/stores/bins/[something].[something].[appname]”) from the CLI. Eventually, it broke completely, so I threw it out again.

It might be working all nicely by now, but I’m not eager to engage with it again, particularly because I prefer to have all my stuff installed by the same packet manager, to avoid having to remember which packet is managed by whom.

That said: Whatever works better for the devs. As long as there’s a workable solution, I’ll be fine.

[paperdigits (Mica)]

I’ve been using flatpak apps for a few years quite successfully. On Debian based distros, fedora, and NixOS. Not sure what distro you use, but perhaps its time to evaluate one where you can easily run the applications you want.

[anon41087856]

@fhoech

Move to python3 is only part of the ongoing work (can’t say more sorry). It will happen eventually, but on my schedule, not anyone elses (that should go without mention).

What can we do to help and make it faster and/or easier for you ?

Your pet project has become a tool upon which people depend. I understand that priorities change and shit happens, but Linux is brittle enough as an ecosystem, let’s try to fix that and not make it worse.

[Thanatomanic (Roel)]

@fhoech

Move to python3 is only part of the ongoing work (can’t say more sorry). It will happen eventually, but on my schedule, not anyone elses (that should go without mention).

From his wording, it does not seem he is interested in collaboration. If so, he would probably have picked up on this in the early posts of this thread. But I may be wrong… I even hope I’m wrong, considering the great care and dedication of this community.

[anon41087856]

Well, bus factor == 1 hits FLOSS once again -_-

I have almost a decade of experience in Python for scientific computation, I coded CIECAM02 and bits of CIECAM16 in C, and just this month a matrix color profile solver, however I don’t have experience with C-Python bindings, but… well I learned C in 2 months.

If @fhoech wants my help, I will be happy to give it but with some supervision because I don’t have time to do another one-man-coding-guerilla again in someone else’s undocumented code with undisclosed dev roadmap.

[fhoech (Florian Höch)]

@darix

especially in the case of py3 this grace period was very very long. even the announcement that py2 will really be killed 2020-01-01 … had like 1y heads up

Well if you only talk about the language itself, libraries not included, then yes. It’s besides the point though, because porting to py3 is not the main thing that’s holding me back. 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.

Anyway, good job to the people that are looking into Flatpak or PyInstaller. If you have something working, feel free to send a link my way, I’ll include it on the page.

[agriggio (Alberto)]

Hi,

@fhoech

If you have something working, feel free to send a link my way, I’ll include it on the page.

This is working as far as I know, although it’s for an old version. I can try packaging the latest with PyInstaller if you are interested.
(In both cases, if you decide to use it, it’s probably better to host it somewhere other than google drive though).