(Sorry, not sure if there are already threads on this - I blame the forum’s bad search function for this.)
OS X 10.12 Sierra adds the ability to merge windows into a single window using Tabs.
For some reason, though, all my Xojo-made apps use this Tab feature automatically. Is that normal, i.e. is that happening for everyone? Or do I have some wonky settings, maybe from running the Sierra betas, on my Mac I need to change?
Either way, I have the impression Xojo’s UI framework is handling tabbed windows incorrectly - it doesn’t automatically adjust for the changed window sizes, so that locked controls do not adjust accordingly. This damages every app’s layout that I’ve tried so far. They all use the classic framework. Not sure if the new one does better, but switching to the newer framework is no option for my large apps at this point, regardless.
What’s the verdict on this?
You could disable it.
NSWindowMBS.allowsAutomaticWindowTabbing = false
Or write feedback case to request support for it.
Thanks for pointing out that setting, but what I’m more concerned about is the second part of my question, i.e. whether the non-adjusting controls when a window gets tabs added is to be considered a bug, and one with high priority, at that, now that this is a common behavior in 10.12.
I’ve noticed a similar misbehavior many years ago, wherein Xojo’s UI framework did not handle this correctly: E.g, if you manipulated the window’s size using the OSX’s Window APIs, Xojo’s controls did not adjust properly, either. I wonder if this is now related. It certainly both looks like the controls arrangement is not routed thru the right channels, i.e. thru resize handlers for the main view, but instead Xojo code makes assumptions about what should happen and ignores the view’s actual changes and callbacks.
I’ll post a demo later as it seems others are not even seeing this.
So, here are some visuals to demonstrate the problem.
First off, let’s assume the user has chosen to use Tab everywhere, with this option in the Dock’s System Preferences:
Let’s assume our app has a window with a listbox that’s locked on all sides, and a button that’s locked to the bottom right:
Now we use the File / New (cmd+N) menu command to open a new window. While on pre-Sierra systems this would open a second window, on Sierra this adds a new tab, like this:
This is clearly not right. The problem here is that neither does Xojo automatically adjust the controls as it does when the user resizes the window by dragging its border, nor do we get a call to the window’s Resized() event. Both are obviously not correct behaviors, because the window’s size (and by that I mean the CONTENT size, which is what matters to us devs when we monitor resize events) has clearly changed.
Which means that if we wanted to support Sierra’s Tab feature in our apps, we cannot get this under control. Thus this is a bug, and one that should be fixed sooner than later. Or does someone know a work-around for this?
Demo project’s source is here.
The problem is (IMHO) the window isn’t being resized, it’s the content bounds of the Windows that’s being resized. With some simply declares, you might be able to check for this in the “Activate” event and then resize the window to fit.
So, since no one has claimed this not being a bug in Xojo, I’ve gone ahead and reported it as a bug: