awesomeWM / awesome

awesome window manager
https://awesomewm.org/
GNU General Public License v2.0
6.36k stars 597 forks source link

Handle setting placement and client size in client rules #2497

Open p-himik opened 5 years ago

p-himik commented 5 years ago

Output of awesome --version:

awesome v4.2-510-g2308509f (Human after all)
 • Compiled against Lua 5.2.4 (running with Lua 5.2)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

How to reproduce the issue: Add a client rule with

properties = {
    floating = true,
    placement = awful.placement.centered,
    width = 500,
    height = 500,
}

Actual result: Placement is applied before resizing. If the initial client size was not 500x500, the client will not be centered.

Expected result: Since there's no x or y, the client size change should be applied before the placement. So, the client should be both resized and centered.

psychon commented 5 years ago

Looks like fixing this would just need fixing the order in which awful.rules applies geometry and placement (search for extra_properties.geometry). However, this would mean that x and y get ignored if placement is also specified...

CC @Elv13

alfunx commented 5 years ago

I think the issue is related to this: lib/awful/rules.lua:676

For now I just added a delayed property called delayed_placement to my configs, which will be executed after x, y, width, height and geometry have been set: ~/.config/awesome/config/rules.lua:149.

p-himik commented 5 years ago

Ah, nice workaround, thanks!

Elv13 commented 5 years ago

@alfunx Mind creating a pull request to add delayed_placement? This is the sanest solution. Moving placement higher in the chain could cause issues. The size_hints, titlebar and floating are already hardcoded to the highest priority to avoid exactly this, but some people might the high_priority to do similar manipulations. Doing this in the normal priority section would cause random behavior depending on which is executed first, which is why it is hardcoded above it. Being by default in delayed adds problem for the "normal" properties that depends on the current placement behavior (aka, people reporting the quick fix for this issue being a regression).

In practice, a more future proof solution would be to move awful.rules.execute to the new graph dependency API we added in 4.3 instead of the manually curated list. However this is a much larger change and as we want to release 4.3 ASAP, is out of the question for now.

p-himik commented 5 years ago

I think adding delayed (default false) key to the placement table could also be considered. Especially since using both placement and delayed_placement doesn't really make sense, I think.

Elv13 commented 5 years ago

I think adding delayed (default false) key to the placement table could also be considered. Especially since using both placement and delayed_placement doesn't really make sense, I think.

Yes, this would indeed be possible. It's too late for v4.3, but once released, I will take a better look.

alfunx commented 5 years ago

@Elv13 Sorry I somehow missed this. Should I make a pull request or will you looking into it?

lguarda commented 1 year ago

If anyone interested, i don't know why but using the following placement function the width and height is handled before the placement, at least it work on my side

properties = {
            placement = function(...) return awful.placement.centered(...)end,
            height = 600,
            width = 1600,
            floating = true,
        }
cronyakatsuki commented 1 year ago

If anyone interested, i don't know why but using the following placement function the width and height is handled before the placement, at least it work on my side

properties = {
            placement = function(...) return awful.placement.centered(...)end,
            height = 600,
            width = 1600,
            floating = true,
        }

Can confirm that this work's.