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)
- 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)
Hi, @bLackburst. Sorry I
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
Some of the features I would like to see for Buttons are:
I was really glad that buttons have been enabled and I'm looking forward to what can be done with them.
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 :
2 - Other UI Stuff :
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.
Can we also have a GUI or UI
Can we also have a GUI or UI class set for the API? Would be interesting to allow people to re-use or remix the building blocks for easy GUI generation from within custom nodes. If this already exists please point me in the correct direction! :-)
[alexmitchellmus] Can we also have
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.
Great plan Steve. Should
Great plan Steve. Should make it easy to build interfaces even inside custom nodes. (For high level logic etc)
Can they be skinable as well? (Custom gif etc). People can make the interface look like whatever they want?
I am starting to really like
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
Chosen to be implemented.
Chosen to be implemented.
Great to see this has be
Great to see this has be chosen to be implemented !
Can we get some info on how the team plans to add and do this ? What sub-parts will be implemented and which not ?
Great to see this being
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
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.
@Alastair, like the existing
Make Buttonnode, 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 Gridand
Align Layer to Windowcould help.
None. Feature request?
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.
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
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
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
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 Layersand
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).
Make Buttonhas 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.
Make Buttonhas 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.
Make Buttononly 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 Interactionnode 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 !
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
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
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.
Finder Explorer Popup.png
Hey y'all. I want to give you
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:
Make Buttonbut more customizable)
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.
Glad to see Fonts make the
Glad to see Fonts make the cut, hopefully for all UI element types Fontface is user assignable.
Ok. Thanks for the update.
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
⚪️ 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)
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.
✅ Custom font faces for text
✅ Custom font faces for text elements of all buttons
⚪️ Can embed fonts for use in Exported Apps and Plugins
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
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
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.
You can use the
Fetch Datanodes, optionally in conjunction with the
Treenodes, to retain the state of the UI nodes.
From CSV issues : don't find
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 ButtonI 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 Listof 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 Browserfor 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
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 Buttonhad an Input port, that it could be iterated with Lists on Ports, and that it could be fed a
Select Latestwith 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 Listwould 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 Buttonto 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).
Capture d’écran 2020-03-13 à 23.49.05.png
Make Button With Value.zip
Is there any timeline for
Is there any timeline for when we might see a text input UI node? Quickly installed 2.0.1 ... nope. Urgently need this one. :-)
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.
For my current use case I
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.
I too would like to see a
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.
Perhaps you could use
Display Console Windowas 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.
Jean Marie The user interface
Jean Marie 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?
I agree with bLackburst.
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
Lost me, but it feels the
Lost me, but it feels the spirit was there somewhere.
I'll say it more simply,
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
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.
If you guys want to spend
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.
I for one don’t believe a web
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!
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
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):
(Also, also, thank you for the kind words Jaymie! Nice to be of help!)
Thanks Martinus for the
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
windowport, 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.
UI Text Fields.zip
Would another workaround
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 Commandnode to allow the access for the user folder, by default it's forbidden for security reasons.
Capture d’écran 2020-08-16 à 17.17.23.png
Capture d’écran 2020-08-16 à 17.17.19.png
@bLackbrust and Chris when a
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
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
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.
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
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 Fieldand
Make Number Field:
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.
Great that the Make Text
Great that the
Make Text Fieldnode supports cut/copy/paste, many levels of undo/redo and double click and triple click!
Unfortunately double click only works sometimes when I use my tablet stylus and triple click only works never. I suspect its the tolerance for mouse coordinate delta between clicks is a bit tighter than what is standard on the macOS frameworks because I never have this problem with my tablet double- and triple-clicking on sentences in text applications (InDesign, Text Edit, Atom, Sublime, BBEdit etc etc). No big deal if I remember to use trackpad instead.
For the poor spellers of the world… spelling correction would be an awesome add.
Jaymie, now that I realise
Jaymie, now that I realise macOS apps exported from Vuo don't natively support published inputs the way image filters and image generators do because the host app deals with all of that, I'm wondering if Qt (community licensing permitting) might be the way to implement more GUI features with a consistent underlying code base that makes expansion of features more easy in the future?
Does Qt to some extent get all the little tiny things sorted without heaps of custom coding?
The text vertical positioning
The text vertical positioning in the Make Text Field node needs a tiny bit of tweaking to my eye. I'm probably a bit OCD on type and glyphs but it stands out to me as being uncomfortable for the type.
The Baseline needs to drop such that the median (a horizontal line which passes through the centre point between the ascender height and the baseline) is about level with the centre of the text box, or a tiny bit lower even. Artworks on paper are often framed with more "whitespace" above the image than below, because it's more "pleasing to the eye" in classical terms. Here we have the opposite, much more whitespace under the text than above it.
Should I make this a FR?
Screen Shot 2021-10-01 at 12.20.12 am.png
Screen Shot 2021-10-01 at 12.41.54 am.png
Does Qt to some extent get
We've looked into that, but unfortunately Qt doesn't solve the problem for several reasons:
So that's why we don't use Qt within compositions, though we still use it in the Vuo editor.
Yes, please create feature requests or bug reports for anything further with the UI nodes.
thanks for detailing the
thanks for detailing the issues with Qt, Jaymie
it’s a shame there’s nothing 3rd party which is cross-platform and extremely useful for UI in Vuo straight out of the box.
The recent discussion about
I would really love to see
I would really love to see the Drop-down menu UI node come into existence! I keep running into situations where it would be so useful to have.
Just a thought, since some of these UI nodes were released in Vuo 2.2 you can no longer vote on the remaining ones. I'm wondering if the above discussion should be sorted through and broken up into individual or grouped votable Feature Requests again. Thoughts?
I don't see any of them mentioned in the proposed Plan for next releases discussion but I'm secretly hoping 1-2 more UI modes could be slipped in with each of these releases. :)
Chris, Bodysoulspirit, and
Chris, Bodysoulspirit, and other community members, we'd like to have individual feature requests for specific UI elements so the community can help us prioritize them. Bodysoulspirit's list might be a good start:
⚪️ Grid (2D) of Checkboxes
⚪️ Radio buttons
⚪️ Group of radio buttons
⚪️ Momentary buttons (sticky vs momentary)
⚪️ Group of momentary buttons (menu)
⚪️ Select box (same as Finder window?)
We've also seen discussion about knobs/rotary sliders. I left out Dropdown menus from the list, since PBourke has created a separate Popup Menu UI node feature request.
I also think a colour picker
Jean Marie I also think a colour picker UI node would be really helpful to have as well. It could output either RGB or HSL values. The output could be either in a list or as individual value outputs.
Color Picker A.jpg
Color Picker B.jpg
Chris, community members,
Chris, community members,
Sure. When you get a chance, please create individual feature requests for whatever UI nodes you believe are needed. We'll do our review and open them for voting.