I've noticed this as well while working on type definitions. extension_add_error should expect a XError, but BadRROutputError, BadRRCrtcError and BadRRModeError aren't.

What about the other Error classes?

What about the other Error classes?

I would expect that those errors also derive from xlib.XError if they are to be used as such.

They didn't crash my program, and as these specific classes had been added recently, I hadn't bothered to look any further. Feel free to fix the others too.

@fransklaver thanks for the fix! Please resolve conflicts before merging it.

Codecov Report

Merging #242 (52800b1) into master (4e8bbf8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #242   +/-   ##
=======================================
  Coverage   78.21%   78.21%           
=======================================
  Files          42       42           
  Lines        4705     4705           
=======================================
  Hits         3680     3680           
  Misses       1025     1025           

What about the other Error classes?

I would expect that those errors also derive from xlib.XError if they are to be used as such.

XError represents errors that are returned from the server and is deserialised from the protocol error message, while the other ones are client-side errors where none of that information is available. Thus it wouldn't make sense to use XError as the base for all exceptions in Xlib, but a new intermediary exception class could be introduced for that purpose if that would be useful (maybe XlibError or XlibException, or maybe there's some other recommendations in modern Python).

What about the other Error classes?

I would expect that those errors also derive from xlib.XError if they are to be used as such.

XError represents errors that are returned from the server and is deserialised from the protocol error message, while the other ones are client-side errors where none of that information is available. Thus it wouldn't make sense to use XError as the base for all exceptions in Xlib, but a new intermediary exception class could be introduced for that purpose if that would be useful (maybe XlibError or XlibException, or maybe there's some other recommendations in modern Python).

That's basically what I meant, yes. If they won't be treated like they're XErrors, there is no point in having them inherit XError. For clarity it could be useful to introduce an intermediate layer, I agree.

That's basically what I meant, yes. If they won't be treated like they're XErrors, there is no point in having them inherit XError.

I see, sorry for the misunderstanding! My brain haven't fully booted up today.

I see, sorry for the misunderstanding! My brain haven't fully booted up today.

No worries. It only clarifies stuff for other people whose brains haven't fully booted yet ;).

Is this not being considered for merging? We're facing #241 / #259 in our project where our end-users have spuriously had processes hang at 100% CPU until restarted.

We are considering pinning 0.31 until a fix is released. However, we ourselves have a slow release cycle with lots of testing/prereleases, so hoping someone can pick this up before we ship a stable one. (as others seem to have done already in herbstluftwm/herbstluftwm#1544)

@vasily-v-ryabov Any chance this will be considered for merge? Or should I just downgrade?

@ErikBjare We've had the version pinned to 0.31 ever since I stumbled upon this issue. The previous release should really have included this fix, and upon request I updated the pull request as soon as I could. I haven't had any further communication about this from @vasily-v-ryabov either.

@vasily-v-ryabov do you need help maintaining this project?

Looking at the commit history there have been no new commits on master since December?

Not holding my breath. Saw that last commits were co-authored by Vasily, figured I would ping.

Given the stability of the Xorg/xlib APIs we use, we might keep the version pinned for a long time to prevent further issues (as issues would lead to data loss in our case).

@benoit-pierre do you also have write access to this repository?

Heys! I was planning to make a PR for some convenience syntax sugar stuff, but the commit history of master and the above comments don't look promising / makes this look pointless. What is the plan for maintaining this library? Does anybody know?

I have no idea what the plan is for this repository.

Neither do I, but I wouldn't expect such a PR to get merged. At least not any time soon.

https://github.com/selkies-project/python-xlib/pulls?q=is%3Apr

I just merged all trivial PRs to my organization's fork. I can give out write access. @Avasam @fransklaver

Use python-xlib @ https://github.com/selkies-project/python-xlib/archive/master.zip for setuptools or pip.

@ehfd This repo does look unmaintained, if not abandoned. I'm mostly interested in #251 . Which I could rewrite much better if you're willing to drop EOL Python (or at least anything under 3.7)

In the mean time, I added stubs to typeshed: https://pypi.org/project/types-python-xlib/

@Avasam
I had to revert your commits (but nonetheless preserved this one) because one of them showed some new regressions with my project with capturing the cursor image consistently. I'd like to check which commit it is when I have time.

Would be grateful if you could help out advancing the fork in any way and testing its reliability.

Speaking as the original author and lapsed maintainer (e.g. coming very late to this thread) this library would really need some active maintainers. I don't use XWindows anymore myself, and I think @vasily-v-ryabov has said something along the same lines.

@petli are you in a position to do something about the maintainer issue? Or would we need to contact @vasily-v-ryabov for that?

@fransklaver I think I count as a maintainer still and could add new ones to the project. I would have to look at pypi publishing, I'm not sure if I have any permissions there. Maybe move this into a discussion thread for visibility?

@petli That sounds like a good idea, not sure where or how at this point, though

@petli @fransklaver Discussions are not available in the GitHub repository, apparently (need to enable). Really keen about someone being able to maintain.

@ehfd @fransklaver I've enabled discussions now, wasn't aware that I needed to do it first, and posted #273 there.