What is the intended usage of property_type parameter in Window.get_{,full_}property()? #261

Activity

1. vasily-v-ryabov

   added

   question

   on Jan 25, 2023
2. MestreLion commented on Jan 25, 2023

   

   MestreLion

   on Jan 25, 2023

   Author

   More actions

   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)
3. petli commented on Jan 25, 2023

   

   petli

   on Jan 25, 2023

   Contributor

   More actions

   @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.
4. MestreLion commented on Jan 25, 2023

   

   MestreLion

   on Jan 25, 2023

   Author

   More actions

   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.
5. MestreLion commented on Jan 25, 2023

   

   MestreLion

   on Jan 25, 2023

   Last edited by MestreLion

   Author

   More actions

   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 use X.AnyPropertyType, to avoid current problems, as the actual type might be STRING or UTF8-STRING. Inspect the result afterwards if required.
   • In get_full_property(), make property_type an optional argument that defaults to X.AnyPropertyType, but ignore it and invoke get_property() with X.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 to expected_type.
6. MestreLion commented on Jan 25, 2023

   

   MestreLion

   on Jan 25, 2023

   Author

   More actions

   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 unlike get_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?