OSX 32-bit support removed from 10.15 (Catalina) upwards

[politas]

Apple are planning to remove legacy 32-bit support soon. Currently, we run the CKAN client in 32-bit mode on OSX because Mono Winforms have not been ported to the Cocoa API

When mono/mono#6701 is resolved, we will be able to allow 64-bit operation on OSX

[HebaruSan]

That issue says they would "really appreciate a pull request," implying the Mono team has no plans to work on this themselves. It sounds like "No more WinForms on Mac" is a distinct possibility.

Thank goodness for cross platform runtimes making low level architecture-related problems like this a thing of the past! 🙄

[politas]

I think that comment was directed at the original poster of that issue who said they had a working version.

[Ruedii]

Adding a GTK# GUI option is the best way to insure future multi-platform support.

Just remember, you might want to ship a skin with it so the Windows version looks nice, because the default windows skin isn't particularly nice if users haven't changed their GTK runtime settings on Windows (which most users don't even have the utilities to do this in GUI, and have no clue how to edit the settings files in question.)

As a note, GTK# has better multithreading which is a big plus.

[politas]

How well does GTK# support OSX, though? Will going through all the effort of writing a GTK# GUI implementation actually be any better for our OSX users?

[HebaruSan]

I would kind of like to see an Electron-style cross platform UI, where the details are done in Javascript and CSS, but when I looked for such a framework for Mono/.NET, I didn't find one.

Then again, after WinForms, TxFileManager, and CommandLineParser, I'm skeptical of any strategy that sees introducing yet another third party dependency as a magic solution.

[politas]

I think there is a fundamental lack of OS developers who use OSX, which means not many developers interested in working on an OSX interface toolkit for a second-tier language.

[ProfFan]

Is there a possibility that CKAN have a stable command line interface and we can then create some frontend for CKAN?

[politas]

As far as I am aware, the command line interface should be stable under all OSs. On the other hand, @HebaruSan's consoleui interface makes it clear that it is possible to create a new separate interface as part of the codebase. I don't have a problem with such a thing happening for a better OSX interface. If there are any OSX interface coders who would like to delve into C# enough to write one, it would be fantastic!

[ProfFan]

@politas Thank you for the info! Actually what I am thinking is wrapping CKAN completely with a GUI in another language, i.e. Electron (like @HebaruSan 's idea). This would make CKAN more like other package managers like apt and pacman, etc., where the actual package management logic is complete separate from the frontend.

[politas]

Sure, that's what i meant with the first sentence. Sorry I wasn't more explicit.

[HebaruSan]

I've been trying out Electron-NET today. Electron-build doesn't support building Mac packages on non-Mac OSes due to some signing thing, so that kind of throws a wrench into that option (but Windows and Linux can build each other).

It generates installers natively, but the downloads are 60+ MB each, 10x what they are now (and that's with no actual code written yet for a CKAN Electron UI and none of our C# DLLs included); I can picture the complaints on the forum already. Maybe someday they'll be able to persuade OS vendors to include some of the node.js architecture as system libraries to reduce that burden per app.

Generally not too impressive or encouraging.

[techman83]

We can build on osx with Travis -> https://docs.travis-ci.com/user/reference/osx/

Doesn't help testing on mac though. I have one, but I sprayed Linux on it as soon as I checked that the hardware was functional 😂

The whole everyone shipping an entire web browser as their app is ugly. But bandwidth and disk space is cheap. We could continue to build the a version with the old interface for a time and consider it deprecated. in theory electron has a lot more energy behind it.

[HebaruSan]

This is what I meant:

C:\Users\user\github\CKAN\ElectronUI\src\app>npm run dist

> [email protected] dist C:\Users\user\github\CKAN\ElectronUI\src\app
> electron-builder -mwl

  • electron-builder version=20.13.4
  • loaded configuration file=package.json ("build" field)
  • writing effective config file=C:\Users\user\github\CKAN\ElectronUI\dist\electron-builder-effecti
ve-config.yaml
Build for macOS is supported only on macOS, please see https://electron.build/multi-platform-build
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] dist: `electron-builder -mwl`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] dist script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\user\AppData\Roaming\npm-cache\_logs\2018-05-20T03_55_30_620Z-debug.log

They've got a hard coded check in the tool that fails if it detects it's not on a Mac.

Electron would be a dream option if the download was < 10 MB. I don't think 60 MB is a reasonable ask "just to install mods."

[ProfFan]

@HebaruSan If the problem is just with building a MacOS VM is sufficient. There are prebuilt VM images scattered around the Internet originally for making Hackintosh installers.

[tsal]

While I don't mind using the CLI interface, having a working GUI would be nice on a macOS. I wouldn't mind downloading a 60 MB package, either. That's tiny compared to a lot of the mods I'm downloading. If I knew the mono / .NET build system at all, I'd offer to help. :/

[rspeed]

As mentioned in mono/mono#6701 (comment), the emclient/mac-playground repo contains code which decouples WinForms from the Carbon library. Might be worth a try if anyone is feeling adventurous.