-
Notifications
You must be signed in to change notification settings - Fork 23
ENH: Added methods to support pywinauto features #26
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
ENH: Added methods to support pywinauto features #26
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An idea that can be inserted in this context is that of modularization.
What do you think about creating a module just for the application and using it to call these functions within the core?
In that situation we would have more code isolation and allow for better maintenance.
botcity/core/application.py
Outdated
| """ | ||
| @wraps(func) | ||
| def wrapper(self, *args, **kwargs): | ||
| if platform.system() != "Windows": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about changing the if negation to something more solid? For example:
| if platform.system() != "Windows": | |
| if plataform.system() == "Windows": | |
| return func(self, *args, **kwargs) | |
| raise ValueError(f'You can connect to an application on Windows OS only. Cannot invoke {func.__name__}.') |
That way the name of the function is more objective. What do you think of this proposal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kayqueGovetri good observations! I was thinking of including the methods in the application.py I had created, leaving it along with the Backend enum and validation decorators. That way, everything would be concentrated in the same 'application' module.
Do you think it would be a good strategy? Or would it be more interesting to leave the methods separate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joao-voltarelli It's a good alternative to make a preview of how it would look.
Something I could do to make it more isolated would be to create sub levels for each situation, for example:
- application.py can become a package application/
- Inside the package it can contain:
- The enums.
- The decorators.
- The functions.
- A
___init__.py file containing the__all__method to make exporting files easier.
What do you think of this approach? It might be more work but I think it's worth the result.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was an alternative that I was considering as well, it would make it easier to include future implementations of functions, decorators...
I'll take a look at these options and see how it gets better organized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes were very good. In the future we can separate even more, if necessary, the Enums and the utils functions. But this way it's pretty cool.
And a question, does the test breaking on the CI interfere with anything?
|
We need to find a way to conditionally add the dependency on the Suggestions:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work on the fixes. I see that it is passing now.
I just added one more small request.
Added initial version of supported methods for pywinauto.
connect_to_app: Connects to an instance of an open application.find_app_window: Find a window of the currently connected application using the available selectors.find_app_element: Find a element of the currently connected application using the available selectors.