Re: 10.7 Full-Screen transition animation corrupts my UI - how to avoid?

  • Thanks everyone (Dennis, Kyle)

    I Implemented the suggested delegate --- and it doesn't even get called!!!!

    Here is my implementation, in case I'm really stupid:

    - (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize {
        NSSize min = [sender minSize];
        NSSize max = [sender maxSize];
        if (frameSize.width > max.width ||
            frameSize.height > max.height ||
            frameSize.width < min.width ||
            frameSize.height < min.height)
            return sender.frame.size;
        else
            return frameSize;
    }

    And then here is my console log from within a resizing delegate call for some inner subview (NSSplitView).

    -(void) splitView:(NSSplitView *)splitView resizeSubviewsWithOldSize:(NSSize)oldSize {
        NSSize newSize = splitView.frame.size;  // to accompany the oldSize...
    .
    . // my handling code in here
    .
    .

    #ifdef    PA_DEBUG
        if (newSize.height < totalMinSize.height) {
            NSLog(@"%@ too short for subviews (need %.1f, has %.1f)). %@ will be collapsed", splitView, totalMinSize.height, newSize.height, autoClosePanelView);
            NSSize winMinSize = _splitView.window.contentMinSize;
            NSView *contentView = _splitView.window.contentView;
            NSSize winCurrentSize = contentView.frame.size;
            NSLog(@"Window min content size:%@ current size %@", NSStringFromSize(winMinSize), NSStringFromSize(winCurrentSize));
        }


    Which yields in the console the following log lines:

    2012-07-22 11:44:01.178 AT&T Connect[19369:407] <NSSplitView: 0x6659ac0> too short for subviews (need 579.0, has 517.0)). <PAMeetingMinutesBaseView: 0x6977460> will be collapsed
    2012-07-22 11:44:01.178 AT&T Connect[19369:407] Window min content size:{1001, 579} current size {1001, 517}

    As you can see, my window is forced to get to 517 pixels height, despite my imposed minSize of 579 pixels, and in spite of the implementation you suggested.

    What now?

    On 19 ביול 2012, at 18:09, Dennis wrote:

    > On Jul 19, 2012, at 5:17 AM, Motti Shneor wrote:
    >
    >> How can a view disregard resizing request? It is simply resized....
    >
    > How about...
    >
    > - (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize
    >
    > in your window delegate? As I recall, this works to prevent resizing by returning the size you want the window to be set to.
    >

    Motti Shneor
    e-mail: <motti.shneor...>
    phone: +972-8-9267730
    mobile: +972-54-3136621
    ----------------------------------------
    Ceterum censeo Microsoftinem delendam esse
  • On Jul 22, 2012, at 2:00 AM, Motti Shneor wrote:

    > I Implemented the suggested delegate --- and it doesn't even get called!!!!
    >
    > Here is my implementation, in case I'm really stupid:

    My guess is that you neglected to either set the delegate for the window, or to declare the NSWindowDelegate protocol in your delegate. I just put together a simple project that shows the method gets called, and does what it's supposed to, in Lion.
  • On Sun, Jul 22, 2012, at 09:13 AM, Dennis wrote:
    > On Jul 22, 2012, at 2:00 AM, Motti Shneor wrote:
    >
    >> I Implemented the suggested delegate --- and it doesn't even get called!!!!
    >>
    >> Here is my implementation, in case I'm really stupid:
    >
    > My guess is that you neglected to either set the delegate for the window,
    > or to declare the NSWindowDelegate protocol in your delegate. I just put
    > together a simple project that shows the method gets called, and does
    > what it's supposed to, in Lion.

    Even when triggering full-screen?

    --Kyle Sluder
  • On Jul 22, 2012, at 10:12 AM, Kyle Sluder wrote:

    > On Sun, Jul 22, 2012, at 09:13 AM, Dennis wrote:
    >> On Jul 22, 2012, at 2:00 AM, Motti Shneor wrote:
    >>
    >>> I Implemented the suggested delegate --- and it doesn't even get called!!!!
    >>>
    >>> Here is my implementation, in case I'm really stupid:
    >>
    >> My guess is that you neglected to either set the delegate for the window,
    >> or to declare the NSWindowDelegate protocol in your delegate. I just put
    >> together a simple project that shows the method gets called, and does
    >> what it's supposed to, in Lion.
    >
    > Even when triggering full-screen?

    It constrains the window to the assigned size when entering Full Screen mode.
  • On Jul 22, 2012, at 02:00 , Motti Shneor wrote:

    > - (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize {
    > NSSize min = [sender minSize];
    > NSSize max = [sender maxSize];
    > if (frameSize.width > max.width ||
    > frameSize.height > max.height ||
    > frameSize.width < min.width ||
    > frameSize.height < min.height)
    > return sender.frame.size;
    > else
    > return frameSize;
    > }

    AFAICT this implementation doesn't do anything. As was mentioned in another thread yesterday or the day before, and in the class documentation, the min/max constraints have already been applied when this method is called, so re-testing the constraints is pointless.

    Of course, that doesn't explain how the window gets smaller than it should be.

    (Also, it seems wrong to return sender.frame.size, since that would prevent the window from actually getting pinned to the limits enforced by this method, if there were any.)

    (Also, if you're using min/maxContentSize as shown in your other code sample, you should check that everywhere rather than min/maxSize in some places. The documentation says the min/maxContentSize constraint "overrides" min/maxSize, not "sets" it.)

    > 2012-07-22 11:44:01.178 AT&T Connect[19369:407] Window min content size:{1001, 579} current size {1001, 517}
    >
    > As you can see, my window is forced to get to 517 pixels height, despite my imposed minSize of 579 pixels, and in spite of the implementation you suggested.

    It would be slightly more reassuring to log all of the window's size, with min and max, as well as the content size, with min and max, as they are this moment in execution.

    Incidentally, NSWindow's 'setFrame:display:' is documented to ignore the min/max sizes. Is there any place you're calling this yourself?
  • Thanks, guys, for all the help.

    Of course the implementation below is meaningless, and also isn't the right thing to do --- It should have returned min/max size if at all.
    I only put it to see if I get there in the debugger (set a breakpoint on the strange lower-than-minimal situation).

    - (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize {
      NSSize min = [sender minSize];
      NSSize max = [sender maxSize];
      if (frameSize.width > max.width ||
          frameSize.height > max.height ||
          frameSize.width < min.width ||
          frameSize.height < min.height)
          return sender.frame.size;
      else
          return frameSize;
    }

    The application UI is dynamic and  quite complicated. It's built from plugin-like modules, each with its own code and .xib with its min/max sizes. After I load all my modules I lay-out my main window with these sub-views, and calculate the overall min/max content size for the window. I then setContentMinSize: and setContentMaxSize: This mechanism works fine. Calculations are right, and have been thoroughly tested.

    There is no way I missed setting the window delegate, because
    1. I set it for sure (double-checked the code and .xib, and my NSWindowController is also the delegate for its window).
    2. many other window-delegate calls are being called without a problem.
    3. This very implementation DOES GET CALLED, except for in the transition to FullScreen!

    I can send in any log that will shed light of this behavior, but spending the last 2 months rolling my own "auto-layout" mechanism, believe me I know when window-size is getting  wrong.

    The snippet I used, is where the problem affects the user --- there is some split-view with several internal "panels" (sub-views) and one of them is automatically collapsed (because the split-view becomes too small for all the panels in their min-size). I have min/max sizes all the way down. So it's really weird for a user to have one panel auto-collapse, when enlarging the window to full-screen.

    On 22 ביול 2012, at 20:22, Quincey Morris wrote:

    > On Jul 22, 2012, at 02:00 , Motti Shneor wrote:
    >
    >> - (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize {
    >> NSSize min = [sender minSize];
    >> NSSize max = [sender maxSize];
    >> if (frameSize.width > max.width ||
    >> frameSize.height > max.height ||
    >> frameSize.width < min.width ||
    >> frameSize.height < min.height)
    >> return sender.frame.size;
    >> else
    >> return frameSize;
    >> }
    >
    > AFAICT this implementation doesn't do anything. As was mentioned in another thread yesterday or the day before, and in the class documentation, the min/max constraints have already been applied when this method is called, so re-testing the constraints is pointless.
    >

    You're right. This was only debug-code to let me see if this delegate gets called with lower-than-minimum size, and if its implementation could save me in transition-time to full-screen. Unfortunately, it doesn't

    > Of course, that doesn't explain how the window gets smaller than it should be.
    >
    > (Also, it seems wrong to return sender.frame.size, since that would prevent the window from actually getting pinned to the limits enforced by this method, if there were any.)
    >
    See above.

    > (Also, if you're using min/maxContentSize as shown in your other code sample, you should check that everywhere rather than min/maxSize in some places. The documentation says the min/maxContentSize constraint "overrides" min/maxSize, not "sets" it.)

    As explained above, I have a whole mechanism for that. Every module calculates its own min/max size from its own constraints and its sub-module constraints, and "reports" it up. This is done recursively, and the window's contents view is just at the top.

    >
    >> 2012-07-22 11:44:01.178 AT&T Connect[19369:407] Window min content size:{1001, 579} current size {1001, 517}
    >>
    >> As you can see, my window is forced to get to 517 pixels height, despite my imposed minSize of 579 pixels, and in spite of the implementation you suggested.
    >
    > It would be slightly more reassuring to log all of the window's size, with min and max, as well as the content size, with min and max, as they are this moment in execution.
    >
    > Incidentally, NSWindow's 'setFrame:display:' is documented to ignore the min/max sizes. Is there any place you're calling this yourself?

    Nope. Never. My windows are plain NSWindow instances until now, but I could create a subclass, for the sake of pinning down a "setFrame:display:" with lower-than-min size, just to prove it happens.

    One thing you say raises a question, though. How can minContentSize: "override" the "minSize" ? these are two different sizes, isn't it?. I'm using setContentMinSize because I don't know how to calculate the "minSize" which also depends on the presence of tool-bar, title-bar and other window parts that can change with versions of the OS. Am I wrong here? should I directly call setMinSize/setMaxSize on my windows?

    I assumed that the window's minSize is calculated from its contentMinSize, plus the other parts of the window.

    Motti Shneor
previous month july 2012 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today