This ensures that systray icons cannot resize themselves. We assign them some
size and they have to deal with what they get!
Fixes: https://github.com/awesomeWM/awesome/issues/487
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit added some variables and this commit makes the surrounding
code use these new variables as well.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There is a client window C. Around this window, awesome adds a frame window F.
When the pointer is inside of C and then moves inside of F, we get a LeaveNotify
with detail=Inferior, but from our point of view, the pointer is still inside of
C, because F is contained in C.
Similarly, if the pointer is in F and moves to C, we get an EnterNotify with
detail=Inferior that we should ignore. However, for an EnterNotify the pointer
can now be inside of a titlebar, so this case has to be handled now.
The above explains the enter/leave behavior for clients. Let's now think about
titlebars: When the pointer moves from C to F, it cannot be in any titlebar any
more, so we must generate a leave event on that titlebar. Similar when the
pointer moves from F to C, but in this case we also have to figure out which
titlebar now contains the pointer.
This patch makes the code handle these events with detail=Inferior correctly.
Closes https://github.com/awesomeWM/awesome/pull/461.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a global variable that tracks the drawable that is currently under the
mouse cursor. This new variable is then used so that we get consistent behavior
for enter/leave signals. Such signals are now also generated when a MotionNotify
event tells us that the pointer is now in a different titlebar.
Before this, it was possible that we did not generate a leave event on a
titlebar since the LeaveNotify contains the cursor position after the leave and
we did not manage to figure out which titlebar was left.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I have noticed that the HeidiSQL session manager window/dialog will be
moved down by the height of the top titlebar when selecting an entry
from the server list.
Closes https://github.com/awesomeWM/awesome/pull/385.
When you run a mousegrabber, the C code calls this callback when the pointer is
moved or when a button is pressed/released. However, the button state is totally
bogus on press/release events, always claiming that the button that was
pressed/released is the only button that is pressed (even for release events!).
This commit fixes up the code so that the button state after the press/release
event is passed to the mousegrabber callback function.
Fixes: #280
Signed-off-by: Uli Schlachter <psychon@znc.in>
This patch provides functions to get/set current keyboard layout.
Current implementation doesn't support any configuration of layout,
it's a merely a layout indicator and switcher, however layout
configuration can be set by tools like setxkbmap or by any third-party
tools.
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>
I never saw a single program that set a border on its own windows. However,
awesome commonly sets borders on its clients and the position of a client is the
part outside of the border. So when processing a position request from a client,
we also have to include this border and fix things up correspondingly.
However, the same isn't needed for the client size, because the size does not
include the borders, but just the titlebar plus the "real" client content.
Thanks to Daniel Hahler for providing a simple test case based on urxvt for
debugging this!
Signed-off-by: Uli Schlachter <psychon@znc.in>
When we get an event due to a previous GrabButtons call, we have to continue
normal event processing again, because the server froze the input device for us.
Without this, everything appears to freeze.
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>
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>
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>
Previously, awesome didn't move windows when they sent a ConfigureRequest (and
it also shrunk them by the size of titlebars, before it forgot to add these).
This commit adds proper gravity support to ConfigureRequest handling.
This was tested with test-gravity from metacity (in src/wm-tester).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit bd8158495e.
The idea was to track the current list of pressed and depressed mouse buttons,
because we get button events for more than 5 buttons, but can only query the
state of the first 5 buttons.
However, there are cases where we see button presses, but won't see the
corresponding release event. This is quite bad.
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>
To avoid some oddities, awesome sets the input focus lazily. Instead of
immediately sending everything to the X11 server, awesome just sets a flag "have
to update the focus later".
However, this can cause problems. As Stefan noticed, awesome can forget about
focus changes on FocusIn events when such an event comes in while we still have
a pending focus change.
The fix here is to send out the pending focus change before we record the fact
that another client now acquired the input focus.
Reported-By: Stefan Haller <haliner@googlemail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
The coordinates as used by X11 place (0, 0) at the top-left corner of the
window, including its border. However, this code wants the position relative to
the drawin's content, thus we also need to substract the border width.
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 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 a keyboard grab activate/deactives, the input focus jumps to the window
which does the grab. These FocusIn events sometimes managed to confuse awesome.
The symptom was that a newly mapped/started client didn't receive the input
focus:
- You press your key-combo to start a terminal. This activates a passive grab
and the input focus jumps to the root window
- The terminal opens and the "manage" rule does client.focus = c
- This doesn't set the focus yet, but instead causes
globalconf.focus.need_update = true and .client = new_terminal
- Before the focus is updated, the key combo is released and the focus jumps
back to the previously focused client
- The FocusIn with mode == Ungrab causes awesome to think that the previously
focused client got focused again and thus globalconf.client.focus gets re-set
to what it was before
- Finally the focus is refreshed and the previously focused client gets focused
The fix is simple: We don't need the FocusIn events which are generated when a
grab activates or deactivates, so we can just ignore them.
Thanks to Majic for reporting this to me.
Signed-off-by: Uli Schlachter <psychon@znc.in>
xcb_event_get_{request,error}_label() return NULL for non-core requests and
error codes. Obviously, that's not really helpful at all, so also print the
numeric information about what failed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Thanks to muni who managed to crash his WM with conky. When conky runs in its
own window, clicking on it will sometimes (depending on the conkyrc) use
XSendEvent() to forward the event to the WM.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Returning true from the callback just to signal keygrabber to continue grabbing
felt redundant (and silly :|).
This will break old code that relied on returning false to stop grabbing,
instead of calling keygrabber.stop.
And fix keygrabber docs.
Signed-off-by: Anurag Priyam <anurag08priyam@gmail.com>
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>
X11 only let's you query the state of mouse button 1 to 5. However, it can
generate ButtonPress and ButtonRelease events for up to 256 mouse buttons.
Instead of asking the server which buttons are pressed, we will now remember
the button state from those ButtonPress and ButtonRelease events. Currently
this let's us keep track of up to 32 mouse buttons.
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>
event_button_callback() pops the top element from the stack, but
event_emit_button() doesn't. This got was expecting both to pop the top from the
stack so Bad Things(tm) happen.
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>
These signals also contain the x and y coordinate of the event which the
capi.button()-based signals can't provide.
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>
This reverts commit 0682499895.
We have to handle all the UnmapNotifies due to ICCCM. The bug this was trying to
fix is now fixed by 9ab8cd4039 ("Set our event
mask on the root window later") instead.
We got XCB_EVENT_MASK_SUBSTRUCTURE_NOTIFY on the root window, but we also have
XCB_EVENT_MASK_STRUCTURE_NOTIFY on the individual client windows. Since we are
reparenting our windows, we can safely ignore all UnmapNotifies that we get
through the root window.
This fixes a bug if there were any windows already present before awesome
started. Those were obviously already mapped which means that ReparentWindow
would cause an UnmapNotify for them on the root window. This commit makes us
ignore that UnmapNotify and thus not throwing away the window immediately again.
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>
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>
ICCCM mandates that window managers have to trigger the conversion to withdrawn
state on the synthetic and the real unmap notify, no matter if any is missing.
Previously we couldn't do this, but thanks to the reparenting, we can now do
this properly.
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>
We no longer use libxcb-event, so we don't have to follow it's API any more.
This means the pointless arguments and return values can be removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Upstream removed most of the code from libxcb-event and there is no
event-related stuff left in this library. We now no longer use any of the parts
that were removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commits makes awesome remove systray windows from the save set when they
are unmapped. This happens for the same reason as with normal client windows.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This will store the widgets references that the wibox have inside their
environment table, and not in the global registry, avoiding memory leaks.
This should fix FS#771.
Signed-off-by: Julien Danjou <julien@danjou.info>
Second try:
Turns out I messed up with XCB_EVENT_SENT() and had a "!" too much. The old code
already tried to cope with this, but forgot to actually unmap the window which
it just set to withdrawn state.
This time I tested the patch *again* and now I found even less bugs than on my
last try.
P.S.: I suck.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
According to the Inter-Client Communication Conventions Manual, if you want to
switch your window to withdrawn state, you unmap it and send a synthetic
UnmapNotify to the root window.
This synthetic event fixes a race condition. When you map and unmap a window
quickly, the map will generate a MapRequest for the WM but won't actually map
the window. Thus, the unmap will be discarded (-> window not yet mapped) and the
window stays map once the WM handles the MapRequest
Before this patch, awesome just ignored the synthetic unmap notify which caused
the bug to appear again. With this patch it doesn't happen anymore.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
This changes wibox_t::mouse_over to a proper reference. That way one can't
remove that widget from underneath us which would lead to an unprotected lua error.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Wiboxes are lazily updated. This means that we could receive an expose event on
them between making them visible and actually painting their content.
Due to this we were copying undefined content to the wibox, because the pixmap
was only created just now, but it wasn't actually filled with anything yet.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
This avoid the problem we can had while modifying globalconf.keys in a
callback function from a key or button event. Now we push all matching
objects on the stack, and call each callback function. If something
modify globalconf.keys, we do not care.
Signed-off-by: Julien Danjou <julien@danjou.info>
This variable didn't really have any effect on anything. It was only ever
checked in a function that would never be called if this flag was false.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Uli Schlachter
Daniel Hahler
Peter Junos
Aleksey Fedotov
Anurag Priyam
Gregor Best
Arnaud Fontaine
Julien Danjou