Really like the new button node, it's going to come in very handy. I'd like to know what plans there are for other ui nodes and perhaps share some thoughts on the current one.

  • Is rollover going to be exposed?
  • Perhaps toggling could be an option in the button itself
  • Style seems to be fixed at the moment. Roundness control, borders would be good
  • the icon seems to be a strange option, given the limited amount of coverage you can get with it. It seems like it would be a great way of skinning buttons but it currently doesn't behave that way. On/off states with different images would be grand.

For me other staple ui items would be sliders, text/val input boxes, drop-downs, perhaps even a way to open a finder window.

And, another request for UI nodes:

From user ddelcourt:

Splitting the single feature request into separate requests.

A GUI nodes library, like controlP5 for processing

The GUI elements would have input ports, to be able to be controlled by anything else (hardware is obvious), and provide visual feedback. Reference: http://www.sojamo.de/libraries/controlP5/.

Team Vuo's list of possible widgets:

  • Momentary button
  • Group of momentary buttons (menu)
  • Checkbox/toggle
  • Grid of checkboxes (2D)
  • Group of radio buttons
  • Select box
  • Slider/dial/thumbwheel (choose a number, either with or without a range, with optional linked textbox)
  • Row of sliders/dials/thumbwheels
  • Progress indicator
  • Row of progress indicators (bar chart)

Component: 

Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo CE and Vuo Pro

Complexity: 

●●●○ — A few months of work

Potential: 

●●○ — Could expand community

Implemented in Vuo version: 

Comments

Hi, @bLackburst. Sorry I

smokris's picture
Submitted by
Feature status:»
Open for community voting

Hi, bLackburst. Sorry I didn't get back to you sooner.

For Vuo 1.1.0, we're planning to include some additional button options, like on/off buttons, and the ability to customize the appearance by providing images/layers to render.

Beyond that, we'd love to include more UI nodes. I've converted this to a feature request, so the community can vote on how we should prioritize it.

Some of the features I would

cwilms-loyalist's picture
Submitted by

Some of the features I would like to see for Buttons are:

  • Pressed and Unpressed UI states
  • Image Skinning for each button state
  • Option for border thickness
  • Press/Release/Unpressed outputs
  • Option to make a button sticky vs momentary
  • More text formatting options including wrap and choosing the location of the text (over below/above etc.)
  • I currently don't find "Icon" large enough. Perhaps if "image skinning" also supported transparency in PNG files they can be used instead.

I was really glad that buttons have been enabled and I'm looking forward to what can be done with them.

Hey guys.

Bodysoulspirit's picture
Submitted by

Hey guys,

As this feature request is gaining more popularity, I wanted to share some thoughts about this exciting group of feature requests.

The first thing to keep in mind is that people want customizable stuff I guess ! (most comments mention that). So I really think this whole UI thing has to be done the easy way and the most customizable way !

I tried to list all the different sub-requests mentioned here and split them in categories. Then I’ll try to share my thoughts about these and how I think things could be done.


So the difference things seen here are :

1 - Buttons :

   - Custom Styled buttons with :
       a - Borders
       b - Transparency
   - On/off States.
   - Pressed/Released/Unpressed States (with Image Skinning for each state).
   - Toggling.
   - Rollover.

2 - Other UI Stuff :

   - Checkbox/Toggle + Grid of Checkboxes (2D) Select Boxes.
   - Finder Windows.
   - Progress Indicators.
   - Sliders.
   - Text / Value Boxes.
   - Text Formatting Options.

   - DropDowns.
   - Momentary Buttons (Sticky VS momentary Buttons) & Group of Momentary Buttons.
   - Group Of radio buttons.

Ok, now let's go this list point by point down :


1 - Buttons & Custom Buttons :

I think the actual Node could become a « Make default Button » node for those who don't want to customize.

And that we could implement a new « Make Custom Button » node :

  • It would have a « Layer » input (Or Image).

  • It could have a similar Input for « Rollover and/or Pressed » states styles (however, modern Buttons are more about smooth animations).

  • With « Combine Layers » you could customize the button’s style the style you want (Including Text, Borders, Shapes, Colors).

  • The outputs could be a - Rollover. b - Pressed. c - Released.

  • On/Off and Toggling could be easily done connecting these outputs to the actual « Switch » & « Toggle » Nodes I guess !?

Concerning Borders. If borders could be added to layers (or images), then all buttons could have customized borders (I am going to make a feature request for a generic Add borders to layer » node and a new discussion about the way all the « Get layer » stuff is retrieved in Vuo. (See mockup Below).


2 - Other UI Stuff

  • Checkboxes & Select Boxes : You could easily turn a custom animated Button into a checkbox. Is it not the same ?

  • Finder Windows : A total yes. A browsing Finder Window allowing us to pick up some images, folders, files …

  • Progress Indicators : I think those can actually already be done. For example you can interpolate the width of a layer on whatever values !?

  • Sliders : Yeah Sliders ! Great ! But again, we will want to customize them. Customizeabled buttons and bars for them. However, wit some tricks this can actually already be done. Check out my composition here, it has some custom sliders (see screenshot below) and here is the link Composition Link.

  • Text and Value Boxes : Yes ! Definitely ! The big missing one so far to me ! But again, the need to be customizable ! For example a custom layer for the box + custom fonts for the text ! (see mockup below).

  • Text Formatting Options : There is a specific Feature request for text wrapping : Wrap Text Request by Teo Dumbski. Could we use that ? Or should buttons have its own possibility here ?

  • DropDowns : Mmm I can’t figure out yet how this could be done.

  • Momentary Buttons (and group of momentary Buttons VS sticky Buttons) : I don’t understand this part. If this is about vanishing buttons after they have been triggered, I think that specific Request about Disabling Nodes could be useful ? Disabling Nodes.

alt text

alt text

alt text

[alexmitchellmus] Can we also have

smokris's picture
Submitted by

[alexmitchellmus] Can we also have a GUI or UI class set for the API?

In the Vuo 1.1.1 source code, check out node/vuo.ui/vuo.ui.button.action.c — that demonstrates creating a layer group and adding rounded rectangle and text sublayers to it.

Going forward, I think we'll start building higher-level C APIs for that stuff, since a lot of code will be reused between, for example, the (existing) action button and the (forthcoming) toggle button.

I am starting to really like

alexmitchellmus's picture
Submitted by

I am starting to really like super simple UI's. Also from an implementation perspective it may be cheaper (load wise) to have a UI consisting of as many square edges as possible. Something like this looks lovely to me:

I understand that that is the LibCinder look, but something similar could be very classy for Vuo.

Link for ciUI: https://forum.libcinder.org/topic/ciui-a-user-interface-block-for-cinder

Great to see this being

useful design's picture
Submitted by

Great to see this being implemented! I think this is a big feature request in and of itself — one of the biggest so far —potentially.

I'd love for community involvement, if we can get notification of the thinking and progress on this particular feature we can think it through with you. GUI elements was something I thought I would like to work on when I first heard about Vuo in pre-alpha days. I'm still not advanced in Vuo enough to have a go at this myself but have lots of thoughts about the challenges it presents.

For example, GUI elements lend themselves to fixed pixel dimensions even when the Viewer Window changes dimension. How does that whole can of worms get sliced and diced? Also what bearing does this have on the bigger discussion we had some time ago about Front Panel interfaces/VST type skinning for sub-compostions. What about GUI elements on the graph canvas itself… some nodal environments allows for sliders and switches on the canvas. Should we consider these bigger things when making what i assume are to become nodes exclusively for using in the Viewer Window allowing user interaction with the comp?

Given how much work Origami have put into this (bought half the QC team to do it by the looks) aspect of QC i think everyone should familiarise themselves with Origami's features and ways of doing things as food for thought (perceived pros and cons i guess). The controlP5 library for Processing sounds pretty interesting too.

This would have big implications for people making open source software for public science type things I hope, (once the Vuo Editor has a free version and these nodes become free to use in that anyhow although an academic licence for Vuo is pretty affordable I think). Thinking in terms of MVC separation of code, we could have the model code in a Python app (or whatever) messaging with the view/controller code in a Vuo app. Done right it's game on. Think how reusable display and GUI code would become with a full set of nodes and graphing/display sub-compositions! might even sell a few licences. unfortunately Mac only is a barrier to that crowd ATM. Compile to NaCL might solve it.

Can we get some info on how

jstrecker's picture
Submitted by

Can we get some info on how the team plans to add and do this ? What sub-parts will be implemented and which not ?

Bodysoulspirit, we've made a plan and started implementing, but I don't want to get specific on promises in case we don't get to all of it in Vuo 1.3. We're taking this whole thread of comments into consideration.

For example, GUI elements lend themselves to fixed pixel dimensions even when the Viewer Window changes dimension. How does that whole can of worms get sliced and diced?

Ew :P

@Alastair, like the existing Make Button node, the UI nodes will output layers, and will scale with the window's width. Although we won't get into advanced UI layouts/sizing for Vuo 1.3, the existing Arrange Layers in Grid and Align Layer to Window could help.

Also what bearing does this have on the bigger discussion we had some time ago about Front Panel interfaces/VST type skinning for sub-compostions.

None. Feature request?

What about GUI elements on the graph canvas itself… some nodal environments allows for sliders and switches on the canvas.

Ditto.

i think everyone should familiarise themselves with Origami's features and ways of doing things as food for thought

How do you mean? My understanding is that Origami has a Button patch but none of the other UI widgets proposed on this feature request.

once the Vuo Editor has a free version and these nodes become free to use

Just to make sure this doesn't become a rumor — Team Vuo doesn't have plans at this time to make a free version. For info on how Vuo is funded, see https://vuo.org/story .

Origami has a large set of

useful design's picture
Submitted by

Origami has a large set of basic and sophisticated touch/mouse interactions as native patches and virtual patches built on top of these Origami patches. While few of the proposed Vuo nodes are native Origami patches, the system is advanced enough to enable construction of pretty much any kind of nuanced interaction with feedback/animations during the interaction and recognition of state following that. Most things you would need for mobile app prototyping are doable if you make the effort (But i guess you could say that about Vuo already if you had all day to make a row of vertical value sliders).

In case of Vuo, feature set is more around controlling tools made with Vuo. Given that Vuo is significantly different to programming in QC, it's not inconceivable that prototyping mobile apps in Vuo could become easier than it is in Origami/QC if there were enough nodes to support it, event based coding is more applicable to app prototyping than the hoops Origami needs to jump through to do what they do and track 'state' when you think about it.

So just from memory, what Origami calls 'wheel or fortune' type interaction (horizontal sliders with 'sticky' stepping values if you like see Paged Scrolling example) is one of the options in a prebuilt macro for horizontal sliding. I'll check all the items in the proposed node list and find out if they are prebuilt or just potential to build. I can't see one in that list that would be impossible to build, though the interactions in Origami are obviously more about prototyping interaction than controlling other things. Not sure what a "Select box" type of interaction is.

This is going to make

cwilms-loyalist's picture
Submitted by

This is going to make interfacing with my VUO projects so much easier! Instead of relying on wireless Art-Net protocol and Luminair to make a less than ideal UI for my project I will be able to make a custom UI and use Duet Display to directly control it via a tethered iPad! I'm really looking forward to trying this out!

Keep doing what you're doing VUO team because it's awesome!

Some notes on how we're

jstrecker's picture
Submitted by

Some notes on how we're planning to implement this node set (to give more of an answer to Bodysoulspirit's question)...

We'll be revising and expanding on the one UI widget already in Vuo 1.2, Make Button, as we add more widgets.

Currently, you display a button by connecting Render Layers to Window : Rendered Layers -> Make Button : Rendered Layers and Make Button : Updated Layer -> Render Layers to Window : Layers. That will still be case (although we might rename the Rendered Layers port, since it will be carrying some additional information).

Currently, Make Button has a trigger port that fires an event when the button is pressed. That will still be the case. Other widgets, of course, will have trigger ports appropriate to the mode of interaction.

Currently, Make Button has input ports Font, Color, and Height. These will be replaced with a single Theme input port. There will be a separate node that inputs such aspects of appearance and outputs a Theme that can be connected to multiple UI widget nodes, giving them all a consistent appearance.

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.

Currently, Make Button only handles mouse interaction. We're looking into supporting other pointing devices, such as Leap Motion. We'd still default to mouse interaction, but provide a Make Interaction node that can input the position and status from any other pointing device if you want to override the default.

So that's an overview of our plans. I just want to reiterate that we're considering all the comments on this feature request, even if I didn't explicitly mention them.

@jstrecker great Jaymie !

Bodysoulspirit's picture
Submitted by

Jaymie great Jaymie !

Glad to hear a node to build a fully-custom theme from layers is on the roadmap !

I guess it is important that people can make it look like they need it.

Hope "border thickness" will be part of the appearance node you mention when you say "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" as it seems that was mentioned several times by people in the comments above.

Any plans for a "Finder Window Explore" node to pickup stuff and retrieve their url's like with "Get Drag values" ? Or do you already think this should be a different feature request ?

Any plans for a "Finder

jstrecker's picture
Submitted by

Any plans for a "Finder Window Explore" node to pickup stuff and retrieve their url's like with "Get Drag values" ?

Bodysoulspirit, we have plans for nodes that display a File Open dialog and a File Save dialog. They would have an event input port to show the dialog, and would output the selected file(s) when the dialog closed. Is that what you have in mind?

@Bodysoulspirit, we have

Bodysoulspirit's picture
Submitted by

Bodysoulspirit, we have plans for nodes that display a File Open dialog and a File Save dialog. They would have an event input port to show the dialog, and would output the selected file(s) when the dialog closed. Is that what you have in mind ?

Sounds great Jaymie ! Cool !

Yep ! Some Finder Explorer Popup similar to the one that comes when in the Vuo Editor you do "cmd-O" or File > Open Composition.

Hey y'all. I want to give you

jstrecker's picture
Submitted by

Hey y'all. I want to give you an update on what Team Vuo expects to include in Vuo 1.3 for this feature. Before anyone gets too excited, we are not on the verge of releasing 1.3. I just want to let you know, in the interest of transparency, which UI components we think we can fit into the next major release and which ones will have to come later.

Planning to include:

  • action button (like current Make Button but more customizable)
  • checkbox
  • slider
  • customizable appearance — including colors when inactive, hovered, or pressed; label font and placement; and corner roundedness

After the next major release, we plan to keep this feature request marked as "chosen" and implement more UI nodes. We won't be able to do everything that has been proposed in the comments on this feature request, but we will try to pick the most popular and widely useful suggestions. We'll let you know. For more advanced/niche UI functionality, you'll be able to create additional feature requests.

Ok. Thanks for the update.

Bodysoulspirit's picture
Submitted by

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)

    Jaymie "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.

Alastair (@usefuldesign)

Bodysoulspirit's picture
Submitted by

Alastair

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 ?

I'm pretty sure I found a way

useful design's picture
Submitted by

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.

Once the UI nodes feature is

cwilms-loyalist's picture
Submitted by

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.

From CSV issues : don't find

Bodysoulspirit's picture
Submitted by

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).

I too would like to see a

wmackwood's picture
Submitted by

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

Paul, William,

jmcc's picture
Submitted by

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.

I agree with bLackburst.

useful design's picture
Submitted by

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

I'll say it more simply,

useful design's picture
Submitted by

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.

Not to be an donkey, but text

MartinusMagneson's picture
Submitted by

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.

I for one don’t believe a web

cwilms-loyalist's picture
Submitted by

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.

Magneson! This is awesome!

jstrecker's picture
Submitted by

Magneson! 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).

bLackburst Well, thank you

MartinusMagneson's picture
Submitted by

bLackburst Well, thank you for the insult I guess. Mr Goldberg did some pretty nifty drawings. When that is said, I hardly think 7 nodes qualifies for a Golberg-esque typing machine, especially when it comes to text input. I do understand that there are different views on how node based systems should work, and that we probably are on different sides of the table there though.

Instead of sitting around waiting for a feature for years, I would advocate trying out what's possible with the current nodes, finding roadblocks there, and suggest improvements to the existing nodes to achieve results. This could for instance be a "text buffer" output in the "Receive Keyboard Typing" node, which would reduce the amount of required nodes to 2 for this application - and would probably be a lot less work-intensive task than making a fully themed UI textbox.

If you read my post I also provided a downloadable composition along with an explanation of what's what in it, and how to scrap useless parts and save it as a user library node. With a MIT license. This means you can store it, have one node do what you want, and claim it as your own without having to neither pay for it or acknowledge my existence in any way. No Goldberging needed on your part, only a tiny bit of effort!

Also applicable XKCD (which pretty much sums up all of Team Vuo's comments in this thread):

 Tasks

(Also, also, thank you for the kind words Jaymie! Nice to be of help!)

Thanks Martinus for the

Bodysoulspirit's picture
Submitted by

Thanks Martinus for the compositions and the reversed queue node !

I got a bit lost between the different subcombs and how to use them, but thanks to you, I was able to tweak your original composition to match my needs, use some buttons as some text fields (clicking a text field resets the field however) (see joined composition below).

One thing I wonder though reading Jaymie's comment about the work needed for an UI text input, is I wonder if under the hood some changes could not be made to Vuo to make these kind of things easier to implement.
Is it because of the push only system it's so hard to code ?
I'm no code expert at all, but UI text fiels are basically everywhere, internet, apps etc, do under the hood they all have major code ?
I was thinking about this also because you can't create lists of buttons since they need the window port, and this isn't supported within process list loops.
I wonder if it will be possible with the "Allow single ports to accept lists" feature request to create a list of buttons on the fly, with each of them be clickable and editable.

Would another workaround

Bodysoulspirit's picture
Submitted by

Would another workaround until implementation of the text UI field also be using some applescript to prompt a text field and retrieve it into Vuo ?

Joined is some composition with some code I grabbed from internet to test.
Works for me, but not sure how that would work for distribution on recent macOS versions due to security restrictions ?

PS : for now the code retrieves an error when canceled.
PS2 : It's also possible to use Applescript to retrieve files and folder paths, for example to load an image, but you have to modify the Execute Shell Command node to allow the access for the user folder, by default it's forbidden for security reasons.

@bLackbrust and Chris when a

useful design's picture
Submitted by

bLackburst and Chris when a websocket plugin was made available for QC i had an low-latency interface with a self hosted (same Mac) GUI that was used to drive giant video screens in front of audiences of 100,000+ people. I built the GUI i wanted with drop down lists etc and push button preview and live states in a few hours. If you want to be dismissive of such solutions, bLackburst then i think that's more on you than anything else. I'm only suggesting that this is a low-effort implementation for Team Vuo, given that they seem to be running into significant hurdles on the UI element nodes.

Chris I can understand why you want stock VUO tools to do it. It's a shame it's so hard to make them using Vuo itself (I haven't ever tried but I'd have thought someone would have by now b/c they are so essential for production tools if you aren't using VDMX or similar). Many people made such things for QC over the journey. I made an advanced GUI inside QC using JS and it had 30 or so buttons and several modes of operation, flashing LED animations when moving between modes and two digital readouts for numbers (it wasn't any improvement on latency than Websocket though).

There's a VUO node for loading an HTML page that could be embedded in your app. VUO may even get an HTML server node one day since Kineme built one for QC, in which case it could be all bundled inside the app.

So far I've been able to do a

cwilms-loyalist's picture
Submitted by

Alastair, so far I've been able to do a lot with the existing buttons and slider nodes, I've never used VDMX or anything else with VUO. Admittedly I'm really looking forward to a native textfield node (Magneson thanks for MM.ListTools, and the great example of how to use it). I would also love to see a dropdown menu node from a list become a thing as well.

As far as the difficulty in building GUI using the existing button nodes I haven't had any real issues and have had great working GUIs that scale well in a few hours. I built the GUI for this project in about 4-5hrs it has 36 buttons; 42 now, and 4 shortcut keys to switch project modes so the same buttons call up different graphics. The backend took much longer but the GUI was pretty easy. I think it's all in the planning, having a good idea of what you want before you start. I use to design webpages early in my career and still work with HTML from time-to-time, so I find the idea of using websockets interesting but I don't want to see it as the only implementation of the GUI features being considered; and that latency concern I have for the live video and graphics previews and program is a big one for me.

One thing I wonder though

jstrecker's picture
Submitted by

One thing I wonder though reading Jaymie's comment about the work needed for an UI text input, is I wonder if under the hood some changes could not be made to Vuo to make these kind of things easier to implement.
Is it because of the push only system it's so hard to code ?
I'm no code expert at all, but UI text fiels are basically everywhere, internet, apps etc, do under the hood they all have major code ?

If you're building, say, an iPhone app or a webpage, it's easy to pop in a textfield because the app or webpage is built on top of a platform that provides the widget. For iPhone, there's a UITextField class within the UIKit framework that you just pop into your code. For webpages, the HTML standard defines an <input type="text"> element that all browsers implement.

For Vuo, we have to build the underlying platform that provides a textfield widget that's cross-platform-compatible and has a customizable appearance. Luckily, we don't have to start from scratch. We're building on top of the open-source stb_textfield. Even so, there's a ton of tweaking needed for the appearance and behavior. Textfields have a lot of little behaviors that most people don't really think about but would miss if they weren't there, or if they behaved differently from typical macOS textfields (cursor, highlight, copy-paste, etc.).

Our next step on the textfield node will be to reassess where we left off and come up with a minimum set of changes, with the goal of not letting the perfect get in the way of the good. Then we can release a textfield node that is hopefully decent, and over time tweak the behaviors that the community considers most important based on bug reports.

Hi Jaymie

useful design's picture
Submitted by

Hi Jaymie

100% about lots of little behaviours. Even two browsers on macOS implement text fields differently. Eg Safari has macOS text substitution (something I miss a lot making comments on science related websites when I’m in Firefox), macOS system spelling correction engine and user dictionary, word/phrase meaning dictionary “lookup” (helpfully always top item in the contextual menu when you right-click), user programable “Services” and more. While Firefox implements it’s own spell-checker, it’s own user dictionary, and none of those other things I mentioned.

I’m wondering, given that Vuo already uses the ‘Qt’ cross platform UI framework, wouldn’t it be useful in this context? It’s made for this kind of situation and extremely versatile and powerful from what I can tell.

Or would there be too many licensing issues? It’s used in all manner of platforms including embedded systems even, so if the popular FR for Vuo on Rassberry Pi ever wins selection to implement then Qt will go the distance, no problems I’d have thought.

Qt do have a free community licence for non-commercial app builds which might apply to people making app for self use. And if selling their apps then the pro version of Vuo could implement the royalties/licensing fees perhaps?

ps I just spent five minutes trying to find the Vuo code base dependencies/licence. I know there’s a page on this site somewhere where they are all listed but I couldn’t find it even doing google searches of the Vuo.org site and naming various dependencies I thought I could remember the names of. I ended up on GitHub and confirmed you are using Qt already in seconds on GitHub.

Can I ask that the 3rd party framework/licence listing page be moved into the FAQ because this is not the first time I haven’t been able to find it on this site?

In Vuo 2.2.0, we added Make

jstrecker's picture
Submitted by
Feature status:
Chosen to be implemented
»
Released

In Vuo 2.2.0, we added Make Text Field, Make Number Field, Make Text Field Theme (Rounded), Display "Open" Window, and Display "Save" Window.

Known limitations of Make Text Field and Make Number Field:

  • right-to-left languages (such as Arabic) aren't currently supported
  • 4-byte glyphs (e.g., 💯) aren't currently supported; they show up as a question mark in a box
  • keyboard shortcut to show the character picker (control-command-space) isn't currently supported
  • System Preferences > Keyboard > Dictation isn't currently supported
  • System Preferences > Accessibility > VoiceOver isn't currently supported
  • tabbing from one field to the next isn't currently supported
  • context menu isn't currently supported (though the shortcut keys for common operations (cut/copy/paste/undo/redo) work)
  • cursor doesn't flash
  • spell/grammar-checking isn't currently supported
  • phrase-substitutions, smart quotes, and auto-capitalization (System Preferences > Keyboard > Text) aren't currently supported
  • should scroll when the text width exceeds the widget width, rather than expanding the widget
  • double-click-drag should select by word, but currently it selects by character

We're going to call this feature request "released". Lesson learned: it's easier to track feature requests that are smaller and more focused :) If there's another UI widget you'd like to see, or limitation of a UI node that you'd like us to prioritize, please create a separate feature request.

Feature status

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for. Vote your favorite features to the top! (How do Vuo feature requests work?)

  • Submitted to vuo.org
  • Reviewed by Team Vuo
  • Community voted
  • Scheduled for implementation
  • Released in Vuo 2.2.0

Who voted?

pbourke's picture
Mika-TS's picture
Alejo's picture
lrock's picture
macsrv's picture
krezrock's picture
alexmitchellmus's picture
wmackwood's picture
jersmi's picture
MartinusMagneson's picture
kyrrelys's picture