@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 @jstrecker! Nice to be of help!)
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 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.
@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.
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 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.
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 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.
Great that the Make Text Field node 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.
@jstrecker, 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 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.
Does Qt to some extent get all the little tiny things sorted without heaps of custom coding?
We’ve looked into that, but unfortunately Qt doesn’t solve the problem for several reasons:
Qt doesn’t support rendering widgets within Vuo’s Layer system (3D graphics rendering, currently implemented with OpenGL, soon to be replaced with Metal).
Qt doesn’t support the amount of customization of widget appearance that community members indicated they wanted.
Including the Qt framework would significantly increase the size of the Vuo framework, affecting the size of exported apps and plugins as well as other applications that integrate Vuo (VDMX and CoGe).
Several years ago, when we tried to use Qt for composition windows, we ran into some pretty hairy macOS-specific issues. We ended up switching to the macOS Cocoa frameworks.
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.
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. :)
@cwilms-loyalist, @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.
@jmcc 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.
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.
) aren’t currently supported; they show up as a question mark in a box
Grid (2D) of Checkboxes
