search

awesomeWM / awesome

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

theme.border_width = 0 causes misshapen clients #1794

Open tyrumus opened 7 years ago

tyrumus commented 7 years ago

Output of awesome --version:

awesome v4.1 (Technologic)
 • Compiled against Lua 5.1.5 (running with Lua 5.1)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: 0.9.1

How to reproduce the issue:

Set theme.border_width = 0 in theme.lua and restart Awesome

Actual result:

Maximized clients shift to the left slightly (presumably 2 pixels, since the previous border_width = dpi(1)) and their respective heights increase to cover the wibar. The latter is only noticeable if the wibar is configured to be on the bottom of the screen. Screenies: Normal with theme.border_width = dpi(1) Normal Messed up with theme.border_width = 0 Messed up

Expected result:

Clients remain the same as before the restart. This worked in 4.0, so something happened between 4.0 and 4.1.

psychon commented 7 years ago

This worked in 4.0, so something happened between 4.0 and 4.1.

Are you really sure about this? I just went through the difference between the two and did not find anything.

I think what happens is the following: When awesome restarts, it makes sure all windows survive by reparenting them to the root window. So when a window is at position (0,0) and has a border width of 1, the "real client" is at position (1,1) while awesome is running. When shutting down, the "real client" is reparented to the root window and moved to position (0,0). The idea here is that when awesome starts again (and the client is managed again), awesome will move the window to (1,1) again.

Basically: We do things so that clients should not move across a restart (at least most of the time - window gravities are fun... not).

When you apply a different border width after a restart, this magic does not end up working and thus the client's position is shifted.

Right now, no idea for why exactly the height becomes larger, but I would guess that this is due to the titlebar.

The short version: Across a restart, not much is preserved.

My question is, why do you restart awesome? Just to apply a different border width? Why can't you do that while awesome is still running? Something like the following should work without a restart. awesome-client 'require("beautiful").get().border_width = 0 for _, c in pairs(client.get()) do c.border_width = 0 end'.

tyrumus commented 7 years ago

This worked in 4.0, so something happened between 4.0 and 4.1.

I'm very sure about this. After installing 4.1 as a .deb, I uninstalled it, and tried 4.0 without the issue I described. I'm back on 4.1 and it happens after every restart. If you were wondering if it's a Chrome-specific issue, I checked with Thunar and Natron, and those both have the same issue.

My question is, why do you restart awesome?

It's easier to test my changes in rc.lua with a quick Ctrl+Mod4+R.

actionless commented 7 years ago

is that reproduciable with the default config?

tyrumus commented 7 years ago

is that reproduciable with the default config?

Yes. Provided you make the changes I described above. It's easier to see if you move the wibar to the bottom and set it's height to something larger like 40 pixels.

psychon commented 7 years ago

Yes. Provided you make the changes I described above. It's easier to see if you move the wibar to the bottom and set it's height to something larger like 40 pixels.

Ok, so I apply the following change to the default config:

diff --git a/awesomerc.lua b/awesomerc.lua
index 7b14754d5..9437777d0 100644
--- a/awesomerc.lua
+++ b/awesomerc.lua
@@ -212,7 +212,7 @@ awful.screen.connect_for_each_screen(function(s)

     -- @DOC_WIBAR@
     -- Create the wibox
-    s.mywibox = awful.wibar({ position = "top", screen = s })
+    s.mywibox = awful.wibar({ position = "bottom", screen = s, height = 40 })

     -- @DOC_SETUP_WIDGETS@
     -- Add widgets to the wibox
@@ -453,6 +453,8 @@ clientbuttons = gears.table.join(
 root.keys(globalkeys)
 -- }}}

+beautiful.get().border_width = 20
+
 -- {{{ Rules
 -- Rules to apply to new clients (through the "manage" signal).
 -- @DOC_RULES@

Then I start awesome and open a window: before

Afterwards I change the border_width to 0 and restart: after

So... the window keeps its size and position here. Isn't this just what is supposed to happen, or am I wrong? Why do you get a different result?

tyrumus commented 7 years ago

facepalm I probably should have said that the clients have to be maximized for it to happen, but yes, you have the changes correct.

I'll update the original post.

psychon commented 7 years ago

I probably should have said that the clients have to be maximized for it to happen,

Yes, you should have. :-P

In that case this makes a lot more sense. However, we recently merged a pull request with the great title "Fix maximize again": https://github.com/awesomeWM/awesome/commit/b98ca2ec981cda7dc6eb495802af7c5ead8d1b2a

New attempt with master at 9016a9296fe3382063c4aea00e4a39778b707635 :

diff --git a/awesomerc.lua b/awesomerc.lua
index 7b14754d5..a2d689bd6 100644
--- a/awesomerc.lua
+++ b/awesomerc.lua
@@ -212,7 +212,7 @@ awful.screen.connect_for_each_screen(function(s)

     -- @DOC_WIBAR@
     -- Create the wibox
-    s.mywibox = awful.wibar({ position = "top", screen = s })
+    s.mywibox = awful.wibar({ position = "bottom", screen = s, height = 40 })

     -- @DOC_SETUP_WIDGETS@
     -- Add widgets to the wibox
@@ -456,6 +456,7 @@ root.keys(globalkeys)
 -- {{{ Rules
 -- Rules to apply to new clients (through the "manage" signal).
 -- @DOC_RULES@
+beautiful.get().border_width = 20
 awful.rules.rules = {
     -- @DOC_GLOBAL_RULE@
     -- All clients will match this rule.
@@ -468,7 +469,9 @@ awful.rules.rules = {
                      buttons = clientbuttons,
                      screen = awful.screen.preferred,
                      placement = awful.placement.no_overlap+awful.placement.no_offscreen
-     }
+     }, callback = function(c)
+         if c.border_width == 20 then c.maximized = true end
+     end
     },

     -- @DOC_FLOATING_RULE@

Before restart: before

After restart: after

I'll close this under the assumption that this was recently fixed. Please reopen, if git/master or awesome 4.2 (once it is released...) still have this problem.

tyrumus commented 7 years ago

Gosh dang it, that's twice that I've missed minor details. I am so sorry for wasting your time. I appreciate the help.

tyrumus commented 7 years ago

Can confirm that it's fixed in master.

psychon commented 7 years ago

I am so sorry for wasting your time.

No problem. Feel free to stay around, help answer questions from others and improve awesome. :-)

tyrumus commented 7 years ago

This is still a problem with 4.2:

awesome v4.2 (Human after all)
 • Compiled against Lua 5.1.5 (running with Lua 5.1)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: 0.9.0

I'd also like to note that Awesome doesn't have to be restarted in order for the client to be misshapen. i.e. When I open Thunar or Steam, they both open as a maximized window. I did not set a rule to force them to do that. They do it on their own accord. At this point, the client is misshapen and shifted downwards, like the screenshot in the OP shows. Then, when I unmaximize and maximize them again, they are positioned properly.

To reiterate, all of this happens when the default client border_width = 0.

Any ideas on what could still be causing the issue? EDIT: I don't have permission to re-open this issue.

blueyed commented 7 years ago

So then it was not really fixed on master for you before? Since then it should be in 4.2 by now, or it has regressed. In this case it could help git-bisecting it.

tyrumus commented 7 years ago

Correct. It was not really fixed. According to the 4.2 release log, I'm pretty sure it was regressed.

Offtopic: really like the Daft Punk version names.