nvaccess
In DynamicNVDAObjectType.__call__, move code that governs fetching of app module and global plugin overlay classes into their own methods on the NVDAObject class and add a variable on the NVDAObject class that decides if NVDAObjectInit should be called or not
Related issues, PRs or discussions
None.
What is the current state of the codebase?
In DynamicNVDAObjectType.call, the fetching of overlay classes for app modules and global plugins are done directly in the call method.
Why are changes required?
In the current implementation, there is no way for an add-on author to create an API class and garantee that no unwanted overlay classes gets included as well without setting the metaclass to a new class and writing the call method from scratch. For example, if an add-on creates a new API class classA, and if another add-on includes an overlay class classB that overwrites properties that classA needs, the author of classA can't decide to not include classB. I also think that an API class should be able to decide if its appModule can run the NVDAObjectInit function on it.
What technical changes are required?
Move the code that governs the fetching of app module and global plugin overlay classes into two seperet methods on the NVDAObject class. I think they should be called findAppModuleClasses and findGlobalPluginClasses. Add a variable on the NVDAObject class that decides if NVDAObjectInit should be called or not.
Are the proposed technical changes API breaking?
No.
Are there potential risks or issues with the proposed implementation?
No.
Could you please create a more specific example of what you want to achieve. To help us understand better please provide a real world use case, and how these changes would help this case.
@seanbudd For example in the NewUIA class in the enhanced object navigation add-on. This class is designed to be used everywhere, regardless if the window has native UIA support. What if another add-on assumes that the object is an IAccessible object, and appends a class that is inherited from IAccessible? It would be helpfull to have full control over what overlay classes are included in instances of your API class. In this case, being able to ither refuse other add-ons to include their overlay classes on NewUIA entirely, or removing classes that are inherited from IAccessible. Hope this makes sence
@Emil-18 - I think we understand your technical case, but can you go a bit more high-level? as in, what is the user story / what is the task being achieved.
I think an extension point might be useful here
@seanbudd I want a stable, supported, and easy to understand way to be able to garantee that other add-ons doesn't accidentally interfere with APIClasses from other add-ons, thus providing a better user experience. About extension points, I also think that a filter extension point should be applied after every overlay class has been added to the clsList, but shouldn't I create another issue for that? The filter extension point sollution in an out of itself isn't good enough, because gathering of overlay classes can be expencive. I also thought about using decider extension points instead of mooving the code. The only advantage of this I can see is that add-ons that are not the owners of an API class also can decide weather overlay classes should be included without the drop in performence caused by using the filter. The disadvantage I can see is that you can't inspect the overlay classes that would have been added, as you can if mooving the code, by using super
@Emil-18 - I understand the technical use case but can you explain the non-technical use case. I.e what would a user do with an add-on using this proposed API
@seanbudd It would make add-ons that use it more likely to work correctly in conjunction with other add-ons
Hi, in this case, can you offer some example add-ons that can benefit from this change? That way authors of affected add-ons can weigh in. Thanks.
@josephsl The two I can think of at the top of my head is Document formatting rotor and enhanced object navigation