Comments (5)
Note this is not only a question but also a enhancement suggestion: as it seems property_type
is not functional (and causing issues such as #212 ), it could be changed to either raise an exception on result mismatch, or be completely ignored (and possibly labeled as deprecated so it can be eventually removed as a parameter)
from python-xlib.
@MestreLion get_property
is just a wrapper for the underlying X request, and thus just implements that interface as-is and any semantics around the property type and what gets returned is according to the X protocol. So this method needs to allow the user to pass in a property type of their choice to support all the functionality of the X protocol. (I can't say what the intended purpose is for this however, since it's many years now since I coded any X clients.)
get_full_property()
is a wrapper around this request provided for convenience. This one maybe need to handle the case when the returned property doesn't match the requested property and stop rather than trying to fetch everything if that is futile.
from python-xlib.
Thanks for the reply @petli ! Good points, I understand python-xlib
strives to support all X protocol functionality. So I read the latest X Window System Protocol official standard trying to find the meaning or intended usage of the property_type
, and found this:
ChangeProperty
[...] The type is uninterpreted by the server. [...]
GetProperty
[...] If the specified property exists but its type does not match the specified type, then the return type is the actual type of the property, the format is the actual format of the property (never zero), the bytes-after is the length of the property in bytes (even if the format is 16 or 32), and the value is empty. The delete argument is ignored in this case. If the specified property exists and either AnyPropertyType is specified or the specified type matches the actual type of the property, then the return type is the actual type of the property, the format is the actual format of the property (never zero), and the bytes-after and value are as follows [...]
Glossary
Property: Windows may have associated properties, which consist of a name, a type, a data format, and some data. The protocol places no interpretation on properties. They are intended as a general-purpose naming mechanism for clients. For example, clients might use properties to share information such as resize hints, program names, and icon formats with a window manager.
So it seems that, as far as the X Protocol is concerned, a property has no meaning or semantics, let alone its type. It's just a well-defined mechanism to manipulate some structured data on a window. I have a feeling GetProperty
was defined this (weird) way regarding property type just because "that's what XLib
does", and that XLib
does so just as a side-effect or implementation detail.
from python-xlib.
That said, I understand python-xlib
's get_property()
should remain unchanged to match Xlib
and X Protocol. As for get_full_property()
, being a python-only method, we have some interpretation room and freedom to change its behavior to be even more convenient and pythonic. And its current behavior is causing issues and misuses both in clients and in python-xlib
itself, as seen in the aforementioned #212 .
So a draft proposal could be:
- Change
get_wm_name()
and related methods to useX.AnyPropertyType
, to avoid current problems, as the actual type might beSTRING
orUTF8-STRING
. Inspect the result afterwards if required. - In
get_full_property()
, makeproperty_type
an optional argument that defaults toX.AnyPropertyType
, but ignore it and invokeget_property()
withX.AnyPropertyType
right away (instead of running it twice), so it always returns the intended full property, with full value and 0 bytes left. - Optionally, if there is a standard warning mechanism in
python-xlib
, emit a warning if returned and expected types mismatch. - Add a docstring to clarify
property_type
is ignored, that it was intended merely as an expected type, and in the future might be deprecated or raise an exception. And/or it might change its signature name toexpected_type
.
from python-xlib.
After some thoughts about this, I believe the dilemma boils down to:
- If
get_full_property()
is meant as a convenience method to always retrieve the full value and 0 bytes left, - ... and the X protocol says if type mismatch then returned value should be empty,
- Then in case of type mismatch
get_full_property()
's intended purpose is in direct conflict of X protocol
What to do now? Well...
get_full_property
is a python-exclusive, so unlikeget_property
it is not bound to X spec behavior. It can do whatever it wants to keep its intended purpose.- It also can handle type mismatches in any way it wants to. It never committed to return an empty value. So it can return full values, or raise exceptions, or completely ignore the type, silently or otherwise.
So the real question is:
What is the intended usage and behavior of Window.get_full_property()
as a whole?
from python-xlib.
Related Issues (20)
- transparent background of window? HOT 1
- key pressing not detecting in gnome-terminal on wayland HOT 2
- Unnecessary import
- 0.32 throws AttributeError: 'BadRRModeError' object has no attribute 'sequence_number' HOT 2
- [Code Health] badge is broken
- Should `ReplyRequest` and `ConnectionSetupRequest` inherit from `Request`?
- `DictWrapper` comparisons make no sense (and crashes)
- Can I switch the input method
- test fails: missing mcookie HOT 1
- AttributeError: BadRRModeError object has no attribute 'sequence_number' HOT 1
- xfixes_get_cursor_image does not work on KDE with Xvfb exclusively HOT 2
- shape_combine definition is invalid - TypeError: Missing required argument destination_window
- how can i get the position of the active window in screen? HOT 1
- Function keysym_to_keycode return 0
- Issue with socket in Cygwin
- No XMaxRequestSize equivalent
- Dependency on nose is broken
- TypeError in Xlib/protocol/display.py
- List all devices
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-xlib.