Re: src/nsterm.m: fix window tabbing on macOS

[Alan Third <alan@idiocy.org>]

On Mon, Jun 07, 2021 at 10:27:42AM +1000, Paul W. Rankin wrote:
> 
> > On 7 Jun 2021, at 4:56 am, Alan Third <alan@idiocy.org> wrote:
> > 
> > On Sun, Jun 06, 2021 at 10:19:57PM +1000, Paul W. Rankin wrote:
> > 
> >> Alan did you see my video of this in action?
> >> https://f002.backblazeb2.com/file/pwr-share/emacs_nsterm.mov
> > 
> > Yeah, I was wrong, it is there and it's very annoying. I think there's
> > a mismatch between the calculation of the height of the content and
> > the actual height of the content. But if it's that I have no idea why
> > it disappears when the toolbar is turned off, because the calculation
> > should still be wrong.
> 
> I've forgotten, what macOS version are you on? macOS 11 combines
> native toolbars in with the titlebar, so I suspect that the
> calculations Emacs is doing expect a separate titlebar and toolbar.

10.14

Emacs does calculate the titlebar and toolbar heights, and it's pretty
good at it, frankly, except that the toolbar height includes the
tab-bar height as well, and I can't see any way round that because
neither the toolbar, nor the tab-bar are accessible as views. I don't
think that really matters, though.

The only explanation I can come up with is that there's some strange
interaction between the frame size when it's created, when the toolbar
hasn't been created yet so has zero height, and then putting that
window into the tab group.

> >> Yeah we're considering this a separate nice-to-have, right?
> > 
> > Yeah, the tabs work exactly as I'd expect them to in fullscreen given
> > the way fullscreen works just now.
> > 
> > I have to say I've spent most of the afternoon on this and I'm no
> > closer to a solution to the height changing thing, so I'm tempted to
> > revert the commit, or put it behind a build flag or something until we
> > have a better solution.
> 
> I do not think that is necessary. I'm going to go out on a limb here
> and speculate that the problem lies with the way Emacs is
> calculating its frame size, not with the OS window manager. The
> heart of it is, someone can open up Xcode and whip up a demo app
> with zero code that will function perfectly well with native tabs,
> it's not functionality that a program needs to implement, so
> whatever it is with Emacs that is interfering with or overriding
> that functionality has been added in between.

That goes without saying, but the fact of the matter is that we're
failing miserably to convince Emacs and the tab-bar to live together
in harmony. There's very little code in the ns*.m files that tries to
calculate the height of the frame, and nothing I do to it makes the
slightest bit of a difference to how the frame is drawn with tabs
enabled.

The fact that when you enable and disable the toolbar the frame size
changes is also something I can't explain because Appkit doesn't even
give Emacs a chance to set the frame size, it just does it and it even
animates the change for us, and lets us know it's been done after the
event. Perhaps we've got something set somewhere that says that the
NSView can't be resized by Appkit? I don't know, I'm not aware of any
setting like that.

Unfortunately I think the current naive enabling of the native tabs
isn't working and needs more work, so I'm going to revert the change.
I'm not saying we can't have the native tabs, just that they need to
be better behaved before we enable them.

Please keep working on this.
-- 
Alan Third