GUI: Window .front

There is a conversation currently on fb, I thought I post it here.
The Window.front method does not actually bring the window to front (i.e. on top of all Supercollider’s windows). It makes it visible, but the w stays always beneath the y.
To get it to front I must use .alwaysOnTop.
Is this behavior correct? Or is my sc3 broken?

Demonstration code from fb discussion:

w = Window.new("GUI w", Rect(200,200,255,100));
w.front;
y = Window.new("GUI y", Rect(200,200,255,100));
y.front;
// only y comes into focus with the following
w.front;
y.front;
w.front;

I am on 3.13.0-dev, Apple Silicon, macOS 12.6

Not sure if I understand you right, but I execute the code just line by line. Lot of time in between. And still, the “w” never comes up to front.
So I do not think it is a timing problem.

Here an example, run line by line, failed:
https://streamable.com/682tsd

If used in loop with fork however, as demonstrated by James, works fine:
https://streamable.com/ra463f

Probably some stupid user error on my side as usual, but I can not find it :smiley:

From the help:

.front

Displays the window on the screen (This has the same effect as setting -visible to true).

So… this method makes the window visible, but does not necessarily bring it to front (the name is a bit misleading in that way).

I thought there was a method that brings a window to front, but indeed there doesn’t seem like it. The closest I can think of is setting visibility to false and back to true.

(
w = Window.new("GUI w", Rect(200,200,255,100));
w.front;
y = Window.new("GUI y", Rect(200,200,255,100));
y.front;
w.visible_(false);
w.visible_(true);
)

BTW there’s no issue with timing here.

1 Like

Thank you Marcin, so it looks to me, the last chronologically created (or recreated by cycling .visible false and true) window stays on top. Regardless .front method.
But then it is interesting why in the example by James it changes though…? What am I missing here :flushed:

(
var windows = Array.fill(2, { |i|
Window("window" + (i+1), Rect(800, 200, 300, 200))
});
r = fork({
loop {
windows.do { |w|
w.front;
1.0.wait;
}
}
}, AppClock);
)
// use cmd-. to stop

Indeed that’s interesting, and a bit unexpected for me.

So what happens here is that if sclang’s GUI is already in focus, then .front will indeed bring a window to front. But if sclang’s GUI is not already in focus (e.g. focus is on the IDE as one’s typing code), then the focus will change to sclang when running .front, but the window will not come to front. I’m guessing that this indeed might be related to timing - i.e. the message to bring the window to front only works if sclang is in focus already, but it is evaluated after sclang is brought to focus, and thus does not bring the window to front.

I’m not sure what the intention of the original method was, as the documentation only mentions making the window visible, but not bringing it to front.

1 Like