I’m finding that all windows expand to full screen if you click the enlarge button even when “Full-screen button” is off in the IDE settings. This is causing some UI headaches, such as full screen windows over other full screen windows. Is there a workaround?
Wasn’t this fixed in 2015r3?
Apparently not.
I’m not seeing this. How do your UI headaches look like?
If a full screen window (legitimate) is displayed and you open another window (that should not be full screen), the second window becomes full screen, too, overlying the first window.
But you don’t need to bother with that setup to see this. All I do is
- Create a new desktop project (Full-screen button is set to off).
- Run and click the green button – the window goes full screen, hiding the menu bar.
Looks okay to me. Can you post a screenshot?
I could, but it wouldn’t tell you anything. It’s just a full screen window (no menu bar, just a window at full dimensions). BTW, this is with the latest update to 10.11.1, if that matters. It doesn’t happen in Yosemite, and I don’t know about the initial release of El Capitan. But it’s certainly happening in 10.11.1 (one other user has sent a video to me confirming this).
This isn’t exactly a bug. From the 10.11 AppKit release notes:
[quote]NSWindow will implicitly opt certain candidate windows into becoming full screen capable. An explicit full screen capable window has the NSWindowCollectionBehaviorFullScreenPrimary bit set in the window.collectionBehavior. A candidate for an implicitly full screen capable window will be a titled NSWindow that is resizable, and can resize to fit the entire screen. The exact semantics of this may change over time, and it is recommended to explicitly opt in primary document windows by including NSWindowCollectionBehaviorFullScreenPrimary in the collectionBehavior.
When in full screen, if a new window is shown the following logic takes effect: A new full screen space will be created for explicit full screen windows. For implicit full screen windows, the window will simply be shown on the current full screen space. These exact semantics may change over time.[/quote]
Thanks, Joe. I’m not sure what the rules are here:
“A candidate for an implicitly full screen capable window will be a titled NSWindow that is resizable, and can resize to fit the entire screen.”
Thats sounds like pretty much any Xojo document window. Is there an opt-out flag, so-to-speak? Or do we just have to live with this?
Sounds like the last paragraph is what you’re seeing
The way I read that it sounds like when your app is in full screen mode IF it creates a new window that could operate in full screen mode it is made full screen
Close, but not exactly. There are several issues:
-
If I click the green button of a normal document window that is not set to be full-screen capable (in the IDE) it does go full screen.
-
(And to your point), if I have a full screen window open and open another window (that should be be full screen), it opens full screen even immediately – I’m not clicking the green button to make it full screen, it just happens. I see this in Safari, too (it’s just the first example I tried) – make a window full-screen, then open a bookmark in a new window (right-click). It automatically opens as full screen. So it seems that this it the new OS behavior, nothing to do with Xojo.
Thanks for your reply.
Right
Thats the fist part of the note
The OS has decided that since its a titled, resizable window that could resize to fill the screen it should be able to make it full screen
Maybe in the open event (possibly others so if it moves from one screen to another) make it resize up to 5 pixels less than the size of the screen
Then it cant resize to fill the screen so the OS may not opt it into being full screen
Thanks for the thought, but the window remembers sizes between launches and automatically reassumes the size the user wants. I’ll jus have to explain to any users that open two full size windows at once this this is the new black.
There’s some control of it with NSWindow’s collectionBehavior property. You can set a window to be ‘auxiliary’, which means it can be shown in the same space as a fullscreen window (but can’t itself be made fullscreen, I think). Other windows that are resizable should just set the FullscreenButton property to True, which will at least make it go on on its own space when shown.
Here is some untested code:
Declare Function collectionBehavior Lib "AppKit" Selector "collectionBehavior" ( obj As Integer ) As UInteger
Declare Sub setCollectionBehavior Lib "AppKit" Selector "setCollectionBehavior:" ( obj As Integer, value As UInteger )
Const NSWindowCollectionBehaviorFullScreenAuxiliary As UInteger = 256
Dim behavior As UInteger = collectionBehavior(myWindow.Handle)
setCollectionBehavior(myWindow.handle, behavior Or NSWindowCollectionBehaviorFullScreenAuxiliary)There’s also the Improving the Full Screen Window Experience talk from this year’s WWDC.
Do you ever get the feeling that Full Screen will be the only way one day?
No.
full screen is a crappy experience on my multi monitor set up
Agreed.
Glad you think so.
I’m not so sure… El Capitan is more of a merger of iOS and OS X, heck one of the bugs I reported during the beta stage has been present on iOS for 3 years, and not in OS X until El Capitan (which suggests that they copied the iOS code over to OS X).
El Capitan auto adds a Full Screen menuitem (which doesn’t always work) and now it assumes that if one of your windows can go Full Screen, they all can…
Then we have the iPad Pro.
Windows 8 tried this and if you’ll recall, it did NOT go over well. 