Skip to content
This repository has been archived by the owner. It is now read-only.

Publish Glimpse Image Editor 0.3.x on Homebrew #402

Closed
ghost opened this issue May 23, 2020 · 6 comments
Closed

Publish Glimpse Image Editor 0.3.x on Homebrew #402

ghost opened this issue May 23, 2020 · 6 comments
Labels
macOS This bug/issue applies to Apple Macs Packaging Packaging methods Won't Fix This will not be worked on

Comments

@ghost
Copy link

ghost commented May 23, 2020

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 : #227 (comment)

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.

@ghost ghost added Packaging Packaging methods macOS This bug/issue applies to Apple Macs labels May 23, 2020
@ghost ghost added this to the 0.2.x Candidates milestone May 23, 2020
@ghost ghost added this to Back Log in Glimpse Overview via automation May 23, 2020
@ghost ghost moved this from Back Log to Packaging in Glimpse Overview May 23, 2020
@jcklpe
Copy link

jcklpe commented Jul 16, 2020

I would love this.

@ghost ghost mentioned this issue Jul 22, 2020
@ghost
Copy link
Author

ghost commented Jul 22, 2020

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/

@ghost ghost modified the milestones: 0.2.2 Candidates, 0.2.0 Release 2 Aug 3, 2020
@ghost ghost modified the milestones: 0.2.2 Candidates, Fork Candidates Aug 11, 2020
@ghost
Copy link
Author

ghost commented Oct 11, 2020

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: #227 (comment))

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.

@ghost
Copy link
Author

ghost commented Oct 11, 2020

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.

@ghost ghost added the Help Wanted Extra attention is needed label Oct 11, 2020
@ghost
Copy link
Author

ghost commented Dec 26, 2020

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.

@ghost ghost modified the milestones: Fork Candidates, 0.3.0 Dec 26, 2020
@ghost ghost changed the title Publish Glimpse Image Editor 0.2.x on Homebrew Publish Glimpse Image Editor 0.3.x on Homebrew Dec 26, 2020
@ghost
Copy link
Author

ghost commented Feb 1, 2021

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.

@ghost ghost added Won't Fix This will not be worked on and removed Help Wanted Extra attention is needed labels Feb 1, 2021
@ghost ghost removed this from the 0.3.0 milestone Feb 1, 2021
@ghost ghost removed this from Packaging in Glimpse Overview Feb 1, 2021
@ghost ghost closed this as completed Feb 1, 2021
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
macOS This bug/issue applies to Apple Macs Packaging Packaging methods Won't Fix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant