Sublime Forum

Focusing the window

#1

Does someone have the working code for OSX that focuses a given window?

There were some bugs in this system and nothing I try works… the window in the background is not brought forward…

I tried:

some_view = window.views()[0]
window.focus_view(some_view)

and

def workaround_bug_on_focus_view(self, view):
    window = view.window()
    window.focus_view(view)
    window.run_command('focus_neighboring_group')
    window.focus_view(view)
0 Likes
Missing: Shortcut to TOGGLE between two windows
#2

Check out https://github.com/ccampbell/sublime-goto-window

You may be able to borrow something from there.

0 Likes
#3

Great idea! Indeed I was able to copy the code (with bug workaround for OSX) from there, so the working script for toggling windows on OSX is here:

I’m still bothered by a small delay while switching because of how workaround has to be done…

0 Likes
#4

An alternative to your Applescript workaround (which did actually work for me) is something like the following:

def workaround_bug_on_focus_view(self, view):
    window = view.window()
    window.focus_view(view)
    window.run_command('focus_neighboring_group')
    if sublime.platform() == 'osx':
        path_to_sublime = '/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl'
        subprocess.call([path_to_sublime, '--command', ''])

Apparently, if you launch sublime without any arguments and you open a pipe to its stdin (even if the input is empty), it opens a new view containing whatever it read from stdin. And for whatever reason this seems to be unavoidable from python in sublime. At least I couldn’t find a way to prevent subprocess from doing this. So that is the reason for the extra ‘–command’ and ‘’ arguments. They basically do nothing, but prevent stdin from being read. (You could also use view.file_name() instead of these two args, but views don’t always have a backing file, so you’d hit the stdin issue.)

If you want a slightly less hard-coded version of the path_to_sublime, you could do something like:

path_to_sublime = os.path.join(os.path.dirname(os.path.dirname(sublime.__file__)), 'SharedSupport/bin/subl')

Maybe there’s a better way to get sublime’s path. I tried sublime.executable_path(), but that returns “/Applications/Sublime Text.app/Contents/MacOS/Sublime Text”, and that launches a new instance of sublime, unfortunately.

And the reason for using subprocess.call instead of subprocess.Popen is that Popen() can leave a zombie process open (named “(subl)”). Not a big deal, but I happened to notice it, and was annoyed by it. call() shouldn’t ever hang, but a timeout arg of 1, for example, could be used if you’re paranoid.

1 Like
#5

Thanks for this! Wouldn’t have thought of it on my own.

Another way to prevent the hardcoding of path to sublime could be require the user to have done the fairly conventional task of creating a symlink to the subl binary somewhere in their shell $PATH. Then path_to_sublime need only be subl. And for any public packages, a setting can allow the user to alter the name of symlink.

0 Likes