Forum

StayOnTop

vvvv beta general
#1

as a reminder:

since introduction of the CTRL-T feature i notice (a little more than occasional) inconsistent, unpredictable, unreproducable behaviour of vvvv windows that wanna persist on top.

mostly you have to ‘CTRL-T’ another patch twice to finish this. since at least 7 betas i’m conditioned to do this and do it by habit.
today i stumbled upon this again.
this is one of those really little annoying things.
(…like the UIrefresh of ioboxes)

i’m not the only one having this issue, or am i?!?!?

#2

I noticed the same behavior :(

#3

me too… no text …

#4

forgot to mention this:

this issue definitely came up with the introduction of the “StayOnTop”-feature.

does anybody need this feature!
i could live without it quite good.

#5

…and sometimes i had a sneaking suspicion that there might be a correlation with that ominous “can’t save patch”-bug.

#6

i think the stay on top is a useful feature, but true, often doesnt work as expected… it always happens with the render window: for instance if you go fullscreen and then back to window mode, it doesn’t keep staying on top, you know what i mean…

about this “can’t save patch” bug, i had this a couple of time, it’s heavily annoying, but dont know how to reproduce it…

basically you try to save and close a patch, but it keeps askin to save it, and no matter how many times you try it keeps askin…

and worst thing is that if you just kill vvvv, when you reopen the patch you realize that you just lost it, the patch is empty and you want to throw the laptop out of the window…

sorry for the long post, but do you know what i mean? did anybody experience the same? does anybody know why this is happening? i’d really like to know

peace and lovvvve

#7

ok
defetto:
lets proceed discussing the cantsavepatch-thing better here to keep all knowledge at one place.
btw: i assume that there are several independent bugs causing the same annoying symptom.

#8

i’m not sure, but thinking that the issue only/mainly appears if there is more than one window “on top”. so, two oe more “on top” windows compete against each other, when overlapping.
so, what about this:
there should always be one window on top – so, if you set another window on top, the earlier one looses this state.
problem: the inspektor is very helpfull if it’s always on top. (for me) perhaps he should be even more on top than all the other windows?

#9

well, before introduction of the feature the behaviour was exactly like it should.

but now you may have windows staying on top (or at least seem to have priorities) WITHOUT that you ever touched CTRL-T once while patching.

#10

© vvvv group