Best framework for building UI for Rhino/Grasshopper in 2020

Is there anyone who can give wise advice, or a link to a great overview article, about a big decision of what UI framework to use for building user interfaces for Rhino and Grasshopper in 2020? I only find this recent, but incomplete discussion here.

Our needs:

  • Ideally true cross-platform, including Web UI and WebAssembly
  • Well documented and great tutorials
  • Can be reused in other software platforms, such as Autodesk and Web.

Our desired abilities:

  • C# but preferably Python
  • If possible CSS styling!

These are the current options in November 2020:

  1. ETO Forms
  2. Xamarin
  3. UNO Platform
  4. Win UI (the new version of WPF or WinForms)
  5. MAUI (the new .NET standard starting Nov. 2021)

The Pros/Cons of each:

ETO Forms

  • pro: cross-platform, but not Web UI
  • pro: extensive
  • pro: integrated into Rhino/GH already
  • pro: can use Python
  • con: poor documentation
  • con: difficult to learn

Xamarin and Xamarin Forms

  • pro: cross-platform
  • pro: great .NET integration and serves as the base for the new MAUI
  • pro: extensive
  • con: difficult to learn, but lots of resources
  • con: no Python (as far as I know?)
  • unknown: can it integrate to Rhino?

UNO Platform

  • pro: true cross-platform including WebUI and WebAssembly
  • pro: extensive
  • pro: great documentation and learning resources
  • con: difficult to learn, but lots of resources
  • con: no Python (as far as I know?)
  • unknown: can it integrate to Rhino?

Win UI

  • pro: .Net support
  • pro: extensive
  • pro: cross-platform
  • pro: well documented
  • con: difficult to learn, but lots of resources
  • con: confusing if it will be deprecated with WPF and WinForms
  • unknown: no Python (as far as I know?)

MAUI the new .NET standard

  • pro: the new standard in .Net 6, November 2021
  • pro: replaces all other windows UI builders
  • pro: will be based on Xamarin and Xamarin.Forms
  • pro: will be well documented with lots of learning resources
  • con: difficult to learn
  • con: no Python support (as far as I know?)

As you can see, it is a big decision where to invest time and energy!!!
I really hope someone has good insight to this challenge.
Thank you.

Given your requirement of C# or python, I think you’ve covered all the possibilities and their pros and cons. If it were me, I’d use Eto because it’s proven inside a rhino environment.

The other possibility to consider is to build a web application and host it in-platform in an embedded browser, with a framework like CEF that lets you marshal communication to and from the web environment. Cefsharp is not supported on mac but it seems like there may be some possibility of using cefglue or chromiumfx? I built a number of Revit plugins this way: effectively using CEFSharp to wrap a vuejs application.

If you’re willing to forego “in-application” interaction too, you might even skip the CEF step and just build and a thin, in-platform C# plugin that communicates with the web app via its application’s API (ie your users would have to have a browser open).

A third option is to build a completely standalone Electron application wrapping your web app, and use some thin platform client to drive it via interprocess communication, rather than via the remote API. Not sure what the IPC landscape looks like on Mac, so this is an untested idea

In general my feeling is that if you want web support at any future point, you should probably start with web technologies and find a way to get that into the desktop platform, rather than starting with desktop tech and trying to port to the web.

2 Likes

@andheum

Thank you so much for your opinion and thinking about scenarios. I have thought about the 3 options, but wasn’t familiar with the tech stacks to use. I would definitely be open to use web technologies due to it’s power and freedom. A few comments and questions:

CEFSharp Implementation
Was it complicated to get data from CEFSharp to interact with the local software? There needs to be a data binding between the web interface and the local software. Did you ever test running Rhino3DM.js or Rhino3DM inside the web interface from CEFSharp? How did you package all of this together for the user to install?

Thin UI + Web UI
Definately interesting. I guess the constraint here is the time to send/receive the inputs from the web interface. We are looking into whether we can offload computation from the local software to our software, so this option would not allow this. But this has lots of potential for some use cases.

Local App (Electron or Other)
I think that UNO can do this as well, with their WebAssembly output. I’m not sure how this would all work. I’m concerned with Electron that it is not multi-threaded and potentially then restricted to just simpler interaction. Electron would be great for some functionality but might not allow us to offload computation into it. I did see that there is Electron Edge but it doesn’t seem maintained. Uno webassembly seems to support mutli-threading..

All said, we still need to confirm if we can offload computation to a local app - with an integrated Rhino3DM running in it… all experiments to be tested still.

The only other thing to add is that we want to have very data-rich visualization in our app, and that means that going towards web UI is probably necessary. We can bring JSON from the local software into our web UI and take advantage of JS libraries like D3, ThreeJS and all sorts of other ones.