Kind of neat how well #GNOME apps fit in on macOS :) Since @nila added support for macOS to #puregotk in https://codeberg.org/puregotk/puregotk/pulls/43 this week I thought I’d give it a shot on my new MacBook Neo - and it works really well.
-
Kind of neat how well #GNOME apps fit in on macOS
Since @nila added support for macOS to #puregotk in https://codeberg.org/puregotk/puregotk/pulls/43 this week I thought I’d give it a shot on my new MacBook Neo - and it works really well. Cross-compilation from Linux to macOS was super easy thanks to purego, no cross-compiler needed, just `GOOS=darwin GOARCH=arm64`. Plus, discovered that macOS’s arm64 library paths are different!
-
Kind of neat how well #GNOME apps fit in on macOS
Since @nila added support for macOS to #puregotk in https://codeberg.org/puregotk/puregotk/pulls/43 this week I thought I’d give it a shot on my new MacBook Neo - and it works really well. Cross-compilation from Linux to macOS was super easy thanks to purego, no cross-compiler needed, just `GOOS=darwin GOARCH=arm64`. Plus, discovered that macOS’s arm64 library paths are different!
@nila https://gist.github.com/pojntfx/bc688a887a940e3e458684df62058843
Little hacky packaging script for all of this so far - allows you to build a .dmg for a puregotk #Go #GTK app, all from Linux, code signing included. `go-gettext` still needs a way to specify where to load the `gettext` dylib from when it's not available in the default location, so I stubbed that out, but no other code changes necessary

-
@nila https://gist.github.com/pojntfx/bc688a887a940e3e458684df62058843
Little hacky packaging script for all of this so far - allows you to build a .dmg for a puregotk #Go #GTK app, all from Linux, code signing included. `go-gettext` still needs a way to specify where to load the `gettext` dylib from when it's not available in the default location, so I stubbed that out, but no other code changes necessary

@nila I doubt I'll be putting much work into the macOS and Windows parts here - for this to actually be useful as in it being a viable way to publish GTK apps to non-Linux platforms while still building on Linux - we'd need a proper auto-updater and Windows support as well, and Flatpak is just too comfortable. I put a bunch of work into this for https://github.com/pojntfx/hydrapp a while back, including a way to auto-update the signed DMGs - maybe some time in the future?
-
@nila I doubt I'll be putting much work into the macOS and Windows parts here - for this to actually be useful as in it being a viable way to publish GTK apps to non-Linux platforms while still building on Linux - we'd need a proper auto-updater and Windows support as well, and Flatpak is just too comfortable. I put a bunch of work into this for https://github.com/pojntfx/hydrapp a while back, including a way to auto-update the signed DMGs - maybe some time in the future?
@nila We can run the XCode command line tools and GTK via MacPorts on Linux running in Docker, and install gcc and GTK via MSYS2 in Wine running in Docker too. Not really puregotk-specific, but would be neat to have a "Flatpak manifest for building GTK apps on non-Linux OSes"-kind of thing some day.
-
@nila We can run the XCode command line tools and GTK via MacPorts on Linux running in Docker, and install gcc and GTK via MSYS2 in Wine running in Docker too. Not really puregotk-specific, but would be neat to have a "Flatpak manifest for building GTK apps on non-Linux OSes"-kind of thing some day.
@pojntfx @nila Pixi is a pretty good fit for "cross platform manifests"!
prefix.dev – solving software package management
prefix.dev – solving software package management
prefix.dev (prefix.dev)
For example, the Pixi manifest for Shortwave, which both works on macOS and Windows (and Linux):
(WIP - not merged yet)
-
@pojntfx @nila Pixi is a pretty good fit for "cross platform manifests"!
prefix.dev – solving software package management
prefix.dev – solving software package management
prefix.dev (prefix.dev)
For example, the Pixi manifest for Shortwave, which both works on macOS and Windows (and Linux):
(WIP - not merged yet)
@haeckerfelix @nila Oh hell yeah, that seems like exactly what I'm looking for, thank you for sharing! At first glance it seems mostly for packages, is there a way for me to publish a self-updating .dmg/.msi with this as well? The idea is that on Linux you'd get a nice Flatpak, and then on the proprietary platforms you get a self-updating package

-
@haeckerfelix @nila Oh hell yeah, that seems like exactly what I'm looking for, thank you for sharing! At first glance it seems mostly for packages, is there a way for me to publish a self-updating .dmg/.msi with this as well? The idea is that on Linux you'd get a nice Flatpak, and then on the proprietary platforms you get a self-updating package

@pojntfx @nila the most easiest / straight-forward way would be to publish the app to conda-forge, this way you don't have to deal with self-updates. It's comparable with Flathub, but cross platform.
The Pixi manifest describes the environment which you can use for development (cross platform), for the actual packaging you use a separate recipe file, which describes the needed dependencies + commands to build the app.
For example (WIP)
https://github.com/conda-forge/staged-recipes/pull/32284 -
Kind of neat how well #GNOME apps fit in on macOS
Since @nila added support for macOS to #puregotk in https://codeberg.org/puregotk/puregotk/pulls/43 this week I thought I’d give it a shot on my new MacBook Neo - and it works really well. Cross-compilation from Linux to macOS was super easy thanks to purego, no cross-compiler needed, just `GOOS=darwin GOARCH=arm64`. Plus, discovered that macOS’s arm64 library paths are different!
@pojntfx @nila I got questions about running Maps on macOS once when I did a presentation. Would be kinda cool to see. But I suspect some things would need fixing. For example GeoClue is not running there, so possibly it would need some abstraction for location service (the same would apply for Window, btw). Or maybe it would still run, but unable to get current location.
-
@pojntfx @nila the most easiest / straight-forward way would be to publish the app to conda-forge, this way you don't have to deal with self-updates. It's comparable with Flathub, but cross platform.
The Pixi manifest describes the environment which you can use for development (cross platform), for the actual packaging you use a separate recipe file, which describes the needed dependencies + commands to build the app.
For example (WIP)
https://github.com/conda-forge/staged-recipes/pull/32284@haeckerfelix @nila Hmm, that makes sense, but won’t that require the user to install Conda? I’m fine with that in the case of Flatpak since it’s pre-installed, but I feel like non-technical people won’t understand how to install a package manager just to install the app

-
@pojntfx @nila I got questions about running Maps on macOS once when I did a presentation. Would be kinda cool to see. But I suspect some things would need fixing. For example GeoClue is not running there, so possibly it would need some abstraction for location service (the same would apply for Window, btw). Or maybe it would still run, but unable to get current location.
@mlundblad @nila Yeah, even in my simple case stuff doesn’t fully work (no D-Bus, so no notifications). WebKitGTK isn’t packaged for macOS, that’s a pretty big blocker.
I wonder if it makes sense to put more work into this? I did a bunch of work on the whole “compile for macOS and Windows” in a UNIXy way (Darling for macOS builds in Docker on Linux, MSYS2 for Windows builds on Linux) with https://github.com/pojntfx/hydrapp, but stopped a year ago bc I’d rather just focus on Linux
-
@mlundblad @nila Yeah, even in my simple case stuff doesn’t fully work (no D-Bus, so no notifications). WebKitGTK isn’t packaged for macOS, that’s a pretty big blocker.
I wonder if it makes sense to put more work into this? I did a bunch of work on the whole “compile for macOS and Windows” in a UNIXy way (Darling for macOS builds in Docker on Linux, MSYS2 for Windows builds on Linux) with https://github.com/pojntfx/hydrapp, but stopped a year ago bc I’d rather just focus on Linux
@mlundblad @nila But yeah if there is enough interest in it, maybe it’s worth it? I’d love to have smth that just takes a Flatpak manifest + “x-“-prefixed extra keys for macOS (Homebrew) + Windows (MSYS2) packages to install instead of SDKs and runtimes, and then just builds self-updating DMGs and MSIs from it
-
G gnome@floss.social shared this topic