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

Restoring focus #1351

Closed
skurfer opened this issue Jan 25, 2013 · 6 comments
Closed

Restoring focus #1351

skurfer opened this issue Jan 25, 2013 · 6 comments

Comments

@skurfer
Copy link
Member

skurfer commented Jan 25, 2013

Continuing a discussion from the mailing list…

What gets an application into this state?

  • Running the Get Selection service
  • Opening the preferences window

What can we do about it?

When this happens, it seems to be the case that Quicksilver has focus (with no visible windows), regardless of what the menubar shows. I've been able to fix it by running Previous Application ⇥ Open, so the question is: Can we do the same thing when automatically when certain windows close (in windowDidClose or something)?

We can't do it across the board for all QS windows. For instance, if you had the Task Viewer set to show automatically, it would open then close and switch applications at random times. Same for the built-in notifier.

Another complication is that running the service triggers the main interface, but switching applications when the main interface closes is usually not the right thing, so we can't do it unconditionally. Checking to see if Quicksilver is the current application might help, but you could have multiple windows open when closing one, so that won't always work either.

@clarkewd
Copy link

Those are great ideas regarding what to do about it. I am happy to help with testing, maybe with the code (not that good w Cocoa etc yet). Where is this found in the source? Thanks Rob.

@pjrobertson
Copy link
Member

I've implemented a 'fix' to the finder selection applescript that moves focus from Finder → "System Events" → Finder so that the selection is correct. If we could somehow stop QS from closing in the middle of this then it may work (it works now, but you need to re-invoke QS)

My only worries about this behaviour are these:

  • It may end up being quite messy in the code, as the number of places we'll need to do if(doNotCloseWindow) is probably to be quite high
  • Playing with focus of apps can be quite dangerous from the point of view of the user. If I open Quicksilver so I can go to the menu item for whatever reason (if I have the dock icon enabled) I don't want Quicksilver losing focus away from me. We eventually decided against something similar to what we're discussing here in Prevent other apps from stealing focus when QS is active (maybe impossible) #810. Here's a commit that changes this behaviour if you want somewhere to start.

@clarkewd
Copy link

thank you!

@Sesquipedalian
Copy link

As discussed in this thread on the mailing list, this continues to be an issue, and it directly affects triggers that are designed to work on the current selection (e.g. get the current selection, do something to it, and then paste back the results).

In that discussion thread, I posted a workaround for the user, in which the AppleScript told System Events to get the frontmost application process, and then to activate itself followed by activating that application process again. This seems to work reliably in various situations for me, although my testing has not been exhaustive.

I wonder, then, if it might not be possible to do something similar as part of executing an action on an object that has been acquired via the service/⌘G/Current Selection proxy. The key, I think, lies in the fact that "frontmost application process" means whichever app currently has the menu bar and that focus isn't being switch back to it until the action is executed (i.e. after Quicksilver's command window has been dismissed). If putting the focus back onto the previous application was left until the time when the action was executed, that might avoid the problems that earlier attempts at fixing this have run into (i.e. the command window dismissing prematurely).

@stale
Copy link

stale bot commented Apr 4, 2022

This issue hasn't been updated in over 2 years. It has been marked as 'stale' and will be closed in 30 days. Please check whether this is still an issue with the latest version of Quicksilver. If so, update or comment on this issue to keep it open.

@pjrobertson
Copy link
Member

Note: the above change fixed the bug when you use the the service (⌘⎋), however it still appears to be an issue if you select the 'Current Selection' proxy object in the 1st pane. This will be more tricky to solve, since the interface is already visible.

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

No branches or pull requests

4 participants