The systray bases its extents on the size of the wibox that it is contained in.
No idea how this is supposed to work when the systray doesn't get the full size,
but in a vertical wibox, using <height of wibox> * <number of icons in systray>
certainly doesn't work for computing the size.
The fix isn't hard: Check the wibox' orientation when drawing and base our
calculation on its width if its orientation is different from East.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes it an error if an unknown signal is connected, disconnected or
emitted. All signals have to be added before they can be used.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit 27f9c0177a.
This commit broke code like the following because reading client.focus would
still return the previously focused client:
awful.client.focus.byidx(1)
if client.focus then client.focus:raise() end
This moves the appropriate fields for client focus from screen_t to globalconf
since only the first screen's fields were used anyway.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes awesome support only a single X11 protocol screen. If you are still
using zaphod mode, you can run multiple instances of awesome on the single
screens, e.g.:
DISPLAY=:1.0 awesome & DISPLAY=:1.1 awesome &
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, if a client had nofocus == true, it wasn't unminimized if sth tried
to focus it. Also, if this client had the WM_TAKE_FOCUS protocol, the focusing
would fail since it's an error to set the input focus to an unviewable window.
For consistency, this also moves the code that sets a client's minimized
property to false into client_unban() since it doesn't make sense to have a
minimized client unbanned (i.e. visible).
Signed-off-by: Uli Schlachter <psychon@znc.in>
If this property is true, setting "client.focus" to this client might have some
effect. If it is false, setting "client.focus" will be ignored completely.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The old code used the wrong constants which meant we always returned "word" for
wrap and "end" for ellipsize.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previous, there was a round-trip after each request for a property since we
waited for the reply immediately. Instead, it makes a lot more sense to first
send all of the requests and then handle all the replies. This now takes only a
single round-trip for all the properties from client_update_properties().
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of calling each property handler with a property reply, it's now up to
the handlers to request the properties.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For each property we handle, there is now a function which sends a request and
returns the cookie and a second function that takes the cookie and saves the
result in the client_t struct. This should make it possible to improve our
latency later on.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This should fix an actual race condition:
- Client unmaps its window (UnmapNotify for awesome)
- Client maps its window (MapRequest for awesome)
- Due to the UnmapNotify: client_unmanage() runs and reparents the window back
to the root (ReparentNotify)
- Due to the MapRequest: client_manage() runs
- Due to the ReparentNotify: We call client_unmanage() again and now the
client's window is lost.
Signed-off-by: Uli Schlachter <psychon@znc.in>
According to ICCCM, if a client wants to reuse one of its windows, it has to
wait until the WM updated WM_STATE. This means updating WM_STATE should be the
very last thing we do when unmanaging a window.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a window is moved, it should be sent a synthetic ConfigureNotify describing
its new position. This also documents why we send a synthetic event if nothing
was changed in response to a ConfigureRequest.
Signed-off-by: Uli Schlachter <psychon@znc.in>
If a client sets its own border on its window, the results look broken. This was
found via xev by Gregor Best, thanks.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The commit which made awesome a reparenting WM broke the fix from 37703948b3.
Fix this again by stacking the frame window correctly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a client is unmanaged, we destroy our frame window. But since the client's
own window was still a child of the frame window, it was destroyed, too. This
commit fixes this by reparenting the client's window back to the root window
first.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This splits up client_getbywin() into two different functions. One of them finds
a client by its frame window, the other checks against the client's own window.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Each window is now reparented under a window created by awesome. This window is
NOT visible, this commit should not cause any visible differences. Instead, this
is done to work around problems with X11.
The only alternative would be to ban windows by moving them offscreen which is
ugly in itself and breaks pagers. Doing it like this seems to be the better
solution.
Signed-off-by: Uli Schlachter <psychon@znc.in>
libxcb-property will be dropped from xcb-utils in the next release, because
upstream thinks it's not really useful and well-designed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
While a window is in the save set, it will automatically be made visible again
when awesome exits/dies. This makes sure that the next window manager will pick
this window up and handle it properly again.
But when a window explicitly asks not to be visible, it doesn't want to be
visible. Even if awesome dies. So we should remove the client's window from the
save set in client_unmanage.
Thanks to anrxc and his xwrits.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The window is now no longer enlarged to make it fit into its aspect ratio, but
only ever made lower. This was verified with a small test app that sets a min
aspect ratio of 0.5 and max aspect ratio of 2.
Signed-off-by: Uli Schlachter <psychon@znc.in>
ICCCM says that the min size should be used for the base size if no base size is
specified. The only exception is when calculating the aspect ratio of the
window, in that case only the "real" base size may be used.
Awesome didn't do this last part before.
Signed-off-by: Uli Schlachter <psychon@znc.in>
If a window is fullscreen it is supposed to cover the full screen. Obeying size
hints makes no sense in this case.
Signed-off-by: Uli Schlachter <psychon@znc.in>
