an incomplete list of aspects on vvvv usability that are concerning me since a while
Most important - this is in my eyes even more a bug than a feature in the current version:
opening and closing of patchwindows causing them to be marked ‚dirty‘ is bad.
we usually work in projects with large hierarchichal patch structrues. When you need to make a change to one specific scene or part of the project this usually means, that you have to navigate through the whole hierarchy until you are the patch you need to edit. The opening and closing alone causes all parent patches to be marked ‚dirty‘. Especially the main patch(es) of the project are permanently dirty, even though there are no relevant changes made. This makes working in teams very hard, because the save dialog is virtually rendered useless, because you have to keep track of all changes yourself in order to avoid commit conflicts.
So I would strongly ask for something like a ‚session view‘, where the box/windowstate and position changes are ignored in patches - unless you save them using a special shortcut or menu item.This would make it convenient set a default opening state for a project, and allow just to change the lowest patch. Even node positions could be ignored.
Feature Requests:
using tab to navigate through the pins of a node. e.g when you have a translate node, you need to click each pin manually to enter x y z values. It would be convenient to just edit-select the next pin using the Tab key.
mark pins that hold user data: pins that are not on default value, i.e. that have been changed (and have an entry in the XML). With nodes with large pinsets it can be very tedious to find out for which pin value they are actually in the patch graph. E.g. Transform 3D. It could just be a differentiation in grey / black values
like in VL: doubleclicking a link brings up the node browser, filtered with the nodes fitting the in- and ouptut types and if a new node is created, it is linked with the first pins.
that whole marked-as-dirty thing: +1 … +2672234. already did some research if it was possible using gitignore/gitfilters … but solving this issue on the vvvv side sounds more reasonable and clean.
@feature requests
ad 1) hmmm yes, but never really felt the urge to cycle through these, I tend to create IO anyway for constant inputs
ad 2) see 1, but could be handy for debugging other patches and workshop-environments. Seems like the most useful feature/ui improvement
ad 3) sounds handy, but saves some clicks only … but in general, yes.
After tidying up a messy patch, which mostly means node positioning, I’d say it’s a relevant change. Ideally there would be two states, one that indicates a mere layout change and another one that shows a “functional” change.
But why do you want to have a layout.changed state, if you don’t want to be prompted if you want to save it? Which is the whole point about this improvement.
I mean you know you made a layout change …
Yes - but it even changes the layout when you pan the window or open a subpatch. So just like now, every patch is constantly dirty. How do you find a significant change? Make a diff counter?
While I get the point of not dirtying a patch with scrolling, moving windows, going fullscreen with the shortcut or minimizing any window (it is a nuisance!) I don’t agree with not flagging dirty, when a node gets repositioned.
Having had the team issue with git for a couple years now, I grew quite good at quickly deciding, if a relevant change has happened to a saved file (from the diff alone), and reverting without a second thought in case it’s not relevant (aka only window layout). While that is certainly not the best solution, it helped to use Save-All again.
But besides that, I’d like to propose Alt+Strg+S to hard-save a patch and its children. Could even be automatically complemented with a clean-up link.
i’m still in for having layout and functionality separated.
while it’s possible to scroll through a diff and check if any dirty line is just a bounds change, usually everyone is too lazy to do that after some heavy lifting in a big project.
and to address the argument of patches not being contained and thus ‘mobile’ anymore. who has only one patch for a project anyways?
Would not 2 kinds of save be the way to do it, 1 save all, node positions included as we have now, and another just save functionality, I guess with a catch for nodes that have no position currently saved?
Also regarding the finder screenshot, finder is dog slow in big patches, with no way to type 73/192/23/1/23 to drill to the patch showing an error in the TTY for example, which would make debugging much easier. I only use finder when looking for s and r nodes because of that tbh!
Well … When saving functionality, you’d want to save all layouting in the affected patches (functionality-dirty) as well. I’d argue the former doesn’t go without the latter. Only the other way around, saving layout without affecting functionality. That said, and giving it another thought, I think it’s not a matter of what’s to be saved. Saving = Save both, otherwise you’d have to check for layout changes to nodes that haven’t been there before as well, hence functionality would also be included anyway.
It should ultimately only be a matter of two differing dirty flags - you may just select which patches to include upon Saving. But it shouldn’t let you choose which parts to save, that may end in some erratic behaviours.
Maybe it helps to clarify the term “layout” a bit, because there seems to be a confusion of two concepts here.
One refers to the layout of interconnected nodes within a patch, and one refers to the layout of patch windows on one or more monitors. Both are intermingled in vvvv because of v4p, quite unlike many other popular coding softwares.
As I understood the original post, it is mainly the second one that causes unwanted havoc within git, when working on a project in teams. This is bad because everybody has the right to organize her workspace as she wants (and in case of vvvv, the workspace is basically just moving, opening, hiding and resizing windows).
About the first “layout”, regarding node positioning: I would argue, that even node and link layout is inherently CODE in a patch based language, which directly reflects readability (so e.g. oversizing a Group node is the pendant of adding some blank lines around an important c# call).
Any change to CODE should require a save-decision (aka “Flag Dirty”).
