Glimpse: Publish Glimpse Image Editor 0.3.x on Homebrew

Created on 23 May 2020  路  6Comments  路  Source: glimpse-editor/Glimpse

Is your feature request related to a problem? Please describe

Currently there is no MacOS port. While we cannot provide a good solution for end users and IT administrators that want to deploy the application, we could still help power users and developers.

Describe the solution you'd like

The ability to install MacOS through Homebrew

Describe alternatives you've considered

DMG or PKG file, but that is unlikely to ever happen for the reasons described in my comment at the end of #227 : https://github.com/glimpse-editor/Glimpse/issues/227#issuecomment-620214794

I have also considered MacPorts, but I believe that conflicts with Homebrew and is not as widely-used.

Additional context

Upstream is currently struggling to port 2.10.18 to MacOS, so this could be something that's genuinely useful for FOSS users on that platform.

It would be different to the way upstream currently does it. On Homebrew, GNU Image Manipulation Program is installed as a DMG file with brew cask install. Glimpse Image Editor would likely be installed from pre-built tarball files (or even built from source) using the standard brew install command.

This work will be dependent on creating a Github Action that can successfully build the code on a MacOS host first.

Packaging Won't Fix macOS

Most helpful comment

As mentioned in #227, because we have now moved all of our automated builds over to Github Actions we do now have access to native macOS CI servers.

After 0.2.0 is formally released, one of our first tasks should be to try and get a working macOS build using that infrastructure. Producing build artefacts for testing purposes that can actually be run on a macOS system would be an important first step.

Once that first step is realized, we can then start investigating how to create Homebrew recipes, and whether those recipes are capable of fetching artefacts from where we want to publish them. (Our project's code base is too big to expect every macOS user to build the application from source every single time)

Potential blockers I can foresee are if it turns out we can't just clone and re-use upstream's fork of gtk-osx, or if there are known issues with 2.10.18 that prevent it from building/running on macOS. These could be overcome in the first case by re-forking ourselves (not ideal, but do-able), and in the second case by potentially backporting important patches from 2.10.20.

I am optimistic though that while this is clearly not as good as providing a proper DMG file like upstream does, we will at least provide a workaround for tech-savvy enthusiasts. We can also still get download stats from here: https://formulae.brew.sh/analytics/

All 6 comments

I would love this.

As mentioned in #227, because we have now moved all of our automated builds over to Github Actions we do now have access to native macOS CI servers.

After 0.2.0 is formally released, one of our first tasks should be to try and get a working macOS build using that infrastructure. Producing build artefacts for testing purposes that can actually be run on a macOS system would be an important first step.

Once that first step is realized, we can then start investigating how to create Homebrew recipes, and whether those recipes are capable of fetching artefacts from where we want to publish them. (Our project's code base is too big to expect every macOS user to build the application from source every single time)

Potential blockers I can foresee are if it turns out we can't just clone and re-use upstream's fork of gtk-osx, or if there are known issues with 2.10.18 that prevent it from building/running on macOS. These could be overcome in the first case by re-forking ourselves (not ideal, but do-able), and in the second case by potentially backporting important patches from 2.10.20.

I am optimistic though that while this is clearly not as good as providing a proper DMG file like upstream does, we will at least provide a workaround for tech-savvy enthusiasts. We can also still get download stats from here: https://formulae.brew.sh/analytics/

Progress on this is currently stalled. The problem is that the build is environment-specific, and the macOS environment provisioned by Github Actions does not match the macOS environment provisioned by CircleCI (the system used by upstream).

That means the scripts that install prerequisites (such as JHBuild) need to be totally rewritten, and it is highly likely that the build process we are trying to duplicate will also need significant changes.

At this stage I am not sure how to move things forward, and it is very frustrating because over the past year I have put hundreds of hours of my spare time into trying to make a macOS port happen without success (see #227)

Either we need someone who's ported GTK+ applications to macOS before to take a look at this, or we need to wait until after the GNU Image Manipulation Program developers successfully re-port their application to the platform.

(For many years, one heroic individual did the macOS port for the GNU Image Manipulation Program on their own local machine. After 2.10.14 they were no longer able to do so, and despite providing an automated CircleCI project the actual build/packaging process itself is still almost entirely undocumented. You can see how far I got with puzzling it out here: https://github.com/glimpse-editor/Glimpse/issues/227#issuecomment-620214794)

I will leave this issue open in case someone else wants to have a crack at it, or I suddenly have a moment of inspiration.

The other idea I have rolling around in my head at the moment is the possibility of creating a PhotoGIMP style plugin for macOS users where they could potentially copy config files, icon packs, translation files & other assets into a pre-existing GNU Image Manipulation Program 2.10.14 installation.

If there is interest in that idea, then I could allocate time towards it. However, I think last time I floated it on the Matrix channel it received a very mixed reception because people felt it undermined and took away resources from the actual fork. The end result would also not be as good, and require schools/workplaces doing mass deployments to add it a post-installation step.

I'm excited to say that the GNU Image Manipulation Program developers now seem to be producing new releases for macOS again (albeit with caveats).

Source: https://www.gimp.org/news/2020/12/25/gimp-2-10-22-released-macos/

That's probably too late for us to include as part of the 0.2.2 release, but I intend to look into it for 0.3.0 (due in July 2020) when we rebase to a newer 2.10.x release.

I did look further into this, but realistically we are still going to have real problems recreating this work downstream.

At this stage we've also reached the point where it's essentially me carrying the fork single-handed while the rest of the Glimpse project is working on NX (our rewrite), so unless we see significant improvements in the upstream documentation it is unlikely that this will be brought into scope by the time we deprecate the fork in late 2022.

I know this will be disappointing for many of you, and as someone who owns Apple Macs I'm also disappointed. But we have to work with the resources and information we have and be honest with people.

My recommendation is you make use of the latest GNU Image Manipulation Program 2.10.22 release. There are regular revisions being produced that have started fixing annoying bugs in Big Sur, and it looks like there's some real momentum behind that now. If you want to use an open source image editing program on macOS, it's your best choice.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

TrechNex picture TrechNex  路  6Comments

chris-short picture chris-short  路  3Comments

HumanG33k picture HumanG33k  路  3Comments

TrechNex picture TrechNex  路  3Comments

jonathancast picture jonathancast  路  3Comments