Menubar geometry does not respect bottom awful.wibox about awesome HOT 8 CLOSED

This looks related to:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1216

from awesome.

I don't have this problem with my config. I have tiltebars, a top and bottom wibox too. You can try my config (see my github). If you do, sorry for its current state, I am in the middle of writing a new theme and I was too lazy to branch my work. If that works for me, it should work for you too. You can also check your screen "workarea" see the API on how to print it. If the workarea is the problem, then it is in the lua side. If the problem is still there (and using my config too), then it should be in the C side. By the way, the "menubar" is the system menu widget. If you refer to the top wibox, please call it top wibox or "wibar". As menubar is used for something else, it can be confusing. Happy new year!

from awesome.

Tried your config on the git version. It causes a LUA backtrace loop. Tried it on awesome 3.5.5 and it loads after modifying fd_async.lua to not call load_icon_async (was nil). Despite your config, it looks like the titlebar maximization bug is still there. It's a bit weird that you're not seeing the bug at all. That's definitely suspicious.

This is starting to smell like a low level bug. Possibly even an Xcb bug, but that's unfounded. I'm currently in the process of reinstalling my system, so maybe the new combination of libraries will make this disappear.

from awesome.

Strange.

I fixed the issue you had with load_icon_async, this may be remotely related as I tested my config on various distro with both 3.5.5 and master. I never had the issue with the missing gtk function, so your system is diffidently different from mine. Can you elaborate on your distro, LGI/Xorg/XCB/Cairo versions and take a screenshot of your problem?

from awesome.

Grml. What happens:

• When a new client appears, it starts without any titlebars
• When the lua code tells the C code to add a titlebar to something, it doesn't change the x/y position of the container window, just its size (just as @grant-h noticed; In X11-speak, the C code assumes a NorthWestGravity). So the client window itself gets moved around by the size of the titlebar.
• When shutting down, the clients keep their position relative to the root window. In other words, they aren't moved around, the titlebar just disappears.

Once upon a time, we tried to change the C code so that it also moves the top-left corner around and keeps the client window's position constant. That caused bugs with multi-monitor setups, because clients appeared on the wrong screen. Because their geometry.x/y changed, they ended up on another monitor just because something added titlebars.

So I guess we should be more gentle during shutdown and reparent clients to the root window and move them to compensate for the space that was added for the titlebar...? I bet someone will complain about that behavior as well (One behavior makes sense to floating windows, another behavior for maximized/fullscreen windows. I am trying to come up with something that works for both. Urgh)

from awesome.

Does commit 27988ec help?

from awesome.

@psychon, unfortunately it does not. Just tested with latest Git, toolbars enabled and a stock bottom wibox. A maximized client on a floating tag, on a restart, overlaps the bottom wibox, while still being maximized.

Here are some system stats:
Linux outpost 3.14.23-funtoo #1 SMP Mon Nov 10 02:42:50 EST 2014 x86_64 Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz GenuineIntel GNU/Linux

awesome v3.5.2-258-g704cf21 (The Fox)
• Build: Jan 25 2015 14:13:24 for x86_64 by gcc version 4.8.4 (user@domain)
• Compiled against Lua 5.1.5 (running with Lua 5.1)
• D-Bus support: ✔

LibXCB 1.11-r1
Xorg server 1.16.1-r2 with kdrive enabled for Xephyr support

from awesome.

I think I fixed that one a while back, didn't I?

from awesome.