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.

1 Like

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.

3 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.

1 Like

Hey @D.Ronald, did you get anywhere with a preferred approach? Iā€™ve looked into using gh-web-ui and it looks promising from a UI perspective but from my non-programming understanding canā€™t grapple with Rhino/GH like Eto can.

@andheum would love to know your thoughts on this discussion after six months, especially with compute maturing?

Our use case would really benefit from a webapp first approach, so we can leverage things like authentication, databases using something simple like Googles Firebase, but donā€™t think thereā€™s a workflow for that yet?

@Lukxf To be honest I havenā€™t found a satisfying solution.

Weā€™ve been looking at multiple ways to send data in/out in realtime for either (1) data processing, or (2) user interface. But this is all complicated due to how you connect with external software, the need to run servers (or other long-term background processes). Nothing would be intuitive for a user experience and distribution of a plugin product to customers.

Iā€™ve even started learning C# now in order to have better control of the Grasshopper dev process. Writing GHPY is super annoying in terms of writing and debugging the code. Iā€™d much rather learn WPF instead of ETO because of far better documentation and tutorials online. But I find the C# (both internal and external) libraries limited for data visualization. Live charts is the only semi-attractive interface. This development was stopped and taken over by Live-Charts 2ā€¦ who knows how stable this is. I donā€™t even know yet if it works with the .NET framework 4.5 (up to 4.7?) that is used by Rhino/Grasshopper.

GH-Web-UI works with .NET Framework 4.8ā€¦ I had to just install it now when testing out the latest version of it. Previously it wasnā€™t stable enough to use for a commercial project, maybe it is now. My bigger concern is to have downstream user interface, such as data visualizationā€¦ and this isnā€™t (yet?) integrated with GH-Web-UIā€¦ maybe this is something I should look intoā€¦ to invert the code to pop-up a web interface.

@D.Ronald thanks for the reply, is helpfulā€¦

Weā€™ve consigned ourselves to using ETO in the short-term and crossing our fingers that we can leverage rhino.compute within the next 12months and build a webapp to interface withā€¦ We sound like weā€™re in the same position; our team is mainly designers-turned-quasi-programmers, so transitioning to C# is going to be a step up :sweat_smile:ā€¦

Had a play with gh-web-ui over the weekend and came away thinking its still not robust enough to be used in the wild, although using a framework like Vue I could see how you could make a very appealing UI with it. I had trouble getting buttons to bind correctly (which I think is noted on the Github page), I also tried connecting it to a back-end service (Firebase) but couldnā€™t get it to work (my laypersons understanding is that gh-web-ui is just serving a static html page with listeners to grasshopper, its not able to do HTTPs calls).

If you know of any good resources for ETO would love take a look at themā€¦

Cheers!

Hello everyone,
Iā€™m wondering why you havenā€™t consider Blazor?

best
C,

1 Like

Dark mode pleaseļ¼ŒWinUI 3 Welcome youļ¼

I donā€™t think Blazor supports .NET framework 4.8 for Grasshopper.

Is it possible to use electron to create a Rhino plugin, or would this only work to create a stand alone application?

I did some work this year to use a web based UI to control a cross platform Rhino plug in written in GH.

1 Like