With this commit, the C code stores if the screen was created with
`fake_screen` and also stores if the Lua side "promise" to manage
(aka, track the viewport and remove it) the object. There is now
3 kind of screens:
* Managed by C (created and deleted by the core code)
* Managed by Lua (replicate the core code, but with more hooks)
* Unmanaged (created directly with fake_screen)
It moves the actual place where when screen array is stored into the
area object. This allows to store the outputs when screens are not
automatically created.
This commit add an optional `--screen off` command to initialize Lua
without first adding the screens. This is inconvinient for most users
since it restrict the APIs that are usable out of the box.
However, this allows AwesomeWM to work independently from the hardware.
This means that when a screen is unplugged, it is the Lua code that will
remove the screen instead of CAPI pulling the carpet from under. It also
allows to ignore some screen areas before the screen is ever created.
Combined, it makes it possible to work with screens even when they are
physically disconnected. Finally, it will allow for an awful.rules like
API to control how screens are created.
All in all, some people need this for their setup and some people might
want to do it anyway for fine grained and/or dynamaic multi-screen
setups.
This commit also adds 4 new signals to `capi` to be able to
execute code at specific points during the initialization. The commit
improves naughty error notifications to work even if problems occurs
before the screens are added.
Note that AwesomeWM will exit if no screens are created. While it would
be easy to just call `refresh_screen();` after unsetting the magic
variable, doing so would have corner cases. Better be harsher and
prevent the user from shooting themselves in the foot from not reading
the f****** manual. Code introduced in future commits will take care
of automatically calling fake_screen in the event nothing is created.
Fixes#1382
This way their name doesn't get mangle by the broken magic. It will also
eventually allow to `error()` in the template when the implicit
`@function` is used.
This commit also fixes a large number of issues found while
proof-reading everything.
ldoc has a magical `@classmod` module type which tries to detect
what is a method and what is a static function. It fails about as
often as it works. This commit makes everything explicit to remove
such issues.
Fixes#2640
Ref #1373
Between xcb_grab_server() and xcb_ungrab_server(), XCB's output buffer
might fill up. Thus, the GrabServer request might already have been sent
to the server, but the following UngrabServer request could end up in
XCB's output buffer. There, it might sit around for quite a while and
cause problems.
Since we cannot detect when XCB's output buffer fills up, we just always
flush after generating an UngrabServer request.
Very-likely-Fixes: https://github.com/awesomeWM/awesome/issues/2697
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of refreshing screens at the end of the current main loop
iteration, this now uses a GLib idle source with a very low priority.
This increases the chance of batching multiple refreshes together. Also,
this means that awesome_refresh() does less work.
Signed-off-by: Uli Schlachter <psychon@znc.in>
As requested in the review, instead of just having a single string
argument, selection_acquire() now has a table as its argument. It
searches the string under the "selection" key here.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
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>
The list of supported formats of the selection is queried by requesting
the target TARGETS. This target is a list of ATOMs and needs special
handling which is what this commit adds.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Incremental transfers are required to be supported. This commit adds
that necessary support to awesomeWM.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds support for simple selection transfers. INCR support is
still missing. The API is that a selection getter object emit the "data"
signal when some data becomes available and "data_end" when all data was
received.
Signed-off-by: Uli Schlachter <psychon@znc.in>
So far they do not do match. The selection and target are specified and
a window is created for a transfer, but no transfer is actually started
yet.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the selection that is watched by an active selection watcher
changes, then the signal "selection_changed" is emitted on the watcher.
This signal has one boolean argument that indicates if the selection is
owned. This means that this argument is false when the selection owner
went away and the selection now has no owner at all.
Signed-off-by: Uli Schlachter <psychon@znc.in>
These objects are created via e.g. selection_watcher("CLIPBOARD") to
track the CLIPBOARD selection. They start watching when their .active
property is set to true and stop when this property is unset again.
This commit implements the Lua side of that: A list of active watchers
is kept and updated when needed.
The next commit will add the X11-side of this so that these objects
actually do something.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds the necessary method calls to setup the class and also
so that xfixes selection notify events can be handled. Currently, these
are empty functions, but later commits will fill them.
Signed-off-by: Uli Schlachter <psychon@znc.in>
No idea what "If the client has multiple classes" is supposed to refer
to, but this commit gets rid of that reference. Also, this commit
clarifies how to get the class and instance out of xprop.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Until now there wasn't much documentation available about how to use
these properties. With the new work on `awful.spawn` that rely more and
more on `awful.rules` integration, it is worth fixing.
This commit add a new documentation section and a future commit will
aggregate them to generate an index.
Previously, this function overwrote the value of its argument with the
result. After this change, the function merely changes the given
variable by the calculated argument.
Thus, the old behaviour is achieved by setting the variable to zero
before the call, which all callers already did. However, for most
callers this change means that a temporary variable can be removed and
instead xwindow_translate_for_gravity() will directly change the target
variable.
No change in behaviour intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are two ways in which the input focus can change: Lua can request
a change and the X11 server can inform us that the input focus changed
(because some application changed it).
In the first case, we still have to inform the X11 server about the
desired change, in the second case we must not to avoid races due to
X11's asynchronous nature.
However, there was a case where we screwed up: When a focus change is
still pending, meaning that Lua assigned the focus elsewhere, but we
have not yet sent this focus change to the X11 server, we could get an
event from the X11 server telling us that the focus changed. To make
sure that the pending focus change is not lost, we sent the focus change
out in this case (call to client_focus_refresh() in
event_handle_focusin()). After sending out this pending call, we updated
the internal state to record that whatever the X11 server just told us
had the focus. The intention was that our just sent-out focus change
will cause the X11 server to send a new event and our to-be-focused
client then has the focus.
However, if the pending focus change was for a client which only showed
up in this event loop iteration, the client was still banned. This means
that client_focus_refresh() would call client_unban() to be able to give
the focus to this client. However, since awesome (partly) allows to
"focus" currently banned clients, client_unban() recorded that there is
a pending focus change. This caused confusion later on.
In this specific bug, a main window opened a dialog, and when this
dialog was closed, a new dialog window was opened immediately. When the
first dialog was closed, Lua (the focus history) gave the input focus to
the main window. Now, a new dialog showed up and Lua focused it. Next,
we received the event from the X11 server telling us that the main
window was focused. Because there was still a pending focus change to
the new dialog window, event_handle_focusin() called
client_focus_refresh() to send out this focus change. This set
globalconf.focus.need_update to false and continued. However, because
the new dialog only just now appeared, it was still banned, meaning that
client_focus_refresh() had to call client_unban(). This set
globalconf.focus.need_update to true. Thus, when client_focus_refresh()
returned, globalconf.focus.need_update was incorrectly true. Next,
event_handle_focusin() recorded that the main window had the focus.
Thus, it now appeared as if there was a pending focus change for the
main window. Next, we got the event from the X11 server telling us that
the dialog is now focused, and because focus.need_update was set,
awesome now send out a focus change request for the main window.
Fix this race by unsetting globalconf.focus.need_update at the end of
client_focus_refresh() and not at the beginning, thus making sure that
client_unban() cannot set this flag again.
Fixes: https://github.com/awesomeWM/awesome/issues/2220
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a window has a WM_TRANSIENT_FOR property that is later unset,
awesome would still keep c.transient_for pointing to the previous
"parent client". This commit fixes that.
First, property_update_wm_transient_for() is fixed so that it unsets
c->transient_for_window if the WM_TRANSIENT_FOR property is deleted.
Additionally, this then calls client_find_transient_for() to update the
c->transient_for pointer.
Secondly (and a bit unrelated), this changes client_find_transient_for()
so that it always sets c->transient_for. Previously, if updating this
property would introduce a cycle in the transient_for relation, it would
just leave c->transient_for with its old value. After this change, it
gets explicitly set to NULL instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes motif wm hints available on clients as c.motif_wm_hints.
Actually interpreting all the values is up to Lua. The definition of the
necessary properties is taken from motif.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Uli Schlachter
mergify[bot]
Uli Schlachter