I am exploring some long term options to create complex scripts or a collection of scripts. I have had good success with Hops and created modular scripts. But for UI I’m torn between ETO and Human UI.
I know some python but ETO documentation and examples for python are not common
Human UI is easy to use but I was trying out an example and realized that anytime a grasshopper value changed, the whole UI had to be rebuilt adding to calculation time.
Am I judging too harshly or is Human UI too much overhead for large scripts?
Nothing in the whole GH ecosystem is really efficient and fast. That is the tradeoff when creating multiple wrappers around the actual technology, so that non-programmers can also use it. On Windows, beneath Eto and Human UI there is WPF. WPF is quite powerful but not easy to master. WPF wraps around the Windows UI and DirectX and was develop for the common languages of .NET, which are C#, VB and C++. Not Python. Especially if you only have some Python skills, I think you would need quite a while to master it. If you look for something more efficient, you could also create a GUI in another technology and use Interprocess communication to bind it to your GH definitions. In any case this is advanced programming. If you lack the knowledge, you should rather live with whats there.
Hello
I’m a regular user of HumanUI.
To avoid excessive calculation time, you can add a button that validates the data entered in grasshopper. This avoids the script having to run each time data is modified in the HumanUi interface.
The HUmanUi components are not resource-intensive.
For large scripts, care must be taken to activate via the human interface only what is really necessary for execution.
Thank you. I am starting to think maybe the example I used was not optimized. Is there ability to add an “Apply” or “Refresh” button to only pass on values once user submits data?
@Muhammad_Talha_Mufte Just want to point out that something in your original statement is not true if you are using HumanUI the way it was intended:
“Human UI is easy to use but I was trying out an example and realized that anytime a grasshopper value changed, the whole UI had to be rebuilt adding to calculation time.”
This is not accurate, the whole UI should never be rebuilt, but it can happen if you are using a Value Listener on one component and feeding that value into a Create component to generate elements dynamically. This is not a paradigm that HumanUI supports and triggers a complete UI rebuild.
If this is something that you are trying to accomplish, you should instead create a predetermined number of components that you would like to display dynamically, and then use the Value Listener to control the data/visibility of your dynamic components. I’m sure there are a decent number of examples here in the forum, Andrew and I have demonstrated this multiple times over the years.
I will add that the performance of HumanUI is on par with WPF performance, and I know this from experience having built very complex HumanUI interfaces and then rebuilt them in WPF. The biggest performance challenges that you will find in HumanUI is:
when creating dynamic elements (as I described above), the instantiation time can be long on load because the WPF construction is not particularly efficient, but execution of the UI itself is very fast
when using live values from elements that trigger GH logic execution (UI execution is negligible here), as described above by Jacques
I cannot thank you enough for the detailed feedback. Sorry if I was asking questions already scattered around the forums. After spending a significant time and rebuilding the script I have now learned how to properly use Set Values when needed to avoid redraw issues and how to make sure that elements are not constantly redrawing. Now I am able to construct the UI I wanted without any lag in calculations. Combined with Hops for the actual scripts I have managed to streamline by process efficiently (since every Hops component has a boolean input to enable/disable which is perfect for Human UI)
