When minimizing a client, we temporarily ignore events for the client window (so
that we don't get the UnmapNotify event that we are causing for the unmap) and
for the root window (I don't actually know why, no "harmful" events should be
caused...).
However, we weren't ignoring events on the frame window itself. This commit
fixes that oversight.
The problem here is that the pointer could be inside the window that is being
minimized. When we then unmap said window, the pointer will now be inside of the
frame window and the X11 server will thus generate an EnterNotify. When we
handle this event later on, we emit mouse::enter on the client and e.g. the
default config then focuses this client, which undoes the minimization.
This fixes a regression introduced in commit 3aeac3870c and fixes#92.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function gets a width and height of a client, applies the client's size
hints to these numbers and returns the result.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fix two things:
(1) Clients asking to be urgent while focussed, this have been reported
a few time for urxvt and I usually link a patch that fix this. This may
not be considered a bug by some, but I think it is.
(2) Add the ability to stop noisy clients from setting the urgent state
themselves.
Because ICCCM pretty much mandates that minimized (aka "iconic") clients are
unmapped. In detail: To go back to normal state, the client should map its
window and for this to work, the window needs to be unmapped.
Thanks to Oleg Shparber for reporting some issue he had with a self-written Qt
program and for providing a simple and short test case.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fun fact: ICCCM specifies that icon_pixmap must have depth 1. Xterm uses a
pixmap with depth 24. Yay... As such, I don't have any test for the depth == 1
case and will just assume that it does the right thing. If it doesn't, I bet no
one will notice anyway.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Everything that needs the lua_State should create a local variable like this:
lua_State *L = globalconf_get_lua_State();
This ensures that the compiler warns if there are two variables with name "L" in
scope. The idea here is that it should become harder to accidentally use the
global lua state instead of the state of the current state.
While writing this commit, I found another place that gets its wrong: Reading
client.focus from a coroutine was broken, since it was returning the result on
the main thread instead of the current one.
Signed-off-by: Uli Schlachter <psychon@znc.in>
tag_client() said that it refers to the tag ontop of the lua stack. However, it
implicitly used globalconf.L as its stack. So if you tagged a client with a tag
from a coroutine, thinks would Go Wrong (tm). Fix this by adding an explicit
lua_State* argument.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A stack index without the corresponding lua_State pointer is useless, because it
could reference another coroutine than the main thread and thus just assuming
globalconf.L is wrong. Fix this by also passing around the corresponding
lua_State pointer.
This improves the result for the following test:
coroutine.resume(coroutine.create(function()
drawin({}).visible = true
end))
Signed-off-by: Uli Schlachter <psychon@znc.in>
Every .c file has to include the corresponding .h file first to make sure the
headers are self-contained. Additionally, this moves some unneeded includes
around.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the screen objects use our existing infrastructure for implementing
classes and objects with lua instead of hand-rolling an own version.
This results in some small API change: Screen objects no longer have an
add_signal() function and instead this function exists on the parent screen
class.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously we would get a short black flicker when a client closes. This
happened because first the client's window would get hidden and only a short
moment later would awesome react to this and close its own window. In the mean
time, the X server filled the frame window with its background-pixel which was
black.
Just removing the background-pixel means we get the default value which is None.
This means that the content will be left untouched and the client's window will
be visible for a moment longer.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The X11 server tells us about things that need to be redrawn via expose events.
When we get such an expose event before lua drew the drawable, we just fill the
exposed area with old data (which is black for newly-created drawables).
Fix this by tracking if we have any usable data in a drawable's double buffering
pixmap. This flag is unset whenever we throw away the old content (e.g. due to a
resize) and is set when lua gave us some new content to display.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We now handle all "important" EWMH messages in lua and lua can decide to do
different things than the current obvious one.
Consistency!
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, ownership of the pixmaps that we are using for double buffering was
a little weird. The pixmap belonged to the drawin/titlebar, but the
corresponding cairo surface was owned by the drawable. Clean this up by moving
the pixmap to the drawable.
This cleans up lots of ugly code and also fixes a crash: When a drawable was
garbage collected before its drawin, drawin_wipe() would crash accessing the
drawable. This was needed to make it forget about the cairo surface we gave to
it for the pixmap that is being destroyed.
By moving the pixmap to the drawable, this whole issues goes away.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Whenever a titlebar of a client needed to be refreshed, all (possibly) four
titlebars would get completely refreshed. So if someone actually added more than
one titlebar to a client, awesome would copy each titlebar's content to the
window four times. Fix this by introducing more fine-grined functions for
uploads.
This also makes awesome only update the affected area when it gets an expose
event for a titlebar instead of all four titlebars completely.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allow to spawn something, then apply some properties or rules when
the client show up ("manage").
This commit add:
* "startup_id" property for all clients object (immutable, can be nil)
* Second return value to awful.util.spawn() with the startup_id
* Update the documentation
Example:
local wait_for_it = {}
local pid,snid = awful.util.spawn("urxvtc")
wait_for_it[snid] = {ontop=true,sticky=false,
tag = awful.tag.gettags(mouse.screen)[1] }
client.connect_signal("manage", function (c, startup)
if c.startup_id and wait_for_it[c.startup_id] then
for k,v in pairs(wait_for_it[c.startup_id]) do
c[k] = v
end
if wait_for_it[c.startup_id].tag then
c:tags({wait_for_it[c.startup_id].tag})
end
end
end)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead, use stack_client_push and emit the `request::activate` signal
from awful.rules.apply, if the client gets focus.
Signed-off-by: Daniel Hahler <git@thequod.de>
This reverts commit a54636751b.
We now have the new xproperty API which does the same thing in a much nicer way.
Thanks to Elv13 for the idea!
Signed-off-by: Uli Schlachter <psychon@znc.in>
When we receive a _NET_ACTIVE_WINDOW request on the root window, we used to just
focus and raise the window. This didn't do much for clients which are on
non-selected tags.
Thus, this commit makes awesome emit request::activate on the client instead.
This is used in awful.ewmh to implement the old behavior again, but with
additionally marking the client as urgent if it isn't visible.
People who don't like this behavior can use client.disconnect_signal to disable
this behavior again. To make this really possible, awful.ewmh becomes a
"non-nil" module.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A drawin's and a client's bounding and clip shape can now be queried and is
returned as a cairo surface. Also, a client window's shape (e.g. xeyes setting
its own shape) can be queried via c.shape_client_bounding and
c.shape_client_clip. All of these properties now emit signals when changed.
(This also silently fixes a bug in luaA_drawin_set_shape_bounding() which forgot
to include the drawin's border in its size calculation)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit c3bca6ac34.
This caused problems where clients would always spawn on the top-left screen and
couldn't be moved around. This was because lua placed them on the other screen,
but when the titlebar got added, their top-left corner was moved over again.
This kind of forces every client to have a window gravity of "static".
This fixes most of the problem of clients moving around across restarts due to
the titlebar. What is left is that they move due to the border width which
should be handled in another patch. Also, another patch should make this honor
the client's actual window gravity.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We no longer have to turn the client's content into an image buffer "by hand".
Instead, we can just use cairo for the job.
Even more exciting, we don't need to turn this into an image buffer at all. We
can just directly return a cairo xcb surface for the client window. Depending on
how lua will use this surface, this could make it possible to avoid having to
create the image buffer at all!
Signed-off-by: Uli Schlachter <psychon@znc.in>
The size saved in c->geometry also includes the titlebars. Thus, for getting the
window content, we have to subtract this from the size.
Before this, the call to xcb_image_get() was failing with a BadMatch error,
because we were asking for an area that is outside of the actual client's
window's geometry.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I noticed high CPU usage while using asunder. The reason was that asunder
re-sets its window name every 0.1 seconds (and awesome's drawing code is way too
slow).
A semi-fix for this is to ignore string property changes if the old and new
value for the property are equal.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Titlebars are not visible for fullscreen clients, so it doesn't make sense to
substract the area used for the titlebar in ConfigureNotify events.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Having this in lua means that size hints are only applied after the client got
resized. The bad side effect of this is some flickering if awesome is being
slow. And apparently, it is slow for way too many people...
Signed-off-by: Uli Schlachter <psychon@znc.in>
When property::surface is emitted, the drawable didn't know its geometry yet,
which had weird side effects. Fix this by changing the C API a little. The
function drawable_set_surface() now no longer allows a NULL surface as its
argument.
The required changes for the titlebar code also means that we no longer throw
away the double-buffering surface when a client is moved.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code assumed that a window gets resized when it enters/leaves the fullscreen
mode. This was needed because the code for resizing a window hides and shows the
titlebars.
However, it is possible for a window to enter/leave fullscreen mode without
getting resized, because it already has the correct geometry. In this case,
titlebars were not handled correctly.
This commit fixes that by forcing a resize to the current geometry when the
fullscreen flag is toggled.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fullscreen windows only worked on a screen which had x and y coordinates 0.
Otherwise, the window inside the frame window was completely misplaced.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fullscreen clients shouldn't be decorated, thus hide titlebars on those.
This commits assumes that clients get resized when they enter or leave the
fullscreen state. I don't think that this assumption is necessarily true, but
let's just wait for bug reports. :-)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, the area of the window that the client could draw to got smaller
when titlebars are added. This causes all sorts of odd-looking effects, so
instead this should enlarge the window suitably.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code was sending out ConfigureNotify events which contained the size of the
frame window. Thus, the client assumed that it is was larger than it actually
was.
Fix this by subtracting the size of the titlebars from the geometry for the
event.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This new property is used for fixing some missing redraws that the old code had.
Those could be seen via awful.menu. Open and close a submenu repeatedly and the
submenu will appear black.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
Daniel Hahler
Julian Wollrath
Uli Schlachter
Emmanuel Lepage Vallee
Daniel Hahler
Jeremy Bethmont
Arvydas Sidorenko
Anurag Priyam
Majic
David Palacio
Gregor Best
Arnaud Fontaine
Julien Danjou