Issue with move windowrule

Hyprland version
Hyprland 0.50.1 built from branch v0.50.1-b at commit 4e242d086e20b32951fdc0ebcbfb4d41b5be8dcc  ([gha] Nix: update inputs).
Date: 2025-07-19
Tag: v0.50.1, commits: 4e242d086e20b32951fdc0ebcbfb4d41b5be8dcc
built against:
 aquamarine 0.9.2
 hyprlang 0.6.3
 hyprutils 0.8.2
 hyprcursor 0.1.13
 hyprgraphics 0.1.5


no flags were set

Describe your issue / feature…

I am having an issue with getting the move windowrule to behave the way I want it to. I am trying to make a floating window spawn on the bottom middle of my screen however it is not really working. I currently have windowrule = move onscreen 50% 100%,class:^(PenTablet)$, but the issue with it is that it is getting centered in relation to the window’s left edge, not the window’s center.

The reason I think that it might be bugged is that I saw on the docs that you should be able to do things like subtracting the window size but when I try things like windowrule = move onscreen 50%-w 100%,class:^(PenTablet)$ nothing really changes.

Moves a floating window (x, y → int or %, e.g. 100 or 20%.
You are also allowed to do 100%- for the right/bottom anchor, e.g. 100%-20. In addition, the option supports the subtraction of the window’s size with 100%-w-, e.g. 100%-w-20. This results in a gap at the right/bottom edge of the screen to the window with the defined subtracted size).
Additionally, you can also do cursor [x] [y] where x and y are either pixels or percent. Percent is calculated from the window’s size. Specify onscreen before other parameters to force the window into the screen (e.g. move onscreen cursor 50% 50%)

I am pretty confused so I would appreciate anyone’s assistance. Am I missing something obvious?

Unless not well described in your post, you are not implementing this like the example.

Sorry for not being as clear I could have been. When I said “when I try things like” I meant that I had tried a lot more then I had wrote. In hindsight my example should have been closer to the docs to exemplify my point (I just grabbed what was sitting in my conf at the time for my example).

I tried all of the following however I could not achieve the behavior I was looking for. In fact the following attempts all produced the exact same output. Which, if the docs are to be believed, should not be the case.

windowrule = move onscreen 50%-w 100%,class:^(PenTablet)$
windowrule = move onscreen 50%-w- 100%,class:^(PenTablet)$
windowrule = move onscreen 50%-w-20 100%,class:^(PenTablet)$
windowrule = move onscreen 50%-w-20- 100%,class:^(PenTablet)$
windowrule = move onscreen 50%-20 100%,class:^(PenTablet)$
windowrule = move onscreen 50%-20- 100%,class:^(PenTablet)$

I tried a good deal of other things as well but as it has been a day and because these attempts were ultimately unsuccessful I cannot remember all of them.


In conclusion, unless I am fundamentally misunderstanding something about the move window-rule, it would seem to be bugged. If it is not bugged then I think the docs should be revised for clarity.

ok, I think I figured this out for you.
You are effectively implementing “distancing” in the wrong coordinate.

Here is what I tried and it works as expected (I use Alacritty)


windowrule = move onscreen 50% 100%-w-340,class:^(Alacritty)$

Needless to say you need to set a “float” windowrule as well for that to work.

I think you misunderstand what I am trying to do or sent the wrong rules (or I messed something up). But I am looking to have the rule center the window horizontally on the bottom of the screen but what you sent centers it vertically on the right side of the screen.

windowrule = float,class:^(kitty)$
windowrule = move onscreen 50% 100%-w-340,class:^(kitty)$

Furthermore, the -340 is an exact value that corresponds to the size of your specific app. For an app of a different size it would not be effective for centering the window. So, even if the window was located in the right location, this will not work for me because in my specific use case, the size of the window varies.

So go ahead and change the percentage of the first (x) coordinate. Something of the likes
windowrule = move onscreen 35% 100%,class:^(kitty)$
or any percentage that suits your liking.
Then if you want to move it up for any reason, subtract whatever number you want from (y).

Yes I recognize that I can change the percentage to make the window closer to the center given that 50% will never be in the center on account of it being calculated from the left edge. But this still doesn’t resolve the problems I have been referring to. What I have been getting at is the ability to to subtract from x.

  1. Once again, I am trying to have my window centered at the bottom of the screen. I have no interest in the y beyond 100%. That being said, in my testing, I have found that you cannot subtract from x. Neither pixels nor percents nor w can be subtracted. This is what I was referring to when I stated that I thought it was bugged. The docs do not clarify that you can subtract from y, just that you can subtract.

  2. Furthermore, as stated, in my use case, the window size is variable. And so, even if you could subtract from x then “subtract whatever number you want” would not work for me as the number changes. To get the effect I want I would need to subtract the window width divided by 2 from 50% on the x. Which doubly doesn’t work because you cannot divide numbers in the move rule.

At this point I am fairly confident that what I want to do is impossible in the current framework of Hyprland. So, I would suggest doing of the following.

  1. If the inability to subtract from x is a bug then fix it (obviously), if it is not a bug then update the docs.

  2. And I think it would be good to adjoin the center window rule to move. This is because they serve a very similar purpose and they cannot both apply to the same window. I think you should be able to do move onscreen center for the behavior that center currently has or alternatively something like (my use case) windowrule = move onscreen center 100%,class:^(kitty)$. to exclusively center on one axis. This would add a lot more flexibility to the move rule.

I have been trying to figure out something similar since I use 2 different PCs with 2 different monitor aspect ratios
I want to open a window that’s 90% of the screen resolution, centered 15 pixels above the bottom edge but I would be happy with on bottom edge.

I presume that you would also like it centered given that that is what I am mainly complaining about here. So, if my proposal was accepted then that could be done like so (with kitty as the example),

windowrule = float,class:^(kitty)$
windowrule = size 90%,class:^(kitty)$
windowrule = move onscreen center 100%,class:^(kitty)$

That being said I am unsure how to offset by 15 pixels with changing aspect ratios. As the system is set up I do not think you could do a simple 100%-15 for the y value because the -15 is related to coordinate placement, it is not relative. To achieve what you are looking for (on that axis) I had to do 100%-(y aspect ratio*.90+15) or 100%-987 on a 1920x1080 monitor and this is made more difficult by if you have a reserve space such as waybar because that changes the aspect ratio it is working with.

edit: I found after doing some testing that my initial statement was just wrong, I have since corrected it. Please do not look at the edit history I am very embarrassed.

Maybe I am misunderstanding things but my current feelings regarding the move window rule is that it just seems really messy to configure. I feel like the more I understand it the less cohesive it is. And once again this might just be a me issue as I am by no means an expert in whatever you would call this but, I dunno, there are a lot of people as stupid as me. And so this makes me feel that if nothing is changed in hyprland itself then I think at the very least the docs should be.

no judgement here. correcting mistakes is good for everyone.

I don’t think this is possible ATM. The entire move windowrule could be rewritten, it’s awful.

1 Like

Unfortunate but that was the impression I was getting.


I would love to see that. :+1:

I hope I am not being bothersome but because we just got a new version (banger by the way) I wanted to make sure this wasn’t forgotten. So, while I figure that it isn’t that high of a priority, I just wanted to verify that it is on the stack. Thank you for your time.