Make hotkey window without brining other windows to front
By gnach... on July 28, 2011 16:41 (imported from Google Code)
Change window class in nib to PTYWindow and don't allocate one in initWithSmartLayout. See visor_fix git branch.
Activity
Comment 1 by spork.spork... on July 28, 2011 19:15
Does this also fix the "windows pop to the foreground when ssh-keychain is contacted for agent auth" issue?
For example, my windows are arranged as I like, most in the background, one in the foreground. I ssh somewhere and ask for agent socket forwarding (ie: ssh -A host), and all windows pop to the foreground.
-
Comment 2 by cehoff...@othercoders.com on July 28, 2011 19:51
I don't see the git branch, but I was interested in seeing if this fixed the issue when activating visor while focused on a full screen application. In that scenario the visor shows but you are moved to a desktop space and visor will then lose focus. Pressing the hotkey again will move back to the previously active full screen application.
-
Comment 3 by geor...@google.com on July 28, 2011 20:47
I don't think it'll fix the issue with alert boxes. They are badly behaved on OSX.
@cehoff The git branch hasn't been pushed yet, which is why you don't see it :). Can you file another bug for the fullscreen issue you describe?
-
Comment 4 by gnach... on July 31, 2011 19:27
I pushed the visor_fix branch. It's incomplete but I can't see a way to make it actually work. Here are the key problems:
- If you call -[NSWindowController setWindow:] or -[NSWindow setStyleMask:] then when that window comes to the front with -[NSRunningApplication activateWithOptions: NSApplicationActivateIgnoringOtherApps] it brings another window along with it.
- The only way to avoid calling one of those methods is to use the window that comes in the nib file without changing its style mask.
- You cannot create a window in interface builder that has a style mask exactly equal to NSBorderlessWindowMask.The combination of these three facts leaves you in a situation where a fullscreen or top-of-screen (the default) visor window will never behave correctly.
-
Comment 5 by egalus... on October 26, 2011 20:43
That can't be true because PathFinder's toolbar button to open Terminal (here) works with the Visor SIMBL plugin to open only one Terminal instance when it is the first instantiation of Terminal app. Meaning, the first call to open a Terminal window is the instantiation of Terminal and results as, by rule, the first window of Terminal.app instantiation is "Visor".
Once Visor is instantiated, (imho) the scope of Visor and its application domain is established. Not sure because haven't looked at its code, but the behavioral pattern demonstrated by Visor (SIMBL plugin) implies that it focuses on assuming control of ONLY the first Terminal.app window as the instantiation of Visor as a process id, then that serves as the parent process id and defines the scope for all shell calls within that.
The question is, does the successful implementation of producing only 1 window and passing a "cd to dir/path/xyz" statement dependent on the point of app's first process instantiation having been only made possible because Visor's fundamental concept/construct is bound to "One Parent Process for One Window of Scope...ONLY" (i.e. only one Parent Process Identified as "Visor" can exist at one time)?
Is it possible to define the "Hotkey Window" as the default instantiation as a child-process that a) can only have one existing instance at one time? b) be the (conditional) default or priority window creation only and always if no other Hotkey Window exists at calltime?
Actually, now that i think about it, perhaps the obstacle is the implementation and concepts defined by the "Profiles" of iTerm2... correct me if I'm wrong, but, where the HotKey Window is a profile itself that is initialized by one "Default" profile which later becomes an independent derivative profile existing in parallel?
Ever think about unifying the identification of "Default profile" vs. "Hotkey Window profile" to simply be the same and the functionality of the hotkey action item would be just a boolean flag and/or the existence of a hotkey keycode as not null?
-
Comment 6 by geor...@google.com on October 26, 2011 20:51
@egaluskin I had trouble following you, but I think you're saying to run two applications, one for the hotkey window, and one for "everything else". That would work, and it is my plan to fix this in the long run. But I haven't figured out how to do it yet because this isn't how Apple intended things to work.
-
Comment 9 by spencer.carst... on February 28, 2014 06:49
Update? It has been quite a while.
Functionally, it makes the idea of a "visor" almost useless when running multiple bigger windows on the same screen.
For reference of personal severity, I just swapped from TotalTerminal and this issue is enough to make me want to switch back. :( There seems to be a lot of duplicate bugs and feature requests related to this as well.
Milestone changed to Feature Complete 3.1
-
Dup of #644 (closed)