VisualARQ for Mac

VisualARQ
9

Hi @Seychellian,

Let me answer you some of your questions from my point of view, as a VisualARQ developer:

As far as I know, developing a plug-in for Rhino for Mac is pretty similar than developing a plug-in for Rhino for Windows.

Here is the problem! Once a plug-in has already been developed for one platform, porting it to a different platform could be very difficult, depending on some the decisions made in the development process, like what programming language, which SDK, or which User Interface library, are going to be used.

Talking about Rhino plug-ins, there are two main SDK available:

  • Rhino C++ SDK: which obviously requires to use the C++ programming language, or
  • RhinoCommon: which could be used from many different programming languages like C#, Python, VB#, etc, as it is a .NET Framework SDK.

A C++ plug-in, like VisualARQ, needs to be recompiled for Mac, and this process requires many changes in our case:

  1. Learn how to develop on macOS or find and hire one (or more) experienced macOS developer.
  2. Convert projects from Visual Studio to XCode.
  3. Duplicate some parts of code that calls Windows API functions and convert those calls to macOS A
  4. Rewrite all user interface, as we’re using MFC, a Microsoft C++ wrapper of Windows User Interface API, and make it mac-like.
  5. Test, fix, test, fix, test, fix…
  6. Create macOS version of installer, updater, documentation, etc.

I don’t know how much time will this process take, but only the third point on that list will take us more than a year of development.

And this is without taking into account that there is no public C++ SDK of Rhino for Mac, and I don’t when will be available, so we cannot start this development yet. I know that McNeel could provide us with a C++ SDK, but they told us this SDK is not yet frozen, so it could be broken in a 5.x update, which will require the plugin to be recompiled again. This should change when Rhino 6 for Mac is released, as it will share the source code with the Windows version.

At the contrary, a Rhino 5 plug-in developed in RhinoCommon should work in Rhino 5 for Mac (yes, Rhino 5 for Mac does support third-party plug-ins), as long as all libraries used by the plug-in are available in .NET for Mac. Unfortunately, as far as I know, not all standard libraries are available or they don’t work like the Windows version, being the GUI toolkits the more problematic:

  • WinForms: a native Windows API in .NET. It does work on Mac, but it has an old Windows look & feel.
  • WPF: an alternative .NET GUI from Microsoft, currently not supported on Mac.
  • Eto: an open-source cross-platform GUI library developed entirely in .NET by Curtis Wensley (@curtisw). Rhino 5 (for Mac) and Rhino 6 (for Mac and Windows) use this library, and McNeel encourages all plug-in developers that want to write a plug-in that should work on Windows and Mac to use also this library.

I don’t know the exact numbers, but I do think that the Rhino for Mac market share is small compared to Rhino for Windows, and this could influence in the decision on if a plug-in needs to be ported. If Rhino 6 shares licenses between Mac and Windows (which I don’t know), it could be very easy for a Mac user to use Rhino 6 on his Mac, running Windows on Boot Camp or WMware Fusion. I know, it’s not an ideal solution, but it works.

Regards,

Enric

4 Likes