Hi Muhammad, as promised - here is the video on dynamic/reactive displays in DKUI:
Cheers
DK
2 Likes
@Phil_Southwell has jumped in and created a new version of his YachtSoft package with a DKUI front end:
Nice work Phil.
Cheers
DK
2 Likes
from the looks Seghier (Fennec / Clipper2 / o.a.) is also currently developing an ETO-based UI for Grasshopper, I’m interested in understanding where your approaches differ
Hi @crz_06
I’ve seen Seghier’s posts on LinkedIn, but I don’t know anything more about it beyond what he’s shown in those videos.
DKUI includes the following features and design decisions, which I hope others will find suitable for their projects:
- Familiar “HumanUI-style” setup for controls
- Cross-platform support built in, thanks to ETO and web-based technology
- UI state saving and loading from the Rhino document or local files
- Fully customizable styling, either via built-in tools or handwritten CSS
- Fully extendable, with an open specification for DKUI-to-GH communication
- Designed for and tested within the GH-to-YAK plugin workflow using the Rhino Script Compiler
- Proven in commercial use — DKUI has been actively developed and used in production for 3 years. It’s not a side project; it’s a critical part of my own Rhino plugin development toolkit. As long as I’m working in this space, DKUI will continue to be developed, maintained, and supported.
Thank you for your question.
Cheers
DK
3 Likes
Thanks, looking forward to test with real users, so far lots of fun. Ps, here the w.i.p. by seghier Controller | Food4Rhino
1 Like
This is the transcript of a recent conversation I had with someone about a couple of features/workings of DKUI - my guess is this is useful info to others so I thought I would record it here:
AM 9:20 AM
Hello there !
I’m going through some examples of DKUI and I really like it so far ! Thank you a lot for developing and documenting it. I’m sure we’re gonna change our “stack” to include it soon !
I have one question so far, didn’t know where to put it… so here I am 
It really is nothing much, just something I thought about.
I was wondering if some setup like this was imagined at some point, or if there’s a strong opinion against it
Currently it doesn’t really work because of the refresh of the panel for the “value” input. And the component seems to be expiring continuously.
I know having something like I’m showing would also mean that the listening to the value in the UI would need to be a separate component and that it might change a lot… I’m just curious
David Kay 10:13 AM
Hi AM, thanks for your message and great to see you looking at the inner workings of DKUI. This question of creating multiple controls from a list of inputs has come up a few times in the last couple of weeks. Currently this is not supported for any user input component in DKUI.
The reason for this is that currently the panel on the value input (the one that auto nick-names) is the “keeper of state” of that input control. For your example above we would need 3 different ‘value’ panels for each of your desired inputs.
I believe I may be able to find a working solution for this requirement in the future tho - leave it with me to mull over and experiment with.
For now, you’ll just need a separate component setup for each control.
AM 12:57 PM
It really would just be a “nice to have” functionality to create all the same kind of inputs at once. But definitely not a deal breaker
Is there a particular reason to have this panel as “keeper of state” rather than a “reader component” like human or synapse use? Out of curiosity
David Kay 1:42 PM
Hi AM, GOOD QUESTION - the #1 reason is that those named panels are actually a key/value pair - the key being the nick name and the value being the panel contents.
This combined with the DK_ prefix naming allows for a very simple scheme to pass values from the DKUI user interface into the Grasshopper script. The DKUI server when it receives an ‘input event’ just looks over the whole GH doc for a panel with the matching nick name and drops the value into it.
Where this EXCELS over the listener component model is in the save/load state setups - these components can scan the whole GH canvas for DK_ named panels and create a key/value pair list without needing any wiring or maintenance. It is beautifully simple and effective compared to what I had to do to add the same function in a HumanUI driven script.
AM 1:56 PM
Really interesting !
The flow is: UI changes → DK_server looks for panel → updates value ?
In the previous plugins (human & synapse) it was always a bad idea to have components of the UI being expired by values from the UI, but that doesn’t seem to be the case here
David Kay 3:13 PM
Maybe check out this video, it will give you more insight to how the DKUI comms model works:
AM 4:11 PM
Yes they are on my list, I should have watched them before asking !
Thanks for the link and for all that documentation
Hi DK,
Thanks for making DKUI available, looks great.
In having an initial play for a UI I have been thinking about adding to one of our scripts i noted that there isn’t a simple single line text input. In this case for a url path for a speckle model.
A text area could be used but the styling is different than a simple input.
Taking inspiration from the number input i managed to modify the input html manually to create it and update a text panel. took a few attempts to keep state by plugging the panel back into the html value field via simple python string substitution but looks to work fine 
Might be a useful input to have though?
<form onsubmit="return text_area('DK_Speckle+Model+URL_main')">
<div class="dk_number_input">
<label for="DK_Speckle+Model+URL_main" style="flex-grow: 1" title="">Speckle Model URL</label>
<input type="text" style="flex-grow: 1" id="DK_Speckle+Model+URL_main" title="" value="{{value}}">
<input type="submit" title="" value="OK">
</div>
</form>
2 Likes
Mate, that’s awesome, this is exactly why I published the DKUI comms model, for others to build on the platform.
That being said, a single text input is actually an overlook in the stock DKUI components. I’ll for sure add one as soon as I get a chance.
Cheers
DK
V25.06.19.1 of DKUI is now on the package manager and now includes a native single line Text Box component:
Thanks
DK
2 Likes
You will be pleased to note that on the next release of DKUI there will be a native table display component:
It takes in lists for the column headers and row names, and a list or tree for the table values.
You can use a flip matrix component to change the layout direction if required:
Cheers
DK
1 Like
Thanks! I noticed as soon as the table previews appeared much better than what I had added. Amazing stuff
1 Like
Further to the above Table Display Component, in the latest version of DKUI uploaded today you will find three new chart components:
Line Chart:
Bar Chart:
Pie Chart:
Please let me know if there might be other types of chart you need in your workflows and I’ll see what I can do.
Cheers
DK
2 Likes
Hi @kiteboardshaper ,
I’m getting this error (in the pic) immediately after installing the plugin. Do you have any idea how to solve this?
Thanks!
Thank you for the bug report.
I suspect this is an issue with downloading and installation of some pip install of python 3 packages I am using in DKUI.
These should load correctly on your machine on first run/use of DKUI, however I believe some people of seen issues with firewalls and/or slow connections.
Would this might be the case here?
Cheers
DK
Actually it is solved after updating Rhino to the latest version!
Thanks
1 Like
Great to see my work out in the wild:
Cheers
DK
Hi @kiteboardshaper,
I followed your YouTube tutorial on how to compile a file with Rhino’s Script Editor, but I encountered an issue.
I created a DKUI Bake button, but it doesn’t work. However, when I open Grasshopper normally without compiling my file, the DKUI interface button works perfectly when I click on it.
Do you have any idea how to solve this problem?
Thank you very much for everything you’ve already done with regard to DKUI
Hi Pley,
Great to hear from you and also great to hear you are using DKUI and the DGRS stack.
I’m out of the office today, so can’t test this setup.
One thing that does come to mind tho, did you check the keep open box in the GH file properties?
Cheers
DK
Thank you for your prompt reply,
Yes, I did select that option.
Kind regards
Hi Pley,
Quick question - which Bake component are you using in your script?
I’ve done some tests today, not fully compiled but using Grasshopper Player, and:
- The Rhino Content Cache component does not work thru the Grasshopper Player
- Human’s Bake component works fine when compiled
Please find attached my test file as an example:
I recommend you use Human’s bake component when compiling a GH script to a YAK.
Cheer
DK
250718_DKUI compiled bake test.gh (19.0 KB)