Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use xcb-errors library if it is available #2665

Merged
merged 2 commits into from
Mar 3, 2019

Conversation

psychon
Copy link
Member

@psychon psychon commented Feb 17, 2019

This library allows to get a human-readable string describing X11
requests, events, and errors. We now use this library to pretty-print
X11 errors if we get any.

To test this code, I added the following two lines to AwesomeWM so that
X11 errors are generated:

xcb_set_input_focus(globalconf.connection, 42, 42, 42);
xcb_randr_set_output_primary(globalconf.connection,
    globalconf.screen->root, 42);

Output without xcb-errors:

X error: request=SetInputFocus (major 42, minor 0), error=BadValue (2)
X error: request=(null) (major 140, minor 30), error=(null) (147)

Output with xcb-errors:

X error: request=SetInputFocus (major 42, minor 0), error=Value (2)
X error: request=RandR-SetOutputPrimary (major 140, minor 30), error=RandR-BadOutput (147)

Signed-off-by: Uli Schlachter [email protected]


One still open question

  • Should (one of the) travis build(s) install xcb-errors to test compilation of this?

@codecov
Copy link

codecov bot commented Feb 17, 2019

Codecov Report

Merging #2665 into master will decrease coverage by <.01%.
The diff coverage is 16.66%.

@@            Coverage Diff             @@
##           master    #2665      +/-   ##
==========================================
- Coverage   86.23%   86.22%   -0.01%     
==========================================
  Files         529      529              
  Lines       36401    36406       +5     
==========================================
+ Hits        31390    31391       +1     
- Misses       5011     5015       +4
Flag Coverage Δ
#gcov 75.61% <16.66%> (-0.04%) ⬇️
#luacov 89.03% <ø> (ø) ⬆️
Impacted Files Coverage Δ
awesome.c 78.5% <ø> (ø) ⬆️
globalconf.h 100% <ø> (ø) ⬆️
event.c 72.62% <0%> (-0.64%) ⬇️
common/version.c 84.21% <100%> (+0.87%) ⬆️

@actionless
Copy link
Member

* Should (one of the) travis build(s) install xcb-errors to test compilation of this?

i think yes

set(WITH_XCB_ERRORS OFF)
message(STATUS "xcb-errors not found. Disabled.")
endif()
endif()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this default to AUTO, and cause an error if ON was used, but it is not available?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no AUTO for option(). It is a TRUE / FALSE thing. I briefly looked into it (it is possible, just not with option()) and then decided to just copy what we do for DBus, since apparently that was good enough so far.

If you disagree, I can look into implementing AUTO for WITH_DBUS, GENERATE_MANPAGES, GENERATE_DOC, and anything else that needs this. But I'd do that in a separate PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, just a quick idea.
I think it would be nice in general, but not really necessary.

.travis.yml Show resolved Hide resolved
psychon added a commit to psychon/awesome that referenced this pull request Feb 18, 2019
Previously, these options had two possible values: ON and OFF.

Now, they have three possible values: ON, OFF, and AUTO.

OFF still does what it always did: The feature is just disabled.

With ON and AUTO, we check for the feature. The difference is what
happens when the feature could not be enabled, e.g. because some
dependencies is missing: With AUTO, we just disable the feature (this is
what happened previously with ON). However, with ON, CMake aborts and
prints an error.

Implements: Suggestion by Daniel
    awesomeWM#2665 (review)
Signed-off-by: Uli Schlachter <[email protected]>
psychon added a commit to psychon/awesome that referenced this pull request Feb 18, 2019
Previously, these options had two possible values: ON and OFF.

Now, they have three possible values: ON, OFF, and AUTO.

OFF still does what it always did: The feature is just disabled.

With ON and AUTO, we check for the feature. The difference is what
happens when the feature could not be enabled, e.g. because some
dependencies is missing: With AUTO, we just disable the feature (this is
what happened previously with ON). However, with ON, CMake aborts and
prints an error.

Implements: Suggestion by Daniel
    awesomeWM#2665 (review)
Signed-off-by: Uli Schlachter <[email protected]>
@blueyed
Copy link
Member

blueyed commented Feb 18, 2019

Let's have this (rebased) after #2671.

psychon added a commit to psychon/awesome that referenced this pull request Feb 19, 2019
Previously, these options had two possible values: ON and OFF.

Now, they have three possible values: ON, OFF, and AUTO.

OFF still does what it always did: The feature is just disabled.

With ON and AUTO, we check for the feature. The difference is what
happens when the feature could not be enabled, e.g. because some
dependencies is missing: With AUTO, we just disable the feature (this is
what happened previously with ON). However, with ON, CMake aborts and
prints an error.

Implements: Suggestion by Daniel
    awesomeWM#2665 (review)
Signed-off-by: Uli Schlachter <[email protected]>
@blueyed
Copy link
Member

blueyed commented Feb 19, 2019

Should also come after #2682 (for addons), but not really necessary.

@actionless
Copy link
Member

@psychon so #2682 got merged

@psychon
Copy link
Member Author

psychon commented Feb 20, 2019

Rebased and updated for those two other PRs.

actionless
actionless previously approved these changes Feb 20, 2019
@@ -65,13 +65,15 @@ jobs:
- liblua5.3-dev
- lua5.3
# Note: luarocks does not work with Lua 5.0.
- env: LUA=5.1 LUANAME=lua5.1 BUILD_IN_DIR=/tmp/awesome-build
- env: LUA=5.1 LUANAME=lua5.1 BUILD_IN_DIR=/tmp/awesome-build WITH_XCB_ERRORS=yes
Copy link
Member

@blueyed blueyed Feb 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for not noticing earlier, but it would be better to add this to the DO_COVERAGE=codecov job.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Went ahead and amended your last commit.

actionless
actionless previously approved these changes Feb 21, 2019
@actionless
Copy link
Member

@blueyed it have a conflict again

blueyed
blueyed previously approved these changes Feb 23, 2019
@actionless
Copy link
Member

@psychon and again :-)

This library allows to get a human-readable string describing X11
requests, events, and errors. We now use this library to pretty-print
X11 errors if we get any.

To test this code, I added the following two lines to AwesomeWM so that
X11 errors are generated:

    xcb_set_input_focus(globalconf.connection, 42, 42, 42);
    xcb_randr_set_output_primary(globalconf.connection,
        globalconf.screen->root, 42);

Output without xcb-errors:

    X error: request=SetInputFocus (major 42, minor 0), error=BadValue (2)
    X error: request=(null) (major 140, minor 30), error=(null) (147)

Output with xcb-errors:

    X error: request=SetInputFocus (major 42, minor 0), error=Value (2)
    X error: request=RandR-SetOutputPrimary (major 140, minor 30), error=RandR-BadOutput (147)

Signed-off-by: Uli Schlachter <[email protected]>
@psychon
Copy link
Member Author

psychon commented Mar 3, 2019

Rebased on master

@blueyed blueyed merged commit d21fd74 into awesomeWM:master Mar 3, 2019
@psychon psychon deleted the util-errors branch March 3, 2019 11:38
petoju pushed a commit to petoju/awesome that referenced this pull request Jun 8, 2019
Previously, these options had two possible values: ON and OFF.

Now, they have three possible values: ON, OFF, and AUTO.

OFF still does what it always did: The feature is just disabled.

With ON and AUTO, we check for the feature. The difference is what
happens when the feature could not be enabled, e.g. because some
dependencies is missing: With AUTO, we just disable the feature (this is
what happened previously with ON). However, with ON, CMake aborts and
prints an error.

Implements: Suggestion by Daniel
    awesomeWM#2665 (review)
Signed-off-by: Uli Schlachter <[email protected]>
actionless pushed a commit to actionless/awesome that referenced this pull request Mar 24, 2021
Previously, these options had two possible values: ON and OFF.

Now, they have three possible values: ON, OFF, and AUTO.

OFF still does what it always did: The feature is just disabled.

With ON and AUTO, we check for the feature. The difference is what
happens when the feature could not be enabled, e.g. because some
dependencies is missing: With AUTO, we just disable the feature (this is
what happened previously with ON). However, with ON, CMake aborts and
prints an error.

Implements: Suggestion by Daniel
    awesomeWM#2665 (review)
Signed-off-by: Uli Schlachter <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants