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>
Before this commit, do this:
c.maximize_hoizontal = true
c.maximize = true
c.maximize = false
assert(c.maximize_hoizontal)
Would not work because the states were not preserved individually.
This commit fixes that. Awesome wont be confused about it's own
state anymore.
This may seem pointless, but when it come to undoing these
maximizations, it was ambiguous.
Before 4.0, maximizing could only be done in 2 operations.
4.0 add an unified way, but kept doing 2 operations. The old
Lua EWMH code to serialize the 2 operations was dropped when
the codepath was simplified and replaced by a generic version
in awful.placement. However this version never implemented
combining multiple mementos into 1.
This commit unify the maximize C code, drop the ugly macro
template and actually fixes a couple more issues that were
caused because request::geometry was sent twice.
I explicitly did not add client_shape_input property since querying the
input shape of the client window seems useless to me.
Signed-off-by: Uli Schlachter <psychon@znc.in>
These warnings might help catching some problems in the future. These
could be asserts, but printing a warning is a lot nicer than dying.
Signed-off-by: Uli Schlachter <psychon@znc.in>
X11 does not allow to resize a window to size 0x0. Also, there are some
possibilities of integer overflows in our case. We tried to handle this
already, but there was a loop-hole: If the too-small-value is only
produced after applying size hints, then this was not caught.
Fix this by applying size hints before checking if the resulting size is
valid. However, this means some check needs to be duplicated to handle
the possibility of integer underflows while applying size hints.
Helps-with: https://github.com/awesomeWM/awesome/issues/1340
Signed-off-by: Uli Schlachter <psychon@znc.in>
We have many places where we are sending an XCB request and expect an
answer where the protocol guarantees that no error can occur and we are
sure to get an answer. However, for example if the X11 server crashes,
these places can still fail. This commit tries to handle failures at all
these places.
I went through the code and tried to add missing error checking (well,
NULL-pointer-checking) to all affected places.
In most cases these errors are just silently ignored. The exception is
in screen querying during startup. If, for example, querying RandR info
fails, we will fall back to Xinerama or zaphod mode. This is serious
enough that it warrants a warning. In most cases, we should exit shortly
afterwards anyway, because, as explained above, these requests should
only fail when our connection to the X11 server breaks.
References: https://github.com/awesomeWM/awesome/issues/1205#issuecomment-265869874
Signed-off-by: Uli Schlachter <psychon@znc.in>
Similarly to what we do with the client list, this signal is emitted
whenever the list of screens changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in luaA_client_swap() is incorrect, because
luaA_object_emit_signal() already pops the arguments to the signal.
Still, the code here tried to remove the arguments from the Lua stack
again, thereby corrupting the stack (removing more items than there are
in the stack).
Normally, popping more things from the stack than it has entries
silently corrupts the Lua stack. Apparently this doesn't necessarily
cause any immediate issues, because this code has been broken since nine
months and no one noticed. This mistakes was introduced in commit
55190646.
This issue was only noticed by accident. Thus, this commit also adds a
small integration test that exercises this bug. This test catches the
issue, but only on Travis, because there we are building our own version
of Lua 5.3 and that one has assertions enabled.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It does not provide much value. The version number is already known to
ldoc globally in the "description" variable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel sees a short flicker of his wallpaper when he closes a client.
This happens because the window is destroyed immediately, but other
clients are re-arranged only shortly later. In the mean time, the X
server updates the display and repaints the root window (= wallpaper
becomes visible).
Work around this by delaying the destruction of frame windows to the end
of the current main loop iteration. This means that we first update the
position of all other windows and later destroy the window that was
actually closed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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".
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 commit makes the function only call client_ignore_enterleave_events() when
it actually has to. Since we expect that most of the time, no client's geometry
is changed, this means that most of the time this function is not called.
Fixes: https://github.com/awesomeWM/awesome/issues/1107
Signed-off-by: Uli Schlachter <psychon@znc.in>
This should "protect" the user from some stupidities that Lua code might be
doing that e.g. makes a client jump to another position and then immediately
back to where it was before. Only the last change in a single main loop
iteration will actually have any effect.
Original idea by Daniel here: https://github.com/awesomeWM/awesome/pull/174
Signed-off-by: Uli Schlachter <psychon@znc.in>
NET_CURRENT_DESKTOP is now being set to the index of the tag with currently focused client.
In case of no focused clients present, first selected tag index is taken, with fallback value being 0.
Current desktop is updated on next client signals: focus, unfocus, tagged, untagged.
Current desktop is also updated on tag property::selected signal.
This should fix drag and drop issues with chrome-based applications on multihead setups
A client c could have no c.machine or no c.pid because the corresponding
properties are not set on its window. Previously, the C code would return an
empty string or 0 for these values. This commit makes the C code give Lua no
value instead (not even a nil).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Why:
* Two different (but related) concepts had the same name
* Users were confused for years on IRC
* The wibar name was already in use in some doc to avoid confusion
Commit 7dad0b3b87 made awesome only ask for mouse events on the actual
client window. Obviously, this means that we no longer get reports for clicks on
the titlebar. Whoops.
Fix this by asking for mouse events on *both* the actual client window and the
frame window. The passive grab on the actual client window is actually unneeded,
but we keep it so that the fix that was done by the above commit is still
present (xev will no longer report leave/enter events just for a mouse click).
Since we now get mouse events inside of a client reported twice, the event
handling code in event.c has to be fixed to handle both cases. E.g. x/y are
relative to the top-left corner of the window and thus needs to be fixed for
titlebar size; the second click has to be ignored.
Signed-off-by: Uli Schlachter <psychon@znc.in>
EWMH specifies that
If _NET_WM_WINDOW_TYPE is not set, then managed windows with WM_TRANSIENT_FOR
set MUST be taken as [_NET_WM_WINDOW_TYPE_DIALOG].
We implement this by forcing a window's type to be "dialog" when it has a
WM_TRANSIENT_FOR property. For windows that have a _NET_WM_WINDOW_TYPE property,
this type change is then later undone. However, when a window changes its
WM_TRANSIENT_FOR property during runtime, then we would set its type to "dialog"
unconditionally.
This commit fixes this by explicitly tracking if we found a _NET_WM_WINDOW_TYPE
property on the window and only applying the fallback if we did not find such a
property.
Fixes-one-of-the-sub-issues-from: https://github.com/awesomeWM/awesome/issues/889
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 8a6787bd54 added screen.fake_add(). Commit 08845c7a4b made us cache a
screen's workarea in the struct screen_t. This new member needs to be
initialized to the screen's geometry when a new screen is added. Since both
these commits were developed concurrently, the workarea was not initialized in
screen.fake_add().
Fix this by calling in fake_add() the helper function added in 08845c7a4b.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit 102063dbbd, awesome is a reparenting WM. That means that we put our
own frame windows around child windows. This means that we have the option of
grabbing input events on the frame window or the child window. This commit chose
the frame window for this.
For keyboard events, this decision was already reverted in 532ec0cd90. This
commit does the same thing for mouse events.
This fixes the spurious leave/enter events that were visible on mouse clicks.
They occurred because the click activated a passive grab (all mouse events now
"belonged" to awesome). This passive grab caused the X server to inform clients
that they "lost" the mouse pointer (with the detail field set to "a grab
activated").
Fixes: https://github.com/awesomeWM/awesome/issues/427
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of computing the workarea whenever some Lua code asks for it, it is now
remembered explicitly as a property on a screen. This allows us to only emit
property::workarea if the workarea actually changed.
Fixes: https://github.com/awesomeWM/awesome/issues/756
Signed-off-by: Uli Schlachter <psychon@znc.in>
Apparently the spec allows to set the _NET_STARTUP_ID value on the property that
WM_CLIENT_LEADER points to instead of the window itself. Thus, if we don't find
a _NET_STARTUP_ID on the window itself, check again on the client leader window.
Apparently GTK even does this (for whatever reason...)...
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a screen is removed, we have to update screen.primary (if it was the
removed screen) and assign a different screen to all clients which were on the
removed screen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A client cannot be used any more after it was unmanaged. Similarly, Lua
shouldn't be allowed to e.g. assign a client to a screen that was removed. This
commit adds such a checker which "breaks" all screens which are not in the
global screen list.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a "removed" signal to screens. Together with the "added" signal
that we have since a while, this allows the C code to update the list of
available screens dynamically without needing to restart.
So far, this code received only minimal testing. So far, I don't have a nice
idea on how to easily test this...
Closes: https://github.com/awesomeWM/awesome/issues/672
Signed-off-by: Uli Schlachter <psychon@znc.in>
We once had the problem that with the nvidia blob, the X11 server told us that
"yes, I do support RandR; there is just a single big screen" even though there
were multiple screens and they could be queried for via Xinerama. To work around
this, we started to ignore RandR if it only provided information about a single
screen.
Our long-term goal is to stop restarting on RandR screen changes. Thus, even if
only a single screen is defined during startup, we should still use RandR later
when another screen is added. This means that we cannot just ignore RandR if it
only mentions a single screen.
This commit copies what GTK+ does: If there is an output named "default", then
some compatibility layer is assumed and we ignore RandR.
I have no way to test if this really does the right thing.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of adding all screens directly to globalconf.screens, the individual
"scanner functions" now get a screen_array_t as their argument and add the
screens there. Also, they no longer emit the "added" signal themselves (through
screen_add()), but the caller does now does this instead once all screens are
found.
This commit drops the "deduplication" of screens. This likely means that clone
mode causes duplicate screens. This will have to be re-added later.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Remove request::fullscreen and request::maximized_* and use
a single request for them. The other client resizing features
will soon also start to use this.
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>
Commit c543f59696 introduced the following warnings:
objects/screen.c:307:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
objects/screen.c:307:1: warning: no previous prototype for ‘screen_scan_randr_monitors’ [-Wmissing-prototypes]
Signed-off-by: Uli Schlachter <psychon@znc.in>
XRandR 1.5 adds support for the new monitor objects.
'Monitor' is a rectangular subset of the screen which represents a
coherent collection of pixels presented to the user. Each Monitor is be
associated with a list of outputs (which may be empty).
The patch below matches 1:1 screens in AwesomeWM with XRandR's Monitors.
This way I get one screen across my 4K monitor, which is represented by
two CRTCs.
Background info: http://keithp.com/blogs/MST-monitors/
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Uli Schlachter
Emmanuel Lepage Vallee
mergify[bot]
Daniel Hahler
mergify-bot
Uli Schlachter
Sergey Vlasov
Kevin Zander
Daniel Hahler
Jagannathan Tiruvallur Eachambadi
Luke Bonham
sudo-nice
Holger Schurig
SammysHP
Vitja Makarov
Ingo Bürk
blueusername
Mikhail Schemelev
Kirill A. Shutemov