This commit makes it possible to add titlebars to a client. These titlebars are
drawables.
The drawin's input handling is moved to the drawable. This allows it to use the
same code for drawin and titlebar input handling, although there are lots of
differences between the two on the C side.
On the lua side, a new wibox.drawable module is created which handles all the
drawable-specific magic and which can also be used for titlebars.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When something gives the input focus to the client which already has the input
focus, bad things can happen. Normally, you'd expect nothing to happen in this
case, but X11 is not that simple.
When updating the input focus and the focused client has the nofocus hint set,
we are actually taking away the focus from this client.
Hopefully this fixes FS#973.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, when we received a FocusIn event, we would update the input focus,
because client_focus_update set globalconf.focus.need_update to true.
However, this is wrong for clients following the globally active focus model,
because in this case its the client which controls which window has the input
focus. It could happen that we thus took away the focus from the client which
just gave itself the focus.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The original struct name is luaL_Reg, but Lua v5.1 had a
`typedef luaL_reg luaL_Reg`, which in v5.2 was removed
and as a result breaking the build in Awesome which uses luaL_reg
version exclusively.
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
Now that the C code uses lightuserdata for passing around cairo surfaces, they
are no longer automatically garbage collected. To avoid memleaks, this commit
compares the C code to use cairo_surface_t pointers instead of the lua stack.
This also fixes a memleak were a client's icon was leaked.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This should be the expected behavior, imo. Otherwise the client doesn't appear
in tasklist regardless of being focussed.
[Thanks Uli][1] :).
[1]: http://thread.gmane.org/gmane.comp.window-managers.awesome.devel/7096
Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Lua code can give the input focus to unfocusable clients. That means they have
nofocus set and they don't implement WM_TAKE_FOCUS.
Previously, the previously focused client continued getting input events in that
event. Now the last client is properly unfocused.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves the loading of the rc.lua and managing of pre-existing clients to
after we ungrab the server during startup. To make sure we have no races with
clients which start up parallel to awesome, we do the QueryTree for all the
clients that we have to manage before the ungrab, but start managing the clients
only after the ungrab.
This means that we have already selected our event mask on the root window in
scan() and thus received an UnmapNotify event when we reparent windows into a
frame window. This has the effect that we immediately unmanage the client again,
whoops.
To fix this, we grab the server again and remove our event mask on the root
window again while we reparent.
This should hopefully fix all cases where we deadlock during startup because
pulseaudio wants to talk to the X server, but is being ignored because we have
the server grabbed while at the same time we are waiting for pulseaudio.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This option is no longer valid in modelines, so it has been removed from
all modelines using the following shellscript:
#!/bin/ksh
git ls-tree -r HEAD | cut -f2 | while read f; do
egrep -e '^(//|--) vim: .*encoding=' $f >/dev/null || continue
sed -E -e '/^(\/\/|--) vim:/s/:encoding=utf-8//' $f > /tmp/foo
mv /tmp/foo $f
done
Signed-off-by: Gregor Best <gbe@ring0.de>
Signed-off-by: Uli Schlachter <psychon@znc.in>
xcb-util is now split into several repositories since 0.3.8. This
release also cleaned up the API a lot, thus update the code
accordingly.
Signed-off-by: Arnaud Fontaine <arnau@debian.org>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Both client_isvisible() and client_maybevisible() where almost exclusively
called with the client's screen as their second argument. Remove this second
argument and let these functions instead always act on the client's screen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a client sets WM_NAME (client->alt_name) but doesn't set _NET_WM_NAME
(client->name), we give alt_name to lua when c.name is used. However, we still
emitted property::alt_name instead of property::name to lua. Obviously, this
breaks stuff.
(The same applies to client->alt_icon_name)
I noticed this via feh whose tasklist entry wasn't refreshed when multiple
images were displayed and I switched to the next one.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, c:tags(tags) and t:clients(clients) first removed all
tags/clients and then added the new one.
This is now changed into only removing the tags/clients that have to be removed
and leaving the others in place. Hopefully, this avoids all kinds of weird
issues which we had.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In commit 3dbf89c I removed a client_unban() in the code path for focusing
clients. The idea was that client focusing is now done after rebanning, so that
it should already be visible by the time this code is executed.
However, minimized clients obviously don't get unbanned, So we have to call
client_unban() here to make sure the client is unminimized.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of immediately setting the X11 input focus when client.focus is assigned
something, we now just remember that we'll have to do something later. The focus
is then set in the next prepare call by libev (= after the current main loop run
is done).
Signed-off-by: Uli Schlachter <psychon@znc.in>
When we receive a DestroyNotify, we have to unmanage the client. However, we
were just informed that the window was destroyed, so it doesn't make sense to
try to do "something" with the window.
This commits fixes some errors from the X server (which we ignored, but still
they are gone now).
Signed-off-by: Uli Schlachter <psychon@znc.in>
All windows which use globalconf.default_depth must also have a backpixel,
borderpixel and colormap set when they are created. Without this, all these
xcb_create_window() calls would fail when globalconf.default_depth is no longer
the screen's default depth.
Signed-off-by: Uli Schlachter <psychon@znc.in>
All the APIs that accept both an image and a cairo surface now only accept cairo
surfaces. Images are gone.
Signed-off-by: Uli Schlachter <psychon@znc.in>
alloca() allocates stack space. The image that we were producing is possibly
huge which means that we were asking for e.g. 9MiB of stack space. This is not
really a good idea and caused crashes.
Fix this by using heap memory instead.
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>
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>
A new window is by default above all other windows. This means that when we map
it and then *later* move it to the correct place in the stacking order (thanks
to lazy restacking), the window on the top of the stack has to redraw itself.
I noticed this via naughty notifies redrawing themselves after opening a browser
window.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When an application loses its connection to the X11 server, all the windows in
its save-set are saved by reparenting them back to their closest ancestor. Also,
to they are unconditionally mapped. This second property is exactly what we
need: All windows should be in mapped state, else the next window manager which
starts up won't be managing them.
This should fix all bugs where clients where lost due to a restart, yay! :)
Signed-off-by: Uli Schlachter <psychon@znc.in>
When one sets a client to fullscreen, this is what currently happens:
- lua code: c.fullscreen = true
- The C code emits request::fullscreen without having touched the client's
fullscreen property yet (c.fullscreen is still false)
- awful.ewmh changes the client's geometry to fullscreen via c:geometry()
- This causes property::geometry to be emitted
- awful.layout reacts on this and causes the screen to be re-arranged, undoing
the fullscreen geometry set in awful.ewmh
- The C code for c.fullscreen = true continues and actually changes the client's
fullscreen flag
The result of this is that we get a client which thinks it is fullscreen'd
without actually being that.
Fix this by first changing the client's fullscreen property and then emitting
request::fullscreen. Same thing for maximized_{vertical,horizontal}.
Thanks to Jim Pryor for reporting this bug and helping reproducing it.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There is a push 15 lines before the push that is removed here, but the client
that is pushed there was never popped. Bad.
Fix this by letting luaA_class_emit_signal() do the needed pop for us.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Uli Schlachter
Arvydas Sidorenko
Anurag Priyam
Majic
David Palacio
Gregor Best
Arnaud Fontaine
Julien Danjou