13" mbp monitor issue

[a7hybnj2]

Hi! Amazing spoon. I spent hours manually making a config before I found this which did almost everything I needed.

My Setup: is a MBP with external monitor.

I am having issues with using this spoon on my laptop monitor. It works flawlessly on my external display but for whatever reason repeated presses of the hotkey do not cycle through the sizes. Only the first size is available.

Here is my init.lua: https://github.com/a7hybnj2/dotfiles/blob/master/.hammerspoon/init.lua

[a7hybnj2]

I haven't been able to figure this out but have some more data to hopefully help point to the cause.

The issue is only present on my mbp screen. It doesn't matter if my external monitor is plugged in or not.

Only certain applications have issues. terminal works completely. Safari works on the left side for 2 of the sizes but doesn't work top, bottom, or right. Messages only has the first position work in up, down, left, right.

When I change "sys prefs - display - scaled - more space" I might have an extra option for size in Messages but not Safari and only on the top.

That last realization makes me think it is a resolution issue...? Maybe a grid of 24 is too many for the 13" MBP (2016)?

this picture doesn't prove anything but I did an hs.grid.show() and you can see it seems very crowded...

[RickCogley]

For what it is worth, I am having no trouble on the main monitor of a MBP 15, 2017 version, 15.4-inch (2880 x 1800), nor on an external Dell P2715Q, 27-inch (3840 x 2160).

[a7hybnj2]

@RickCogley
I still haven't figured it out. Like my last post indicated I don't have the issue on my external monitor only on the 13" mbp screen. Doesn't matter if the external is plugged in or not. Guess I should edit the title of this issue... And...it is not every application that fails to format correctly.

I have recreated most of the functionality using straight hammer-spoon commands and those don't have issues sizing the selected windows to the same sizes. I haven't taken the time to follow the code of miro to see how it is processing everything but maybe I will...

[kyranjamie]

Can confirm I have the same issue.

[zzyyfff]

I have been able to recreate this when attempting to set window sizes smaller than an app will allow. For example, if Miro tries to set a Chrome window to size 6/1 (one sixth of the monitor width), then it will, in some circumstances, get stuck.

Have you tried to recreate this behavior with an app that allows for smaller window sizes? Try TextEdit.app that comes with Mac OS. This one works fine for me.

Take a look at the init.lua that's inside of MiroWindowsManager.spoon (right click and select "Show Package Contents"). What is obj.sizes set to?

I don't immediately have a fix for this, but if the above is also true for everyone experiencing this problem, then we're one step closer to figuring it out ^_^

[kyranjamie]

I've got mine set to obj.sizes = {2, 3, 4/3, 3/2}

[zzyyfff]

I've got mine set to obj.sizes = {2, 3, 4/3, 3/2}

I wonder if the monitor in question can hand a window of size 1/3 (the "3" in your obj.sizes), for the app you're testing it with.

Have you tried recreating this bug with the built in Text Edit app?

[kyranjamie]

@zzyyfff You're accurate with your description of the issue.

TextEdit and other app windows that can resize to stated size, works fine. But, for those that don't, they won't even cycle through and resize to the larger sizes the window can support.

Gif is of cycling through resize, hyper key + right arrow

[zzyyfff]

Great! At least we've narrowed down the bug. I'm not a dev of this project and this is my first time playing with Lua, but my guess is that there's a logic/math bug in how this app decides when to cycle sizes if an App won't let it get to it's smallest windows sizes.

I'm guessing that it taking a look at the current window size and deciding "Can I make this one size smaller, in the user's list of desired sizes? obj.sizes ? I'm not that small yet, so I should go to the next smallest size!"

However the app in question (Spotify in your example) prevent it from getting that small and the problem repeats.. again.. and again...

I don't know if there is a way for Miro/Hammerspoon to be aware of the smallest-allowed-size for a given foreground app window, but perhaps we can just track to see if the most recent size change failed at getting to the desired size. If yes, Miro should reset to the largest desired size on the next hyper key attempt.

I'm busy so I can't dive into this now. If no dev has gotten to it before I have some free time, I'll see if I can learn enough Lua and Hammerspoon to hack together a solution ^^

Please let me know if you figure out a solution before then! =)

[a7hybnj2]

This new information seems to be accurate. I can make terminal any size I want on my 13" screen but an app like messages gets stuck and will not comply. The odd thing messages gets stuck at a small size and will not grow. Would be nice if we could get it to just avoid whatever size the hangup is and cycle through the sizes that should work.

Let me know if I can test anything on my end to help out. I would be more than happy to. I am still just my init file as linked above and it is one of the most helpful scripts ever. Works flawlessly on the external monitor.

[a7hybnj2]

I just setup this script on my new MBP 16" and I still have the problem. I was hoping with the extra screen real estate I would not.

I can drag a corner of the apps that don't size correctly with the app. I don't know what preference sets the minimum window size and why I can drag it smaller but cannot hammerspoon it smaller.

If I cannot figure out a way to make this work I will have to find another script that can help out.

[a7hybnj2]

This started to bug me so I took a few minutes and did this:

horizontal = 0
--add one here for 2/3 right for testing
hs.hotkey.bind(hyper, 'b', function()
	horizontal = horizontal + 1
	if horizontal > 2 then
		horizontal = 0
	end
	print(horizontal)
	local win = hs.window.focusedWindow()
	local f = win:frame()
	local max = win:screen():frame()

	local x = f

	x.x = ((max.w / 3) * horizontal)
	x.y = 0
	x.w = ((max.w / 3) * (3 - horizontal))
	x.h = max.h
	win:setFrame(x)
end)

This has not been cleaned up but appears to work on the previous windows that I had issues with. I was hoping that other people here could test it on the windows they were having issue with.

If it works I can flesh out a more complete version. This version is hyper + b (so what ever you set hyper to for micro). And it just cycles from 3/3 2/3 1/3 all right justified.