Window rule to force windows above top layer components

[Vosjedev]

Description

Since not-so-long flameshot came with wlroots-based compositor support, on hyprland with some window rules (see this comment). However, bars like waybar appear above the window when layer is set to top. I would like to have a window rule to make windows appear above the top layer. Would this be possible, and if so, would you be interested in making it?

Additional info:
Use flameshot-git from the AUR, or the source-compile the latest commit of flameshot for wlroots-support to work.

[vaxerski]

fullscreen it

[gfhdhytghd]

Hello, I have the same windowsrule needs. I'm sorry that I can't send contributions directly because my programming skills are really not very good. My situation is like this. I created a script and some windowsrules to implement a "Linux Copilot" and it worked. Good, but the top is blocked by the waybar, so I also want a windowsrule that forces the window to be higher than the top layer

On my computer I could modify this GPT's window to align with the edges of other windows, but since I want to incorporate this "copilot" into my own hyprland installation script, take into account various monitor situations , I can only make it appear across the entire vertical direction, otherwise it will be uneven and it will be ugly.

To sum up, I need a rule that forces the window to be displayed higher than the top layer.

If possible, I also hope to have a rule that can set the position and size of the window by setting the distance from the edge of the window to the edge of the screen. This rule will, to a certain extent, enable the same configuration file to be used on different monitors. Better compatibility.

picture of the "Linux Copilot"

[gfhdhytghd]

This is My solution for screen shot

bind = $mainMod, S, exec, grim -t jpeg -q 100 -g "$(slurp)" - | swappy -f - # take a screenshot

[Vosjedev]

@gfhdhytghd Grim and slurp, or rather grimshot, is not really an option for me, for several reasons.

I sometimes make screenshots where timing is a problem. Slurp does not pause the screen while selecting, if something is moving it will keep moving.

I also need some other functions of flameshot, and find gimshot (even with swappy) a bit underfunctioning...

@vaxerski (sorry for pinging you) I tried fullscreening the window but it just moved the window to my smaller monitor and moved it down:

[Vosjedev]

For now I solved this with the following script which just hides waybar:

#!/usr/bin/bash

flameshot gui &
sleep 3
killall -SIGUSR1 waybar # toggle waybar
wait # wait for flameshot to exit
killall -SIGUSR1 waybar # toggle waybar

you will need to ajust the sleep timing according to the speed of your computer.

I guess as I am not the only one with this problem I won't close this for now? Vaxry, you can decide if this needs to be closed or not.

[alba4k]

fullscreen it

Add an option to fullscreen something on every display, like you can on i3 (and I think sway too) with fullscreen toggle global

[shasherazi]

I also want to render my dmenu floating window over my waybar, but I can't since waybar is always on top. Is there any way of doing that currently? I tried alterzorder and pin but they didn't work.

[alba4k]

I think you can fix that by using a dmenu version that's actually made for working on wayland, and therefore can be set to use an overlay layer, rather than just using the normal one via xwayland

https://github.com/nyyManni/dmenu-wayland

I found this, not sure if you can make it appear on top of waybar rather than below it (y-wise) tho

[alba4k]

Add an option to fullscreen something on every display, like you can on i3 (and I think sway too) with fullscreen toggle global

@vaxerski would this be achievable in any meaningful way?

Basically just like resizing a floating window to fit every screen, which is what the author was doing with flameshot

[vaxerski]

scripts/plugins. Not planned to be a part of core. It's, for all intents and purposes, stupid.

[shasherazi]

@vaxerski what about my usecase? Can I render a window on top of wayland?

[Vosjedev]

For anyone using the window rules mentioned in that original post: The rule name changed, so change the line

windowrule = nofullscreenrequest,flameshot

to be

windowrule = fakefullscreen,flameshot

[vaxerski]

if you move your bar to the bottom layer it will be below windows.

[alba4k]

And so will the tooltips

[vaxerski]

yea yea I will fix that one day

[alba4k]

Thanks @vaxerski for being a good boy :)

Now @Vosjedev since the original issue is fixed I guess this issue could be closed? even tho there is no real "fix"? up to you ig

[Vosjedev]

Then I'll move that to vaxerski like I already did ~3weeks ago:

I guess as I am not the only one with this problem I won't close this for now? Vaxry, you can decide if this needs to be closed or not.

:D

I guess it (kind of)^[1] works for this specific case (flameshot), but as @gfhdhytghd had some usecase for this as well, I don't know wheather this is accually resolved... But maybe I need to learn some C++ and write a plugin for this. It will probably be months before I start on that though, as I got some other big things in mind to do first. But if others (@gfhdhytghd ?) are really interested in this working, I can give it more importance on my todo list and move it to sooner.

[1] It is however a bit sketchy as not all UI elements get hidden, for example another overlay I added later is still in front of flameshot, and my notifications also still show up. This means it is a bit of a temporary solution to me.

[vaxerski]

I still will not budge on the fact that accommodating for apps' laziness in doing things in a fucking shit way instead of the proper way is not what I will be interested in doing.

[alba4k]

tbh being able to fullscreen on every monitor was a neat feature to have sometimes, but sure

[Vosjedev]

I still will not budge on the fact that accommodating for apps' laziness in doing things in a fucking shit way instead of the proper way is not what I will be interested in doing.

I am not saying you need to fix this, you already said you don't want to, and I won't push my will on people making open source software in their own time. I agree that this is indeed a flameshot issue now that I read this.

[gfhdhytghd]

Not very important to me, I have temporarily removed this feature from my scripts and default configuration files, since I am in China and almost no one here can use this feature. But I still hope to have such a function, because I think this function will be quite useful in some other situations. Temporarily turning off the waybar is not a good solution. Sometimes it will cause the tray to not work or other problems, such as high performance overhead and severe lag on some old computers.

Anyway, I don't know anything about C, so I can't be of much help in plug-in development.

Maybe we should politely ask the waybar developers if they can make different parts of the bar run at different levels? For example, the bar itself is at the bottom and the tray and hover pop-up window are at the top? Or politely ask the software developers (flameshot, chrome, etc.) to provide an option to render the software at any level?

[Vosjedev]

Or politely ask the software developers (flameshot, chrome, etc.) to provide an option to render the software at any level?

For that they would have to get the compositor to put the windows above the shell, so a wayland protocol for that would need to exist. I don't think there is any protocol for requesting normal (non-shell) windows to be above the top shell layer, but correct me if I'm wrong here. I also don't think they will make it 'at wayland' (the protocol developers), given the fact they are currently discussing about basic functionality : ) but I guess flameshot should be able to do the same as slurp, however I have no idea how hard that would be to implement. Flameshot is not very busy in supporting wayland, so also don't expect them to do that much about it...

Maybe we should politely ask the waybar developers if they can make different parts of the bar run at different levels?

I don't think they will do that, they have better things to do I guess.

[letavocado]

Hi folks! I guess I have also new case.

Description:

When using LunarVim as an IDE for Flutter development, the Android Emulator is set to float above other windows. However, when LunarVim is toggled to fullscreen, the Emulator window is hidden, even though it is expected to remain visible and it's okay. But how to make Emulator always on top?

Expected Behavior:

The Android Emulator should remain visible on top of the fullscreen LunarVim window, maintaining its floating state.

For example, when runing wofi it's always on top.

Cheers! :sparkles:

[alba4k]

Wofi is renderes as a layer, not a window