Subject: bug#25408: Remove Decorations Around Emacs Frame (NS port)

From: martin rudalics <[email-masked]>
Date: Sun, 16 Jul 2017 10:28:19 +0200

>>> It appears that making the child frame invisible ‘disconnects’ it from
 >>> the parent frame, so the next time it’s made visible it no longer
 >>> moves with the parent. I guess I’ll have to make sure that when a
 >>> frame is made visible it’s reconnected with it’s parent. Or find a way
 >>> to prevent it disconnecting. It seems a really odd thing for it to do.
 >
 > I’ve pushed a fix for this now.

Thanks.  One of the largely untested behaviors with frames is what a
frame looks like when it was invisible/iconified for a while, in that
period operations (resizing, moving, reparenting) have been applied to
it and the frame is made normally visible again.  I've been struggling a
while with the similar problem how to set a frame's size when it was
fullscreen for a while and in that period a resize request was posted
for it.

 > It turned out that there was no NS version of
 > mouse-absolute-pixel-position, so I’ve created one and suddenly all of
 > the above things work. :)

Fine.  Please add a

(declare-function ns-mouse-absolute-pixel-position "nsfns.c")

to frame.el.

 > I’m slightly worried that there may be issues if the frame is resized
 > across a screen edge, as it treats each screen as it’s own ‘space’,
 > starting at (0, 0) at the top left. This is how the existing
 > set-mouse-absolute-pixel-position works so it makes sense to me to
 > keep them the same.
 >
 > It might make more sense to treat multiple screens as one ‘space’,
 > though. I’m not sure.

Can you give me an example?  I never use multiple screens so my ability
to imagine how a mouse behaves there is very limited.  There's also the
problem that some systems (Windows, IIRC) consider (0, 0) the top-left
corner of some sort of "primary" screen and allow negative coordinates
while others consider (0, 0) an abstract location at the top-left corner
of all screens.

Thanks, martin