bug#25818: 25.2; frame moved off display does not return (OS X)

[Anders Lindgren]

Hi!

 

I've tested my patched version of Emacs master and I can stretch one
frame across both screens (seemingly) without any problem.  It is
possible that my patched version would not do the right thing on OS X
10.9+, though, if the interaction with "Spaces" and constrainFrameRect
is different there.

[BTW, if I understand right, "Spaces" in Mac OS X 10.9+ prevent you from
having any frame spanning multiple monitors.  Does the current Emacs
code (without my patch) remove that limitation?]

In 10.9, a "space" is a dedicated full-frame area. I don't think your patch will affect this.

It took quite a lot of work to get the current implementation to work for a variety of scenarios. To throw in a "quick fix" for another scenario will most likely break things that work today. It would be better to identify some situations when the function should behave differently and fix those specific cases.

> A better solution would be to add to code to check if the Emacs frame is
> outside any monitor, and then (and only then) call the constrainFrameRect
> method of the parent class.

Your use case above for a frame (placing it above the top of the screen,
as with `(set-frame-position (selected-frame) 0 -10)' in your test
code), would (I think) count as bringing the frame outside of a screen,
and therefore constrainFrameRect would kick in, bringing the frame back
to ((top . 0) (left . 0)) -- as my patched version does.  But this is
apparently not what you want.  So we would need to allow some leeway in
the calculation to allow a frame to be only slightly outside of a
monitor?  This sounds complicated to me.

I think it is acceptable if a frame is partially outside the display. What I suggested was to check if the frame was ENTIRELY outside any monitor, and in that case call the parent function to bring it in. This test should be trivial to implement.

You can find a lot of the recent design decisions of the NS port in the epic discussion thread of bug 21415.

Also, thank you for pointing out `ns-auto-hide-menu-bar'.  I did not
know about that variable.  But I do not understand why you would want to
place a frame above the top of the screen when the menu bar is hidden.
It might give you an extra row of text, at the cost of obscuring the
close/iconify/maximize buttons, and the frame title.  You could get more
bang for your buck by turning off `tool-bar-mode', IMO.  And I don't
think OS X natively allows a user to place a frame above the top of the
screen anyway.

By placing the title bar above the top of the screen, I'm able to use the entire height of the monitor for text, while having access to the menu by moving the mouse pointer to the top of the screen. I don't need the buttons and the frame title is of little use.

Admittedly, I'm a bit crazy when it comes to screen real estate -- with a small font, six side-by-side windows, and Follow mode enabled, I get 888 consecutive lines of text.

> Anyway, I'm glad that you have looked into this. The number of people
> actively working on the NS port are close to zero (I threw in the towel
> about a year ago, simply because I couldn't find the time I needed to spend
> on it). If you are interested in contributing, you can look at the
> "NeXTstep port" section of the "TODO" file.

Will do.  Do you know of any good resources for tinkering in this area?
I have some old Apple docsets available which I haven't really gotten
around to reading yet, but that's about it.

I mostly look at the reference documentation like https://developer.apple.com/reference/appkit/nswindow

There are tons of introductory text on macOS (which, internally, is similar for iOS). You have to look for one which suit your background knowledge. You can, however, skip anything related to the "Interface Builder", since it's not used by Emacs. If you don't know Objective-C, I would recommend you to start with an introduction to that, and go from there.

    -- Anders