Matrix operations are hard. Apparently I always keep confusing the order
that transformations are applied in the matrix resulting from a matrix
multiplication.
This commit fixes things in wibox.hierarchy that were wrong due to the
wrong order and changes a unit test so that it would now catch the
breakage (and makes sure that it does not happen again).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of matrix_to_device and matrix_to_parent, this now provides the
full hierarchy instance managing the current widget.
In addition to x, y, width and height (which are an over-approximation
of the widget's extents on the drawable), this now also provides
widget_width and widget_height in the widget's local coordinate system.
These last two values are exact.
For example, the tooltip needs x/y/width/height while a widget that
wants to figure out which point on it was hit with a mouse press will
need widget_width and widget_height (together with the position argument
that is passed in with mouse::press).
I don't know how to document the return type of this function properly.
Hopefully just describing the structure of the resulting table is good
enough.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, this mentioned non-existent arguments (widget) and
duplicated parts of the (not yet really existing) API documentation for
find_widgets().
Signed-off-by: Uli Schlachter <psychon@znc.in>
Just because they sound similar to mouse::press and mouse::release does
not mean that the arguments are the same. Perhaps they should be, but
that's another story.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For a while, it was often suggested on IRC to replace the default
request::activate handler to implement custom focus stealing policies.
While it is working, it isn't user friendly. This commit add a simple
mechanism to add such policies.
This adds a tparam alias "@screen" for "@tparam screen" (when used to
document e.g. arguments for callbacks), and "@screen_or_idx" when a
function accepts a "screen" or "number".
The default config had tables like mywibox and mywibox[s] was the wibox
that is visible on screen s. When a screen is removed, nothing cleans up
these tables and so the screen and the wibox could not be garbage
collected. The same applies to the layoutbox, taglist etc.
This commit removes the global mywibox table and instead saves it as a
property on the screen. This way, the screen is not explicitly
referenced and when it is removed, the screen, its wibox and all of its
widgets become unreachable and can be garbage collected.
This commit also updates the docs and the tests that referenced things
(mostly the wibox) via mywibox[s] to now use s.mywibox.
Fixes: https://github.com/awesomeWM/awesome/issues/1125
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, gears.object.properties used a weak table for adding
additional information to a C object. However, weak tables can easily
cause leaks when the value references the key.
This commit makes the code instead use the new .data property that is
available on all C objects. This means we have no more magic with a weak
table and instead only use "regular" tables instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This table is "just a normal Lua table". Lua code can use it in whatever
way it wants to store things related to a given C object.
An object (userdata) already references a "plain Lua table" via
lua_setuservalue() / lua_setfenv(). This is used to keep a reference to
signal functions that are connected to an object. The signal code only
uses lightuserdata keys in this table. This commit adds an entry with
key "data" to this table which just references another table. This is
the table that is made available as .data.
Via this .data property, Lua code can add own properties to C objects
without having to use, for example, weak tables. The weak tables have
the downside that they produce a leak if the value references the key.
The new .data property does not have any such problem (no weak
references are involved).
This new data property is not documented, because I'd have to touch lots
of files and I'm lazy.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The new client is hopefully faster. Why, you ask?
Instead of spawning a new Lua process each time a test asks for a new window,
there is a "daemon process" which gets commands to open new windows from its
standard input. That way, Lua doesn't have to load LGI all the time and lots of
pointless work is skipped. The daemon process exits when its stdin is closed and
thus should automatically exit when awesome exits.
Fixes: https://github.com/awesomeWM/awesome/issues/1089
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are some situations where we do things that can make the mouse pointer
enter another window. We do not want to react to these "self inflicted" mouse
enter and leave events, because they aren't "real" (= generated by the user).
Before this commit, this is done by going through all windows and toggling the
"please send us enter and leave events"-bit on them. This becomes slower when
many windows are visible and floods the server with requests.
This commit changes this to a constant-time logic. Each event contains the
sequence number of the last request that the X11 server handled. Thus, we just
remember the right sequence numbers and ignore any events that comes in whose
sequence number falls into the ignored range.
In detail, we keep a list of "begin" and "end" sequence numbers and ignore any
enter and leave events that fall in this range. If we get any event with a
sequence number higher than "end", we remove this pair from the list, since it
is no longer needed.
To generate these pairs, we use a GrabServer request in
client_ignore_enterleave_events(). This gives us a sequence number and makes
sure that nothing else besides us can cause events. The server is ours! In
client_restore_enterleave_events(), we first do a NoOperation request to
generate the sequence number for the end of the pair and then do UngrabServer.
Any event that is generated after UngrabServer will have at least the sequence
number of the UngrabServer request and thus no longer fails between begin and
end.
Fixes: https://github.com/awesomeWM/awesome/issues/1107
Signed-off-by: Uli Schlachter <psychon@znc.in>
drawin_apply_moveresize() calls client_ignore_enterleave_events() internally,
because it also wants these to be ignored. This means that the code disables
enter/leave events twice and then enables them twice. This recursive disabling
is something that should not occur.
Fix this by having drawin_map() disable the events a bit later.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This test changes the mouse cursor's position and afterwards has an
assert that checks something on the tooltip. This really looks a lot
like it expects the mouse cursor's position to be already updated and
its enter and leave events to be handled. However, this is now how
things actually work.
Fix this by moving the assert into its own step, so that in between the
normal main loop runs.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I don't know why we force CMAKE_BUILD_TYPE to be RELEASE, but I don't think we
should do that.
This also changes the default build type to something which does not contain
-DNDEBUG in CFLAGS. This means that assert()s will start to work.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This restore a feature that was available in Awesome 2.1-3.2.
The reason margin is implemented rather than use a container is to
be able to make the background smaller than the bar.
The current progressbar code dates from a time when Awesome had
a very limited drawing API. This commit first re-write the
algorithm to remove the workaround used to draw the border using
full rectangles only. It then add support for outer and inner
shapes with their respective border settings.
This commit also add clip support. This is enabled by default, but
could be disabled to have the bar taller than the background.
Uli Schlachter
Daniel Hahler
Emmanuel Lepage Vallée
Daniel Hahler