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

Improve application context detection #106

Closed
chilimangoes opened this issue Sep 24, 2015 · 6 comments
Closed

Improve application context detection #106

chilimangoes opened this issue Sep 24, 2015 · 6 comments
Assignees
Labels
Dragonfly A catchall label for issues related to Dragonfly Enhancement Enhancement of an existing feature

Comments

@chilimangoes
Copy link
Collaborator

Dragonfly's built-in AppContext waits until the user starts speaking to detect application context changes. I would like to take a shot at detecting application switches using the native Windows API. Using this method, we could eliminate some of the window polling that Caster currently does, and potentially improve performance.

Additionally, as I've had to work from home the last couple of days and connect to my work computer over the VPN, I'm noticing that it would be nice to have application-specific grammars work correctly over an RDP session. This may be easier said than done with firewalls and such getting in the way, but again it's something I'd like to try.

@synkarius
Copy link
Collaborator

These sound awesome. I'm very interested in the first one in particular.

@chilimangoes
Copy link
Collaborator Author

Had another thought about this earlier today. In addition to providing information about which app has focus, our context provider could serve as a repository for other useful information. For example, which monitor the active application is on, what the coordinates and window size of the app's main window are, client rectangle of the currently focused control/window within the application, whether the start menu is open, etc.

One example of how we could use this would be to limit the grids to the active window client area by default (or provide a separate command for that, or make it configurable).

@synkarius
Copy link
Collaborator

All of the window-pinging stuff has been moved to the AutoSwitcher class in control.py now, FYI.

I agree though, that access to that other info from Windows would be very useful. How difficult would it be to ensure that this is Vista-compatible until MS no longer supports Vista? (If it's not the sort of nightmare that supporting IE7 was, it'd be nice to support whatever MS supports.)

@chilimangoes
Copy link
Collaborator Author

These are core APIs that have changed very little since Windows 2000 (95 in some cases). I'm actually more uncertain about supporting Windows 8, with it's funky start menu. I have no idea how that thing works or if it uses a mechanism completely different from the standard windowing APIs. But that's what VMs are for. I'll test it thoroughly on Vista through 10. Which reminds me, I should do the same with the current grid stuff in working on.

@LexiconCode LexiconCode added the Enhancement Enhancement of an existing feature label Mar 19, 2018
@LexiconCode LexiconCode added the Dragonfly A catchall label for issues related to Dragonfly label Apr 16, 2018
@LexiconCode
Copy link
Member

I believe this script contains most of what we need to implement window change listener.

@LexiconCode
Copy link
Member

Closing issue due to age if interest picks up again feel free to reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dragonfly A catchall label for issues related to Dragonfly Enhancement Enhancement of an existing feature
Projects
None yet
Development

No branches or pull requests

3 participants