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

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5321 bytes --]