-
-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Super-awesome Mac client implementation #1334
Comments
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. |
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. |
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. |
This may be of interest of you want to call Mono code from a native application: http://www.mono-project.com/docs/advanced/embedding/ |
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. |
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.). |
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. |
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. 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:
|
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 ;) |
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. |
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.)
The text was updated successfully, but these errors were encountered: