GNU bug report logs - #79704
frame-parameter fullscreen should nil when a frame is explicitly sized

Previous Next

To reply to this bug, email your comments to 79704 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: martin rudalics <rudalics <at> gmx.at>
Subject: frame-parameter fullscreen should nil when a frame is explicitly sized
Date: Sun, 26 Oct 2025 17:04:37 -0400

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

I sense the subject and the example are self explanatory.  I can submit a
patch for this if agreed, unless Martin wants to do it--perhaps it's
trickier than I think.

(set-frame-parameter nil 'fullscreen 'maximized)
(set-frame-size nil 400 400 'pixelwise)
(set-frame-position nil 10 10)
;; fullscreen should not remain maximized now that the frame has been
;; explicitly sized or positioned
(when (eq (frame-parameter nil 'fullscreen) 'maximized)
  (error "fullscreen should now be nil"))

-Stéphane

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>,
 bug-gnu-emacs <at> gnu.org
Subject: Re: frame-parameter fullscreen should nil when a frame is explicitly
 sized
Date: Mon, 27 Oct 2025 09:22:26 +0100

> I sense the subject and the example are self explanatory.  I can submit a
> patch for this if agreed, unless Martin wants to do it--perhaps it's
> trickier than I think.

Much trickier.  You cannot resize a maximized frame -
'adjust-frame-size' inhibits it.  With emacs -Q

(defun frame-size-string (prefix)
  (with-current-buffer (get-buffer-create "*history*")
    (insert
     (format "%s .. %s x %s\n" prefix
	     (frame-pixel-width) (frame-pixel-height)))))

(progn
  (frame-size-string 'initial)
  (set-frame-parameter nil 'fullscreen 'maximized)
  (sit-for 1)
  (frame-size-string 'maximized)
  (set-frame-size nil 400 400 'pixelwise)
  (sit-for 1)
  (frame-size-string '400)
  (set-frame-position nil 10 10)
  (sit-for 1)
  (frame-size-string '10)
  (set-frame-parameter nil 'fullscreen nil)
  (sit-for 1)
  (frame-size-string 'demaximized))

gets me here

initial .. 752 x 792
maximized .. 1680 x 938
400 .. 1680 x 938
10 .. 1680 x 938
demaximized .. 752 x 792

so neither 'set-frame-size' nor 'set-frame-position' have any effect.

If you want to change that, then you could try the following (guided by
an option):

Have 'set-frame-size', 'set-frame-width', 'set-frame-height' and
'modify-frame-parameters' first reset the 'fullscreen' parameter and
then apply the new sizes.  Resetting the 'fullscreen' parameter is
absolutely needed to tell the WM to change any 'maximize' button
appropriately, move the frame into the display (maximized frames are
usually set off by the negatives of their border sizes) and size the
frame back to its previous size which WMs usually store at some
inaccessible (for the application) location.

And for 'fullboth' frames. the WM would even have to re-create the
decorations first.  Finally, a similar approach would be needed to
reposition a maximized frame.

martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Mon, 27 Oct 2025 07:48:50 -0400

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

On Mon, Oct 27, 2025 at 4:23 AM martin rudalics via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:

>  > I sense the subject and the example are self explanatory.  I can submit
> a
>  > patch for this if agreed, unless Martin wants to do it--perhaps it's
>  > trickier than I think.
>
> Much trickier.  You cannot resize a maximized frame -
> 'adjust-frame-size' inhibits it.  With emacs -Q
>
> (defun frame-size-string (prefix)
>    (with-current-buffer (get-buffer-create "*history*")
>      (insert
>       (format "%s .. %s x %s\n" prefix
>              (frame-pixel-width) (frame-pixel-height)))))
>
> (progn
>    (frame-size-string 'initial)
>    (set-frame-parameter nil 'fullscreen 'maximized)
>    (sit-for 1)
>    (frame-size-string 'maximized)
>    (set-frame-size nil 400 400 'pixelwise)
>    (sit-for 1)
>    (frame-size-string '400)
>    (set-frame-position nil 10 10)
>    (sit-for 1)
>    (frame-size-string '10)
>    (set-frame-parameter nil 'fullscreen nil)
>    (sit-for 1)
>    (frame-size-string 'demaximized))
>
> gets me here
>
> initial .. 752 x 792
> maximized .. 1680 x 938
> 400 .. 1680 x 938
> 10 .. 1680 x 938
> demaximized .. 752 x 792
>
> so neither 'set-frame-size' nor 'set-frame-position' have any effect.
>
> If you want to change that, then you could try the following (guided by
> an option):
>
> Have 'set-frame-size', 'set-frame-width', 'set-frame-height' and
> 'modify-frame-parameters' first reset the 'fullscreen' parameter and
> then apply the new sizes.  Resetting the 'fullscreen' parameter is
> absolutely needed to tell the WM to change any 'maximize' button
> appropriately, move the frame into the display (maximized frames are
> usually set off by the negatives of their border sizes) and size the
> frame back to its previous size which WMs usually store at some
> inaccessible (for the application) location.
>
> And for 'fullboth' frames. the WM would even have to re-create the
> decorations first.  Finally, a similar approach would be needed to
> reposition a maximized frame.
>

Thanks for taking a look.

Perhaps this is a bug only in NS (I should have been more careful to relay
this was on macOS).  Reading through frame.c, I don't quite see the
fullscreen non-nil prohibition on changing frame size either
in `gui_set_frame_parameters_1` or in `adjust_frame_size`. Could be
insufficient caffeine blindness.

I'm happy if the behavior is as you say, that fullscreen being non-nil
remains so, and prevents frame position or size changes unless first set to
nil.  I did not find this documented anywhere in the code or docstrings or
documentation.  Also could be more caffeine blindness.

-Stéphane

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Mon, 27 Oct 2025 15:05:36 +0100

> Perhaps this is a bug only in NS (I should have been more careful to relay
> this was on macOS).

What did the code I posted the last time produce on your system?

> Reading through frame.c, I don't quite see the
> fullscreen non-nil prohibition on changing frame size either
> in `gui_set_frame_parameters_1` or in `adjust_frame_size`. Could be
> insufficient caffeine blindness.

It's here in frame_inhibit_resize

(struct frame *f, bool horizontal, Lisp_Object parameter)
{
  Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);

  return (EQ (frame_inhibit_implied_resize, Qforce)
	  || (f->after_make_frame
#ifdef USE_GTK
	      && f->tool_bar_resized
#endif
	      && (EQ (frame_inhibit_implied_resize, Qt)
		  || (CONSP (frame_inhibit_implied_resize)
		      && !NILP (Fmemq (parameter, frame_inhibit_implied_resize)))
		  || (horizontal
		      && !NILP (fullscreen) && !EQ (fullscreen, Qfullheight))
		  || (!horizontal
		      && !NILP (fullscreen) && !EQ (fullscreen, Qfullwidth))
		  || FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))));
}

in particular the two lines

		  || (horizontal
		      && !NILP (fullscreen) && !EQ (fullscreen, Qfullheight))
		  || (!horizontal
		      && !NILP (fullscreen) && !EQ (fullscreen, Qfullwidth))

If they don't inhibit on your system, maybe the

	  || (f->after_make_frame
	
fails.  If it doesn't work, please debug 'set-frame-size' with a
breakpoint at the

  return (EQ (frame_inhibit_implied_resize, Qforce)

line so you can tell us where and how it fails.

> I'm happy if the behavior is as you say, that fullscreen being non-nil
> remains so, and prevents frame position or size changes unless first set to
> nil.  I did not find this documented anywhere in the code or docstrings or
> documentation.  Also could be more caffeine blindness.

Basically, the fullscreen parameter mimics what the WM does for specific
key combinations or mouse clicks.  There, parts are undocumented, parts
don't work as expected.  In particular, 'fullheight' and 'fullwidth'
have no equivalents on some WMs.  OTOH, the Windows API had a function
for specifying the normal size of a frame after leaving fullscreen IIRC.
But I never made use of it because X had no equivalent.

I'll try to cook up something for the Elisp manual.

martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Mon, 27 Oct 2025 10:31:18 -0400

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

On Mon, Oct 27, 2025 at 10:05 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > Perhaps this is a bug only in NS (I should have been more careful to
> relay
>  > this was on macOS).
>
> What did the code I posted the last time produce on your system?
>
>  > Reading through frame.c, I don't quite see the
>  > fullscreen non-nil prohibition on changing frame size either
>  > in `gui_set_frame_parameters_1` or in `adjust_frame_size`. Could be
>  > insufficient caffeine blindness.
>
> It's here in frame_inhibit_resize
>
> (struct frame *f, bool horizontal, Lisp_Object parameter)
> {
>    Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
>
>    return (EQ (frame_inhibit_implied_resize, Qforce)
>           || (f->after_make_frame
> #ifdef USE_GTK
>               && f->tool_bar_resized
> #endif
>               && (EQ (frame_inhibit_implied_resize, Qt)
>                   || (CONSP (frame_inhibit_implied_resize)
>                       && !NILP (Fmemq (parameter,
> frame_inhibit_implied_resize)))
>                   || (horizontal
>                       && !NILP (fullscreen) && !EQ (fullscreen,
> Qfullheight))
>                   || (!horizontal
>                       && !NILP (fullscreen) && !EQ (fullscreen,
> Qfullwidth))
>                   || FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))));
> }
>
> in particular the two lines
>
>                   || (horizontal
>                       && !NILP (fullscreen) && !EQ (fullscreen,
> Qfullheight))
>                   || (!horizontal
>                       && !NILP (fullscreen) && !EQ (fullscreen,
> Qfullwidth))
>
> If they don't inhibit on your system, maybe the
>
>           || (f->after_make_frame
>
> fails.  If it doesn't work, please debug 'set-frame-size' with a
> breakpoint at the
>
>    return (EQ (frame_inhibit_implied_resize, Qforce)
>
> line so you can tell us where and how it fails.
>
>  > I'm happy if the behavior is as you say, that fullscreen being non-nil
>  > remains so, and prevents frame position or size changes unless first
> set to
>  > nil.  I did not find this documented anywhere in the code or docstrings
> or
>  > documentation.  Also could be more caffeine blindness.
>
> Basically, the fullscreen parameter mimics what the WM does for specific
> key combinations or mouse clicks.  There, parts are undocumented, parts
> don't work as expected.  In particular, 'fullheight' and 'fullwidth'
> have no equivalents on some WMs.  OTOH, the Windows API had a function
> for specifying the normal size of a frame after leaving fullscreen IIRC.
> But I never made use of it because X had no equivalent.
>
> I'll try to cook up something for the Elisp manual.


On Emacs 30.2, running your program, I get:

initial .. 595 x 508
maximized .. 1800 x 1077
400 .. 435 x 404
10 .. 435 x 404
demaximized .. 595 x 508

-Stéphane

[Message part 2 (text/html, inline)]

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Mon, 27 Oct 2025 14:10:27 -0400

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

On Mon, Oct 27, 2025 at 10:31 AM Stéphane Marks <shipmints <at> gmail.com> wrote:

> On Mon, Oct 27, 2025 at 10:05 AM martin rudalics <rudalics <at> gmx.at> wrote:
>
>>  > Perhaps this is a bug only in NS (I should have been more careful to
>> relay
>>  > this was on macOS).
>>
>> What did the code I posted the last time produce on your system?
>>
>>  > Reading through frame.c, I don't quite see the
>>  > fullscreen non-nil prohibition on changing frame size either
>>  > in `gui_set_frame_parameters_1` or in `adjust_frame_size`. Could be
>>  > insufficient caffeine blindness.
>>
>> It's here in frame_inhibit_resize
>>
>> (struct frame *f, bool horizontal, Lisp_Object parameter)
>> {
>>    Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
>>
>>    return (EQ (frame_inhibit_implied_resize, Qforce)
>>           || (f->after_make_frame
>> #ifdef USE_GTK
>>               && f->tool_bar_resized
>> #endif
>>               && (EQ (frame_inhibit_implied_resize, Qt)
>>                   || (CONSP (frame_inhibit_implied_resize)
>>                       && !NILP (Fmemq (parameter,
>> frame_inhibit_implied_resize)))
>>                   || (horizontal
>>                       && !NILP (fullscreen) && !EQ (fullscreen,
>> Qfullheight))
>>                   || (!horizontal
>>                       && !NILP (fullscreen) && !EQ (fullscreen,
>> Qfullwidth))
>>                   || FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))));
>> }
>>
>> in particular the two lines
>>
>>                   || (horizontal
>>                       && !NILP (fullscreen) && !EQ (fullscreen,
>> Qfullheight))
>>                   || (!horizontal
>>                       && !NILP (fullscreen) && !EQ (fullscreen,
>> Qfullwidth))
>>
>> If they don't inhibit on your system, maybe the
>>
>>           || (f->after_make_frame
>>
>> fails.  If it doesn't work, please debug 'set-frame-size' with a
>> breakpoint at the
>>
>>    return (EQ (frame_inhibit_implied_resize, Qforce)
>>
>> line so you can tell us where and how it fails.
>>
>>  > I'm happy if the behavior is as you say, that fullscreen being non-nil
>>  > remains so, and prevents frame position or size changes unless first
>> set to
>>  > nil.  I did not find this documented anywhere in the code or
>> docstrings or
>>  > documentation.  Also could be more caffeine blindness.
>>
>> Basically, the fullscreen parameter mimics what the WM does for specific
>> key combinations or mouse clicks.  There, parts are undocumented, parts
>> don't work as expected.  In particular, 'fullheight' and 'fullwidth'
>> have no equivalents on some WMs.  OTOH, the Windows API had a function
>> for specifying the normal size of a frame after leaving fullscreen IIRC.
>> But I never made use of it because X had no equivalent.
>>
>> I'll try to cook up something for the Elisp manual.
>
>
> On Emacs 30.2, running your program, I get:
>
> initial .. 595 x 508
> maximized .. 1800 x 1077
> 400 .. 435 x 404
> 10 .. 435 x 404
> demaximized .. 595 x 508
>

The issue seems to be that `frame_inhibit_resize` should probably treat any
non-nil 'fullscreen parameter as inhibitable?  I only ever use 'maximized
and definitely expected 'fullscreen to reset to nil when resizing.

>

[Message part 2 (text/html, inline)]

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Mon, 27 Oct 2025 14:17:41 -0400

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

On Mon, Oct 27, 2025 at 2:10 PM Stéphane Marks <shipmints <at> gmail.com> wrote:

> On Mon, Oct 27, 2025 at 10:31 AM Stéphane Marks <shipmints <at> gmail.com>
> wrote:
>
>> On Mon, Oct 27, 2025 at 10:05 AM martin rudalics <rudalics <at> gmx.at> wrote:
>>
>>>  > Perhaps this is a bug only in NS (I should have been more careful to
>>> relay
>>>  > this was on macOS).
>>>
>>> What did the code I posted the last time produce on your system?
>>>
>>>  > Reading through frame.c, I don't quite see the
>>>  > fullscreen non-nil prohibition on changing frame size either
>>>  > in `gui_set_frame_parameters_1` or in `adjust_frame_size`. Could be
>>>  > insufficient caffeine blindness.
>>>
>>> It's here in frame_inhibit_resize
>>>
>>> (struct frame *f, bool horizontal, Lisp_Object parameter)
>>> {
>>>    Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
>>>
>>>    return (EQ (frame_inhibit_implied_resize, Qforce)
>>>           || (f->after_make_frame
>>> #ifdef USE_GTK
>>>               && f->tool_bar_resized
>>> #endif
>>>               && (EQ (frame_inhibit_implied_resize, Qt)
>>>                   || (CONSP (frame_inhibit_implied_resize)
>>>                       && !NILP (Fmemq (parameter,
>>> frame_inhibit_implied_resize)))
>>>                   || (horizontal
>>>                       && !NILP (fullscreen) && !EQ (fullscreen,
>>> Qfullheight))
>>>                   || (!horizontal
>>>                       && !NILP (fullscreen) && !EQ (fullscreen,
>>> Qfullwidth))
>>>                   || FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))));
>>> }
>>>
>>> in particular the two lines
>>>
>>>                   || (horizontal
>>>                       && !NILP (fullscreen) && !EQ (fullscreen,
>>> Qfullheight))
>>>                   || (!horizontal
>>>                       && !NILP (fullscreen) && !EQ (fullscreen,
>>> Qfullwidth))
>>>
>>> If they don't inhibit on your system, maybe the
>>>
>>>           || (f->after_make_frame
>>>
>>> fails.  If it doesn't work, please debug 'set-frame-size' with a
>>> breakpoint at the
>>>
>>>    return (EQ (frame_inhibit_implied_resize, Qforce)
>>>
>>> line so you can tell us where and how it fails.
>>>
>>>  > I'm happy if the behavior is as you say, that fullscreen being non-nil
>>>  > remains so, and prevents frame position or size changes unless first
>>> set to
>>>  > nil.  I did not find this documented anywhere in the code or
>>> docstrings or
>>>  > documentation.  Also could be more caffeine blindness.
>>>
>>> Basically, the fullscreen parameter mimics what the WM does for specific
>>> key combinations or mouse clicks.  There, parts are undocumented, parts
>>> don't work as expected.  In particular, 'fullheight' and 'fullwidth'
>>> have no equivalents on some WMs.  OTOH, the Windows API had a function
>>> for specifying the normal size of a frame after leaving fullscreen IIRC.
>>> But I never made use of it because X had no equivalent.
>>>
>>> I'll try to cook up something for the Elisp manual.
>>
>>
>> On Emacs 30.2, running your program, I get:
>>
>> initial .. 595 x 508
>> maximized .. 1800 x 1077
>> 400 .. 435 x 404
>> 10 .. 435 x 404
>> demaximized .. 595 x 508
>>
>
> The issue seems to be that `frame_inhibit_resize` should probably treat
> any non-nil 'fullscreen parameter as inhibitable?  I only ever use
> 'maximized and definitely expected 'fullscreen to reset to nil when
> resizing.
>

To complete the thought: either we inhibit resizing for non-nil fullscreen,
or we should allow resizing/repositioning for maximized but set it to nil
afterward.

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org,
 "<alan <at> idiocy.org> <gerd.moellmann <at> gmail.com>" <aaronjensen <at> gmail.com>
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Tue, 28 Oct 2025 09:27:22 +0100

> On Emacs 30.2, running your program, I get:
>
> initial .. 595 x 508
> maximized .. 1800 x 1077
> 400 .. 435 x 404
> 10 .. 435 x 404
> demaximized .. 595 x 508

Then we have a bug.  I can't tell the cause for it because fullscreen
handling on MacOS is way more complicated than on all other systems.
All I can do is to add Alan, Gerd and Aaron to the discussion.  Maybe
they can tell.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Tue, 28 Oct 2025 09:27:47 +0100

>> The issue seems to be that `frame_inhibit_resize` should probably treat
>> any non-nil 'fullscreen parameter as inhibitable?  I only ever use
>> 'maximized and definitely expected 'fullscreen to reset to nil when
>> resizing.
>>
>
> To complete the thought: either we inhibit resizing for non-nil fullscreen,

When a frame is 'fullheight' we should allow resizing it horizontally.
When a frame is 'fullwidth' we should allow resizing it vertically.  In
all other cases we should inhibit resizing it.

> or we should allow resizing/repositioning for maximized but set it to nil
> afterward.

We cannot simply "set it to nil afterward".  We have to first inform the
WM that the frame should be no more fullscreen.  Otherwise, we lose
synchronization with the WM.

martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Tue, 28 Oct 2025 08:28:24 -0400

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

On Tue, Oct 28, 2025 at 4:27 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  >> The issue seems to be that `frame_inhibit_resize` should probably treat
>  >> any non-nil 'fullscreen parameter as inhibitable?  I only ever use
>  >> 'maximized and definitely expected 'fullscreen to reset to nil when
>  >> resizing.
>  >>
>  >
>  > To complete the thought: either we inhibit resizing for non-nil
> fullscreen,
>
> When a frame is 'fullheight' we should allow resizing it horizontally.
> When a frame is 'fullwidth' we should allow resizing it vertically.  In
> all other cases we should inhibit resizing it.
>

I verified that all fullscreen modes are ignored by NS and can be resized,
so there is a set of constraint tests missing somewhere in nsterm.

 > or we should allow resizing/repositioning for maximized but set it to nil
>  > afterward.
>
> We cannot simply "set it to nil afterward".  We have to first inform the
> WM that the frame should be no more fullscreen.  Otherwise, we lose
> synchronization with the WM.


Agree.  I had thought this was just a missing housekeeping thing.  Clearly
NS frame resizing under fullscreen is broken, in general.

-Stéphane

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Wed, 29 Oct 2025 09:11:31 +0100

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

> Agree.  I had thought this was just a missing housekeeping thing.  Clearly
> NS frame resizing under fullscreen is broken, in general.

Can you try the attached patch?  It should fix the 'set-frame-size' case
by resetting the fullscreen parameter first.

martin

[reset_fullscreen_before_size_change.diff (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Wed, 29 Oct 2025 09:28:05 +0100

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

> Can you try the attached patch?  It should fix the 'set-frame-size' case
> by resetting the fullscreen parameter first.

The diff attached now should handle all sorts of explicit resizing
including setting frame parameters directly.

martin

[reset_fullscreen_before_size_change.diff (text/x-patch, attachment)]

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Wed, 29 Oct 2025 08:06:47 -0400

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

On Wed, Oct 29, 2025 at 4:28 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > Can you try the attached patch?  It should fix the 'set-frame-size' case
>  > by resetting the fullscreen parameter first.
>
> The diff attached now should handle all sorts of explicit resizing
> including setting frame parameters directly.


With the patch on NS:

[I added tracking fullscreen parameter to the output as (fs).]

initial .. 597 x 508 (fs nil)
maximized .. 1800 x 1077 (fs maximized)
400 .. 437 x 404 (fs nil)
10 .. 437 x 404 (fs nil)
demaximized .. 437 x 404 (fs nil)

So now, NS still resizes when maximized counter to the desired effect, but
at least fullscreen is now reset to nil.

We still have an nsterm bug, though, yes, if the constraint that frame
resizing/repositioning is intended to be disallowed when fullscreen is
non-nil?  I did not test other platforms, so it is entirely possible this
constraint discussed above doesn't really exist? I did a cursory
read-through of xterm.c and didn't find this constraint honored there.
Unless it's enforced in frame.c and what you patched is the entirety of
what's needed, I suppose?

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org, shipmints <at> gmail.com
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Wed, 29 Oct 2025 14:26:15 +0200

> Cc: 79704 <at> debbugs.gnu.org
> Date: Wed, 29 Oct 2025 09:11:31 +0100
> From:  martin rudalics via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
>  > Agree.  I had thought this was just a missing housekeeping thing.  Clearly
>  > NS frame resizing under fullscreen is broken, in general.
> 
> Can you try the attached patch?  It should fix the 'set-frame-size' case
> by resetting the fullscreen parameter first.

If this is installed, please add a NEWS entry about it, since it's an
incompatible behavior change.

Thanks.

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Wed, 29 Oct 2025 14:08:41 -0400

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

On Wed, Oct 29, 2025 at 8:06 AM Stéphane Marks <shipmints <at> gmail.com> wrote:

> On Wed, Oct 29, 2025 at 4:28 AM martin rudalics <rudalics <at> gmx.at> wrote:
>
>>  > Can you try the attached patch?  It should fix the 'set-frame-size'
>> case
>>  > by resetting the fullscreen parameter first.
>>
>> The diff attached now should handle all sorts of explicit resizing
>> including setting frame parameters directly.
>
>
> With the patch on NS:
>
> [I added tracking fullscreen parameter to the output as (fs).]
>
> initial .. 597 x 508 (fs nil)
> maximized .. 1800 x 1077 (fs maximized)
> 400 .. 437 x 404 (fs nil)
> 10 .. 437 x 404 (fs nil)
> demaximized .. 437 x 404 (fs nil)
>
> So now, NS still resizes when maximized counter to the desired effect, but
> at least fullscreen is now reset to nil.
>
> We still have an nsterm bug, though, yes, if the constraint that frame
> resizing/repositioning is intended to be disallowed when fullscreen is
> non-nil?  I did not test other platforms, so it is entirely possible this
> constraint discussed above doesn't really exist? I did a cursory
> read-through of xterm.c and didn't find this constraint honored there.
> Unless it's enforced in frame.c and what you patched is the entirety of
> what's needed, I suppose?
>

Do we want to do the same when a fullscreen both or fullscreen maximized
frame is repositioned? Repositioning a full-screen frame seems counter to
it being fullboth or maximized as one has to toggle-frame-fullscreen to
first disable fullscreen and then restore it to its 0,0 origin. i.e., I'm
asking if we think the 0,0 origin is part of the definition of being
fullboth or maximized.

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Thu, 30 Oct 2025 09:47:38 +0100

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

> So now, NS still resizes when maximized counter to the desired effect, but
> at least fullscreen is now reset to nil.

What the "desired effect" is remains in the mind of the beholder.  And a
careful programmer would always check the fullscreen status before
attempting to resize a frame and either reset the status explicitly or
leave the size unchanged whenever it is set.

> We still have an nsterm bug, though, yes, if the constraint that frame
> resizing/repositioning is intended to be disallowed when fullscreen is
> non-nil?  I did not test other platforms, so it is entirely possible this
> constraint discussed above doesn't really exist? I did a cursory
> read-through of xterm.c and didn't find this constraint honored there.
> Unless it's enforced in frame.c and what you patched is the entirety of
> what's needed, I suppose?

As for (P)GTK you would have to look into xg_frame_set_char_size (hardly
readable).  For other toolkits there is no special handling.

I now added a new variable 'resize-fullscreen-frames' (to become an
option eventually) that lets you tune the behavior.  Here with

(defun frame-size-string (prefix)
  (with-current-buffer (get-buffer-create "*history*")
    (insert
     (format "%s .. %s x %s .. FS %s .. RFS %s\n" prefix
         (frame-pixel-width) (frame-pixel-height)
	 (frame-parameter nil 'fullscreen)
	 resize-fullscreen-frames))))

(progn
  (frame-size-string 'initial)
  (set-frame-parameter nil 'fullscreen 'maximized)
  (sit-for 1)
  (frame-size-string 'maximized)
  (set-frame-size nil 400 400 'pixelwise)
  (sit-for 1)
  (frame-size-string '400)
  (set-frame-position nil 10 10)
  (sit-for 1)
  (frame-size-string '10)
  (set-frame-parameter nil 'fullscreen nil)
  (sit-for 1)
  (frame-size-string 'demaximized))

it gets me

initial .. 752 x 792 .. FS nil .. RFS nil
maximized .. 1680 x 938 .. FS maximized .. RFS nil
400 .. 1680 x 938 .. FS maximized .. RFS nil
10 .. 1680 x 938 .. FS maximized .. RFS nil
demaximized .. 752 x 792 .. FS nil .. RFS nil
---------------------------------------------
initial .. 752 x 792 .. FS nil .. RFS t
maximized .. 1680 x 938 .. FS maximized .. RFS t
400 .. 428 x 396 .. FS nil .. RFS t
10 .. 428 x 396 .. FS nil .. RFS t
demaximized .. 428 x 396 .. FS nil .. RFS t
-------------------------------------------
initial .. 752 x 792 .. FS nil .. RFS reject
maximized .. 1680 x 938 .. FS maximized .. RFS reject
400 .. 1680 x 938 .. FS maximized .. RFS reject
10 .. 1680 x 938 .. FS maximized .. RFS reject
demaximized .. 752 x 792 .. FS nil .. RFS reject
------------------------------------------------

so you can see that the behaviors for nil and 'reject' are the same.
They should differ for you.

martin

[resize-fullscreen-frames.diff (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Thu, 30 Oct 2025 09:47:58 +0100

> Do we want to do the same when a fullscreen both or fullscreen maximized
> frame is repositioned? Repositioning a full-screen frame seems counter to
> it being fullboth or maximized as one has to toggle-frame-fullscreen to
> first disable fullscreen and then restore it to its 0,0 origin. i.e., I'm
> asking if we think the 0,0 origin is part of the definition of being
> fullboth or maximized.

When Emacs sets a frame position it uses some sort of fire and forget
policy although it usually stores the new position first in the top_pos
and left_pos slots.  As a rule, the WM gets back to us and tells us the
right position later.  For a fullscreen frame, the WM should simply not
move it - what happens to the position values is of no real concern
then.

Here a fullscreen frame does not change position but we have this
cryptic comment in gtkutil.c

      /* Don't set hints when maximized or fullscreen.  Apparently KWin and
         Gtk3 don't get along and the frame shrinks (!).
      */

so there might be something to it.  And IIRC Wayland and a couple of WMs
(mutter) do not not care about positions or report incomprehensible
values anyway.

martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Thu, 30 Oct 2025 14:00:50 -0400

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

On Thu, Oct 30, 2025 at 4:47 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > So now, NS still resizes when maximized counter to the desired effect,
> but
>  > at least fullscreen is now reset to nil.
>
> What the "desired effect" is remains in the mind of the beholder.  And a
> careful programmer would always check the fullscreen status before
> attempting to resize a frame and either reset the status explicitly or
> leave the size unchanged whenever it is set.
>
>  > We still have an nsterm bug, though, yes, if the constraint that frame
>  > resizing/repositioning is intended to be disallowed when fullscreen is
>  > non-nil?  I did not test other platforms, so it is entirely possible
> this
>  > constraint discussed above doesn't really exist? I did a cursory
>  > read-through of xterm.c and didn't find this constraint honored there.
>  > Unless it's enforced in frame.c and what you patched is the entirety of
>  > what's needed, I suppose?
>
> As for (P)GTK you would have to look into xg_frame_set_char_size (hardly
> readable).  For other toolkits there is no special handling.
>
> I now added a new variable 'resize-fullscreen-frames' (to become an
> option eventually) that lets you tune the behavior.  Here with
>
> (defun frame-size-string (prefix)
>    (with-current-buffer (get-buffer-create "*history*")
>      (insert
>       (format "%s .. %s x %s .. FS %s .. RFS %s\n" prefix
>           (frame-pixel-width) (frame-pixel-height)
>          (frame-parameter nil 'fullscreen)
>          resize-fullscreen-frames))))
>
> (progn
>    (frame-size-string 'initial)
>    (set-frame-parameter nil 'fullscreen 'maximized)
>    (sit-for 1)
>    (frame-size-string 'maximized)
>    (set-frame-size nil 400 400 'pixelwise)
>    (sit-for 1)
>    (frame-size-string '400)
>    (set-frame-position nil 10 10)
>    (sit-for 1)
>    (frame-size-string '10)
>    (set-frame-parameter nil 'fullscreen nil)
>    (sit-for 1)
>    (frame-size-string 'demaximized))
>
> it gets me
>
> initial .. 752 x 792 .. FS nil .. RFS nil
> maximized .. 1680 x 938 .. FS maximized .. RFS nil
> 400 .. 1680 x 938 .. FS maximized .. RFS nil
> 10 .. 1680 x 938 .. FS maximized .. RFS nil
> demaximized .. 752 x 792 .. FS nil .. RFS nil
> ---------------------------------------------
> initial .. 752 x 792 .. FS nil .. RFS t
> maximized .. 1680 x 938 .. FS maximized .. RFS t
> 400 .. 428 x 396 .. FS nil .. RFS t
> 10 .. 428 x 396 .. FS nil .. RFS t
> demaximized .. 428 x 396 .. FS nil .. RFS t
> -------------------------------------------
> initial .. 752 x 792 .. FS nil .. RFS reject
> maximized .. 1680 x 938 .. FS maximized .. RFS reject
> 400 .. 1680 x 938 .. FS maximized .. RFS reject
> 10 .. 1680 x 938 .. FS maximized .. RFS reject
> demaximized .. 752 x 792 .. FS nil .. RFS reject
> ------------------------------------------------
>
> so you can see that the behaviors for nil and 'reject' are the same.
> They should differ for you.
>

That seems to work.  In the docstring for `resize-fullscreen-frames`,
perhaps saying NS is better than macOS since GNUstep is part of that
family.  I also wonder if using the Emacs convention terminology inhibit is
better than saying reject?

P.S. In my usual code, I am sufficiently careful to first reset fullscreen
before changing sizes.

[Message part 2 (text/html, inline)]

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Thu, 30 Oct 2025 14:07:20 -0400

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

On Thu, Oct 30, 2025 at 4:48 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > Do we want to do the same when a fullscreen both or fullscreen maximized
>  > frame is repositioned? Repositioning a full-screen frame seems counter
> to
>  > it being fullboth or maximized as one has to toggle-frame-fullscreen to
>  > first disable fullscreen and then restore it to its 0,0 origin. i.e.,
> I'm
>  > asking if we think the 0,0 origin is part of the definition of being
>  > fullboth or maximized.
>
> When Emacs sets a frame position it uses some sort of fire and forget
> policy although it usually stores the new position first in the top_pos
> and left_pos slots.  As a rule, the WM gets back to us and tells us the
> right position later.  For a fullscreen frame, the WM should simply not
> move it - what happens to the position values is of no real concern
> then.
>
> Here a fullscreen frame does not change position but we have this
> cryptic comment in gtkutil.c
>
>        /* Don't set hints when maximized or fullscreen.  Apparently KWin
> and
>           Gtk3 don't get along and the frame shrinks (!).
>        */
>
> so there might be something to it.  And IIRC Wayland and a couple of WMs
> (mutter) do not not care about positions or report incomprehensible
> values anyway.


At least Windows and macOS are consistent enough that we could get those
"right"?  The wild world of window managers is a crapshoot (and, yes, I
dislike that Wayland is so hellbent on refusing to do what its users ask as
if Wayland owns our computers).

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Fri, 31 Oct 2025 09:40:02 +0100

> That seems to work.  In the docstring for `resize-fullscreen-frames`,
> perhaps saying NS is better than macOS since GNUstep is part of that
> family.  I also wonder if using the Emacs convention terminology inhibit is
> better than saying reject?

I'll incorporate your suggestions when I make this an option.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Fri, 31 Oct 2025 09:40:19 +0100

> At least Windows and macOS are consistent enough that we could get those
> "right"?  The wild world of window managers is a crapshoot (and, yes, I
> dislike that Wayland is so hellbent on refusing to do what its users ask as
> if Wayland owns our computers).

You didn't tell me so far what position and size you get when you just
try to move a maximized frame by calling 'set-frame-position'.  We might
have to fix that as well.

martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Fri, 31 Oct 2025 09:33:35 -0400

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

On Fri, Oct 31, 2025 at 4:40 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > At least Windows and macOS are consistent enough that we could get those
>  > "right"?  The wild world of window managers is a crapshoot (and, yes, I
>  > dislike that Wayland is so hellbent on refusing to do what its users
> ask as
>  > if Wayland owns our computers).
>
> You didn't tell me so far what position and size you get when you just
> try to move a maximized frame by calling 'set-frame-position'.  We might
> have to fix that as well.


I think the results were above but here again with a changed symbol to
indicate which entry was the repositioning entry:

initial .. 597 x 508 .. FS nil .. RFS reject
maximized .. 1800 x 1077 .. FS maximized .. RFS reject
400 .. 1800 x 1077 .. FS maximized .. RFS reject
pos-10-10 .. 1800 x 1077 .. FS maximized .. RFS reject ; <==== still
maximized
demaximized .. 597 x 508 .. FS nil .. RFS reject

If there's something else you'd like to see, let me know, and thank you.

-Stéphane

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Fri, 31 Oct 2025 17:17:32 +0100

> If there's something else you'd like to see, let me know, and thank you.

Just the value returned by 'frame-position' ideally before and after you
'set-frame-position' - the after with a (sit-for 1).

Thanks, martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Fri, 31 Oct 2025 12:27:16 -0400

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

On Fri, Oct 31, 2025 at 12:17 PM martin rudalics <rudalics <at> gmx.at> wrote:

>  > If there's something else you'd like to see, let me know, and thank you.
>
> Just the value returned by 'frame-position' ideally before and after you
> 'set-frame-position' - the after with a (sit-for 1).
>
> Thanks, martin
>

This is with your "reject" patch applied, but obviously not in play since
we're not resizing, just repositioning.

(defun frame-size-string (prefix)
   (with-current-buffer (get-buffer-create "*history*")
     (insert
      (format "%s .. %S .. FS %s .. RFS %s\n"
         prefix
         (frame-position)
         (frame-parameter nil 'fullscreen)
         resize-fullscreen-frames))))

(progn
   (frame-size-string 'initial)
   (set-frame-parameter nil 'fullscreen 'maximized)
   (sit-for 1)
   (frame-size-string 'maximized)
   (set-frame-position nil 10 10)
   (sit-for 1)
   (frame-size-string 'pos-10))

initial .. (601 . 183) .. FS nil .. RFS reject
maximized .. (0 . 40) .. FS maximized .. RFS reject
pos-10 .. (10 . 40) .. FS maximized .. RFS reject

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Fri, 31 Oct 2025 18:53:20 +0100

> initial .. (601 . 183) .. FS nil .. RFS reject
> maximized .. (0 . 40) .. FS maximized .. RFS reject
> pos-10 .. (10 . 40) .. FS maximized .. RFS reject

So the frame allegedly moves right by ten pixels.  Can you actually see
that movement?  If so, we probably should inhibit it too.  But then
setting the position would first resize the frame to normal and then
move it which doesn't sound very intuitive either.

And are the 40 some sort of bar at the top of your display that inhibits
moving a window there?  Can you move a "normal" frame to (10 . 10)?

martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Fri, 31 Oct 2025 14:07:24 -0400

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

On Fri, Oct 31, 2025 at 1:53 PM martin rudalics <rudalics <at> gmx.at> wrote:

>  > initial .. (601 . 183) .. FS nil .. RFS reject
>  > maximized .. (0 . 40) .. FS maximized .. RFS reject
>  > pos-10 .. (10 . 40) .. FS maximized .. RFS reject
>
> So the frame allegedly moves right by ten pixels.  Can you actually see
> that movement?


Yes, it moves visually.


> If so, we probably should inhibit it too.  But then
> setting the position would first resize the frame to normal and then
> move it which doesn't sound very intuitive either.
>
> And are the 40 some sort of bar at the top of your display that inhibits
> moving a window there?  Can you move a "normal" frame to (10 . 10)?
>

This was -Q so it had a tool bar and I'm guessing that's a "normal" frame.

(tool-bar-mode -1)
(set-frame-position nil 10 10)
(frame-position) ; reports (10 . 40)

So I guess I can't move to (10 . 10).

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Sat, 1 Nov 2025 11:19:24 +0100

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

>> If so, we probably should inhibit it too.  But then
>> setting the position would first resize the frame to normal and then
>> move it which doesn't sound very intuitive either.
>>
>> And are the 40 some sort of bar at the top of your display that inhibits
>> moving a window there?  Can you move a "normal" frame to (10 . 10)?
>>
>
> This was -Q so it had a tool bar and I'm guessing that's a "normal" frame.
>
> (tool-bar-mode -1)
> (set-frame-position nil 10 10)
> (frame-position) ; reports (10 . 40)
>
> So I guess I can't move to (10 . 10).

OK.  I'll leave it open whether we want to inhibit moving fullscreen
frames and renamed the option to 'alter-fullscreen-frames' so it might
encompass both.  When I drag the title bar of a maximized frame with the
mouse, XFWM here first resizes the frame to its normal size and then
moves it.  'set-frame-position' OTOH has no effect.  I cannot change the
size of a maximized frame by dragging one of its borders because XFWM
hides the borders of maximized and fullboth frames.

New diff attached.  Please try the customization interface.

Thanks, martin

[alter-fullscreen-frames.diff (text/x-patch, attachment)]

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Sat, 1 Nov 2025 07:09:31 -0400

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

On Sat, Nov 1, 2025 at 6:19 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  >> If so, we probably should inhibit it too.  But then
>  >> setting the position would first resize the frame to normal and then
>  >> move it which doesn't sound very intuitive either.
>  >>
>  >> And are the 40 some sort of bar at the top of your display that
> inhibits
>  >> moving a window there?  Can you move a "normal" frame to (10 . 10)?
>  >>
>  >
>  > This was -Q so it had a tool bar and I'm guessing that's a "normal"
> frame.
>  >
>  > (tool-bar-mode -1)
>  > (set-frame-position nil 10 10)
>  > (frame-position) ; reports (10 . 40)
>  >
>  > So I guess I can't move to (10 . 10).
>
> OK.  I'll leave it open whether we want to inhibit moving fullscreen
> frames and renamed the option to 'alter-fullscreen-frames' so it might
> encompass both.  When I drag the title bar of a maximized frame with the
> mouse, XFWM here first resizes the frame to its normal size and then
> moves it.  'set-frame-position' OTOH has no effect.  I cannot change the
> size of a maximized frame by dragging one of its borders because XFWM
> hides the borders of maximized and fullboth frames.
>
> New diff attached.  Please try the customization interface.


That works.  One suggestion for `alter-fullscreen-frames` customize is to
say "Passthrough" or "System" or "Window Manager" rather than "Undecided".

I also agree that if the host system allows a 'maximized window to be
dragged around, then we leave it alone as the fullscreen notion remains
size geometry independent of position geometry.  'fullboth on most (all?)
systems has no title bar so can't be dragged around so that condition
likely doesn't need additional constraints.

-Stéphane

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: 79704 <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Sun, 2 Nov 2025 09:30:39 +0100

> That works.  One suggestion for `alter-fullscreen-frames` customize is to
> say "Passthrough" or "System" or "Window Manager" rather than "Undecided".

I now say "forward to window manager".

> I also agree that if the host system allows a 'maximized window to be
> dragged around, then we leave it alone as the fullscreen notion remains
> size geometry independent of position geometry.  'fullboth on most (all?)
> systems has no title bar so can't be dragged around so that condition
> likely doesn't need additional constraints.

If needed we can add them later.  I checked in the changes now.  Please
close the bug if you see no more issues

Thanks, martin

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

From: Stéphane Marks <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 79704 <at> debbugs.gnu.org, 79704-done <at> debbugs.gnu.org
Subject: Re: bug#79704: frame-parameter fullscreen should nil when a frame is
 explicitly sized
Date: Sun, 2 Nov 2025 13:03:45 -0500

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

Looks good, so far.  Thank you.  Closing.

On Sun, Nov 2, 2025 at 3:30 AM martin rudalics <rudalics <at> gmx.at> wrote:

>  > That works.  One suggestion for `alter-fullscreen-frames` customize is
> to
>  > say "Passthrough" or "System" or "Window Manager" rather than
> "Undecided".
>
> I now say "forward to window manager".
>
>  > I also agree that if the host system allows a 'maximized window to be
>  > dragged around, then we leave it alone as the fullscreen notion remains
>  > size geometry independent of position geometry.  'fullboth on most
> (all?)
>  > systems has no title bar so can't be dragged around so that condition
>  > likely doesn't need additional constraints.
>
> If needed we can add them later.  I checked in the changes now.  Please
> close the bug if you see no more issues
>
> Thanks, martin
>

[Message part 2 (text/html, inline)]

Previous Next

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