Glimpse: Support macOS

[TrechNex]

Is your feature request related to a problem? Please describe.
Currently Glimpse Image Editor is not available for the macOS platform.

Describe the solution you'd like
Upstream project has now provided instructions for how we could go about this: https://gitlab.gnome.org/Infrastructure/gimp-macos-build/

Describe alternatives you've considered
SeaShore is the GNU Image Manipulation Program alternative we currently suggest.

Additional context
We were unable to support this for 0.1.0. I think it would be cool if we could make that happen for 0.2.0

[TrechNex]

Suggestion from Twitter that we could consider pkgsrc as a distribution platform to expedite our macOS port: https://pkgsrc.joyent.com/install-on-osx/

This would also have the benefit of providing an installation mechanism for people using other UNIX systems like *BSD, Haiku, MINIX & others.

source: https://twitter.com/azimechprojekt/status/1210939341452656640

[TrechNex]

I've pushed this out to 0.3.x as 2.10.16 will be the first upstream release that makes use of their new automated build framework.

As the build and packaging steps are not documented by upstream at all, we're reliant on that build job working correctly. (I think 2.10.14 was still built on someone's desktop!)

[TrechNex]

Brought back in as a 0.2.x candidate as it seems upstream release will be delayed. I doubt it'll be available for 0.2.0, but it should hopefully be a thing for 0.2.2

[TrechNex]

I am hopeful this can be achieved within the next few months. I need to find time to puzzle out the circle-ci build steps locally, then figure out how to package it.

This is all the upstream documentation I have to work with: https://wiki.gimp.org/wiki/Hacking:_Building/Mac_OSX

[TrechNex]

We have determined that this is unfortunately not going to be possible with the code fork. I have put hundreds of hours into investigating this since we started the project, but sadly it's just not going to be viable.

My apologies to MacOS users that were hoping we would bring our software to their platform. For what it's worth, these are the detailed reasons:

Poor documentation
Because the GNU Image Manipulation Program does not have many contributors for its MacOS port (in fact, it's literally being maintained by one heroic individual!) this is all the documentation we have to work with: https://wiki.gimp.org/wiki/Hacking:_Building/Mac_OSX

In July/August 2019 that wiki page just consisted of one line, and that one line pointed to an archived website from years ago and suggested we use jhbuild. At the time I wrote this comment it had been expanded to link to a CircleCI build.

That means getting a build to work ourselves would take hundreds of hours puzzling it out through trial and error, and we cannot make any estimates about how long it would take to package the end result. Until more MacOS developers step up to the plate and help upstream, we are going to struggle to reproduce their work downstream.

Apple's requirements
The GNU Image Manipulation Program is able to satisfy security, notarization and approval requirements with the resources provided by The GNOME Foundation.

We do not have access to the same resources, and because our project is not a formal organization it would require an individual acting on our behalf to buy an Apple Mac, pay an annual subscription for a developer account, and then manage everything themselves. If that individual loses interest in our project, we would have to do it all over again (assuming we can find someone else).

That is clearly not a reproducible or "long term sustainable" solution, so it would force us to only distribute the application through channels like MacPorts and Homebrew. While we are not against supporting those repositories, they are not necessarily suitable for non-technical users or school/business deployments.

GTK is not well-supported on MacOS
There is a project called gtk-osx, but this is primarily intended for GTK developers to pick out specific modules they need as part of a larger effort to port their code to MacOS.

The GNU Image Manipulation Program relies on their own fork of that project, and one individual constantly patches it to keep up with Apple's changes and decisions. We do not have the expertise in our project to do the same, or the capacity to maintain another forked project.

Automating MacOS builds is impractical
Our project cannot afford MacOS build servers on CircleCI, so we cannot reuse the GNU Image Manipulation Program's gimp-macos-build repository, and as far as we can tell there is no good way of cross-compiling and packaging MacOS applications on GNU/Linux.

That means if we did produce a MacOS port it would need to be built and packaged manually on one individual's Apple Mac, and they would likely encounter bugs that need patching because we cannot sanity check the build while we are still making changes.

Building and fixing things for MacOS manually would significantly delay every single release. Time we spend doing that is also time we can't spend developing the application itself, so as things stand it's unfortunately just not feasible for us to take on this task.

[LunaTheFoxgirl]

I'll add that this is still on the roadmap for the UI rewrite.

[pbx]

Thanks for the update.

For personal use, I'm not put out; I run Linux. But my work machines are often Macs, and cross-platform support tends to increase my enthusiasm (and evangelism).

I understand the practical constraints (thanks for laying them out so completely). But it's a disappointing outcome because it closes off a large group of potential users. I'm guessing that per-capita use of Photoshop is far higher among Mac than Windows users, though maybe that's just my former life as a graphic designer talking. In any case I think the focus on "better overall user experience" and usability improvements would be especially well received by Mac users.

Ah well. At least they have Seashore. Thanks for trying, and for explaining the state of things.

[TrechNex]

This is still a "wontfix" for now, and will remain closed. But I'm providing an update for people here.

Since we closed this issue we have shifted all of our CI across to Github Actions. This means we have working native macOS CI servers and we could potentially automate the building and packaging of the software for macOS.

The most likely use for this will be to create pre-built tarballs as build artefacts for testing purposes. It would also definitely help our efforts to provide a source-built port via Homebrew, which we're tracking in #402. While that's still not as good as providing a properly code-signed DMG file like upstream does, this does improve the feasibility of a port.

I am hoping we can just clone and use upstream's existing fork of gtk-osx, because having to maintain that ourselves would be a headache.

[ocraig]

@TrechNex - thanks for your persistence _and_ for the Jul22 update. Glimpse is such a stellar experience on Linux & Windows I can't help but keep fingers crossed for macOS.

[TrechNex]

Confirming I have seen this exciting news that the GNU I.M.P developers: https://www.gimp.org/news/2020/12/25/gimp-2-10-22-released-macos/

I'm currently tracking progress in #402, but this issue may get re-opened in February/March if I determine that producing a proper universal binary is feasible.

[MisutaaUrufu]

We do not have access to the same resources, and because our project is not a formal organization it would require an individual acting on our behalf to buy an Apple Mac, pay an annual subscription for a developer account, and then manage everything themselves. If that individual loses interest in our project, we would have to do it all over again (assuming we can find someone else).

@TrechNex just giving you a little bit of information that won't be a _big_ help, but may be useful none the less.

---

Whilst yes, the _best_ way of distributing an app is _by having it notarized_; this identifies the application as having been reviewed by Apple; You can still run _un-notarized applications_ on later versions of macOS.

_Contrary to Apple documentation_, in my experience, "Apple Developer"-signed (i.e. free developer account) un-notarized applications _can still be ran on the latest versions of macOS for Intel systems._. (I currently have this enabled on my Mac on Big Sur.)

The only caveat is that it requires users to re-enable the option to run software from "anywhere", _which reduces the effectiveness of Gatekeeper_. This means that, for _less savvy users_, they could potentially expose themselves to malware. (Gatekeeper will still check applications against a list of known malware, and prevent them from running if there is any found, but only on first run as before, and only against its current definitions list at the time of first run.).

I also do not have an M1 Mac to test whether this applies to ARM-based systems. I would assume so, seeing as at its core it is the same OS, but it is _possible_ there are additional measures taken on Apple Silicon systems.

---

Additionally, if you were able to crowdsource the funds for a paid Developer ID, _you wouldn't need the developer ID to belong to the individual building the application._

You can actually export signing certificates from Apple's Developer account settings, which can then be installed on the build machine for use with signing. — It's a little more complicated a process (the builder wouldn't be capable of using XCode's automated certificate management, which would mean more back-and-forth.), but it would allow upper level project management to maintain the developer account.

---

In all, I hope a method of distribution is found. I really don't like the crass-ness of the GNU IMP team when it comes to branding, and in all the Glimpse project looks promising as a _successor_ as much as it is a fork.

Good luck.