Yes, I know, this has been discussed a couple of times and we’ve gotten used to this UI flaw …
But can we finally have this fixed as a vvvv maintenance effort or do you not plan on spending any more time on vvvv?
not sure, but maybe this is related to what you are referring to: Pins in subatches cant be hidden
Or are you referring to stuff like how you can Ctrl-click to select several nodes, but only if that doesn’t include an IOBox, at which point you loose your entire selection? But you can Click-drag to select and even edit several IOBoxes at once, but you will almost always select other stuff as well and then it doesn’t work any longer to edit multiple IOBoxes at once. So you always end up doing this weird thing where all the IOBoxes go on top in a row, so I can select all of them more easily. Really annoying and just a bug… since, well, forever…
Also why don’t we have zooming again? I don’t need the scroll wheel to move up and down the patch and nobody else does either, as you can just right-click-drag like a normal person :D
/endrant
No, I’d say @readme refers to the black band with the Descriptive Name
and\or IOBox objects or IOBox content that disappear until you scroll all the way in a direction and back, forcing UI to refresh.
edit: h99 was faster and exactly right.
Ah no, your proposals I consider an actual feature request / usability improvement …
I’m talking of labels of (labeled …) IOBoxes that disappear while patching, sometimes entirely, sometimes just some parts of it … sometimes you can’t read a node’s name (text missing iirc), …in short: thing look odd and you have to hide/unhide the window or resize the window a little to force the UI to redraw.
There’s even been a workaround by @velcrome that would do exactly that semi-automatically by assigning it to a hotkey.
You know, one has kind of learned to get around these things, but actually one shouldn’t.
It’s a little embarassing when showing vvvv in a lecture or to someone not familiar with it and you have to explain all those little buggers like “yeah well, it does that - no, it will probably stay like this”.
absolutely, it doesn’t make a good impression when teaching vvvv , when students see this behaviour in the first lesson. combined with 10 minutes startup time due to windows defender (not vvvv fault of course) and fuckups due to error-prone installation of addonpack and dx11.
please give the UI a bit of love, it would be very much appreciated !
1 pixel resize every 10 seconds? :) every solution would be a hack like this… or a complete UI invalidation from time to time… might be possible somehow. i’ll make an issue.
@tonfilm , a periodic update sounds like a potential performance hog since the vvvv gui is known to have an impact on the mainloop.
what is goin wrong with the painting in the first place ? it is not happening without user interaction, therefore there should be a way to catch and redraw when this happens.
note to myself, investigate when this is happening
F5?
Funny, I was just doing an installation and this happened again, and I said to myself “OK, this has been going on for at least five years, I’m going to finally make a forum post about it” and when I get home here it is. Great minds etc.
So why is this happening? What it is that is unique about vvvv that causes this while no other windows program does this? Is it something in Delphi that vvvv cannot directly deal with?
It is a CONSTANT annoyance, and of course happens when you can least afford it, and seems to increase in likelihood the greater the importance of the person watching or trying to use the patch…
This is definitely part of the ancient Delphi core. When I do guess inside the black box, I think there is a part of the node drawing lib, that has partiallly async code gone amok.
It was much better, some versions ago, but it never fully went away. The more you scroll in (big) patches, the more often the glitch occurs. It’s been part of vvvv patching for so long, I guess many hardcore users are like me and don’t even feel the chronic pain anymore. A gallery screenshot every once in a while is the most we do. Mostly for lulz though.
You know, scroll once, glitch, scroll twice, glitch again, but eventually you take the workaround of Ctrl+G and refactor until you don’t need to scroll anymore to see the entire patch.
That said, this is not a friendly thing to happen to new users, or paying customers. But I fear, noone will actually start to fix the Delphi lib, sorry to break it to you.
PS: Good thing vl gui has no dependency like that, All async problems ever are home grown there
I tend to hardly scroll in my patches and pack everything pretty dense I guess … I either experience this without scrolling at all or do seem to still scroll the window a little unconsciously.
“Whole Lotta Scroll”
You need nestin’, baby, I’m not foolin’,
I’m gonna send you back to groupin’,
Way down inside, honey, you need it,
I’m gonna give you my node,
I’m gonna give you my module.
Wanna whole lotta scroll [4x]
You’ve been groupin’, baby, I’ve been freezin’,
All them good times, baby, baby, I’ve been ghostin’,
Way, way down inside, honey, you need it,
I’m gonna give you my node
I’m gonna give you my module.
Wanna whole lotta scroll [4x]
You’ve been savin’, baby, I’ve been reloadin’,
All the good times baby I’ve been codin’,
Way, way down inside, I’m gonna give you my scroll,
I’m gonna give you every stride of my scroll,
Gonna give you my scroll.
Yeah! All right! Let’s go!
Wanna whole lotta scroll [4x]
Way down inside… patch… you need… scrooooooll.
Shake for me, patch.
I wanna be your backdoor man.
Keep it nestin’, baby. [4x]
i laughed out loud
indeed the problem with this is that in countless hours of debugging this over the years i’ve not found anything that causes this or any idea how to prevent it. yes, we could have prioritized this higher and replaced the ui at some point, which we decided against and rather focused on the new thing. at least what i could have definitely done earlier is offer a shortcut to press that redraws the IOBoxes whenever this happened. only now that this was brought up again it occured to me to actually do that. weird. so hereby i humbly give to you: F5 (in latest alphas).
while at it, i found some comment in the code that mentioned an observation that the problem often (but not only) seemed to happen when switching away from vvvv to another program. there was even already code in place that did a redraw whenever vvvv lost focus but apparently that didn’t help much as it was probably in the wrong place. so now what i did in addition to the shortcut, i’m running that same IOBox redraw whenever a patch is activated or vvvv looses focus. i sat here switching to and from vvvv for about an hour after that change and didn’t see the problem again (while i still saw it randomly after some time before this “fix” was applied).
so while this still obviously is not a solution, i hope that it at least eases some of the annoyance. and i kneel here before you, hoping you’ll accept this (too) late attempt by offering my sincere apology:
wholelottascroll.zip (2.5 MB)
hahaha probably the most terrible interpretation of that song i ever heard… sorry guys ;)))
but sooooo cute… lovvvve
lol. what other programming language overlord records songs for his underlings?
Guys! @joreg’s singing!
P.S. Take one… yeah… we all gonna believe that…
Very refreshing
so good, the zip, so good :D
Could it not do a refresh when you stop scrolling, and have an option to disable that hack if it is a performance hog?