RIP DisplayCAL ?

I think we do need to remember that developers of free software, may have other things on their mind, during a global pandemic…

2 Likes

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 ofcourse everyone would be happier without it happening.

It’s rather unfortunate in the FOSS world where manpower cannot be easily relocated to tackle such things. I think Aurelien tried this in his own way with this thread. Thanks @agriggio for stepping in!

Blaming the user would be the more upsetting part here.
But, I also reluctantly understand the gist of it. If you know what a calibration is, which colorspace you target, what dE is, what profiling means and how it’s different from calibration…you already know a lot about very technical things. Hacking some cli commands should not stop you. It’s just very very inconvenient (as it comes on top of the time spent on the calibration/profiling itself).

2 Likes

Guys, I feel we have a strong tendency of being too political, too religious or even docmatic (maybe I am struggling finding the right word in a foreign language).

The only question remains:

  • What has to be done in which way, so that DisplayCal’s code can get the love, it needs and how to make @fhoech accepting help, when others have different ideas about what is an appreciable timing to adapt ?
  • (e.g. it could be moved to github, @fhoech is the release director and off it goes)

(Me I cannot code, but I can volunteer for testing. Until then I use this, which is even harder than displayCAL’s CLI )

3 Likes

For what it’s worth, it’s possible to even use a GitHub repo with an SVN client: https://docs.github.com/en/free-pro-team@latest/github/importing-your-projects-to-github/support-for-subversion-clients… so it wouldn’t even require switching to git, if that’s considered a blocker.

People can use git and/or svn with GitHub repos. Their choice.

Also: I checked to see if GitLab supports this. It doesn’t (at least according to a 6-month-old comment).

2020 has been a struggle for everyone. Overall: Tensions are high, patience is low, and things are tough. We should all remember this, especially as plain text, like in this forum, can easily be misconstrued.

I hope (and think) we’re all friends here, with a common goal: using (and in some cases, aslo developing) some amount of FOSS (Free / Open Source Software) for photography… whether that’s a complete FOSS stack or even just one tool.

Much thanks to all the devs who make this possible and :heart: to all.

(Hopefully the Python 2 → 3 thing can be solved with DisplayCAL in some friendly way.)

1 Like

Heck I won’t be reading through all this, just addressing a few points:

  1. SourceForge hasn’t been the place where DisplayCAL code development happens for over a year now. I moved to a different (currently private) repo.
  2. 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).
  3. Flatpak sounds like a good interim solution for Linux if someone wants to bundle the current version.
9 Likes

No, it would not stop me if I it came down to it. But it would cost me an afternoon to work out how DisplayCal’s interface even works and what goes where, assuming the documentation is decent.

However: openSUSE Tumbleweed has removed DisplayCal entirely, not just the GUI, and the only package I could find on OBS threw an error when trying to install it. So in my individual case, I can’t even work around the problem by moving to the commandline. Fortunately, I saw the package posted above by agriggio, and that is what saved me.

However however: This is not about just me. There are a lot more people using Linux who are less informed than me. I already have the huge advantage of having found this thread. The ones who have not are out of luck because they don’t even know what to do. And I think it would be elitist to shrug and say that’s their problem, because if I did, then I’d have to be okay with someone else doing the same to me in other areas where I’m less equipped to fix stuff myself. Even if it only ever happened in areas where I’m perfectly capable of circumventing a problem: A world in which I have to fix all the stuff myself is a world in which I get nothing done, ever.

So my argument is not about what developers should do, it’s about people claiming that if they themselves can work around an issue, then if it is an issue for anyone else, that’s those people’s fault. If such an attitude came to prevail in the free software community, that would mean that any free software would be useful only to nerds, and none of those nerds could use more pieces of software than they can keep on top of simultaneously.

Note that this is completely separate from Florian’s statement that he does not have time to deal with the Python migration right now. “Sorry, I can’t help you right now” is a valid response to somebody who could use help, but “Tough luck, you’re not qualified to use this software anymore” is not.

I’d just suggest to also consider making PyInstaller-generated versions available that can run from userspace, like @agriggio posted above. At least I prefer that to Flatpak, because Flatpak has always been pretty unwieldy to use and has caused issues of its own on my system. I suspect that unless it’s already set up on their machines in a good way, most non-technical users will find it easier to download and unpack an archive than to get flatpacks to work.

Although I’d be rather curious, I start to understand why you would not want to feed more “internal” details into a public discussion about your project… Hope that your current work goes smoothly and turns out to be worth it.

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

And adding Flathub, if it’s not already there by default (as it is on at least EndlessOS, ElementaryOS, Pop_OS!, PureOS, Zorin, Linux Mint, and ClearLinux), is usually a matter of just by clicking “Install” on Flathub. The browser downloads the file, passes it to the software installer app (GNOME Software, KDE Discover, etc.), and it gets registered — automatically.

For the ones above that have flatpak installed and Flathub already registered, they can also just search in their software app installer and click install (without ever visiting Flathub.org). That’s it; just about as simple as it gets.

There are additional instructions @ Flatpak—the future of application distribution (linked from every app on Flathub) too, such as those for Ubuntu (where it’s a few more steps to set up, as Canonical is different from everyone else and defaults to Snap instead): Flatpak—the future of application distribution

An app in flatpak form is easier to install and integrates better into a system than a PyInstaller. A flatpak doesn’t even need a command line to install (although you could install it that way, if you wish).

However, it probably wouldn’t hurt to have a flatpak and a PyInstaller version. Both methods would be better than what we have now, with most distros having already dropped Python 2.7 completely.


Meanwhile, I tweeted out a request for help with packaging. People are looking into it already: https://twitter.com/garrett/status/1339948532036493313

1 Like

Yup, 100% with you on that.

Totally.

My impression is, that this is already the case. I know zero artists who run Linux and the Photographers I know only on their backup fileserver, if at all. And the reason is exactly the amount of time you have to spend on finding out how certain things work on Linux IF they work (hello wayland-colormanagment discussion).

To some extend, of course it is. And are you happy with this state of affairs? 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!
There’s probably also some amount of “I didn’t have it easy, so neither should anyone else” – another one of those really stupid sentiments.

I for one am not happy with this state of affairs, because it punishes not just non-technical users, but also me, who’s been at it for about 20 years now. Sure, I can deal with issues. But that becomes an enormous time sink, and if my OS prevents me from using time efficiently, then all the nice efficient tools I have set up here are for naught. So, should I just give in and allow Microsoft to surveill me? Are efficient working free software mutually exclusive? And should they be? I think nobody who thinks that free (libre) software has value can believe that its use should stay limited to those whose technical knowledge qualifies them for it. And I certainly don’t think that suitability to non-expert users is a technical obstacle for free software.
In fact, this seems to me the biggest factor holding Linux back.

And just to reiterate (because for some reason people just love to read things that way): That does not compel/force/whatever anyone to do anything. I’m not trying to enforce my will here or make demands. I’m trying to make a case that people losing access to a piece of software is also a bad thing if those people haven’t used bash before, and declaring them irrelevant is only reinforcing an existing problem. Therefore, I would like people to stop dismissing non-expert users, and take them into account when deciding on their own priorities.

1 Like

I would say so. Thanks for your patience. :stuck_out_tongue:

1 Like

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.

3 Likes

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

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!

4 Likes

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

7 Likes

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

4 Likes

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.

8 Likes

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.

10 Likes

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.

2 Likes

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