DKUI is built on ETO.Webview so runs cross platform. The actual user interface is completely Web technology based - HTML/JS/CSS.
Building UI’s is somewhat similar to the classic HumanUI system - maybe a little simpler.
I’ve been using the ‘bones’ of this UI system in my own Rhino Plugin products for a couple of years.
This is a rebuild that removes 3rd party dependencies and cleans the code up for public consumption.
Current user inputs available:
Tab controls (for tab style pages)
Button
Check Box
Number Input
Number Slider
Pull Down List
Toggle Button
To set the appearance of your UI I’ve built a pair of ‘CSS’ builder components - one with light mode presets and the other with dark mode. There is also a component that can tell you which mode Rhino is currently set - to allow switching between display styles.
To be able to save/load the state of your DKUI driven GH programs I’ve also added some components to:
Read the complete UI state to key/value pairs (for saving program state)
Load a set of key/value pairs to the UI (for loading program state)
Saving and Loading Key/Value pairs to/from the Rhino Document User Text
Feel free to have a look and send feedback/wish lists.
I will schedule a time to make a “How To” video in coming weeks.
Love the direction. Using a Webview for UI’s is something that I’ve been considering for while to make it easier for my team to flex between our different environments.
Are you planning to release this as an opensource tool, a free to use tool, or a paid plugin in the long term?
The main appeal for using WebView is the honestly MASSIVE amount of documentation for html based UIs online. Tho ETO is likely the best choice for Rhino built in support, it’s learning resources are low and it’s learning curve is steep.
The question about future plans is a good one. In this thread there is a discussion about the current state of GH user interface building tools:
In many cases the projects are no longer being supported or developed, which is particularly painful for many with HumanUI.
DKUI exists purely because it solves my own problems, solving these problems has allowed me to develop three commercial rhino plugin products in the last three years.
DKUI is likely a useful solution for others as well, but in releasing it as a plugin I will also then be responsible for the performance of others projects, not just my own.
This video has an interesting take on FOSS:
As of today HumanUI is listed as having 60k downloads on Food4Rhino. I personally used it in the early days of development of my commercial plugin products. I’ve never sent Andrew any money for his amazing work on this plugin, I don’t even know how too? If HumanUI had a paid level of use, would Andrew still be interested in maintaining and upgrading it?
I don’t have an answer, for you, DKUI is my first Grasshopper plugin. Nautilus is the only GH plugin I know of that has a paid level of use.
As a developer, even a small amount of income from your work can be highly motivating to keep it up to date and improving.
Maybe others have ideas for how a project that is useful for so many users could reward the time and effort put into its upkeep.
@stevebaer tho I would be very keen to contribute there are two issues,
1/ HumanUI is windows only, so even tho it’s an amazing piece of work that does a great job, it no longer suits my requirements
2/ My c# skills amount to less than zero, like wth does that “void” keyword mean and why is it in the first line of every c# source I see?? I’m somewhat productive in Grasshopper and somewhat dangerous in Python…
Web-apps are running inside a sandbox (Browser). This is safe, and works exactly the same on all machines with the same browser version. But you are not indented to leave this sandbox, e.g. to access the file-system.
“Webviews” or technologies like Elektron are embedding an entire browser inside a Window and solve this access problem by providing an interface to the system. Nowadays its quite optimised and has a relative low footprint of memory and cpu usage. But if you consider that you instantiate an entire browser just for provide basic controls, then you could argue that this very inefficient. Also its not guaranteed anymore that it acts the same on every system. So you cannot assume that your application works on MacOs the same as on Windows anymore. Even if its less likely to run into OS specific differences.
All very good points you make there - and I mostly agree.
For access to the file system, since a local copy of GH is my ‘back end’, I use buttons to trigger the standard Rhino Script Syntax UI file open/save tools and let the GUI just be the GUI.
I do have some some small cross platform issues I need to sort out, fonts and some text encoding - but in the big scheme of things they are minors.
If we were arguing the most efficient way to develop desk top apps and plugins we would not be starting in Grasshopper! And you have called me out directly on this in ‘that thread’. However I’ve not seen any major overhead. The current Rhino 8 I have open with my source and the Rhino Script editor running is 578MB, Thunderbird, Chrome and Dropbox are all taking more memory to run than this.
Hoping to get some time later this week to do a ‘Getting Started with DKUI’ video. Watch this space.
First of all, thank you for sharing such an awesome plugin!
I have two questions.
Is it possible to fix the position of the panel to a specific location?
As of now, it seems like I have to manually adjust it to the desired spot every time I open the file.
The other question is whether it’s possible to upload a file.
Everything else works great—text, sliders, dropdowns, color settings—but I find it a bit unfortunate that file upload isn’t supported.
First of all, thank you for making this available for everyone. I remember discussing your work with interfaces and thoroughly impressed by your approach. I tested the plugin and just the fact that it is cross-platform, easily modifiable with html elements, and super quick to set up I think this is truly the success to Human UI. Human UI is really amazing for what it does but I think your system even in beta does pretty much 99 percent of what users normally require.
Just couple of thoughts and questions:
Any plans to implement file/folder picking input? Would be a great combination with the load/save features you have added.
I have not really tried this but how is webview suitable for hiding/showing inputs parametrically? That is one area where Human UI was really powerful. I think the webview redraws every time so shouldn’t be a problem?
It really does feel snappier and super lightweight compared to other interface plugins.
Are you planning a table view to show data? Or what is the best approach to visualize quantities in realtime?
Something I am going to test is compiling scripts with your UI and Script Editor in R8 to create standalone tools for my team.
All in all, amazing stuff. Cannot wait to see how it progresses. Beer on its way.
You are the second person in the last 24hrs to ask for this. For myself, even when I used HumanUI I simply hooked a UI button to trigger a python component and used the Rhino Script Syntax OpenFile dialogue. This wont take long at ALL to add to the components list - consider it #1 project for next release.
Hiding/showing inputs
Very possible and very simple to do, I have a couple of examples going already in my own code. IN FACT the whole TABS setup in DKUI is just a big version of this. I’ll cue this up as a video topic and cover in depth for you.
Data Table
Its on the development list, no time frame yet. KaroroCAD has a version of this going but to be honest that is a complete mess/hack - mostly as I had backward compatibility I wanted to keep in save files.
I’ve not yet used the Script Editor to compile a DKUI app, but do use the Rhino Script Compiler CLI tool. I have been asked to make a video to detail the process - watch this space.
DKUI is however built and compiled using the Script Editor, which for GH Python to GH plugins is an amazing tool.
On the next release of DKUI there will be two new inputs on the DK Page Server:
page_x page_y
This will take a factor from 0 to 1.0 as a % of the SCREEN that Rhino is currently on (its aware of multi screen setups) and will position the DKUI at that point every time you ‘show’ the DKUI window.
Also updated on this new component:
The launch input has now been renamed to the show input - toggling this off will hide/close the window.
I have also added a close_rhino input to enable/disable the 'The DKUI window was closed, did you want to close Rhino" dialog.
