Zoomalign and rectanglealign anomalies

I am trying to align a window on the right but not go behind the dock if the dock is on the right, the statement

zoomalign “right”

moves the window behind the dock on the right. But it will leave space when I zoomalign to the side opposite the dock.
The same behavior occurs with this code:

local lvrec
zoomwindowrectangle lvrec

However, aligning to the bottom correctly accounts for the dock on the bottom

Any ideas of what is happening?

I confirm this behavior, and it happens in a similar way when the dock is placed on the left side of the screen. In that case the database window leaves space when it is aligned to the right, and it hides behind the dock when it is aligned to the left side.

It seems as if the parameters for left and right in those align statement / functions are messed up.

The problem seems to be with the info("availablescreenrectangle") function which is used internally by the zoomalign statement as well as in the example code with the rectanglealign( function shown above. Using message rectanglestr(info("availablescreenrectangle")) returns the erroneous left/right values if the dock is set to one side or the other. If the dock is on the bottom it returns valid values. If the dock is set to automatically show and hide then it is ignored completely.

I am going to add this issue to Bitbucket.

Unfortunately it appears that this is due to a bug in Apple’s code so I probably won’t be able to fix this issue, since I have no way of knowing the area of the dock other than requesting that information from Apple’s code.

If I have the dock on the left, and create a new empty database, its window opens with its left edge properly aligned with the dock. Is there any way to determine in advance what the coordinates of a window that is left or right aligned will be?

I’m wondering if you are using [NSScreen visibleFrame] to get the values. The Apple documentation on this states that it will allow room for the dock even if it is currently hidden. I know that info("availablescreenrectangle") does not do this and just returns the entire screen size if the dock is not currently being displayed and does not subtract for the menu bar. Here is the note from the Apple documentation:

The returned rectangle is always based on the current user-interface settings and does not include the area currently occupied by the dock and menu bar. Because it is based on the current user-interface settings, the returned rectangle can change between calls and should not be cached.


Even when dock hiding is enabled, the rectangle returned by this method may be smaller than the full screen. The system uses a small boundary area to determine when it should display the dock.

This statement:

message rectanglestr(info(“screenrectangle”)) +cr()+ rectanglestr(info(“availablescreenrectangle”))

gives the message:

06 am

The difference between the two first values tells me my menu bar is 23 points high. The difference between the two third values tells me my dock is 57 points high. Doesn’t that provide the required info?

I was going to leave that detail out because I figured it was too technical! But yes, that is where info("availablescreenrectangle") is getting the values. I think there is a bug in [NSScreen visibleFrame].

Yes, it works fine when the dock is on the bottom of the screen. The original report was that it doesn’t correctly adjust the width when the dock is on the left or right. I believe this is because Apple’s [NSScreen visibleFrame] is not returning the correct values. Unfortunately, Apple’s code does occasionally have bugs!

The current dock setting is available in the com.apple.dock.plist file in the user’s Preference folder.

One other problem I see is that if you have two monitors and you have the dock set to Right it will appear on the right side of the right monitor and if you have it set to Left it will appear on the left side of the left monitor. Good luck trying to account for that as well. :grimacing:

Two problems with that. First, I don’t think that is an official supported API for that information. But more importantly, that still doesn’t tell you the dimensions of the dock. The user can make the icons bigger or smaller. The [NSScreen visibleFrame] API is supposed to tell you not only the position but the exact current dimensions of the dock (or actually, the inverse – where the dock isn’t).

It has been a long time since I fiddled with the Dock controls, so I fiddled with them tonight. I keep mine on the right. There are so many things on it that the size control does nothing on my MacBook Air; it always stays at the minimum width. So there must be a lot of factors that make the usable width of the screen variable.

I think that this should move a window to the edge of a right-aligned dock, retaining the top alignment and window size:

local a,b,c,d,windowtop,dockwidth
getwindow a,b,c,d
windowtop = a
zoomalign "left"
getwindow a,b,c,d
dockwidth = b
zoomalign "right"
getwindow a,b,c,d
zoomwindow windowtop,b-dockwidth,c,d,""

It should, but it doesn’t. That’s the point of this topic. ZoomAlign depends on info(“availablescreenrectangle”) to tell it where the boundaries are, and info(“availablescreenrectangle”) makes no allowance for the dock, when it’s on the left or right.

Your code works perfectly here.

The Pan X Help says: “getwindow is obsolete”, and it recommends to use info(“windowrectangle”). How would that change your code?

I thought the statement

zoomwindowrectangle info(“screenrectangle”)

would cause the top window to fill the entire screen, but it only aligns it on the left side of the screen, behind the dock if it is on the left. What is wrong with that I thought?

Michael’s suggestion works for me also if the dock is on the right. Michael, can you do one for the case of dock on the left, and then code that will figure out which side the dock is on?

This code should move a window to the edge of a left-aligned dock, retaining the top alignment and window size:

local a, b, c, d, dockwidth, screenwidth
getwindow a,b,c,d
screenwidth = val(rectanglestr(info("screenrectangle"))["-,",-1][2,-1])
dockwidth = screenwidth - val(rectanglestr(info("availablescreenrectangle"))["-,",-1][2,-1])
zoomalign "left"
zoomwindow a,dockwidth,c,d,""

These coordinates were taken with the dock on the left,

and these were taken with the dock on the right.

It looks like it’s measuring from the right side of the screen instead of the left.

If you already know the location of the dock, you easily can move a window to the side of the screen allowing for the size of the dock. First lets get some screen data:

local widthDifference

This will give you the width of the dock and if you know the dock is on the right side of the screen and you want to move the window far right:

windowtocorner "right-"+str(widthDifference)

If the dock is on the right and you want to move a window to the left:

windowtocorner "left"

If the dock is on the left and you want to move the window to the far left:

windowtocorner "left+"+str(widthDifference)

If the dock is on the left and you want to move the window to the far right:

windowtocorner "right"

Since zoomalign works with the bottom dock then to move a window to the top or bottom of the screen you would just use zoomalign in the normal way.

But what if you don’t know where the dock is set at the moment. Here is a sneaky way to get that info from the the dock preference .plist file. That file is a binary file and we need to get the information from the xml version of that file. The unix plutil command will help us here. We first use a shellscript command to convert the .plist file to xlm, then load it to a variable and then immediately reconvert it back to binary. Once we have the xml version in a variable we can parse out the location of the dock by checking the “orientation” tag. Having this info we can run whichever of the above lines of code we need. Here is the code to get the dock location:

local thePosition,x,y
shellscript ||| plutil -convert xml1 $«x»$|||,y
shellscript ||| plutil -convert binary1 $«x»$|||,y

If you want to move a window to the top or bottom of the screen as well as to either side, you would first use the top or bottom code and then follow with the appropriate side code. Of course the easiest option is to simply wait to see if Apple ever fixes the [NSScreen visibleFrame] problem.

Since I have two monitors I am not able to check the left dock because it places it on the second monitor’s left edge. There sure are a lot of nasty ramifications with these bugs that are hard to account for along the way.