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
moving/resizing electron based apps (slack, vscode) #2316
Comments
You're right, it happens with other apps as well. It's happening with iTerm for me. The animation is one weird symptom and another is that my logic for moving the app between screens doesn't work properly, like it loses the screen, or the window/screen relationship. |
Are you using a spoon or the API itself? I am using WindowGrid spoon which does depend on http://www.hammerspoon.org/docs/hs.grid.html |
Sometimes this kind of thing can be caused by apps having a different name in their Info.plist from the name of their .app bundle. If that’s the case here, maybe we can figure out where we’re using the wrong one, and try to fix it. |
I'm using both |
@cmsj do you need anything from me? Console log or any other info? I am not familiar with macOS internals & Lua but would love to help. :) |
Are there any errors in the Hammerspoon Console when the movements fail to trigger? |
I get no errors. In addition to simple I'll dig more over the weekend, I'm sure I can figure out exactly where my code is failing, maybe that will provide some additional hint. |
Also, yesterday, vscode was having this problem, today it doesn't have the problem, but now firefox does. I don't think it's related to specific apps. |
im hittingthis at the moment. with vscode focusedWindow() is nil but also happens when doing to hammerspoon its like vscode has no windows at all. |
I also found that ecamm live's customziation docks are not detectable/filterable by hammerspoon. which is shame as their auto layout is bad and i would love to fix it. |
I'm having a similar issue with slack. Hammerspoon does not detect any slack windows:
This seems to have happened recently. |
I've been seeing this issue as well when using My Emacs would sometimes require three calls, which in no particular order would resize height, resize width, and set origin. Another datapoint that bolsters the theory that the issue is with untitled windows: After changing my Emacs window title to begin with |
Hopefully not just pouring confusion on the fire, but I just had this happen to me with Slack, and found that restarting Slack fixed the issue. (For now...) |
i am having a similar issue with VScode that Hammerspoon does not detect any VSCode windows. After I changed my VSCode window title to start with |
I'm actually amazed by this bug, some things work but require multiple "tries" and others simply don't work. I have my own screen-moving logic and I also tried using the WinWin spoon, both using just weird, man. EDIT: one thing I noticed today is that the behavior is better when passing some more arguments to -- works better!
window:moveToScreen(previousScreen, true, false) |
For me the
When looking at the code of the hammerspoon/extensions/window/init.lua Line 594 in 53257ea
The _setFrame function performs 3 calls: setSize followed by setTopLeft and again setSize : hammerspoon/extensions/window/init.lua Line 313 in 53257ea
It seems that the |
Sorry ,Rectangle does not work too. |
oh I got U, they are both work when I restart vscode. It's weird ! |
I got the same issue, but solely with Finder. Even with the example taken from the "Getting Started" page. Before migrating my window management to Hammerspoon, I used pure AppleScript for Window Management, and here, there are two methods for resizing windows, one of which caused the same issue while the other worked fine. Maybe this helps with fixing this issue? # using bounds, everything works fine
# however, setting window bounds is only available for apps with proper AppleScript support
use framework "AppKit"
set allFrames to (current application's NSScreen's screens()'s valueForKey:"frame") as list
set max_x to item 1 of item 2 of item 1 of allFrames
set max_y to item 2 of item 2 of item 1 of allFrames
set x to 0.2 * max_x
set y to 0.1 * max_y
set w to 0.6 * max_x
set h to 0.8 * max_y
tell application "Finder" to set bounds of window 1 to {x, y, x + w, y + h} # using size and position works for apps without regular AppleScript support
# but causes issues with some apps that do have regular AppleScript support
use framework "AppKit"
set allFrames to (current application's NSScreen's screens()'s valueForKey:"frame") as list
set max_x to item 1 of item 2 of item 1 of allFrames
set max_y to item 2 of item 2 of item 1 of allFrames
set x to 0.2 * max_x
set y to 0.1 * max_y
set w to 0.6 * max_x
set h to 0.8 * max_y
tell application "System Events"
tell process "Finder"
tell window 1
set position to {x, y}
set size to {w, h}
end tell
end tell
end tell |
Okay, I looked into it and I am quite positive that the issue is caused by the difference between the position-size-method and the bounds-method I posted above. After a bunch of testing, the issue 100% only occurs for apps with explicit AppleScript support. You can check whether an app has explicit AppleScript support by launching the Script Editor, and then selecting "open dictionary" in the file menu. You can also check it programmatically by looking whether a
Consequently, you should use the bounds-method for AppleScript-capable apps, and the position-size-method for the others. From what I can tell, Hammerspoon seems to use purely the position-size-approach for all apps, resulting in the bug. Using the bounds-approach for the apps in question should also fix the problem for Hammerspoon. Unfortunately, I have zero knowledge of C and Objective-C, but maybe someone who does can fix this? edit: there seems to be one exception for me: Sublime Text does not have explicit AppleScript support (i.e. the bounds-method does not work), but still has the issue when using the the position-size approach 😵💫 In the meantime, you can effectively use function resizingWorkaround(win, pos)
local winApp = win:application():name()
-- add Applescript-capable apps you are using to the if-condition below
if (winApp == "Finder" or winApp == "Brave Browser" or winApp == "BusyCal" or winApp == "Safari") then
hs.applescript([[
use framework "AppKit"
set allFrames to (current application's NSScreen's screens()'s valueForKey:"frame") as list
set max_x to item 1 of item 2 of item 1 of allFrames
set max_y to item 2 of item 2 of item 1 of allFrames
]] ..
"set x to " .. pos.x .. " * max_x\n" ..
"set y to " .. pos.y .. " * max_y\n" ..
"set w to " .. pos.w .. " * max_x\n" ..
"set h to " .. pos.h .. " * max_y\n" ..
'tell application "' .. winApp .. '" to set bounds of front window to {x, y, x + w, y + h}'
)
else
win:moveToUnit(pos)
end
end |
I got the same behavior with Chrome for a while (multisteps necessary to move and place windows, and animation is happening even if my animation duration setting is set to 0). My other electron based apps (slack, vscode) were always working fine. The culprit on my end was the Gramarly Desktop app, which adds a little overlay on top of some apps. Just dropping this here in case this helps someone with a similar issue. |
Well after 2 years of no problems I'm back with Slack giving |
Looks like this is probably an issue with the |
I was so annoyed that positioning windows is not working, that for some features, I developed a timer based loop hack that keeps issuing the command until the window seems to be in the right spot. I'm almost sad to see it go, I kinda like to see the window twitching 4-5 times until it settles down in the desired position :) resizeloop.mp4 |
I am still experiencing this issue for specific applications, notably Firefox (Librewolf). Closed my issue to instead track this one, but more details can be found there: Quite hacky, but this is the workaround for moving windows with retries that I came up with; feedback is always welcome! -- Convert relative `unitrect` to `rect` (couldn't get hs.window:fromUnitRect to work)
local function _unit_rect_to_rect(unit_rect)
local screen_frame = hs.screen.mainScreen():frame()
return hs.geometry.rect(
screen_frame.x + (unit_rect.x * screen_frame.w),
screen_frame.y + (unit_rect.y * screen_frame.h),
unit_rect.w * screen_frame.w,
unit_rect.h * screen_frame.h
)
end
-- Temporary workaround: move windows until we confirm that they are at the frame that
-- we expect. Have a retry of 3 to prevent any unwanted infinite loops.
local function _move_to_unit_with_retries(geometry, window)
window:moveToUnit(geometry)
local retries = 3
hs.timer.doUntil(function()
return retries == 0 or window:frame():equals(_unit_rect_to_rect(geometry):floor())
end, function()
window:moveToUnit(geometry)
retries = retries - 1
end, 0.25)
end |
All the electron applications I use (actually slack and vscode, but not spotify) have the same problem moving/resizing within a screen and between screens.
I have to press the shortcut key multiple times and every time it does part of the movement (resize only, then on next press it'll put the window in the right place). Also, only those apps are animating the resize, even though I have
hs.window.animationDuration = 0
.All the shortcuts work in Finder/Spotify, but as soon as I switch to vscode, it starts animating and not fully working.
I thought it was just
hs.grid
based code, but seems like it happens withwin:maximize()
andwin:moveToScreen()
.Thanks
The text was updated successfully, but these errors were encountered: