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:
ETO Forms
Xamarin
UNO Platform
Win UI (the new version of WPF or WinForms)
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.
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.
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.
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 ā¦
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ā¦