Skip to content
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

how to get active window title etc. #129

Closed
sol opened this issue Aug 18, 2016 · 3 comments
Closed

how to get active window title etc. #129

sol opened this issue Aug 18, 2016 · 3 comments

Comments

@sol
Copy link

sol commented Aug 18, 2016

I tried a function action like

def diagnostics_command():
    window = Window.get_foreground()
    print (window.executable, window.title, window.handle)
        "diagnostics": Function(diagnostics_command),

but now when I say diagnostics, it prints the window title of the client (my Windows VM) instead of that of my X11 app. Can I somehow access the window title of the X11 app?

@mzizzi
Copy link
Contributor

mzizzi commented Aug 20, 2016

Interesting use case. Currently aenea doesn't provide a proxy for the Window class. This was probably skipped as each platform (windows, x11, osx) will have different properties that would somehow need to be unified.

That being said, the client does have access to this information. When dragon processes an utterance on the client it needs context from the server to decide what action to take. This context is gathered via a call to the get_context RPC on the server. If you're interested to see how this is done take a look here:
https://github.com/dictation-toolbox/aenea/blob/master/client/aenea/proxy_contexts.py

The default x11 server implementation grabs context information here:
https://github.com/dictation-toolbox/aenea/blob/master/server/linux_x11/x11_xdotool.py#L221

A quick hack for you might be to call aenea.proxy_contexts._get_context() on the client. A slightly better solution might be to add a log statement to get_context() on the server and look at server output to get your debug information. Otherwise you should look at solving your problem using aenea's plugin system. A plugin would allow you to make a custom RPC to the server to grab / format context as you please.

Good luck!

@sol
Copy link
Author

sol commented Aug 20, 2016

Hey, thanks for the reply. I solved this by adding a print statement to the server.

I'm away from the computer, can somebody close this?

Sent from mobile

On 20 Aug 2016, at 9:21 PM, mzizzi notifications@github.com wrote:

Interesting use case. Currently aenea doesn't provide a proxy for the Window class. This was probably skipped as each platform (windows, x11, osx) will have different properties that would somehow need to be unified.

That being said, the client does have access to this information. When dragon processes an utterance on the client it needs context from the server to decide what action to take. This context is gather via a call to the get_context RPC on the server. If you're interested to see how this is done take a look here:
https://github.com/dictation-toolbox/aenea/blob/master/client/aenea/proxy_contexts.py

The default x11 server implementation grabs context information here:
https://github.com/dictation-toolbox/aenea/blob/master/server/linux_x11/x11_xdotool.py#L221

A quick hack for you might be to call aenea.proxy_contexts._get_context() on the client. A slightly better solution might be to add a log statement to get_context() on the server and look at server output to get your debug information. Otherwise you should look at solving your problem using aenea's plugin system. A plugin would allow you to make a custom RPC to the server to grab / format context as you please.

Good luck!


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@calmofthestorm
Copy link
Member

It might make sense to add a non _ method to proxy_contexts for getting the context, since we're already getting it and it should be available. Whenever I've needed this in the past, it's been of the form "Is window foo in the foreground" where foo might be a regex or something, so I just used the ProxyAppContext() and then called match() in cilent code.

Breaking window was a deliberate design decision -- Unfortunately the Dragonfly API for it is very MS Windows specific (iirc it also has operations like moving windows that are going to be window manager dependent on linux) and I could not figure out a good way to provide a cross platform implementation as I did for the other Proxy* classes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants