Super-awesome Mac client implementation

[pjf]

I'm currently at OSCON, sitting next to @desplesda, who has repeatedly expressed an interest in improving the CKAN for the Mac, including the potential for a Gtk# Mac-specific implementation that wouldn't require X11, and which would be less likely to hit bugs in mono.

To foster encouragement, I'm opening this ticket, along with presenting some screenshots of the existing GUI. However it should be noted that some of the UX exists to work around bugs in mono; in particular I know we've hit issues with dialog boxes and additional windows.

(For those following along, my conference ends tomorrow, so I'll be playing CKAN catch-up soon after that.)

[pjf]

Here are some sample screenshots, for guidance only. :)

[mgsdk]

I played a bit with https://github.com/mono/xwt at one point, and I think @RichardLake also looked at it. I can't recall if there were any issues (apart from the daunting task of rewriting the GUI). This should have more native looking widgets available for all platforms.

[RichardLake]

I think the issue I had with XWT was the lack of binary releases which leads to having to have a OSX machine to build the Cocoa engine backends. Another library I was looking at is https://github.com/picoe/Eto which doesn't seem to have the same issue with needed a OSX build machine.

[Crazor]

I thought about doing this for some time now, too. What I'd like to do is write a native Cocoa gui and call into CKAN. So far I'm not quite sure how to do the CKAN calls. All I found so far is how to call Objective-C stuff from Mono, but not the other way round. I suppose if there is a seperate OS X GUI to maintain, it could as well be as native as possible. I figure I could always call ckan.exe and parse the output, but that would be kinda awkward...

[mgsdk]

This may be of interest of you want to call Mono code from a native application: http://www.mono-project.com/docs/advanced/embedding/

[mgsdk]

If anyone manages to get embedded Mono to work let me know. I've tried to get the embedding process working on Arch Linux to no avail.

[Crazor]

My problem on OS X so far with embedding the Mono runtime is that the distribution only contains 32bit code and libraries. Native 32bit programs are a hassle on OS X nowadays (no ARC etc.). This project sounds promising, but I haven't tried it yet. Homebrew's Mono formula builds 64bit Mono libraries, but doesn't seem to build a .framework

[CalMlynarczyk]

I've managed to get the embedded Mono calls to work (up to a point). I built a 64-bit version of Mono and referenced its dylib in my application. I tried to write a prototype to see if I could call into the existing codebase to pull down the mod list from the repository, but I ran into a wall with initializing the RegistryManager.

However, I think my issue is with initialization itself, and not embedding Mono in the application. I think because I am initializing a KSPManager using a NullUser object, it is not properly registering everything, and I am getting null values when trying to retrieve instances from the RegistryManager.

In regards to calling Mono via the embedded interface, it is incredibly painful and error-prone. The wrapping layer we would have to write over it to interface a Cocoa app with a Mono backend would probably be more code than the UI itself.

Just some images below to show what I've got so far. I am by no means an expert at OS X development (or even desktop interfaces for that matter, as my experience is primarily with web dev), so it's a little rough. I just tried to mirror the existing interface for the time being, and not make any of the changes I would like to the interface.

[CalMlynarczyk]

I have posted the code to embed Mono into a Cocoa application and call into the CKAN DLL. This is just for initializing and retrieving a RegistryManager instance so that I could later pull a list of mods from the CKAN repo.

Mono Embedding Example

As you can see, there is a lot of class and object probing involved to get the various method signatures and recover usable object pointers from them. Unfortunately, Swift does not seem to like typedefs in the Mono headers that do not declare explicit structures, so a lot of the object types that are available in Mono.dylib for embedding calls do not get imported; you have to work with raw "void" pointers to the Mono objects. I do not know if it is feasible (or even necessary) to write our own C wrapper around these missing types so that we could bring them into a Swift application for strong-typing purposes.

Regardless, I am not sure this is the right approach to take to write a native OS X version of CKAN, as it is incredibly bug-prone without any strong-typing around the calls to CKAN.dll. Here are the options I see we could take in order to make this task feasible:

1. Re-write CKAN for Cocoa. We have two parallel versions of the same application that need maintained. This may simplify some things by removing the need to handle OS X quirks in the Mono version of CKAN, but ultimately this would probably double the amount of development effort needed in order to maintain two versions of the same application.
2. Use the prior-demonstrated Mono embedding technique to link to CKAN and call it directly from a Cocoa application. I (and probably most devs) would prefer to use Swift instead of Obj-C for this, but as I have found there are some gaping holes with it that would likely require us to write a bridging layer in C/C++/Obj-C to handle the interoperability problems. The other downside to writing it in Swift is that we would have to distribute a 64-bit version of the Mono runtime with the application (Swift only runs on x86-64), as the Mono Project does not currently distribute 64-bit builds for Mac (and I don't think relying on users to install one is the right way to go). Obj-C apps can be built for i386, which would bypass this issue.
3. Re-write CKAN Core in a more FFI-friendly language (ex. C, Rust). At first, I thought Python might be the right choice in this regard as it strikes a good balance with greater developer community familiarity and language simplicity, but the embedding interface for it is no better than Mono's. I am a personal fan of Rust, but I am not sure how many compatibility issues we would run into using it on both Windows and Unix platforms.
4. Re-architect CKAN so that the command line interface becomes a first-class citizen. This is probably the most sane option, as it allows us to keep all of the existing codebase while bringing the command line functionality up to par with the GUI version. We can then write a Mac version that simply calls out to a new CKAN process for each operation. This avoids all the nastiness around linking Mono and Cocoa into one application, but still allows the existing Mono UI implementation to continue linking to CKAN Core. Building out the command-line version of CKAN also opens up more capabilities, allowing users to create re-usable scripts to restore KSP setups if something breaks. This could also apply for mod developers to simplify troubleshooting and reproducing bugs. However, the existing export functionality might already fulfill this role (not sure how capable it is for these purposes as I have never used it).

[Crazor]

Thanks for your research! I was afraid that this could be somewhat ugly, and especially so in Swift. Even though we are constantly being told otherwise, interfacing with the outside world is still pretty ugly in Swift... I think I'll give this a shot in good old Objective-C. If the code looks any more sane than that atrocity you fabricobbled together there, I'll report back ;)

[CalMlynarczyk]

I have created a fork of CKAN where I will track the work I have done. There is an XCode project under the directory OSX, if you would like to work off of something that is already up and running.