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;
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.
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);
)
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
(
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.
Hi guys, getting back on this topic; calling Window:front to bring an already visible window to the front does work as described in the posts above, but only on macOS (with the limitation that it can bring the window to the front but doesn’t focus it). When I try this on Linux it doesn’t bring anything to the front, not even sclang… Testing on Debian 12 arm64 (QEMU virtual) with the current SC.
and adding more to this; bringing the window to front with .front doesn’t fire the toFrontAction. Can we please have a working way to bring a window really to the front? Like, the same that happens when you actually click on a window?
That hasn’t worked here either. But it stopped being a problem when I switched to a tilling Windowns Manager.
I think we have fewdev people working on that kind of thing. I’m glad we still have the author of SwindOSC in the community, we have alternatives yet))
BTW, maybe you can be able to make a workaround tweaking your window manager in Linux. The command xprop | grep WM_CLASS followed by a mouse click will tell you the name you need to use to configure the WM. The thing is that each one is different…
For example, in Xmonad, I configure all SC gui to float above when they are created, and stay there until I want to hide or tile them etc
