after a long break in using vvvv, i recently returned to it. despite the inital “awww, such a nice and straight forward way of coding” experience ( it is an awesome tool!!), i again struggled with some usability flaws that make life difficult for newbies and/or people that come from a different platform.
probably you guys are so used to it you might not even notice these obstacles are there, so i hope you find my experience helpful. maybe it contributes a little bit to an even better future vvvv.
** closing / hiding vs. learned user behaviour
ctrl+w closes a subpatch, but deletes its node as well. that is quite confusing and error-prone in regards to learned user behaviour. moreover code-windows behave even differently - ctrl+w closes the window, but the node stays! (actually this is the behaviour you would expect, coming from any other editors/ide/software).
renderer-windows close and are deleted when pressing ctrl+w - even if the renderer-node is in a subpatch! so you might not even notice you just ruined your sub-patch…
if you than start using alt+3 to close all sorts of vvvv windows, you end up with new troubles - with help patches: they close, but i.e. their renderer windows stay open! if you close these later on using ctrl+w you delete them from then help patch that is not even visible. can be quite a source of frustration …
long story short, why not have ctrl+w close the current window only? (be it the renderer, code window, subpatch, helppatch.) not have it delete any node from any hosting patch.
** closing dialog
longer path names sometimes cut off. a small suggestion to circumvent this, please see the attached image.
** new renderer windows sometimes pop up in existing windows
(getting sligthly strange looking tabs.) but how to control in what window the renderer opens its output?
further these tabs names only add the renderers description. but if the renderer sits inside a subpatch - i.e. using the Preview node! - you end up with a number of tabs all called “dx renderer”. I wonder how that could be improved.
You would still need a close shortcut to actually close a sub patch then, otherwise when you opened a help file for example, it would remain in memory (and in the root patch)
I think that the ctl+w to close a shader editor is wrong, it should delete the node to be consistent and ctl+3 should close the editor but keep the node
Long path names +1!
And I have petitioned to stop docking of renderer windows, as I dislike it! I can kind of see a reason for it occasionally, but mostly find it annoying!
Just so you know, a window is docked when it is in the same location and size as another window, if you have multiple copies of a subpatch with a renderer in, they are all in the same location, as they copies of the same patch, so they’re docked and annoyingly have the same descriptive name too! Here I think, that if you have named a renderer, the descriptive name should be displayed instead of dx renderer, and maybe there could be an index number after it for further copies?
Okay, right. That’s the reason why you can still close->delete (->fuck up) patches that are “invisible”.
In that case a solution could be: have ctrl+w close the current window only - except its node is on the root patch and root is not visible, only then delete the node as well.
@catweasel: i had a few comments/questions about DistortedFromOpticalFlow - but that request form didn’t do what i had hoped for. how can i catch up with you? (if its okay to annoy you about it.)
good idea with the closing dialog. check latest alpha.
ctrl+w is windows standard for closing the currently active document/tab (this is consistent among word, many other texteditors and browsers). as when closing a tab in a browser that you don’t longer want to waste cpu-cycles you ctrl+w a patch-document and its according node instance.
it is true though that vvvv codeeditors behave differently (since the introduction of the new codeeditor around b24 iirc). thats not cool, but consider this: the codeeditor is not specific to any of the instances of the code it represents. so when closing it vvvv wouldn’t know which instance to remove. this is different with patches that always belong to a specific instance…we’re working on this…
the alternative to docking renderers would be having them non-docking and you would only always see the topmost. i’m frustrated myself everytime using the preview module but i don’t see a solution for that. for now.
@joreg: Like ctrl+tab, would a keyboard shortcut to toggle/switch renderers to topmost help? For example ctrl + tab and alt+ tab switch within application or the application itself, likewise 2 different shortcut to switch the renderers within the active patch or all of the patches makes sense?
Also auto completion in the shader editor… nightmare.
Interface colors ? why can’t we change it to have something darker and by the way protect our eyes while spending hours in front of vvvv (please dev have a look at Blender, AfterEffect, Illustrator, Autocad etc…).
Shortcuts… we could have a menu to change them the way we want perhaps ? for me one really important thing is to keep my patch clean and organised, in order for other people to read it, or just for me, to keep it easy to work on later. There is nothing to help us doing that… ah yes well… CTRL+L… XD, super handy shortcut.
Balance between using the mouse and the keyboard also… quite hard to understand the logic here.
But hey, we talk about all that for some years already no ? ;)
yes I know, different background is useless if you can’t change other part. Imagine a darker background, then what happened to everything else ? default color for the background is actually the brighter color… the color chart doesn’t work with any other color background.
yes, that would be good. Just inverted, doesn’t really work but you feel the difference I guess, that why it would be cool to have something to change color of : pin, connection line, node, background, text, etc… and save it in a file. Same for the shortcut and control in vvvv interface.
And a snap ? because when we will be able to use the zoom in zoom out we saw at NODE13, how can we connect anything while every node are like twice smaller after a zoom out ? try to reach a pin or even read the node name ;)
Nodes are now all graphically equal, but not at all in term of functionality, the interface doesn’t give any obvious information about that, while this is the case in a code editor and some other software (TouchDesigner, Quartz, AutoCAD, Blender3D node editor).
Ah yes, I remember you highlighted what already exist in a code editor. Which in my opinion, is still missing in vvvv, sadely.
A pity because node base programming is like making “concept map”, module and subpatch can somehow carry an idea, and are part of a structure in the program.
With colors, as you were talking about in the old thread you mensioned, we could create graphic chart for our program, sometimes specific to companies, or just specific to a project. This could help a lot to read, let say, after a zoom out, how the whole structure of the program is designed, and then, at a smaller scale, understand in details what each part is doing.
It is now technically the case, but graphically, it’s really hard to do it.
for the shader editor part though i’d rather lobby for the ability to use external editors on-the-fly. like how it’s done in processing. it would be cool to use sublime text for shader and c# coding
+1 for inverted colours and colours in general. It would be nice to be able to have themes like you get for sublime, espresso, etc. to have almost like code higlighting. Different colours for nodes from different groups (the way they are organised in the node list, when rightclicking. Or even different colour connections depending on what type they are (value, string, raw, etc.).
I really love the (visual) simplicity of vvvv, but a little bit of colour could go a long way to making it more easily understandable, when dealing with large patches. Its obviously possible already as debug mode colours individual elements.
The Ctrl+W thing has confused me a few times, but i’ve finally understood when to use which shortcut, so its not so much an issue for me. I think its ok for every software, especially one that needs to be as universal and multi-functional as vvvv to have its own little quirks.
i really love the color-simplicity of vvvv and don’t want it to be a color-splash like in some other patching environments.
But, i don’t see any evil in a node (überkalle) that accepts a bunch of enums and corresponding colors.
such a node could have a peaceful living in the ROOT and would be, of course, pre-filled by the devvvvs to ensure an initial and unique color-theme.
it could be a similar concept as it’s used for NodeList (vvvv).
