The code that claims to do what XRRUpdateConfiguration() would do was actually
wrong. That function does not send any requests to the X11 server, but it just
updates the local, in-memory state.
This commit makes us do the same: We update the size of the root window if it
changed. The code is directly inspired from the code in libXrandr.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit copies part of what XRRUpdateConfiguration() would do. When the root
window is resized, we update the information that the X11 server sent to us when
we connected to it to contain the new size of the root window.
This is 50% ugly, but having our own copy of the root window size would be 51%
ugly, so it's better to write to the XCB-owned structure.
Right now this is all dead code anyway, because we restart anyway, but since the
goal is to get rid of that restart, this is a step in the right direction (e.g.
root.size() will automatically return the new size).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function needs the event numbers for events from some extensions. These are
assigned dynamically by the server. Right now, this is done by having a bunch of
static variables that are initialized when needed.
Refactor this to have a function event_init() instead that sets variable in
globalconf (where all of our state should be saved). Also, a preprocessor macro
is introduced to handle event dispatch which also looks a bit nicer.
Signed-off-by: Uli Schlachter <psychon@znc.in>
gears modules usually don't depend on Awesome C-API. This code has
been placed there for unclear reasons.
Also, there is ongoing work to unify each "concepts" API into one
single page. Having `gears.screen` go against this effort.
This reverts commit e6037b4738. It causes many
issues with non-trivial solutions that we first need to come up with. As a
middle ground, we will for now only emit signals if something changes after the
config is loaded.
See https://github.com/awesomeWM/awesome/issues/799.
Fix a build breakage accidentally introduced by a merging pull requests
The build failed because both PR were developed in parallel and made different
assumptions. Last week new test framework assumed only CAPI normally print on stderr and #787
assume printing warnings on stderr has no consequences. Both assumptions were true when the
code was published, but they no longer were by the time #787 was merged.
Emmanuel Lepage Vallee
Uli Schlachter
Daniel Hahler
Daniel Hahler