VVVV b24 Interface - Bugs and Wishlist



Since recently word of a beta25 is floating around and the devvvvs seem to be even harder at work, I thought I’d share some bugs and ideas I had regarding VVVVs interface in the hope that some of these might not come as a distraction from more important improvements but as pointers to little itches that could be scratched along the way :)

But first things first, I really like the recent changes introduced in 24(.1), like middle-click I/OBox generation, red nodes, IPluginInterfaceV2, Vector-I/OBoxes in Quicknodes, etc… lovely stuff, and I haven’t felt the need to switch back to beta23 :)

Now the bugs and wishes. These are all just related to the interface of VVVV. And most are small things. Here goes:

Interface Bugs:
I/OBox having been set to ColsRowsPages once and then (back) to Input will not again display empty space when having less than ColsRows slices.
*When you start resizing an I/OBox (String) in comment mode (i.e. light background) by dragging the bottom edge its height will be automatically decreased by one or two pixels as soon as you move the mouse. Only slightly annoying, but it is.
*Creating an I/OBox with middle click when far to the left so that the created I/OBox will be partly in negative coordinates causes the connection not to be established.
*Moving I/OBoxes past the left or upper limit is generally weird, with the display area of the node being separated from the node bounds.
*While patching I/OBoxes will often lose their render area and just show “I/O”. This happens frequently (several times in a minute) since my switch to beta24 and Win7 (don’t know who’s the culprit exactly). This is reproduceable by starting a link creation (from any node) and circling closely around an I/OBox for a while without ever hovering it.

*Code completion needs to be less invasive - much less.
*Bracket pairing in CodeEditor doesn’t like comments in between, also //-comments in the same line as an if will not be grayed out. Actual parsing is not affected.
*It would be nice if the CodeEditor remembered its window size. The standard is higher than my monitor (800px minus taskbar) and I have to resize every time by dragging to a screen edge (good that win7 has this feature).
*When the view is scrolled to the right then the up-and-down movement of the cursor get’s whacky (on pressing up/down the cursor is displaced to the right by roughly the distance the view has from the left border)

Interface wishlist:
*When writing in a multirowed/-columned IO-Box pressing TAB goes to next slice in write mode.
::{img src = “tab iobox.png”}::
*Connection line control points are rendered on top of I/OBoxes. I move quite a lot of I/OBoxes around when refining connection layout.
*Dragging VHV lines anywhere on the horizontal part to move the line up & down
*When only a single node is selected Ctrl+L/Align moves the node horizontally so the node’s first output pin will be directly above its destination pin (because I just go OCD when it comes to patch layout)
::{img src = “singlealign.png”}::


was the same behaviour before. and to be honest: i like that behaviour.

good idea!


Oh, you do? Why exactly? Actually it’s probably my least concern in vvvv, but maybe there are benefits I haven’t seen :)



lets see what we got here:
@Interface Bugs:

thats kinda by designa. as when switching back the value-ioboxes X input keeps its slicecount. works fine though for ioboxes of other types.

thanks for caring. pixelwise. fixed.

stupid me. fixed.

annoying since 2002. fixed in 2010.

known problem. hovering a decapitated IO box with the mouse should bring all ioboxes back. will take some time still to have the guilty code replaced.
the following fall in the same category:


Coolio - thanks a bunch!


While browsing nodes, the “helpful” info tab gets in the way of nodes below the one you are currently hovering over. Could the helpful box be moved below the list, or only appear after a certain amount of time?


for a middle mouse also noticed
** that when you make i/o box for output you can’t set it to vector
** after midle click you automaticly have selection on i/o and node, so if you need to move it around you move you node too, witch annoy bit


Or to the left side of the list? (Switching to right-side if NodeBrowser is too far left)

-> That annoys me too. But see change-log 10th point :)


aight. fixed.

mm…still there but note how the tooltip is gone if you scroll with the mousewheel (or beta>24.1: if you hover leftmost with the mouse)

not perfect yet but quite improved for editing hlsl

hm…cannot confirm?!

mkay, default set to 700 now. confirmed: remembering of windowsize is a bit off for now…


Neither can I ^^;
I don’t know what it was exactly.
There are weird things happening with comment highlighting sometimes, but I still have to find a method to consistently reproduce that.

Might be a working compromise between tooltip placement consistency and not obstructing the view too much, we’ll see how it feels in beta25

(Since this discussion is ongoing I removed the solution flag for now)


This is likely to be a known issue but just wanted to ask:
When I change a value in an i/o-box the renderer always get’s a little hick-up. Can this be fixed?


good question.


very small thing:

when an iobox is created from a pin of a node by using the middle mouse button, both the iobox and the node are selected. almost always I immediately deselect both, just to select the iobox, so I think it’d be nice just to select the new iobox.


this has been asked a few posts up already, and has been fixed already for the next version -> see change-log 10th point :)


nice :)… no text …