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>
This commit makes all C code that previously returned a screen index now return
a screen object, continuing the deprecation of screen indicies. Note that this
is an API break and will likely cause all kinds of problems for users.
The change also breaks some tests which are suitably fixed in this commit.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of focusing the root window, we now create a "focus window" inside of
our frame window. This window is placed so that it is not visible, but we can
grab key bindings on it to simulate the window having the input focus.
Fixes: https://github.com/awesomeWM/awesome/issues/699
Signed-off-by: Uli Schlachter <psychon@znc.in>
Right now this just always returns the first screens, but this can easily be
implemented properly later.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Even when a screen is just an integer, the code becomes a bit more
self-documenting. Even better, if we start to handle screen objects to Lua
instead of screen indicies, there will only be one place that needs to be
changed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When we manage the transient before the main window, the client object's
.transient_for property would stay nil. This happens because the property points
to a window which we don't know (yet) and thus is ignored.
Fix this by remembering the value of WM_TRANSIENT_FOR and checking in
client_manage() if the new client is the "missing window we did not find
before".
Fixes: https://github.com/awesomeWM/awesome/issues/181
Signed-off-by: Uli Schlachter <psychon@znc.in>
This creates a new helper function for setting the transient_for property of a
client. This is a preparation for a following commit. No behaviour changes
intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
To quote from ICCCM (§4.1.2): "The window manager will not change properties
written by the client."
We tried to do this anyway to update WM_HINTS so that the current urgency state
is reflected. Apparently, Chrome does a similar read-modify-set cycle and the
resulting race condition meant that the "accepts input" hint on Chromium's
window was permanently disabled.
This helps with https://github.com/awesomeWM/awesome/issues/670, but I still
think that Chrome shouldn't try to implement "please don't focus me when I do
the following" by temporarily claiming "please don't ever focus me".
Signed-off-by: Uli Schlachter <psychon@znc.in>
E.g. trying to press mouse button 1.5 via root.fake_input() doesn't make sense.
Previously the code silently truncated the number to an integer. Now it
complains about this instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only remaining calls are for a window's opacity and in the DBus type
handling. Everything else wants integers, not something with a comma.
Signed-off-by: Uli Schlachter <psychon@znc.in>
ICCCM specifies when the WM has to send a ConfigureNotify. Java does not care
and wants one all the time. Meh.
Fixes: #248
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allow layout "arrange" to be called less often and react on
the cause of the change itself rather than it's consequences
(usually, the "focus" signal).
Previously, the layout were re-arranged everytime the focus changed.
Now, with "raised" and "lowered", it require less "arrange".
"swapped" allow smarted layouts. Currently, swapped cause a full
re-arrange. It re-read the "index" list from scratch and create
a "new" layout. With "swapped", incremental layout changes are
possible.
Fixes https://github.com/awesomeWM/awesome/issues/616
When a client is unmanaged, we know emit mouse::leave on its titlebar before the
client object is invalidated, so that Lua can still work with it. Before, this
event was emitted only when we got a LeaveNotify from the X11 server.
Fixes: #620
Signed-off-by: Uli Schlachter <psychon@znc.in>
luaA_warn() prints a Lua backtrace and thus generates more useful output. warn()
should only be used in awesome-internal places (e.g. receiving an error from the
X11 server).
Closes https://github.com/awesomeWM/awesome/pull/608.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Some words about X11 event handling: Every X11 client can select input on any
window. For this, inside the X11 server each window has for each client a
bitmask for the kind of events that this client is interested in. When a mouse
button is pressed inside of a window, a corresponding event is generated for
that window and sent to all X11 clients which asked for
XCB_EVENT_MASK_BUTTON_PRESS. When no client is interested in this event, the
event is propagated to the parent window and the same procedure is done again
here. This continues up until the root window is reached.
Some words about the event masks that awesome uses: For clients, we ask for
button press events on the frame window that we reparent the client window into
so that we get any kind of press on the titlebar (and also events inside of the
client window if the client itself doesn't care for click events?). We are also
interested in button presses / releases on the root window. However, before this
commit, we didn't actually ask for button events on drawins (e.g. the wibox).
This worked fine, because no one asked for these events and the event propagated
to the root window where it was then sent to awesome.
However, newer Qt versions do something weird and the above broke. I don't
actually know what is going on. I know about the above propagation rules, but
looking at protocol traces of what Qt does, awesome should still get the button
events. During startup, Qt asks for button events on its own windows. After a
hotplug event, it asks the same again, but now also includes the root window.
So... how can Qt asking for button events on the root window cause awesome not
to get them? I have no idea.
(And yes, I guess that Qt asking for mouse events on the root window is a bug,
but I have no idea how exactly this happens nor about any other side effects of
it).
This commit makes us ask for button events on our drawins so that the server
will send them to us. This is the right thing to do anyway and it was reported
to have some positive effects.
Ref: https://github.com/awesomeWM/awesome/issues/415
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only exception is the window for _NET_SUPPORTING_WM_CHECK. That window
already had a _NET_WM_NAME property before and doesn't get a WM_NAME property in
this commit. I just decided for myself that it doesn't need one. :-)
Right after startup with the default config we now have the following situation:
$ xwininfo -root -tree
xwininfo: Window id: 0x2d7 (the root window) (has no name)
Root window id: 0x2d7 (the root window) (has no name)
Parent window id: 0x0 (none)
7 children:
0x200011 "Awesome drawin": ("awesome" "awesome") 1500x20+0+0 +0+0
0x200010 "Awesome drawin": ("awesome" "awesome") 1x1+0+0 +0+0
0x20000d "Awesome drawin": ("awesome" "awesome") 100x30+0+0 +0+0
0x20000a "Awesome no input window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200009 "Awesome systray window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200008 "awesome": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200007 "Awesome WM_Sn selection owner window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
One of those drawin is the awful.wibox. Another drawin is created by awful.menu.
I guess that the third one is created by awful.tooltip, but I'm not sure. Wow,
so many windows...
Closes https://github.com/awesomeWM/awesome/pull/556.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is an enhancement to make non-ASCII symbol keys usable for
implementation and configuration of Awesome.
The enhancement was proposed and had been developed under the
initiative of Daniel Hahler. Thanks to his sharing of his results with our
community, we gradually deepened our understanding on the issue. This
commit is the fruit his enthusiasm spawned.
Closes https://github.com/awesomeWM/awesome/pull/538.
Before this, we grabbed the keys on the frame window. That meant we only got key
events for things that nothing else grabbed directly on the key window.
After this, we grab directly on the client window itself and so we "fight" with
everything else which wants to grab keys. I don't actually know how the winner
is decided... First come, first serve, the rest gets an error?
Signed-off-by: Uli Schlachter <psychon@znc.in>
blueusername
Emmanuel Lepage Vallée
Daniel Hahler
Uli Schlachter
Uli Schlachter
Mikhail Schemelev
Kirill A. Shutemov
Daniel Hahler
Kazunobu Kuriyama