This will be useful to address the screens by roles/names in the client
and tag rules. Since the sceen rules will make setups where sceens are
attached and removed much easier to work with, using indexes or output
names in the rules becomes a limitation.
When the screens are created from the viewport in Lua, the signal is
sent too early and the DPI and outputs have not yet been added. This
cause the `connect_for_each_screen` callbacks to be called with a
partially initialized screen object. It also causes the drawables to be
repainted too early.
CAPI now emits "_added" and "awful.screen" takes care of emitting
"added".
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>
The getters for properties already get the object as their second
argument, so there is no need to get the object again from Lua.
Fixes: https://github.com/awesomeWM/awesome/issues/2299
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a new client appears, we reparent its window into a window of our
choice so that we can add decorations. However, windows can be difficult
making the reparenting fail. For example, some snapshots of GTK+ set a
parent-relative background, which means that its parent windows have to
have the same depth as the window itself. This makes reparenting fail if
transparency is used/supported.
Make the failure mode... different, by checking if reparenting
succeeded. If it failed, we print an error message and unmanage the
window immediately. This means that those GTK+ windows just do not
appear at all, instead of behaving weirdly.
This idea of this patch came from i3.
Related-to: https://github.com/awesomeWM/awesome/issues/2279
Signed-off-by: Uli Schlachter <psychon@znc.in>
The systray_cleanup() function gives up the _NET_SYSTEM_TRAY_Sn
selection ownership and should be called only when Awesome exits.
Calling systray_cleanup() from drawin_systray_kickout() is not correct,
because drawin_systray_kickout() is called when the system tray window
needs to be hidden, including the case when the last tray icon was
removed and the tray became empty.
Fixes: https://github.com/awesomeWM/awesome/issues/2301
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
* Make fake screens permanent
Before this, screen_scan() made sure that awesome's information about
available screens conforms to what the X11 server reports. Since fake
screens are, well, fake, this meant that they were deleted.
This commit marks fake screen and handles them specially in
screen_scan() so that they are not deleted.
Note that I did not test this commit at all since I still haven't
figured out how to test RandR stuff without actually messing with
hardware.
Thanks to @madduck for bringing this up and making me fix this long
standing "huh? is that really supposed to work like that?".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Up to now, we always asked the X11 server for color allocation ("which
pixel value corresponds to (r,g,b)?", an AllocCollor request).
This commit adds direct support for TrueColor and DirectColor visuals.
In such a visual, the X11 server gives tells us where the red, green,
and blue color components are in a pixel value and we can then just
directly compute the pixel value.
Additionally, this commit adds code that assumes that in a depth=32
visual, the remaining values (after handling red, green, blue) is the
alpha channel for colors. Thus, this adds support for transparent client
borders.
This commit also touches code for the systray. However, the systray must
always use the X11 server's default visual and that one always(?) has
depth=24, i.e. does not support an alpha channel. Thus, the systray
background still cannot be transparent.
Also, in theory this commit should support visuals where some color
component does not have 8 bits, for example RGB565. However, this is
just theoretic and I have no idea how to actually test this (without
jumping through too many hoops).
Fixes: https://github.com/awesomeWM/awesome/issues/162
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a screen is in the process of being removed, it is still valid, but
no longer in the global list of screens (globalconf.screens). In this
time frame, trying to swap screens could cause a NULL pointer
dereference.
Fix this by throwing a Lua error in this case instead.
Fixes: https://github.com/awesomeWM/awesome/issues/2110
Signed-off-by: Uli Schlachter <psychon@znc.in>
_NET_WM_STATE could contain _NET_WM_STATE_HIDDEN, which we interpret as
minimized. Minimized clients have WM_STATE set to WM_STATE_ICONIC, but
the code in client_manage() would later overwrite this to
WM_STATE_NORMAL.
Fix this by setting the initial WM_STATE_NORMAL by doing so before
processing _NET_WM_STATE.
Fixes: https://github.com/awesomeWM/awesome/issues/2095
Signed-off-by: Uli Schlachter <psychon@znc.in>
The screen object can be indexed by strings to find a screen via some
RANDR output name. However, if a string is used which does not
correspond to a known output, the code just falls through to a function
which will complain "string provided, userdata expected".
This commit provides a slightly more useful error message instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function tried to move the client to its new screen based on
shifting around its current geometry. However, it assumed that the
client was actually visible on its current screen, which is not always
the case.
Fix this by just forcing the client into its new screen if our moving
approach does not work.
This also reverts commit d5e365804c which
is no longer necessary. This commit only hid the issue (partly).
Fixes: https://github.com/awesomeWM/awesome/issues/318
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code here made sure that clients were not moved outside of the root
window. However, that's not enough, because clients can still end up
inside the root window, but outside of anything that is visible in some
output. Thus, just remove this.
Related-to: https://github.com/awesomeWM/awesome/issues/318
Signed-off-by: Uli Schlachter <psychon@znc.in>
Aborting the process is sometimes a bit harsh for a failed assertion.
This adds a non-fatal assert() macro called "check()" and uses it in
some places where we might be able to survive the error.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We were only using this for tag names. This means we are assuming that
everything is UTF8, but tag names are provided in the local locale and
need to be translated into UTF8? That makes no sense, so just drop this.
Fixes: https://github.com/awesomeWM/awesome/issues/1753
Signed-off-by: Uli Schlachter <psychon@znc.in>
Every call to client_ignore_enterleave_events() must be paired with a
following call to client_restore_enterleave_events(). In between these
two calls, no other calls to client_ignore_enterleave_events() is
allowed.
The code in banning_refresh() sometimes broke these rules. This can
happen because the code causes signals to be emitted and Lua code can do
basically anything.
Fix this by moving the calls into the called functions.
Fixes: https://github.com/awesomeWM/awesome/issues/1746
Signed-off-by: Uli Schlachter <psychon@znc.in>
I failed to see the obvious. Thanks to mlen from IRC to make
me look into i3's source code so that I can figure out the obvious.
First, what is the problem? We want to be informed about mouse clicks on
client windows, e.g. for client-to-focus. For this we have to grab mouse
buttons on the client window, since only a single client at a time can
ask for information about all mouse clicks (I think...) and that right
is reserved for the actual application and not the WM.
We also want to be informed about mouse clicks on the titlebar, so that
clicking there actually does something (and also e.g. click-to-focus).
Obviously, we can just grab mouse buttons on the titlebar as well.
However, this causes lots of problems. The X11 window containing the
titlebar is not just the size of the titlebar, but also includes all of
the actual client window. This means that clicking into the client also
activates our button grab on the titlebar. This, in turn, causes the
input focus to briefly shift to the window for the titlebar. This shift
of focus can be detected by clients and caused various issues.
This fix is so obvious that I missed it. We don't have to grab buttons
on the titlebar window. We can just use the "normal" event propagation
without grabs there, i.e. we just include the event masks for button
press and button release and get informed about all mouse events. In
fact, we already have this event mask in place, so the whole use of
grabs is redundant.
That's what this commit does. It also partially reverts commit
394ff06589 which is where this unnecessary grabbing was introduced.
Fixes: https://github.com/awesomeWM/awesome/issues/1479
Fixes: https://github.com/awesomeWM/awesome/issues/1658
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit changes the systray widget, wibox.drawable and the C code to
fix the following bug: When the systray widget is removed from a
drawable without being moved somewhere else, the systray stayed visible.
This was because the systray is not drawn by awesome, but only placed.
When the widget is no longer "drawn", it stays wherever it was placed
last.
This change works by detecting the situation when the systray is
removed. Then, the C code is specifically told to remove the systray
window from the drawable.
Note that this is only a partial fix. This change works correctly when
the widget is removed completely, because it is no longer placed by its
parent widget. However, for example, when you do
wibox.widget.systray().visible = false, the effect is just that the
systray widget gets size 0x0. This is not really visible, but as far as
this change is concerned, the widget is still part of the drawable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds c.icon_sizes which is a table containing the width and height
of each available icon. With c:get_icon(i), Lua can query the i-th icon
as a lightuserdata.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Clients can provide various icons in their _NET_WM_ICON property. Up to
now we only saved a single one, now we save all of them.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Without RandR telling us what the primary screen is, we just pick the
first one. However, the code here did not emit the right signal.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Aire-One
Uli Schlachter
mergify[bot]
Uli Schlachter
Daniel Hahler
mergify-bot
Sergey Vlasov
Kevin Zander
Daniel Hahler
Jagannathan Tiruvallur Eachambadi
Luke Bonham