GNU bug report logs - #36672
27.0.50; NS build: Creating child frame leads to empty space

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36672 in the body.
You can then email your comments to 36672 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; NS build: Creating child frame leads to empty space
Date: Mon, 15 Jul 2019 20:38:31 +0300

[Message part 1 (text/plain, inline)]

Assume there are only one space - Desktop
1. emacs -Q
2. M-x toggle-frame-fullscreen
   Now there are two spaces - Desktop and *scratch*
3. eval (make-frame `((parent-frame . ,(window-frame))))
   Now there are three spaces:
   - Desktop
   - Empty space named *scratch* with emacs menu
   - *scratch* with emacs frames but without menu

Although attached patch solves this problem for me these cases still not
handled right way:

1. Removing parent-frame property leaves the frame is same space:

(let ((new-frame (make-frame `((parent-frame . ,(window-frame))))))
  (modify-frame-parameters new-frame `((parent-frame . nil))))

Maybe child frame must go fullscreen if ex-parent frame is in
fullscreen.

2. Setting parent frame after frame creation:

(let ((frame (window-frame))
      (new-frame (make-frame)))
  (modify-frame-parameters new-frame `((parent-frame . ,frame))))

Thanks!

In GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin18.6.0, NS
appkit-1671.50 Version 10.14.5 (Build 18F132))
Windowing system distributor 'Apple', version 10.3.1671
System Description:  Mac OS X 10.14.5

[ns-emacs-spaces.patch (application/octet-stream, attachment)]

Message #8 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to
 empty space
Date: Tue, 16 Jul 2019 20:28:22 +0100

On Mon, Jul 15, 2019 at 08:38:31PM +0300, Andrii Kolomoiets wrote:
> Assume there are only one space - Desktop
> 1. emacs -Q
> 2. M-x toggle-frame-fullscreen
>    Now there are two spaces - Desktop and *scratch*
> 3. eval (make-frame `((parent-frame . ,(window-frame))))
>    Now there are three spaces:
>    - Desktop
>    - Empty space named *scratch* with emacs menu
>    - *scratch* with emacs frames but without menu

I hit C-x C-c at this point to exit Emacs and it completely crashed my
session. Not great...

The patch looks good to me, but lets see if we can find solutions to
these other issues. To be honest, given that Apple don’t provide any
way to properly deal with spaces, I’d expect this stuff to be handled
sensibly by default, but I guess that’s too much to ask.

> 1. Removing parent-frame property leaves the frame is same space:
> 
> (let ((new-frame (make-frame `((parent-frame . ,(window-frame))))))
>   (modify-frame-parameters new-frame `((parent-frame . nil))))
> 
> Maybe child frame must go fullscreen if ex-parent frame is in
> fullscreen.

I suppose the best thing to do would be to move it onto the first
space, but there’s no API for that, apparently. Going fullscreen seems
like a reasonable work‐around to me.

> 2. Setting parent frame after frame creation:
> 
> (let ((frame (window-frame))
>       (new-frame (make-frame)))
>   (modify-frame-parameters new-frame `((parent-frame . ,frame))))

What do you see happening in this case? I’ve got spaces turned on and
everything I do just seems to create a new fullscreen space (except
when it crashes my session).

-- 
Alan Third

Message #11 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Third <alan <at> idiocy.org>, Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to empty
 space
Date: Wed, 17 Jul 2019 10:39:15 +0200

>> Assume there are only one space - Desktop
>> 1. emacs -Q
>> 2. M-x toggle-frame-fullscreen
>>     Now there are two spaces - Desktop and *scratch*
>> 3. eval (make-frame `((parent-frame . ,(window-frame))))
>>     Now there are three spaces:
>>     - Desktop
>>     - Empty space named *scratch* with emacs menu
>>     - *scratch* with emacs frames but without menu
>
> I hit C-x C-c at this point to exit Emacs and it completely crashed my
> session. Not great...

No backtrace?  It sounds already strange that one apparently gets two
spaces with the same name "*scratch*" here.  Do things return to
"normality" when one deletes the child frame before trying to exit
Emacs?  BTW, does maximizing a frame run into similar problems?

> The patch looks good to me,

Does it work with two child frames of the same parent?

> but lets see if we can find solutions to
> these other issues. To be honest, given that Apple don’t provide any
> way to properly deal with spaces, I’d expect this stuff to be handled
> sensibly by default, but I guess that’s too much to ask.
>
>> 1. Removing parent-frame property leaves the frame is same space:
>>
>> (let ((new-frame (make-frame `((parent-frame . ,(window-frame))))))
>>    (modify-frame-parameters new-frame `((parent-frame . nil))))
>>
>> Maybe child frame must go fullscreen if ex-parent frame is in
>> fullscreen.

Does making it fullscreen then give it a separate menu?  Note also
that the new parent could be another frame (even a child frame).

> I suppose the best thing to do would be to move it onto the first
> space, but there’s no API for that, apparently.

What happens when one sets 'parent-frame' to nil and removes the
'NSWindowCollectionBehaviorFullScreenAuxiliary' simultaneously?

> Going fullscreen seems
> like a reasonable work‐around to me.
>
>> 2. Setting parent frame after frame creation:
>>
>> (let ((frame (window-frame))
>>        (new-frame (make-frame)))
>>    (modify-frame-parameters new-frame `((parent-frame . ,frame))))
>
> What do you see happening in this case? I’ve got spaces turned on and
> everything I do just seems to create a new fullscreen space (except
> when it crashes my session).

Can't one set the 'NSWindowCollectionBehaviorFullScreenAuxiliary' just
as with the initial frame here?

martin

Message #14 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to empty
 space
Date: Wed, 17 Jul 2019 21:51:47 +0300

[Message part 1 (text/plain, inline)]

On Jul 16, 2019, at 22:28, Alan Third <alan <at> idiocy.org> wrote:
> 
> On Mon, Jul 15, 2019 at 08:38:31PM +0300, Andrii Kolomoiets wrote:
>> Assume there are only one space - Desktop
>> 1. emacs -Q
>> 2. M-x toggle-frame-fullscreen
>>   Now there are two spaces - Desktop and *scratch*
>> 3. eval (make-frame `((parent-frame . ,(window-frame))))
>>   Now there are three spaces:
>>   - Desktop
>>   - Empty space named *scratch* with emacs menu
>>   - *scratch* with emacs frames but without menu
> 
> I hit C-x C-c at this point to exit Emacs and it completely crashed my
> session. Not great...
> 
> The patch looks good to me, but lets see if we can find solutions to
> these other issues. To be honest, given that Apple don’t provide any
> way to properly deal with spaces, I’d expect this stuff to be handled
> sensibly by default, but I guess that’s too much to ask.
> 
>> 1. Removing parent-frame property leaves the frame is same space:
>> 
>> (let ((new-frame (make-frame `((parent-frame . ,(window-frame))))))
>>  (modify-frame-parameters new-frame `((parent-frame . nil))))
>> 
>> Maybe child frame must go fullscreen if ex-parent frame is in
>> fullscreen.
> 
> I suppose the best thing to do would be to move it onto the first
> space, but there’s no API for that, apparently. Going fullscreen seems
> like a reasonable work‐around to me.
> 

I manage to make this code work. Please see attached updated patch.
But this patch is not completely ready as it missing compilation conditions.
Just hope you find it useful.

>> 2. Setting parent frame after frame creation:
>> 
>> (let ((frame (window-frame))
>>      (new-frame (make-frame)))
>>  (modify-frame-parameters new-frame `((parent-frame . ,frame))))
> 
> What do you see happening in this case? I’ve got spaces turned on and
> everything I do just seems to create a new fullscreen space (except
> when it crashes my session).
> 

I see same result as in the first case: Desktop, empty blank space
with Emacs menu, space with Emacs frame and no menu/titlebar.

Still can't make this case work. Probably window animation stand in the way:

nsterm.m  : 1869: [  376]  ns_set_parent_frame
nsterm.m  : 1912: [  377]  | child frame must not be in fullscreen
2019-07-17 21:20:49.027 Emacs[91925:3597098] not in fullscreen state

If ns_set_parent_frame is called while window is still in process of going
full screen then maybe it must be deferred until animation ends.

[ns-emacs-spaces-wip.patch (application/octet-stream, attachment)]

Message #17 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to empty
 space
Date: Tue, 23 Jul 2019 21:14:19 +0300

[Message part 1 (text/plain, inline)]

> On Jul 16, 2019, at 22:28, Alan Third <alan <at> idiocy.org> wrote:
> 
> The patch looks good to me, but lets see if we can find solutions to
> these other issues.

I made some progress on this issue.

The idea is to wait for fullscreen transition to complete:
- Set property isFullScreenTransition on windowWillEnterFullScreen and
  windowWillExitFullScreen events;
- Clear that property on windowDidEnterFullScreen and
  windowDidExitFullScreen events;
- Wait for property to be cleared when we need to.

Removing parent-frame property causes child frame to enter fullscreen
if some of parent frames is in fullscreen.

Setting parent-frame property to fullscreen window causes window to
leave fullscreen.

As a side effect (sleep-for 0.5) in toggle-frame-fullscreen is no
longer needed (bug#28496).

But I need help with some questions:

1. Is it the rigth way to wait for some NS event by calling
   wait_reading_process_output or is there a better way?

2. I commented some code in windowDidMove with FIXME comment.
   After windowDidMove event is triggered, windowDidExitFullScreen is
   not received and fullscreen transition is never "completed".
   With that code commented windowDidExitFullScreen is received.
   Is this code somehow breaks the events queue?

Actually it is the first time I'm working with the C side of Emacs.
And with AppKit. And with C :) Please let me know if my decisions
and conclusions are wrong.

Thanks!

[ns-emacs-spaces.patch (application/octet-stream, attachment)]

Message #20 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to
 empty space
Date: Fri, 14 Feb 2020 10:23:22 +0200

[Message part 1 (text/plain, inline)]

Andrii Kolomoiets <andreyk.mad <at> gmail.com> writes:

>> On Jul 16, 2019, at 22:28, Alan Third <alan <at> idiocy.org> wrote:
>> 
>> The patch looks good to me, but lets see if we can find solutions to
>> these other issues.
>
> I made some progress on this issue.
>
> The idea is to wait for fullscreen transition to complete:
> - Set property isFullScreenTransition on windowWillEnterFullScreen and
>   windowWillExitFullScreen events;
> - Clear that property on windowDidEnterFullScreen and
>   windowDidExitFullScreen events;
> - Wait for property to be cleared when we need to.

Updated patch to work with latest master

[ns-emacs-spaces-updated.patch (text/x-patch, attachment)]

Message #23 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to
 empty space
Date: Thu, 20 Feb 2020 23:23:08 +0000

On Fri, Feb 14, 2020 at 10:23:22AM +0200, Andrii Kolomoiets wrote:
> Andrii Kolomoiets <andreyk.mad <at> gmail.com> writes:
> 
> >> On Jul 16, 2019, at 22:28, Alan Third <alan <at> idiocy.org> wrote:
> >> 
> >> The patch looks good to me, but lets see if we can find solutions to
> >> these other issues.
> >
> > I made some progress on this issue.
> >
> > The idea is to wait for fullscreen transition to complete:
> > - Set property isFullScreenTransition on windowWillEnterFullScreen and
> >   windowWillExitFullScreen events;
> > - Clear that property on windowDidEnterFullScreen and
> >   windowDidExitFullScreen events;
> > - Wait for property to be cleared when we need to.
> 
> Updated patch to work with latest master

Sorry for the delay, I’ll try and get a look this weekend.
-- 
Alan Third

Message #26 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to
 empty space
Date: Sun, 1 Mar 2020 17:16:08 +0100 (CET)

On Fri, Feb 14, 2020 at 10:23:22AM +0200, Andrii Kolomoiets wrote:
> Andrii Kolomoiets <andreyk.mad <at> gmail.com> writes:
> 
> >> On Jul 16, 2019, at 22:28, Alan Third <alan <at> idiocy.org> wrote:
> >> 
> >> The patch looks good to me, but lets see if we can find solutions to
> >> these other issues.
> >
> > I made some progress on this issue.
> >
> > The idea is to wait for fullscreen transition to complete:
> > - Set property isFullScreenTransition on windowWillEnterFullScreen and
> >   windowWillExitFullScreen events;
> > - Clear that property on windowDidEnterFullScreen and
> >   windowDidExitFullScreen events;
> > - Wait for property to be cleared when we need to.
> 
> Updated patch to work with latest master

Thanks! This looks much better than what we had before. No crashes for
one!

A few nitpicks:

> +   BOOL is_fullscreen_transition;

I may be misunderstanding this, but would ‘in_fullscreen_transition’
be a better name?

> +#if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
> +          // child frame must not be in fullscreen
> +          if ([view fsIsNative] && [view isFullscreen]){

Opening braces go on a new line.

> +- (void)waitFullScreenTransition
> +{
> +#if MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
> +  while ([self isFullScreenTransition]){

Opening brace, again.

>  - (BOOL)fsIsNative
>  {
>    return fs_is_native;
> @@ -7904,10 +7963,17 @@ - (void)updateCollectionBehavior
>      {
>        NSWindow *win = [self window];
>        NSWindowCollectionBehavior b = [win collectionBehavior];
> -      if (ns_use_native_fullscreen)
> -        b |= NSWindowCollectionBehaviorFullScreenPrimary;
> -      else
> +      if (ns_use_native_fullscreen) {
> +          if ([win parentWindow]) {
> +            b &= ~NSWindowCollectionBehaviorFullScreenPrimary;
> +            b |= NSWindowCollectionBehaviorFullScreenAuxiliary;
> +          } else {
> +            b |= NSWindowCollectionBehaviorFullScreenPrimary;
> +            b &= ~NSWindowCollectionBehaviorFullScreenAuxiliary;
> +          }
> +      } else {
>          b &= ~NSWindowCollectionBehaviorFullScreenPrimary;
> +      }

And again. That ‘} else {’ should also be over three lines.

>  #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
> @@ -7932,9 +7998,14 @@ - (void)toggleFullScreen: (id)sender
>      {
>  #if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
>  #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
> -      if ([[self window] respondsToSelector: @selector(toggleFullScreen:)])
> +      if ([[self window] respondsToSelector: @selector(toggleFullScreen:)]){
>  #endif
>          [[self window] toggleFullScreen:sender];
> +        // wait for fullscreen animation complete (bug#28496)
> +        [self waitFullScreenTransition];
> +#endif
> +#if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
> +      }
>  #endif
>        return;
>      }

Should that final #if #endif not be within the outer #if #endif? And
the opening brace again.
-- 
Alan Third

Message #29 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to
 empty space
Date: Tue, 10 Mar 2020 10:42:11 +0200

[Message part 1 (text/plain, inline)]

Alan Third <alan <at> idiocy.org> writes:

> Thanks! This looks much better than what we had before. No crashes for
> one!
>
> A few nitpicks:
>
>> +   BOOL is_fullscreen_transition;
>
> I may be misunderstanding this, but would ‘in_fullscreen_transition’
> be a better name?

OK, renamed. 

> Opening braces go on a new line.

Braces style is fixed to match Emacs code style.

> And again. That ‘} else {’ should also be over three lines.
>
>>  #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
>> @@ -7932,9 +7998,14 @@ - (void)toggleFullScreen: (id)sender
>>      {
>>  #if defined (NS_IMPL_COCOA) && MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
>>  #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
>> -      if ([[self window] respondsToSelector: @selector(toggleFullScreen:)])
>> +      if ([[self window] respondsToSelector: @selector(toggleFullScreen:)]){
>>  #endif
>>          [[self window] toggleFullScreen:sender];
>> +        // wait for fullscreen animation complete (bug#28496)
>> +        [self waitFullScreenTransition];
>> +#endif
>> +#if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
>> +      }
>>  #endif
>>        return;
>>      }
>
> Should that final #if #endif not be within the outer #if #endif?

Yes. Fixed.

Thanks!

Please see attached patch. Log message is also provided.

[0001-NS-child-frame-in-native-fullscreen.patch (text/x-patch, attachment)]

Message #34 received at 36672-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Andrii Kolomoiets <andreyk.mad <at> gmail.com>
Cc: 36672-done <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to
 empty space
Date: Fri, 13 Mar 2020 00:27:09 +0100 (CET)

On Tue, Mar 10, 2020 at 10:42:11AM +0200, Andrii Kolomoiets wrote:
> Please see attached patch. Log message is also provided.

This all looks good to me. Pushed to master as
bbc48b263485c26c6823eabdbbd7e9af62178e34.

Thank you!

-- 
Alan Third

Message #37 received at 36672-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Third <alan <at> idiocy.org>, Andrii Kolomoiets <andreyk.mad <at> gmail.com>,
 36672-done <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to empty
 space
Date: Fri, 13 Mar 2020 10:38:57 +0100

> This all looks good to me. Pushed to master as
> bbc48b263485c26c6823eabdbbd7e9af62178e34.

Alan, one child frame related question: When I specify a child frame in
a GNUstep build and move its parent frame around, the child frame does
_not_ move along with the parent but keeps its old position on the
display.  However, clicking into that child frame with the mouse
afterwards, moves it to its previous location within the parent frame.
Is this behavior observable with other NS builds?

Thanks, martin

Message #40 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Andrii Kolomoiets <andreyk.mad <at> gmail.com>, 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to
 empty space
Date: Fri, 13 Mar 2020 16:13:27 +0100 (CET)

On Fri, Mar 13, 2020 at 10:38:57AM +0100, martin rudalics wrote:
> > This all looks good to me. Pushed to master as
> > bbc48b263485c26c6823eabdbbd7e9af62178e34.
> 
> Alan, one child frame related question: When I specify a child frame in
> a GNUstep build and move its parent frame around, the child frame does
> _not_ move along with the parent but keeps its old position on the
> display.  However, clicking into that child frame with the mouse
> afterwards, moves it to its previous location within the parent frame.
> Is this behavior observable with other NS builds?

On macOS the child windows move with the parent. I thought GNUstep
worked that way too, but in my own experiments I can’t get them to
move at all, even with clicking in the windows like you’re doing.

I just tried an ancient build and it doesn’t work there, so I guess
this has probably never worked right.

I wonder if support is a WM thing?
-- 
Alan Third

Message #43 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Third <alan <at> idiocy.org>, Andrii Kolomoiets <andreyk.mad <at> gmail.com>,
 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to empty
 space
Date: Fri, 13 Mar 2020 17:29:17 +0100

> On macOS the child windows move with the parent.

Good.

> I thought GNUstep
> worked that way too, but in my own experiments I can’t get them to
> move at all, even with clicking in the windows like you’re doing.

Indeed.  What I tried was to move the child frame by dragging its mode
line.  What happens when you call (set-frame-position child-frame x y)
for a child frame and some values of x and y?

> I just tried an ancient build and it doesn’t work there, so I guess
> this has probably never worked right.
>
> I wonder if support is a WM thing?

Indirectly, maybe.  I have to try with window maker later.

Thanks, martin

Message #46 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Third <alan <at> idiocy.org>, Andrii Kolomoiets <andreyk.mad <at> gmail.com>,
 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to empty
 space
Date: Fri, 13 Mar 2020 18:45:20 +0100

>  > I wonder if support is a WM thing?
>
> Indirectly, maybe.  I have to try with window maker later.

Window maker shows the same behavior.  That is, moving a parent frame
does not move the child frame and in addition the child frame does not
necessarily appear on top of the parent frame.  I doubt that we can do
much about this.

martin

Message #49 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Andrii Kolomoiets <andreyk.mad <at> gmail.com>, 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to
 empty space
Date: Sat, 14 Mar 2020 00:53:07 +0100 (CET)

On Fri, Mar 13, 2020 at 05:29:17PM +0100, martin rudalics wrote:
> > I thought GNUstep
> > worked that way too, but in my own experiments I can’t get them to
> > move at all, even with clicking in the windows like you’re doing.
> 
> Indeed.  What I tried was to move the child frame by dragging its mode
> line.  What happens when you call (set-frame-position child-frame x y)
> for a child frame and some values of x and y?

It does what I expect. So the Emacs side child frame stuff appears to
work, but the GNUstep stuff doesn’t. As far as I can see in the code
we are setting the child frame correctly, so I have to assume it just
doesn’t work.

-- 
Alan Third

Message #52 received at 36672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Third <alan <at> idiocy.org>, Andrii Kolomoiets <andreyk.mad <at> gmail.com>,
 36672 <at> debbugs.gnu.org
Subject: Re: bug#36672: 27.0.50; NS build: Creating child frame leads to empty
 space
Date: Sat, 14 Mar 2020 09:48:29 +0100

> It does what I expect. So the Emacs side child frame stuff appears to
> work, but the GNUstep stuff doesn’t. As far as I can see in the code
> we are setting the child frame correctly, so I have to assume it just
> doesn’t work.

OK.

Thanks for looking into it, martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.