User interface (UI) node set — buttons, sliders, text/number boxes, menus

[Bodysoulspirit]

Ok. Thanks for the update.

Maybe it would be cool to keep the “Notes from Team Vuo” on top updated in some ways, summarizing the suggested sub-parts, the chosen-to-be-implemented-next ones (), the to-be-implemented-later ones () and the tabled/refused/duplication ones (). Tried to sum it up here (PS There may be duplicates within the list since I don’t understand some of the requests)

Main Button :
Borders option
Border thickness
Button Roundness
Transparency support for icon images
Larger icons
Different icons depending on states
Rollover/Pressed/Released states booleans
Rollover/Pressed/Released event outputs
Rollover/Pressed/Released skinning
Toggling output within the button
Text size scale with button
Text wrap option
Scale button to text width option
Support other pointing devices
Make custom button/UI element Node from layers
Make Theme Node & Theme port on Make Button

Checkbox/Toggle Button
Grid (2D) of Checkboxes
Sliders
Radio buttons
Group of radio buttons
Dropdown menus
Momentary buttons (sticky vs momentary)
Group of momentary buttons (menu)
Select box (same as Finder window?)

Text/Value Boxes
Progress Indicators
Finder File Open dialog window
Finder File Save dialog window

For me I guess it’s important that :

• The texts/labels can scale with the buttons ( Text size scale with button)

• And ( Make custom button/UI element Node from layers)

@jstrecker “For each type of widget, there will be a node to specify font, colors for various states (normal, hovered, pressed), corner radius, etc., AND A NODE TO BUILD a FULLY-CUSTOM THEME from LAYERS”.

Don’t know how this was planned to be realized, but it would be awesome. It would allow users that want deep customization to reach their needs before all the specific skinning sub-parts are implemented.  

[useful_design (Alastair)]

Custom font faces for text elements of all buttons

Can embed fonts for use in Exported Apps and Plugins  

[Bodysoulspirit]

@useful_design

Regarding “ Can embed fonts for use in Exported Apps and Plugins” you know about When I export my composition to an app, how do I embed a font in it?

For plugins I once had a dream we could bundle stuff inside a Vuo composition too, like in Apps, so that actually the Vuo file would be a bundle with the actual Vuo composition in it … But I will create a discussion about this.

And regarding “ Custom font faces for text elements of all buttons” if I understand you correctly I’m not sure if that fits this list since it’s a basic feature of Vuo to be able to use custom fonts already is it not ?  

[useful_design (Alastair)]

I’m pretty sure I found a way to bundle some assets in Quartz Builder but I forget if fonts was one of those things, sure they will bundle but will they be loaded by the host OS?

Some kind of shell script that can run an AppleScript at startup would be quite nice. I’m sure Team Vuo have much higher priorities but it would be nice, and I could envisage some low-cost sellable screensavers and apps coming out of that.

[cwilms-loyalist (Chris)]

Once the UI nodes feature is implemented would would text and number input boxes retain any data entered into them or would they go back to default the next time the composition is loaded? I can think of a lot of scenarios in my compositions where I would want the data retained between composition runs.

[jmcc (Jean Marie)]

Chris,

You can use the Save Data and Fetch Data nodes, optionally in conjunction with the Tree nodes, to retain the state of the UI nodes.

[Bodysoulspirit]

From CSV issues : don’t find the good setup it’s obvious one can’t at the moment make a long list of action buttons (and other UI elements I guess).

So I’m wondering about 2 things :

---

A - Generally spoken, for the Action Button I guess an output event on press is good, but for several needs it requires to create another list with other nodes to map the specific events (for example a Select Latest List of URL’s that receive an event).

If for example the make action button also had a Value input & output that would fire on click (for example text with an URL, (but generic would be better)), one could directly make a list of Select Latest (with variable amount of inputs would be cool here) with those output values, and send the latest in an Open in Browser for example.
That would be already easier for a small amount of buttons, but for the example case linked on top, you would already need to make too many instances of that node.

---

B - You can’t process buttons either in a build list, nor with Copy Layer.

I don’t know if Iteration: Turn most nodes into iterators by allowing single-value ports to accept lists will be possible.

So I wonder.
If Make Action Button had an Input port, that it could be iterated with Lists on Ports, and that it could be fed a Select Latest with variable amount of ports, that would be the best I guess.

But if Iteration would not be possible with Lists on Ports, I guess a Make Action Button List would be something.
For inputs, beside the other required elements (theme, window, …) one could have :
• VuoList of labels input,
• VuoList of Values input,

And for outputs,
• a button layer list of course,
• an event output, or maybe rather an index Integer fired from the last clicked button,
• and the Value output of the last clicked button (the labels could technically be used, but if you have an URL, the URL as the label won’t do it).

Without a Value input & output, if this hypothetical list fired an index of the clicked button, it would allow to map events, but would still be more work to map the events.

PS : I have tried to modify the Make Action Button to add Value inputs & outputs, I have the ports, it outputs the text Value, but it fires events on mouse moves for example at 80 FPS so I’m missing something (joined).

 

Make Button With Value.zip (4.65 KB)

[pbourke (Paul)]

Is there any timeline for when we might see a text input UI node? Quickly installed 2.0.1 … nope. Urgently need this one. :-)

[jmcc (Jean Marie)]

Paul,

We are interested in knowing how you would use a text input UI node. As a workaround, perhaps a TouchOSC implementation might work (as in Simple TouchOSC Typewriter). Once we know what you need, we could give you an estimate on commissioning it.

[pbourke (Paul)]

For my current use case I have realtime graphics being created by Vuo on a secondary screen that is projected, this is what the audience sees. I wanted the operator (teacher) to be able to feed text questions into the realtime graphics.

[wmackwood (William J Mackwood)]

I too would like to see a text/number input UI node. This would be very helpful for the ‘lighting visualizers’ I create in VUO. These would not need to be complex, just a graphic box that accepts either text or numbers when highlighted, and fires when ‘enter’ is hit.

Not a super high priority, but very helpful for interactive compositions.

William

[jmcc (Jean Marie)]

Paul, William,

Perhaps you could use Display Console Window as a workaround for now. As the node documentation says, “Typed Line — When a linebreak is typed in the window, this port fires an event with the line just completed.” So you can enter a line of text in the Console Window and output it.

[bLackburst]

@jmcc The user interface IS the product sometimes, displaying a console window is not a workaround. It’s clearly a sought after and useful thing, presumably not that difficult(?). It’s a six year old feature request now that was chosen to be implemented 4 years ago. Should we give up hope?

[useful_design (Alastair)]

I agree with @bLackburst. Console window is not a viable workaround from real-time operation of anything.

Years ago I spend countless hours making a multi-bank switcher in QC for QC that used spooky patches along with some pretty simple JS to sample data at any point of the composition and record that value (bool, int, real, string, array or complex object) and then save that to a patch like an old analogue synthesiser (think Roland synths like the Juno 60). Then at any time you could restore any of these patches and those data values, including objects would replace the value on the noodle coming out of it. If you changed the value coming into the patchbank node then it would change the value again just like moving a slider on an old analogue synth would edit the current patch. The JS code for the controller app was hundreds of lines long and became too much of a headache for me when i realised I needed to refactor it using an improved coding style to get the bugs out (I was teaching myself JS along the way!)

Anyhow, I put in a feature request to put the framework for that concept into Vuo. Basically the ability to sniff state and write state. Either in dedicated Vuo nodes or as a new API interface for all new Vuo nodes.

But another work-around is another thing I requested. A websocket node. Websockets allow two way binding between web pages and other programming tools. there was a 3rd part websocket tool i used with QC that allowed for reasonably sophisticated UIs to be built competitively effortlessly with HTML & CSS and a tiny bit of JS just to implement the websocket binding for each button, slider, enumerated list etc.

EDIT> FR links added  

[bLackburst]

Lost me, but it feels the spirit was there somewhere.

[useful_design (Alastair)]

I’ll say it more simply, @bLackburst!

Team Vuo clearly has a capacity issue in delivering FRs and updates for what many consider to be core-need Vuo features. Therefore we need to make it as easy as possible for Team Vuo in terms of development hours and integration complexity with the existing Vuo codebase and code roadmap. Not to mention bug fixing down the track.

UI tools are inherently behind the times because expectations are always moving on to the next big thing. In my experience using QC, it takes a long time to smooth all the rough edges and corners making generalised tools that work for any window size and play nice with resizable windows etc etc.

In my view deploying the websocket API offers the most bang for buck for @teamVuo’s effort to provide a workable UI solution. All they need to do is build a bridge using the tried and true websocket framework. All the UI tools are already there in internet-land. Anybody who can teach themselves VUO can learn to make a few buttons, radio buttons, sliders and drop down lists and arrange them on an HTML/CSS page with other text and images. And i can guarantee you whatever UI tools Team Vuo can release in the next year, some people will find them lacking compared to what they’re used to in other apps.

One down side is that it will be outside of a compiled Vuo app that we might want to distribute to other people, but a browser based UI will still be able to talk to the Vuo app via websocket and we might even be able bundle the HTML/CSS/JS files and to script the webpage to launch?

If Team Vuo think that they can do a set of custom UI features with less time invested in dev and polishing than it takes to make a websocket API implementation inside Vuo then go for it but I’m, extremely doubtful. Remember that a Vuo UI feature set will require all the logic processing nodes to do the view/controller/data back-end of the screen elements also. To me, websocket is the best option for step one down this path.

Also i found this thing Mozilla developed called HumbleNet: A cross-platform networking library that works in the browser. It consists of a C wrapper around WebSockets and WebRTC that abstracts away cross-browser differences, facilitating the creation of multi-user networking functionality for games and other apps. It might be a shortcut for Team Vuo to get websockets and the WebRTC low-latency protocol happening ASAP, although I’m not sure how much it allows for websocket exclusive use, seems ot be used just for the authorisation phase of the connection.  

[MartinusMagneson (Magneson)]

Not to be an donkey, but text input has been available for some time. See my post here to get a primer.

You should also search for “vuo.ui”, “vuo.mouse” and “receive” in the sidebar. Most of what’s asked for in this thread is available through the nodes listed there. Some will have to be built more from scratch than others - but I had working sliders from those nodes in 1.1 or 1.2 iirc.

[bLackburst]

If you guys want to spend time coding websocket guis and Rube Goldberg typing machines knock yourselves out. Vuo needs a text field gui element.

[cwilms-loyalist (Chris)]

I for one don’t believe a web socket GUI solution would work well for me. I currently use the existing GUI buttons along with live video feeds and live graphics in a couple of my projects with almost 0 latency which is important to how I use VUO. I also have a number of ideas for future projects and applications that will require a built-in GUI as part of the exported app and so really want these as non-websocket controls.

So I am very interested in these new GUI features that will eventually be coming out and believe they will be worth waiting for, I would also be really disappointed in a websocket only implementation. I’m not saying websockets can’t be useful but I don’t want to see it as the only solution to this feature request.  

[jstrecker (Jaymie)]

@MartinusMagneson! This is awesome! Thanks for providing not only a working example of text input, but also a tutorial on how you built it.

Until there’s a textfield node built in to Vuo, people can reuse your composition in their own compositions. At the end of your tutorial, I like how you explain how to turn it into a subcomposition for easier reuse.

@bLackburst, please keep in mind the community agreement, specifically about generalized negative statement. Ideas about alternative ways to accomplish a task in Vuo are always welcome on this forum. Criticisms are also welcome, but they need to focus on specific points that could be improved.

To all who’ve asked about a textfield node — We’re still planning to add one. We actually started work on a textfield node while developing the Vuo 2.0 release. I would not have guessed this, but it is surprisingly, fiendishly difficult to make a textfield with customizable appearance that behaves like a proper macOS textfield. After a lot of hours spent, we decided that it wasn’t worth holding up the release for this, and we would come back to it as soon as we could. Right now our focus is on getting Vuo ready for the macOS 11 release and Apple’s ARM processors. Once those are under control, we plan to pick up where we left off with the textfield node (which, based on the comments on this issue, is resoundingly the most wanted of the remaining potential UI nodes).