Thank you so much for your outstanding work on DKUI — it is truly a very promising UI solution for Grasshopper.
I noticed that the new DKUI no longer seems to support specifying a custom server URL (e.g., http://localhost:xxxx), as was previously possible via BENGESHT. For my intended use case, this functionality is quite important, as I’m exploring ways to implement real-time control and remote access to Grasshopper definitions using tunneling tools like zrok.
I understand that platforms like ShapeDiver also offer cloud-based Grasshopper access. However, for my research and development needs, I prefer a fully self-hosted solution due to reasons such as data privacy, response latency, and the need for direct integration with local hardware and scripts. Additionally, hosting a lightweight WebUI on localhost allows for much more flexibility when deploying custom interactive tools, especially in experimental workflows or installations.
Would it be possible to retain or reintroduce the option to set a custom WebUI URL — or perhaps allow DKUI to work alongside BENGESHT again?
I completely understand if this feature was removed for simplicity or stability, but having the ability to point DKUI to an external or localhost web server would make it incredibly powerful in hybrid workflows — especially when working with non-technical clients or in remote control scenarios.
If there’s a more suitable or recommended approach to achieve similar functionality, I would greatly appreciate any guidance or suggestions.
Thanks again for your excellent work. I’m really looking forward to seeing how this project evolves!
Thanks for your kind words and for reaching out with such a thoughtful question.
You’re absolutely right — the early versions of DKUI were based on the Bengesht server component. However, that setup came with several drawbacks:
Stability: The Bengesht server had a tendency to crash, and recovering from that wasn’t straightforward. I had to add quite a bit of logic in my Grasshopper definitions just to manage restarts, which made it unsuitable as a clean, reliable solution for others.
No Longer Supported: Bengesht is no longer maintained by its developer, meaning it could break with any future Rhino or .NET update — a risk I didn’t want to pass on to users.
No Package Manager Support: Bengesht predates the Rhino Package Manager, so it has to be manually installed. This limits how easily it can be shared through GH files or compiled into distributable packages.
That said, DKUI is not intended as a replacement for Bengesht’s server components. Instead, DKUI removes the dependency on any server component for locally deployed ETO.WebView interfaces. It uses a server-less, direct communication model, which I’ve started documenting in a few videos.
That said, it’s interesting you bring this up — I do have some internal code that launches an ETO.WebView and points it to an external URL. I’ve used it personally for linking to documentation (e.g., a Google Sites help page), and while this setup doesn’t support GH control integration, it might still be useful for display purposes or embedding reference content.
If you think that could help your workflow, I’m happy to share a snippet or explore how it could be expanded.
Thanks again for your interest — I really appreciate your support and the perspective you bring from your research use case.
By the looks of that image you have downloaded/tried to open the original MVP/Demo file I posted in May.
As is often the case with new release/beta test software bugs have been found and fixed. In particular those listed components have all be re-written from Python 2 to Python 3 to help with non-ascii character support. They still exist but the new versions do not auto update on the previous demo files.
If you need that particular. let me know, and I’ll rebuild in the latest DKUI for you.
Otherwise I suggest looking at some of the more recent videos on my YouTube channel:
Each of these has a link to the GH source code used in video in the description.
Hi Dave. I am watching this project for a while and finally found a bit of time to play with it. In our company we are looking for a more versatile replacement for HumanUI, where we pretty much ran out of its capabilities, especially when it comes to styling and responsiveness
HTML/CSS based approach might as well be it, however I know nearly nothing about HTML nor CSS so while I’m learning, please excuse me if some of the questions I ask are utterly dumb.
Down below I will write a few comments/questions that came to my mind so far:
Flow: I have not understood why output value of the DKUI component does not go only downstream but also is propagated upstream in front of the component, which is against GH flow. Is there any specific use case why you decided to use this approach? I would expect that the value input only is a “initial” value of the UI element
Tooltip formatting: when a tooltip for an element is defined, it is displayed as a plain text in a thick-outlined box. Is the tooltip something that can have its appearance also modified via CSS? Furthermore I think it would also be highly beneficial if tooltip could contain more than just text, eg. picture, diagram, formatted text block… If that is only editable via CSS, we probably need some pointer to target a specific UI element. This point leads me to following two concerns
Unique UI element identifier: I presume there must be something that uniquely identifies UI element among the others. What we need is to modify the element without influencing the others, meaning outside of generic CSS styles. Currently I can not figure out how to do that. Use case example:
In out current UI, we often use buttons that contain icons instead of a text. The icons are changing based on button “state” (actually an icon ID, because there can be more states than just 2). Or we use images/colors to give user all kinds of feedback. In such case I do not know, how to target specific element and change its state. I presume you are familiar with HumanUI and all of its “SetElement” components. Thinking about something similar, just for your plugin.
Clustering: another thing that bugs me about HumanUI is unability of clustering UI definitions. Example: I prepared a row in the UI that consist of multiple elements, that I need to repeat 10x (eg. handling of object attributes). In ideal case I would just cluster it and then copy, so that all modifications propagate to other instances. HumanUI cannot do this. Can your plugin by any chance handle such approach?
Defining custom element keys: When you create DKUI element, automatic identification key is generated for its receiver panel. However, when element with same setting is copied, it creates a duplicate key, and the can then interfere. Would it be possible to define a custom key? That would allow me to define long, descriptive key, which would be very useful for sending the button signal to panels across the canvas. That would leverage the full potential of what you are doing I think - be able to pick the key, that is binded to specific UI element, and then be able to cast it anywhere across the canvas (into a panel). Please note that this “interference” as such is not a bad thing. It allows to trigger “same target” from multiple locations, which was slightly annoying to achieve with HumanUI. We just need the ability to control it. Little detail to this would be the possibility to add your own additional tags to receiver panel name (= you would not do exact text match, instead an inclusion). Use case: we use group tags to search and jump through components on a canvas. If I had remote controlled group, like this DKUI receiver group, I would tag it “_rem” in the NickName, our helper script changes its color and makes it searchable item. If this did not interfere with DKUI object matching, that would be perfect.
Maybe some of the above mentioned is possible, and I just don’t know how. May I ask you this - would it be possible to give us more in-depth tutorial on creating pure html-based UI elements, collecting feedback from them (eg. custom button with images) and modifying their appearance? I believe your plugin might be able to do this. I saw your tutorial where you work with hrefs, but when I tried to apply these steps on a button, it did not collect data.
All in all, what you are doing looks very promising. If there was a way of just defining anything HTML based, collecting data from the element and targeting it for feedback modifications, it would be a true banger. Great work so far!
Great to hear from you and thank you so much for your interest in DKUI.
Those are some AWESOME questions you have given me, I was hoping to have had time today to answer at least some of them, however my Monday got completely out of hand and I’m still in my office at now 8:20pm.
If you can please bare with me, I will approach to answer each of your questions in turn over the course of a few days.
The answers may in fact take the form of videos on my channel if I see that this is the best format.
The Value Panel on all DKUI components is the “Keeper of State” - it is the location of what is the current state of of both the DKUI User Interface AND that input to the Grasshopper definition.
It is in fact a KEY/VALUE pair - with the KEY being the panel nickname and the VALUE being the panel contents:
In this case the KEY = “DK_Check+my+box” and the VALUE = “True”
Each DKUI user control creates a valid HTML format user input based on the state of this value AND you GH document also uses the value to calculate whatever is in the GH Doc.
Also, and this is VERY different to HumanUI, the COMPLETE User Interface window is rebuilt and reloaded on every every change to these key/value pairs. Hence these these panels being the “Keeper of State”.
When a new value is entered in the user interface, this is sent to the DK Page Server, decoded and the new value is written into the Value Panel of the control that was changed.
To this end, and as you have asked in one of your later questions - a UNIQUE Key is required for every user input. If there are copies, the new value will be written into ALL the panels with that key.
There are a number of advantages in this approach.
With the UI being built live and on every value change, it is ALWAY a representation of the state of the system. It cannot go out of sync.
It makes it VERY simple to save and reload the state of the DKUI user interface - which why DKUI has a powerful set of State Saving components - that do not require extensive “wiring in” to your UI logic.
Please let me know if you need any more information than that.
@Ukrutony DKUI tooltips currently use the default HTML title attribute:
Because of this, the appearance is entirely controlled by the web browser rendering the UI - in our case, the embedded WebView2 engine (and this varies by platform). So unfortunately the basic tooltip styling isn’t something DKUI can override directly.
To be honest, the tooltip feature in DKUI was a quick addition I included simply because the underlying HTML attribute was easy to expose. Rich formatting, images, and other advanced tooltip behaviours weren’t originally part of the plan.
That said, it is absolutely possible to build fully custom, richly formatted tooltips using CSS and HTML:
Doing this properly would require custom DKUI components, which I’ll cover more when I reply to your later questions.
This might be a good moment to clarify DKUI’s intent and the scope I’m aiming to support.
DKUI was never meant to cover every possible UI use case. The goal has always been to provide a lightweight, fast-to-implement UI system for Grasshopper. But - because the communications layer is fully web-based - I fully expect power users to push further and build their own specialised HTML/CSS/JS components where needed.
And to be clear:
I highly encourage the creation of custom components to extend DKUI wherever the bundled tools don’t meet your needs.
@kiteboardshaper Hi Dave, take it easy. My days are also getting out of hand regularly and I barely found time to read your answers
Thanks for those so far, I’ll hold back for a bit because I see some interesting info coming from your side, since the most important ones are still to come. Hope that will benefit anyone reading this thread.
The thing with tooltips was not as important, it is due to the fact that we have large group of users who from time to time have problems with more complex features of our scripts. In the past we have been even using pictures or diagrams in the tooltips, that’s why that came to my mind.
I understand the intention you described and it is of course only natural that plugin author only provides certain set of features. It is also fair to admit that sometimes author gets slightly carried away and provides us with a feature that people barely use, while something fundamental is missing. Now I am not thinking about you, but HumanUi instead, to which I have kind of love-hate relationship in that sense (that also translates to the overall amount of time I spent fiddling around with it). Since you are still in the process of developing your UI and I reminded you, this surely won’t happen to you
In accordance with your philosophy, I was seeing the main benefit of your UI in possibility of creating custom elements, as you also suggest. I hope you will elaborate a bit more on that once you find time and also hope that I am not the only one interested.
Further to the above post, I have made a major update to DKUI over the last week - with ALL CSS now only being generated in the Light and Dark styling components.
I’ve also added more CSS div’s to each of the standard controls to allow more targeted styling per type of control OR to an individual control.
A video showing the update and what you can do with it is pending, however the Christmas break is bearing down on me and time is short to get this done.
Send me a DM if you need a question answered or have a bug to report.
On this particular topic, in the last release of DKUI in 2025 I made some major changes in the way CSS is handled across all components and the document as a whole.
Of maybe most interest to you here is each component is now DIV referenced both as a type of component AND a unique DIV based on the DKUI ID. This will allow targeted CSS at an individual control level if needed - which will make state changes like icons and colour possible.
This is a pretty quick one to answer - unfortunately DKUI will never be able to work in a cluster.
The #1 issue here is clusters are an embedding of a completely separate GH canvas within the main canvas you are working on.
DKUI works by searching the GH canvas it is on and identifying all panel components with the DK_ prefix - it can then interact and communicate with these panels - say to update a value changed in the user interface.
No panel inside of a cluster is visible to DKUI as these are all separate/remote/hidden.
This is a very good question and I believe is likely taken care of already with the maybe poorly named “page_id” input on all of the DKUI controls.
I added this input originally as I had identical named controls on different tabs of a user interface, and page_id allowed them to show the same name to the user but have a hidden unique ID for the DKUI comms model.
However page_id is just as useful in situations that you would like a add a hidden custom ID to the component please see these examples:
In the top example the buttons have the same name but each has a unique ID, in the lower case the buttons have unique names but a common suffix that allows for custom search.
