My favorites | Sign in
Project Home Issues
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 309: Without scrollbar, accessibility based resizing is off.
1 person starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----


Sign in to add a comment
 
Reported by dcur...@gmail.com, Jan 4, 2011
What steps will reproduce the problem?
I use a program called Divvy which allows me to create macros to resize windows (like split screen that windows does or tiling window managers) and there are a number of similar options.

When I disable the scrollbar, MacVim seems to take up more space then it's told to resize to.  I don't know a lot about how it works but it seems like the main system windowing manager gets a signal to resize a particular window and it does it.  (Enable access for assistive devices has to be enabled in my Universal Access settings for any of these apps to even work).

What is the expected output? What do you see instead?
Anyways, when I split the screen 50/50 using Divvy, Macvim actually creeps over a bit and takes over more than it should.  I am going to attach a screenshot and you can see the overlap.  In face, I can see MacVim go to the requested size then expand a bit.  I imagine this is due to MacVim calculating the required size for fonts, rounding to the nearest, and expanding to accommodate it.  However, I think that MacVim should actually always round down in the case that it gets a call to resize to a specific dimension.

What version of MacVim and OS X are you using (see "MacVim->About MacVim"
and  "Apple Menu->About This Mac" menu items, e.g. "Snapshot 40, 10.5.6
Intel")?

I am using Snapshot 56, 10.6.5

Please provide any additional information below.

Screen shot 2011-01-04 at 2.40.57 PM.png
13.1 KB   View   Download
Screen shot 2011-01-04 at 2.42.00 PM.png
8.9 KB   View   Download
Jan 8, 2011
Project Member #1 bjorn.winckler@gmail.com
I agree - it should round down.  I'll see if I can fix this.

By the way, does it only happen in the horizontal direction (as in your screen shot)?  Or does it happen vertically as well?
Jan 8, 2011
#2 dcur...@gmail.com
Vertical seems to suffer the same problem.  In the attached file I sized iTerm, Mail, and MacVim to the same size.  You can see that iTerm sizes down to match the size of the text, Mail sizes to the exact size since it doesn't worry about fonts, and MacVim is actually sized bigger.  Looks like it's just a matter of rounding when resizing so should be an easy fix.  Wherever it handles a resize event.
Screen shot 2011-01-08 at 1.26.23 PM.png
11.0 KB   View   Download
Jan 9, 2011
Project Member #3 bjorn.winckler@gmail.com
I had a quick look and it is not a simple rounding problem, so I am going to have to find a way to reproduce the bug before I can fix it (which will take time).

By the way, does it only occur when the scrollbar is disabled?
Jan 9, 2011
#4 dcur...@gmail.com
It doesn't seem to happen when there are scrollbars.
Jan 9, 2011
#5 dcur...@gmail.com
I think i need to add that I'm using the experimental rendering but I just disabled it an it didn't make any effect.

The other weird thing is that if I enable the bottom scrollbar, it oversizes down also.  Is there something where the window size doesn't take into affect the titlebar area or does Cocoa only report the size of the inner contents?
Jan 9, 2011
#6 dcur...@gmail.com
Hey Bjorn,

After much debugging I figured out this is definitely an OSX issue (more specifically I think it's a Cocoa issue) because I went back and compared this with iTerm and when I disable scrollbars and set a specific width, it does behave in the same way.  If I enable scrollbars in iTerm then this doesn't happen.  There *has* to be something in how the NSWindow is calculating its frame size and reporting it that is off.  Normally I think Cocoa gets away with this because most people don't do this kinda thing.  In the future version of Divvy they are going to allow people to set borders around resizing so this should help me a bit just so things don't overlap.

Lets close this up but refer to the bottom to see what trouble I got myself into (jokingly speaking).  

I did some debugging in the MacVim source and I found the following code would resolve the issue but it didn't properly render the internal content (the VimView, TextView, etc.)


- (NSRect)contentRectForFrameRect:(NSRect)frame
{
    NSRect rect = [super contentRectForFrameRect:frame];
    if (![tablineSeparator isHidden])
        --rect.size.height;

	rect.size.height -= 1;
	rect.size.width -= 1;
    return rect;
}

- (NSRect)frameRectForContentRect:(NSRect)rect
{
    NSRect frame = [super frameRectForContentRect:rect];
    if (![tablineSeparator isHidden])
        ++frame.size.height;
	frame.size.height +=1;
	frame.size.width +=1;
    return frame;
}

Jan 9, 2011
#7 dcur...@gmail.com
Also, iTerm suffers the same problem resizing down also, but only when you *don't* have the tab bar open.  WTF???

RANDOM!
Jan 9, 2011
Project Member #8 bjorn.winckler@gmail.com
This sounds very peculiar.  Maybe there is an off-by-one bug in MacVim...it sounds unlikely that it is a bug in Cocoa.

Changing the methods you mentioned is probably not the right solution (even if you did get it working), but if you figure it out please let me know.

When I get the time I thought I'd try debugging this by changing the window frame size from some Apple Script and see if I can reproduce the problems but I doubt I'll get time for this in the next few weeks or even months.
Jan 9, 2011
#9 dcur...@gmail.com
Yeah, but like I said, iTerm does the same thing.  I don't believe they ripped off your code???  Why would both programs suffer the same problem in the same situation?

What is interesting is that if you actually look at mac windows, there is a one-pixel border around most windows.  That would lead me to believe there should be a difference between the frame size and the contents size, but that's not what they report.
Jan 9, 2011
#10 dcur...@gmail.com
bjorn,

more testing here.  please read carefully.

I put the "setFrame" function into the MMWindow class to catch when it was getting called.  I put in a breakpoint and it is getting called twice by the NSWindow(NSWindowAccessiblity) accessibilitySetSizeAttribute function which is not part of the public API.  But what is more interesting is below.

I wrote an applescript to set the window size to exactly half of my screen size, 840.  But when "accessibilitySetSize"  calls "setFrame" it's setting the width to 843!  If I change my applescript to set the window to 839, then "accessibilitySetSize" calls "setFrame" with a width of 836.

What I believe is happening is that NSWindowAccessibility is looking at the setting for "resizeIncrements" and it is rounding rather than doing a "floor".  This makes sense because the incrementSize is 7.  I believe the first call is to see the size of the window and get the remainder.  Here are my two examples.

Lets say I want my window to be 840 and originally my window is 493 wide, well, 493-floor(493/7)=3.  So you can deduce that there is 3 pixels of extra window width.  So, accessibility says, OK, I want the window to be 840, so 840/7 = 120, and 120*7+3 is 843.

Now, lets say instead I want my window to be 839 and again my window is originally 493, so again we have 493-floor(493/7)=3.  This time accessibility wants the window to be 839, so 839/7=119 and 119*7+3 is 836.


I am attaching my Automator script for testing.
Window Left Half.workflow.zip
64.4 KB   Download
Jan 9, 2011
#11 dcur...@gmail.com
I screwed up the original remainder calculation in my examples, it should've been: 493-floor(493/7)*493=3 because floor(493/7)=70 and 70*7 = 490.  Sorry about confusion there.  I hope this clears things up.
Jan 10, 2011
Project Member #12 bjorn.winckler@gmail.com
Thanks for the information - your analysis makes sense.  I can't think of an immediate solution to this problem so I am open to suggestions.
Sign in to add a comment

Powered by Google Project Hosting