two Change Window Position nodes both firing creates madness that is probably not in accordance with Apple's GUI

Steps causing the bug to occur

  1. see attached composition, two Change Window Position nodes attached to one window
  2. both set to fire every window refresh.

Have you found a workaround?

I think the Window node should default to the higher in the order if both positions are firing at once. I realise ‘at once’ doesn’t really exist in Vuo like it does in QC evaluation. I can’t see an easy way to fix this and still allow more than one positioning node to be attached to a Window node.

Other notes

  • Vuo version: 1.2.1
  • macOS version: OS X 10.10
  • How severely does this bug affect you? Not much; I’m just letting you know about it.

DisplaySphere.window-positioning-feature.vuo (2.88 KB)

hey @@useful_design ;)

I don’t understand why one would want to connect simultaneously 2 different “Set window position” nodes but I don’t understand the bug here.

First your attached composition only has one “Set window position” connected, the other is disconnected (may be intended ?).

Secondly, when I connect both, Vuo seem to use the last connected one, which I found somehow normal.

If you connect the 0;0 position first and the 100;100 below, you’ll see that the composition starts at 0;0 and jumps to 100:100 after a millisecond.
And when 100 is connected first and 0 on the second state, you’ll see the composition slightly moves on start to 0.

Perhaps it’s not really a bug. What is that you are trying to achieve with this ? Maybe I could try to help to find another way ?

For me it oscillates between positions at ~60 Hz connected to both. Why might you have two positions, well I would never i’d use a switch to select the position if i had two positions to move to. But surely Vuo should safeguard against malicious code :P

The other bug that is more serious and I forgot to include is that if the window is on my MBP internal display (and my Editor app is always on my External display) it moves the Window to the position on the external display not the internal display. Actually, come to think of it, Eureka! if this bug fixed it would solve the problem I have that every time i restart the composition i have to move the Viewer window over to internal display because unlike QC, Vuo doesn’t remember Editor or Viewer window positions, nor node graph scale and position for that matter.

Mmm.

Ok, let’s see what the Vuo team has to say about a priority based on the position if two nodes are pushing different values at the same time.
But I guess it’s a normal behavior. As you say, I’d use a switcher.

Concerning your second note I guess by default the Vuo composition loads on the same screen as the editor. I know there this feature request to remember window positions (I’d love that too and even editor zoom memory).
Perhaps that will solve it for different screens too, you might want to add a note there about it or create a separate feature request ;)

1 Like

Whether the window oscillates seems to depend on Mac OS version (or something about the system). It happened on my 10.8 system, didn’t happen on a 10.11 system.

I guess we could modify Render Scene to Window to accept the first Change Window Position and ignore the rest. Though I’m having trouble imagining a situation where someone would connect multiple Change Window Position nodes, see the window oscillating, and not realize what was going on. Can you think of a plausible situation?

if the window is on my MBP internal display (and my Editor app is always on my External display) it moves the Window to the position on the external display not the internal display.

That’s because Change Window Position uses global screen coordinates, and (0,0) is on your external display. That’s a feature, because it means Vuo can smoothly move windows across displays. If you’d like the window to appear on a specific screen, use Get Screen Values to get that screen’s coordinates.

only suggesting malicious code is possible but i guess that’s true of most developer tools

thanks for explanation about global space. looking at all the window node docs to understand more. I think I can set windows to start on 2nd display (int MBP display) now, yay :-)

only suggesting malicious code is possible but i guess that’s true of most developer tools

Yeah, the programming environment tries to carry out the programmer’s intentions, and has no way of judging whether they are malicious.  

Added a note to that other FR thanks @Bodysoulspirit