Window being constantly in front

[JanDiederich]

I have an application with constantly animated text, that breaks the Winit backend and the Qt backend. I tested both, but the result stays the same. The window is a constant topmost application, which can't stay in the background and constantly, annoyingly, workflow-stopingly, pushes itself into the topmost front.

How can I fix that?

My systems: Ubuntu 20.04.6 LTS 64 Bit and Raspberry Pi OS 64 Bit latest version.

Edit: As soon as I disable the animation, the window behaves normal. The "redraw" call, caused by the animation, seems to trigger it.

[ogoffart]

That is a strange bug.
Do you have always-on-top: true; on your Window by any chance? If yes, that explain it and you should remove that.
If not, you can try always-on-top: false; but that should have been the default.
If there is no animation, is the window still always on top?

[JanDiederich]

As soon as I disable the animation, the window behaves normal. The "redraw" call, caused by the animation, seems to trigger it (I deep debugged the code, but couldn't find the actual error).

Adding always-on-top: false; doesn't change anything.

Edit: It seems that Slint isn't prepared for animations, coming from outside of Slints own animation system. But this is an endless text scroll, and the code is slightly more complicated than Slints embedded stuff.

Here is the core code:

self.timespan_pos -= TIMESPAN_SCROLL_WIDTH * (time_passed_in_millis as f64 / ANIMATION_UPDATE_INTERVAL);
if self.timespan_pos < -main_window().get_timespan_width() as f64 / 2.0 {
    self.timespan_pos += main_window().get_timespan_width() as f64 / 2.0;
}

main_window().set_timespan_offset(self.timespan_pos as Coord);

A few explanations: The TIMESPAN_SCROLL_WIDTH is the scroll distance, basically the speed, time_passed_in_millis is the time passed between the last update call, since the timer doesn't fire 100% regularly. get_timespan_width() gives the Text width property. The remaining code should be self-explanatory.

Am I wrong, is this code which could be written embedded in Slint?

[ogoffart]

I am really puzzled as i don't explain at all what happens. I never heard of anything like that.
Is it possible to take a screencast of your screen when this happens?

[JanDiederich]

As demanded, here is a demo: https://github.com/JanDiederich/slint_completely_front.git.
Clone & run this, and see it for yourself. Use it for debugging and fixing, if you like (it's under the super free CC0 license).

This bug is 100% reproducible, always, creating the demo was super easy, barely an inconvenience.

Edit: Under Linux Gnome with Ubuntu 20 64 Bit and Raspberry Pi OS 64 Bit.

[JanDiederich]

As demanded, here is a demo: https://github.com/JanDiederich/slint_completely_front.git.
Clone & run this, and see it for yourself. Use it for debugging and fixing, if you like (it's under the super free CC0 license).

This bug is 100% reproducible, always, creating the demo was super easy, barely an inconvenience.

Edit: Under Linux Gnome with Ubuntu 20 64 Bit and Raspberry Pi OS 64 Bit.

[ogoffart]

It is not reproducing the issue on my system (Ubuntu, tried both Plasma X11 and Gnome wayland)
The window can very well be in the background of other Windows.

Is there anything special about your system than could cause this? I have never heard of such strange problems.

[JanDiederich]

Did you test this with Ubuntu 20.04 LTS with defaults? Or Raspberry Pi OS?

That's a huge difference, both mean Gnome 3. Latest Ubuntu LTS (22) means Gnome 4 (which doesn't mirror Raspberry Pi OS's Gnome version).

Edit: I experimented with the Wayland settings, that doesn't seem to influence the bug in any way.

[ogoffart]

I am using Ubuntu 23.04
I can't easily test with ubuntu 20.04

[JanDiederich]

Please use a Virtual Machine, like https://www.virtualbox.org/ and then install https://releases.ubuntu.com/focal/.
Or install the latest Raspberry OS on an Raspberry Pi.

Edit: To compile Rust on a Raspberry Pi, the Pi needs at least 1 GiB of RAM, better 2 GiB RAM.

[ogoffart]

Could you make a video of this happening so i can try to understand what's going on?

[tronical]

I can reproduce this, after installing focal in a VM.

So far I've tracked it down to this:

1. The closure invoked regularly (via timer) in the example app ends up triggering a call to apply_window_properties().
2. That means we repeatedly call winit_window.set_window_level(winit::window::WindowLevel::Normal); and each time that's called, the window is brought to the foreground.

[tronical]

We'll have to work around this. I'll create an issue from this discussion.