-
-
Notifications
You must be signed in to change notification settings - Fork 634
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
Create new locationHelper module to facilitate easier conversion between rectangle and point types #7423
Comments
I've considered this kind of thing in the past. The problem is that it
requires all NVDAObjects and TextInfos to return locations and points using
these new objects. While we can modify core ones (though that will touch
quite a bit of code), NVDA's extensibility means others can (and do)
implement their own NVDAObjects and TextInfos. As soon as one location
property doesn't return the new kind of object, the whole idea goes out the
window. There's no way for us to cleanly intercept the location property on
older objects for backwards compatibility. Unless you have a solution to
this problem that I'm missing, I'm afraid this just isn't possible.
|
At least for the location part, I think a deprecation path could solve most of this. Note that the location[0] notation will still work, location.left won't. An ugly, but effective way to maintain backwards compatibility during the deprecation period would be a trick like location=Location(*location) before you request properties like left or top. More easy would be a two stage approach, implement the locationHelper part in the first stage, and a year after, assume that everyone has been able to update their code to support locationHelper. For rectangles and points, I have less concern, as they are already property based, even though they aren't tuples. So, I belief the only problems there would be:
|
…gles and points (PR #7537) Closes #7423 Previously there were many different ways in which a location is presented in NVDA: - (left, top, width, height) - (left, top, right, bottom) - textInfos.Rect, which has left, top, right and bottom properties - ctypes.wintypes.Rect, which is a struct and also has left, top, right and bottom properties - (x,y) - textInfos.Point, which has x and y properties - ctypes.wintypes.Point, which is a structure and also has x and y properties On the fly conversion between the different types is not possible. Also, conversion from screen coordinates to client coordinates, physical to logical coordinates, etc. is somewhat cumbersome.
Currently, there are many different ways in which a location is presented in NVDA:
Although there aren't many use cases for this at first sight, i propose a new locationHelper module to get rid of these inconsistencies and conversion code that must be duplicated several times. This includes:
New namedtuple based classes with some extra enhancements
Helper functions to convert between the new locationHelper classes and ctypes ones. I've bee nthinking about monkeypatching ctypes to do conversion on the fly, but this seems complex and might not be something we should even consider.
One concern about changing the Point and Rect objects from textInfos into named tuples is that named tuples aren't mutaple. There are some places in NVDA Core where this would lead to issues, however they could easily be solved. Regarding backwards compatibility with add-ons, we could decide to keep textInfos.Point and textInfos.Rect and deprecate them.
Some examples from current code
From TouchHandler.notifyInteraction
Current code
new code
displayModel.DisplayModelTextInfo._get__storyFieldsAndRects
Note that location for DisplayModelTextInfo is a rectangle, and location for object is based on width and height. Named tuples would make this clear when inspecting from a console. It is quite confusing, and I initially did this wrong when writing down below code.
Current code
New code
The text was updated successfully, but these errors were encountered: