This new test suit add a rather extensive coverage to the "legacy"
notification popups. A few minor bugs have been found and fixed
and we can rest assured that the new spec 1.2 support and extended
manipulation API wont regress existing configs.
Previously, it would create a new object. The leaves the old
`replaces_id` logic mostly intact for now to keep the full backward
compatibility. I don't think anybody would have noticed the changed, by
time and time again we had proof that some silent users have some
amazing and advanced code hidden somewhere. It could be cleaned later
when breaking compatibility isn't an issue.
When the mouse is over or a keyboard driven menu is open, avoid
unexpected expiration to mess with the current notifications.
This commit also improve the `suspended` behavior to correctly
emit some signals.
The current API is non-compliant with the 1.0 spec and cannot represent
the v1.2 spec at all. The pair of name and callback fails to represent
the explicit ordering and cannot support the icons cleanly.
Plus to support the keyboard navigation use case, the notification
action need to be able to get some sort of focus state. Having an
object makes this easy.
Today I learnt that _NET_WM_STATE_STICKY means something else than I
previously thought.
ICCCM and EWMH support virtual desktops that are larger than the actual
screen. The idea is that one can scroll through this virtual desktop,
which means that e.g. all windows move to the left, so one can see the
windows that are further to the right.
_NET_WM_STATE_STICKY indicates that a window is sticky. This means that
it does not scroll with the virtual desktop, but instead sticks to its
current position.
In AwesomeWM, we use a different definition. A sticky window is always
visible, even when it is not tagged with any of the currently selected
tags. This behaviour is indicated in EWMH with a special value of
_NET_WM_DESKTOP. This commit updates the code to actually set this
special value.
This fixes attaching tabs in Google Chrome when the "target window" is
sticky (in the AwesomeWM sense).
Fixes: https://github.com/awesomeWM/awesome/issues/2652
Signed-off-by: Uli Schlachter <psychon@znc.in>
The function selection() is now registered in the Lua global table from
selection.c instead of in luaa.c. This "feels cleaner" to me and is
preparatory for later changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
luaL_register() only exists in Lua 5.1 and was removed in never
versions. It has two completely different behaviours depending on
whether its second argument is NULL or not.
This commit splits that up by adding a wrapper for luaL_setfuncs()
(which does not exist in Lua 5.1) and using that everywhere instead of
our wrapper for luaL_register().
No behavioural changes are intended. This is simply meant as a cleanup.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In Lua 5.1, xpcall() has exactly two arguments: The function to call and
the error handler. Everywhere else, xpcall() passes extra arguments on
to the function to call. This includes LuaJIT, however since LuaJIT sets
_VERSION to "Lua 5.1", so far gears.protected_call used the workaround
for Lua 5.1 here.
This commit switches gears.protected_call to actually test for this
feature instead of just guessing based on _VERSION. Thus, this now also
uses the better code with LuaJIT.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a selection transfer is done, we are no longer interested in events
from the selection window. However, this happens after we set the
property to indicate end of transfer, not before.
The (untested) theory here is that this should make selection transfers
from AwesomeWM to AwesomeWM, i.e. internal transfers, work.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a "continue" signal on transfer objects. This signal is
used to request the next chunk of data from Lua after the last one was
sent.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Large amounts of data have to be send in chunks via the INCR protocol.
This commit adds support for that protocol to selection transfers.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes :send{ data={"TARGETS", "UTF8_STRING"}, format="atom"}
work correctly. This was tested with xclip -o -target TARGETS.
With this commit, it becomes possible to implement the TARGETS target.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the following work on a selection acquire object:
o:connect_signal("request", function(_, _, t)
t:send{ data = "Hello World!\n" }
end)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This now creates a selection transfer object and requests Lua to reply
to the request via this object. However, so far no answer is possible.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows to voluntarily give up ownership of a selection. Because
selection acquire objects cannot be garbage-collected before they are
released, this also gets rid of the function destroying the window when
its selection acquire object is destroyed. Instead, the window is
immediately destroyed when no longer needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Sorky
Uli Schlachter
Uli Schlachter
Daniel Hahler
mergify[bot]