Hi Muhammad, as promised - here is the video on dynamic/reactive displays in DKUI:
Cheers
DK
@Phil_Southwell has jumped in and created a new version of his YachtSoft package with a DKUI front end:
Nice work Phil.
Cheers
DK
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:
Thank you for your question.
Cheers
DK
Thanks, looking forward to test with real users, so far lots of fun. Ps, here the w.i.p. by seghier Controller | Food4Rhino
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>
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
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