In the case where one want to put the cursor at the middle of the
workarea, it is logic to do:
x=screen.workarea.x+screen.workasrea.width/2
However, this can cause floating points. This commit move the
burden back to the C-API so the Lua placement code doesn't have
to add a large number of rounding methods. Given 1 type of rounding
cover a vast majority of use cases for each types of coordinates,
the C-API can take care of it in peace. For the other corner cases,
it is still possible for the Lua code to do the rounding there, but
no longer necessary. The convenstions are:
'x' and 'y': use round (move to the closest point)
'width' and 'height': use ceil (to avoid involontary truncating)
This change catches things like c:geometry { width = -42 }.
Helps-a-bit-with: https://github.com/awesomeWM/awesome/pull/820 (fixes X errors)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Some words about X11 event handling: Every X11 client can select input on any
window. For this, inside the X11 server each window has for each client a
bitmask for the kind of events that this client is interested in. When a mouse
button is pressed inside of a window, a corresponding event is generated for
that window and sent to all X11 clients which asked for
XCB_EVENT_MASK_BUTTON_PRESS. When no client is interested in this event, the
event is propagated to the parent window and the same procedure is done again
here. This continues up until the root window is reached.
Some words about the event masks that awesome uses: For clients, we ask for
button press events on the frame window that we reparent the client window into
so that we get any kind of press on the titlebar (and also events inside of the
client window if the client itself doesn't care for click events?). We are also
interested in button presses / releases on the root window. However, before this
commit, we didn't actually ask for button events on drawins (e.g. the wibox).
This worked fine, because no one asked for these events and the event propagated
to the root window where it was then sent to awesome.
However, newer Qt versions do something weird and the above broke. I don't
actually know what is going on. I know about the above propagation rules, but
looking at protocol traces of what Qt does, awesome should still get the button
events. During startup, Qt asks for button events on its own windows. After a
hotplug event, it asks the same again, but now also includes the root window.
So... how can Qt asking for button events on the root window cause awesome not
to get them? I have no idea.
(And yes, I guess that Qt asking for mouse events on the root window is a bug,
but I have no idea how exactly this happens nor about any other side effects of
it).
This commit makes us ask for button events on our drawins so that the server
will send them to us. This is the right thing to do anyway and it was reported
to have some positive effects.
Ref: https://github.com/awesomeWM/awesome/issues/415
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only exception is the window for _NET_SUPPORTING_WM_CHECK. That window
already had a _NET_WM_NAME property before and doesn't get a WM_NAME property in
this commit. I just decided for myself that it doesn't need one. :-)
Right after startup with the default config we now have the following situation:
$ xwininfo -root -tree
xwininfo: Window id: 0x2d7 (the root window) (has no name)
Root window id: 0x2d7 (the root window) (has no name)
Parent window id: 0x0 (none)
7 children:
0x200011 "Awesome drawin": ("awesome" "awesome") 1500x20+0+0 +0+0
0x200010 "Awesome drawin": ("awesome" "awesome") 1x1+0+0 +0+0
0x20000d "Awesome drawin": ("awesome" "awesome") 100x30+0+0 +0+0
0x20000a "Awesome no input window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200009 "Awesome systray window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200008 "awesome": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200007 "Awesome WM_Sn selection owner window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
One of those drawin is the awful.wibox. Another drawin is created by awful.menu.
I guess that the third one is created by awful.tooltip, but I'm not sure. Wow,
so many windows...
Closes https://github.com/awesomeWM/awesome/pull/556.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes it possible to add something similar to a __index / __newindex
metamethod to all our C objects. Based on this, Lua can then easily implement
arbitrary properties on our capi objects.
This adds luaA_getopt_integer, luaA_optinteger and luaA_checkinteger.
Lua 5.2 does not have support for this, but it would be available in Lua
5.3.
Closes https://github.com/awesomeWM/awesome/pull/320.
This just pushed the drawin onto the stack L, but then tries to access it via
globalconf.L. This just calls for problems...
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>
This fixes the following code:
local d = drawin({})
d.visible = true
The drawin now has a cairo surface assigned
d.visible = false
d.width = 1234
d.visible = true
The width change while the drawin was not visible would not get propagated to
the drawable because of the code that this patch removes. The expectation was
that drawin_map() would update the drawable later.
However, because the drawin was already visible, its drawable also already has
a surface assigned. Thus, drawin_map() wouldn't update the drawable either.
Fix this by just removing this optimizations.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in drawin_moveresize() tries to be clever and only updates the drawing
state of the drawable when it is resized, not when it is moved around. This used
to be necessary because once upon a time, drawin_update_drawing() threw away all
of the drawing state and thus forcing a repaint. These days it just calls
drawable_set_geometry() as well and that function special-cases moves.
So this old code in drawin_moveresize() is no longer necessary and actually
caused problems.
These problems occurred because drawin_update_drawing() is being clever and
doesn't do anything for .visible = false drawins, because their drawing state
will be updated once they become visible. However, not skipping
drawable_set_geometry() means that this broke, because drawin_map() thought that
the drawing state was up to date while in reality it wasn't.
References: http://article.gmane.org/gmane.comp.window-managers.awesome/10852
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>
The only caller for drawin_unref_simplified() is in ARRAY_FUNCS() and here it is
only used in the implementation of drawin_array_wipe(). However, this function
is unused and thus we don't need drawin_unref_simplified() either.
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>
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>
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>
Before this commit, we always threw away the drawin's cairo surface whenever it
was made visible and thus forced a redraw.
This commit changes this so that we only force a redraw if the drawin was
resized why it wasn't visible. To remember when this happens, we free the
drawin's cairo surface without allocating a new one when the drawin is resized
while not being visible. Thus, we then only have to allocate a new surface if
the drawin doesn't have one when it is being made visible.
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>
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>
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>
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>
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>
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>
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>
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>
We were only creating an X11 window for a new drawin after we handled all the
options that were passed in. However, this means that drawin({ height = 4 })
would try to resize the window before we created a window, which caused an X11
error.
Fix this by moving our initialization before of the handling of construction
arguments.
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>
Open some windows, select a layout which does something (=not floating) and
restart awesome. It's likely that it will crash during the shutdown.
The reason is that awesome cleans up various state before going down. This is
mostly all the lua state. However, drawin_wipe, which is called for cleaning up
after a drawin, dared to emit a sigal which then let various lua code run which
had access to objects which were already destroyed.
Various bad things can happen this way, in this situation it was a crash when an
already-destroyed client was resized.
The fix is to move the signal out of drawin_wipe. It doesn't belong there
anyway. Instead, property::workarea should be emitted when the drawin's visible
property changes as this is when the workarea changes, too (screen_area_get()
only looks at visible drawins).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fixes a crash when the opacity of a not-visible drawin is changed. This
happened because we got a PropertyNotify for our own change of _NET_WM_OPACITY
and then tried to set the drawin's opacity to this new value.
However, the drawin was only reachable through globalconf.drawins and wasn't
ref'd in lua. This means that the luaA_object_push() call in
property_handle_net_wm_opacity() didn't find the drawin and instead pushed a
nil. This then later caused an unprotected lua error in window_set_opacity().
Signed-off-by: Uli Schlachter <psychon@znc.in>
There isn't much point in the screen property of a drawin because the geometry
already defines on which screen the drawin is.
The biggest chunk of changes from this is due to removing the functions
drawin_detach and drawin_attach which where called when the screen property was
set/unset.
The code from drawin_detach is moved into drawin_set_visible and drawin_wipe.
drawin_attach is moved into drawin_init.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Thanks to a recent commit, a drawin's window will always be a valid and existing
window. This means we can remove all the code which checks this before doing
something.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We don't need an up-to-date pixmap and cairo surface for a drawin which isn't
visible. Thus, only bring those up-to-date when the drawin is visible.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of creating/destroying a window whenever the drawin is attached/detached
from some screen, a window is now created when the drawin is created and it
isn't destroyed until the drawin is garbage collected.
Since we can now safely assume that a drawin always has a associated window,
this should make it possible to simplify some stuff.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Uli Schlachter
Daniel Hahler
Julian Wollrath
Tumin Alexander
Arvydas Sidorenko
Gregor Best