Open p-himik opened 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
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.
Ah, nice workaround, thanks!
@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.
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.
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.
@Elv13 Sorry I somehow missed this. Should I make a pull request or will you looking into it?
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,
}
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.
Output of
awesome --version
:How to reproduce the issue: Add a client rule with
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
ory
, the client size change should be applied before the placement. So, the client should be both resized and centered.