An idea for Windows UI Elements in Dynamo

Packages
1

Yesterday I came across a blog entry by John Pierson over on Sixty Second Revit in which he showed an incredibly non-straight-forward way of making something that would resemble a dropdown dialog UI element for Dynamo. See the whole post here.

It is obvious that this is not the way to go and luckily Ian Keough saw what we were talking about on Twitter and asked what we would like to do. So here goes…

<span style=“font-size: large;”>Windows UI-elements for Dynamo —> Dialogbox canvas node</span>

Allright, here is my idea how the problem could be addressed with a few new nodes of course, of which some have some very special behaviour.

UI-elements that would be needed are:

  • edit_box
  • check_box
  • dropdown_list
  • radio_button
  • radio_button_group
  • a grouping element that would host several UI nodes and create a frame around them. The whole group can then be moved on the canvas easily by just moving the group element.
  • a bitmap picture element to show an explanatory image of what the other elements control
  • probably more but I am too lazy to imagine them all right now (also I got some work to do in the office :) )
To keep things simple I will start with the first three elements only. If you get the principle of those you will see how the radio buttons would work. But I will at least describe those ones too but without a picture.

Ok, here is a quickly photoshopped picture of a simple dialog definition. Open this image in another browser window while you read the description below.

 

dynamic_dynamo_dialog

 

 

 

 

 

 

 

 

 

 

 

 

<b>The text_box:</b>
A text_box is definied with a just few input variables:

  • id - An identifier which gives the object it's identity
  • label - A text that should appear as the input box label
  • default value - a default value with which the edit_box is populated
  • width - a width in pixels or another unit which allows to give the edit_box a size
<b>The check_box:</b> The definition of a check_box is very similar to the text_box with the exception that the default value is a boolean.

<b>The dropdown_list:</b>
The dropdown_list is a little more complicated to define since it can host a list of values. To build this list the usual Dynamo measures are used, see the screenshot.

Now things get interesting…

<b>The User Interace node:</b>
The UI node takes UI elements as inputs, provides a canvas on which the UI elements appear and where the user can move them around to group them together so they make sense for the user.
It would make sense if the movement can be locked down so that end-users don’t accidentically destroy the layout by an unintentional drag & drop twitch with the mouse.

The UI node also provides the values of all UI elements as outputs. What those are is obvious I think. The output value of the dropdow_list would be the index of the selected option.What the actual value is can be determinded easily afterwards.

Perhaps the inputs and outputs can somehow be hidden from the end users to simplify the layout. I am a bit undecided about this one.

OK, this is not an easy solution for the Dynamo team, I know, but it’s easy for Dynamo script-writers and end users who get to use the dialogs.

<b>radio_buttons and radio_button_groups</b>
(take a look at Dynamo’s boolean node if you don’t know what a radio button group is)
A radio_button node is easy to imagine from the definitions above. Two or more of those nodes make up a radio_button_group. The group then becomes an input for the UI canvas node.

The radio_button_group should have the ability to align the single radio buttons in a row or in a column.

Allright, that’s it already. Let’s discuss things if you are interested :slight_smile: It all is obviously not thought through all the way. The UI node definitions are not finished, there are many more options all the nodes would need. With this I think of the DCL-language of …don’t hit me! … AutoLISP… HAHAHA

2

Sorry about the crappy formatting. Somehow I cannot edit the post, it won’t update correctly.

3

I posted this comment on your blog as well…

First off, I really like the ideas you are presenting. It would be great to have this functionality available in the Dynamo canvas. With that said, I wanted to clarify a bit.

My method is simply showing a way of getting something similar as of the current Dynamo release (0.8.2). There are a few choices for a dropdown, my hacky way, learn C#, or wait for the developers to roll it into a release. For instance, if I want to do this today I only get to choose from first two of the three.

And since I don’t have time to learn C# this morning I resorted to the hacky way. :slight_smile:

 

I do like the idea you present though!

4

Hello John,

yes, I understand :slight_smile:

I have the same problem like you and likely many others have (which is the primary reason why we use Dynamo in the first place): Learning C# and the Revit API is not something you do just during your breakfast. The advantage of Dynamo over that is that script-kiddies like us can build elaborate stuff without the need of messing around in Revit’s guts all that much.

What I have in mind with this idea is a way to build end-user UI’s that would resemble a common dialog box more than what is available right now within Dynamo. People who only just use Dynamo scripts could fiddle around with the parameters more easily because they would be presented in a more easy-to-grasp way. In my office I have literally hundreds of such people who will be very intimidated when they have to deal with a large screen of spaghetti code. That’s why I am looking into Dyno for Dynamo too, where the actual Dynamo code is hidden from the normal user. In my opinion it is time (and I am currently working on that in my office) to get BIM into the hands of everyone, especially those who couldn’t even learn Dynamo. To me, most of BIM is a real chore because stuff is highly underdeveloped, especially when it comes to Autodesk Revit. This needs to change as quickly as ever possible.

Anway, I can imagine other ways of defining the UI nodes, as an alternative, that would hide even all the UI definition stuff from the user. The canvas node could be like a code block node and when you edit it you see the UI node definitions in the editor that opens. The language used in that edit window could be some UI definition script like DCL was (or actually still is) in AutoCAD. Maybe it could be some built-in (into Dynamo itself) Python functions we call and which would place the UI nodes on the canvas. One would define the UI elements in code and the user would not see those at all, except they find the edit command. From the end-user perspective this would even be better because the UI node could be the starting node for the whole script. My idea above would place it somewhere into the middle of the script. Defining UIs with code would be a bit harder because the script author would need to learn Python. Perhaps not too big of a problem. Actually, I would prefer this idea because it presents the end-user an easier script.

5

Great idea!

I could certainly use something like this. Just yesterday I was just looking for some way to create radio buttons, but reading your idea made me realise I could use checkboxes, dropdown lists and others as well. I’m just not really sure what the edit box you described would be able to do?

If I may I would suggest keeping the nodes really simple, maybe this way its easier to accomplish something like this.

input nodes