Cleaned up dock handling

[ezig]

Fixes #22

I couldn't figure out if that 16px difference between the dock height and the tile size is a constant or not, so it seems like using the Obj-C to to calculate the difference between the frame and the visibleScreen is the most reliable solution without needing assistive devices enabled. I think the reason the Obj-C utility might have been unreliable before and sometimes wouldn't detect the dock is that it was comparing diffHeight != 0 which could fail due to floating point imprecision. I tried to fix this by comparing diffHeight and diffWidth to FLT_EPSILON which is a very small, non-zero constant that should account for any weird floating point problems.

Overall, I kept the main logic similar but added in checks needed for left/right dock support.

One case that seems a bit weird is that it appears when the dock is set to auto-hide, there's a small region used to detect the mouse-over that is 4 px tall for me. I'm not sure if this 4 px is a constant that we could account for when the dock is autohiding.

Tested on a two monitor setup in Terminal and iTerm. I will keep testing this out and see if I find any issues, but I thought I would put this PR up so others could take a look and test.

[apaszke]

Right, floating point errors could be the case. We can set up the epsilon even to something bigger (like 2), because such difference is negligible on screen and no dock will fit into 2px (or even 10px).

I'm not sure if changing the screen to mainScreen is a good idea. As far as I remember it's something different, because object 0 from screens is the screen that is active at the moment, while the mainScreen is always the one with the main menu bar.

I've had the same problem with 4px dock detected when autohide is enabled, but we don't have to care about it (we can just subtract the screen size in AppleScript only if autohide is disabled). Can you see any difference in visibleFrame when the dock is vertical? I can only see that the visibleFrame.origin.left is 4.04 (while having dock on the left, which takes up 60px).

Also I think that we should have some fallbacks in AppleScript, which correct the Obj-C utility. I had once a problem when I could resize windows to be below the dock and visibleFrame reported that I can use the full screen, but the lowest 80px were mostly covered... We have to deal with such things as well. We should still have some constants (or scaling based on the method you've found) for some weird scenarios.

[ezig]

I could have it backwards about the difference between mainScreen and screens[0], but from the Apple docs: "The main screen refers to the screen containing the window that is currently receiving keyboard events."

I can double check what happens with visibleFrame when the dock is vertical. If it's also 4px there and 4px seems to be a constant, it would be pretty easy to fix that in the AppleScript

I agree that it would be good to have a fallback in the AppleScript. Here's my initial idea: If auto-hide is not enabled and the dock position is bottom, if the dockHeight from the Obj-C script is smaller than the tileSize in the prefs file, set the dockHeight to be tileSize + 16.

And have similar checks for left/right dock positions.

[apaszke]

I'll check the docs tomorrow. I think that Obj-C can only tell us on which screen is the dock and we can try to use it to get the height of horizontal one. We won't get anything useful besides that.

I think that I'd be best to figure out a solid way of doing it in AppleScript with a little bit help from some reliable hints from Obj-C.

I'll have more time tomorrow and I'll do some measurements then.

[apaszke]

I think that 9e9ac33 and de4406e contain all the fixes you have included. I'm closing this PR. Thanks for help @ezig!

(I'm not closing #22, because we still need a better fallback algorithm)