Open dylnclrk opened 6 years ago
Which version do you use - try the latest from homebrew - should work.
@fikovnik I tried updating (via homebrew cask) before posting this bug report. Unfortunately I'm still seeing the issue on 1.6.5 (and Mac OS 10.13.3).
Oddly enough, I also noticed an inconsistency in the reported version number… see #275 when I clicked "Check for updates". So maybe I'm messing something up with the update?
I wish I were more handy with OS X so I could do a better job helping with these issues.
Let me know if there's anything else I can do to help triage.
Ditto for this issue on OS X 10.12.6 and ShiftIt 1.6.6.
Same issue with OSX 10.13 and ShiftIt 1.6.3. And I've noticed that this issue only occurs when terminal-based application running fullscreen (including Terminal and iTerm2). If you fullscreen other types of application (i.e. browser / finder / iTunes ..) this block would not happen!
I updated to Shiftit 1.6.6, and I'm still seeing this issue. As @emptylambda says it seems to be somewhat inconsistent and depend on the application that's full-screened.
Fullscreened application: Safari Windowed application on other screen: Chrome/Terminal.app/Spotify/Safari Behavior: Works as normal
Fullscreen: Terminal.app Windowed: Chrome/Spotify/Safari Behavior: Doesn't work. But if there is a terminal.app window in the background of the windowed screen, it gets resized (even if you have focus in another application).
Fullscreen: Chrome Windowedn: Spotify/Terminal.app/Safari Behavior: Doesn't work. But if there is a Chrome window in the background of the windowed screen, it gets resized (even if you have focus in another application).
Getting this with 3 monitors (1 - Slack in fullscreen, 2 - App i want to maximize with ShiftIt, 3 - PHPStorm);
macOS 10.13.2 + ShiftIt 1.6.6
2018-03-05 10:39:56.791 ShiftIt[20848/0x7fff88491340] [lvl=3] -[ShiftItAppDelegate invokeShiftItActionByIdentifier_:] Execution of ShiftIt action: maximize failed: Windows in fullscreen are not supported
NSError stack trace:
org.shiftitapp.shifit.error:20103 - Windows in fullscreen are not supported
Im looking into the codebase for this, it seems like Terminal-like app automagically obtains the highest priority for CFWindows list and will always get chosen as if it is "focused" windows.
Therefore once any Terminal-like application gets into fullscreen mode, any other ShiftIt action could not be performed despite our focus and intention is for another application's window. Baseline logic is not wrong: a fullscreen window should not be able to shift left or right anymore.
I pin down the issue currently located in file SIWindowManager.m
the function getFocusedWindow
(around line 144).
Since Im not familiar with Core, my fix may take a bit longer but Im trying to mend this :)
I can repeat the behaviour with any full screen app, not just terminal (iTerm2).
I switched to Spectacle.app which doesn't have this problem.
This is happening to me too. MacOS 10.13.3, ShiftIt 1.6.6. MacBook Pro with 4k Dell monitor hooked up. Trying to work on the 4k monitor and watch The Masters on the MacBook Pro display. 🖥⛳️
Thanks to the ShiftIt team for the hard work developing this free app. 👏
Thanks to the ShiftIt team for the hard work developing this free app. 👏
Seconded. I failed to mention in my previous comment that my switch was reluctant. Apart from being a great app otherwise, ShiftIt has a universal shortcut to fullscreen an app on OSX, which for some strange reason doesn't have a standard OS level shortcut.
ShiftIt has a universal shortcut to fullscreen an app on OSX, which for some strange reason doesn't have a standard OS level shortcut.
@nikcorg Doesn't it? Well, maybe not a standard one.
But, nothing's stopping you from customizing your system, and creating one yourself?
Seems like you can simply create your own custom shortcut for that. As a matter of fact, you can create your own shortcuts for any macOS app (separately), just by adding a menu item's title, and hitting a shortcut?
System Preferences > Keyboard > Shortcuts
@UrGuardian4ngel yes, I've set that keyboard shortcut, but despite that all apps don't adhere to it. E.g. iTerm listens to command-enter, VS Code listens to ctrl-command-f.
Hmm... For me, both seem to work?
cmd + ctrl + alt + F
keybindingcmd + enter
for e.g. iTermI'm on macOS 10.13.3.
Just wondering, the menu title in preferences is case sensitive. So it should match the menu title exactly...
@UrGuardian4ngel I noticed in iTerm the menu item is actually called Toggle Full Screen, which is why it didn't match. Fixed and now it works. So yet another case of PEBKAC. :-)
FYI, it appears PR #276 fixes this issue, for those who wish to build locally. Quit ShiftIt, then run below to patch:
git clone https://github.com/fikovnik/ShiftIt
cd ShiftIt
git checkout master
curl https://patch-diff.githubusercontent.com/raw/fikovnik/ShiftIt/pull/276.diff > fix.patch
git apply fix.patch
cd ShiftIt
xcodebuild -target "ShiftIt NoX11" -configuration Release
rm -rf /Applications/ShiftIt.app
cp -R build/Release/ShiftIt.app /Applications
open /Applications/ShiftIt.app
Note that for those of you who are not mac or iOS developers but are trying to apply the patch, the Xcode tools need to be installed and Xcode needs to have been opened at least once in order for the xcodebuild
statement that @hadidotj mentioned above to work. If you (like me) downloaded Xcode to run that statement but did not open it, running the above code leads to the unhelpful error message "Command /Applications/Xcode.app/Contents/Developer/usr/bin/ibtool failed with exit code 6. The tool may have crashed."
tool 'xcodebuild' requires Xcode
When running xcodebuild -target "ShiftIt NoX11" -configuration Release
you may get the error:
tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
To get around this:
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
Credit to this stackoverflow thread
Question: if I have multiple monitors, and some windows in full-screen mode, should I be able to use the "Next" and "Previous" shortcuts, or are they intended to only work on windowed apps? I don't know if I should file a feature request or a bug report....
Came into the same problem when open a fullscreen Chrome window on my second monitor, it became ok when exit fullscreen mode. And it is also ok to open a fullscreen Chrome window on my first monitor.
2018-09-04 10:19:28.355 ShiftIt[5569/0x7fff97844380] [lvl=3] -[ShiftItAppDelegate invokeShiftItActionByIdentifier_:] Execution of ShiftIt action: maximize failed: Windows in fullscreen are not supported
NSError stack trace:
org.shiftitapp.shifit.error:20103 - Windows in fullscreen are not supported
2018-09-04 10:19:48.602 ShiftIt[5569/0x7fff97844380] [lvl=3] -[ShiftItAppDelegate invokeShiftItActionByIdentifier_:] Execution of ShiftIt action: maximize failed: Windows in fullscreen are not supported
NSError stack trace:
org.shiftitapp.shifit.error:20103 - Windows in fullscreen are not supported
Same here, I had this issue but didn't realize that it has something to do with Full screen mode on one of the screens. Thanks
Same here for me running 10.14.6 with ShiftIt 1.6.6
Note It appears this issue is a duplicate of a previous issue
Same here for me running 10.14.6 with ShiftIt 1.6.6
Note It appears this issue is a duplicate of a previous issue
It appears ShiftIt has been abandoned. I'm using https://rectangleapp.com/ for the same purpose, and it works great.
Problem:
I can't use Shiftit when one of my monitors is in full-screen mode.
More detail:
I have two monitors set up today. In one monitor I have Terminal.app running in full-screen mode, in the other I have several applications (including Chrome) running in regular, windowed mode.
When trying to resize the focused Chrome window, nothing happens, and I see,
in the debug log.
So it seems like it's trying to resize my full-screened Terminal window.
Workaround:
Take Terminal out of full-screen mode, and everybody's happy. Shiftit works.