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>
Instead of having the C code mess with which tags are selected, we now emit a
signal on the tag that says that something requested it to be selected. Lua can
then handle this by only switching tags on the correct monitor and by updating
the focus history correctly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
This commits adds awesome.register_xproperty(). This allows lua code to register
arbitrary X11 properties with awesome which will then watch these properties.
Whenever such a property is changed on a client or drawin, we will emit the
xproperty::name signal.
This also adds window:get_xproperty(name) and window:set_xproperty(name, value)
which allows to mess with properties.
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>
Thanks to Michael Stapelberg, there is now a xcb-only port of libXcursor which
does everything we need. This patch switches awesome over to that new library.
Since the only reason for using XOpenDisplay() instead of xcb_connect() was so
that we can use libXcursor, we can get back to that older state again. This
means that this effectively reverts the following commits:
531f8b415c "Added initial support for Xlib cursor themes"
77243cd09a "Add x11-xcb to the pkg-config checks"
779d43fc46 "Don't let Xlib own the event queue"
03759b4847 "Fix keyboard layouts"
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>
This commit ports awesome from libev to the glib main loop. This means that
awesome has fewer dependencies, because we were already depending on glib before
and now no longer need glib.
However, the main reason for this change is that, thanks to lgi, we have glib
bindings for lua. This means that lua code can add all kinds of event sources to
the main loop (timeouts, fd watchers, SIGCHLD watchers, ....). Yay
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>
Commit 03e0ee53d2 removed window shapes, because at the time I was too
lazy to port them from the old image system to oocairo.
This commit re-adds them, but for now only as a way to set the shape.
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>
We only need to update a drawin's drawing related resources when its size
changes. Thus, when a drawin is just moved, drawin_update_drawing() is not
called. However, this function was used for telling the drawin's drawable about
its geometry. This means that the drawable had an outdated idea about what its
geometry was.
Fix this by making sure to always call drawable_set_geometry().
Thanks to Javafant for reporting this bug on IRC.
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>
What's the point of distinguishing between "opacity 1" and "no opacity set"?
This commit makes awesome handle both cases identically.
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>
A drawable is something that you can draw to, just like a drawin. However, a
drawable isn't necessarily its own windows. This will later on be used to
implement titlebars where the titlebars are drawables.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I hope this time i got all right with git format-patch.
Signed-off-by: Tumin Alexander <iamtakingiteasy@eientei.org>
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>
The default background color (None) means that the server will leave the
window's content untouched when an exposure happens. This should get rid of all
cases of "flashing window".
The real background will later be drawn while awesome is handling the expose
event.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel Hahler
Uli Schlachter
David Mohr
Jeremy Bethmont
Tumin Alexander
Arvydas Sidorenko
Anurag Priyam