GNU bug report logs - #21317
25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager)

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 21317 in the body.
You can then email your comments to 21317 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: Pip Cet <pipcet <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager)
Date: Fri, 21 Aug 2015 22:34:30 +0000

When starting Emacs (GTK build) on an X server which has no window
manager (such as a newly-created Xnest session), setting
`frame-resize-pixelwise' to t followed by a resize operation often has
no effect.

In GNU Emacs 25.0.50.31 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-08-21 on ...
Repository revision: a9d799b5dea1efb9216dc6f985ffc9bdd25d8cba
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
System Description:	Debian GNU/Linux unstable (sid)

Configured using:
 `configure 'CFLAGS=-O0 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item
user-error: End of history; no default available

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns help-mode easymenu cl-loaddefs pcase cl-lib mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind gfilenotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 81307 5982)
 (symbols 48 19076 0)
 (miscs 40 42 86)
 (strings 32 13284 4355)
 (string-bytes 1 377456)
 (vectors 16 11222)
 (vector-slots 8 413750 4157)
 (floats 8 130 19)
 (intervals 56 179 0)
 (buffers 976 11)
 (heap 1024 33363 990))

Steps to reproduce:

Xnest :3 -geometry 877x877+0+0
DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t)
(set-frame-parameter (selected-frame) 'fullscreen 'fullboth))"

Expected result:
Emacs frame fills Xnest window precisely.

Actual result:
Emacs frame size differs from Xnest window size. In my case, the
minibuffer/echo area is cut off and there is an area to the right of
the Emacs window that is not used by the Emacs frame.

Analysis:
There are two problems:
(1) x_check_fullscreen (xterm.c) calls XResizeWindow without first
calling x_wm_set_size_hint (gtkutil.c), which would propagate the
`frame-resize-pixelwise' flag to have an effect on GTK/GDK
(2) x_wm_set_size_hint returns without propagating the
`frame-resize-pixelwise' flag when the frame's fullscreen property is
'maximized or 'fullboth.

The first appears to be simple oversight, but the second is
intentional to work around a KWin bug.

Note that despite the name, the GTK version of `x_wm_set_size_hint'
does not rely on the presence of a window manager or indeed
communicate with it.

Fixing the first problem is trivial, but the second problem would
require knowing more about the KWin bug that is being avoided by the
workaround at #14627.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>, 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Sat, 22 Aug 2015 08:40:43 +0200

> When starting Emacs (GTK build) on an X server which has no window
> manager (such as a newly-created Xnest session), setting
> `frame-resize-pixelwise' to t followed by a resize operation often has
> no effect.

According to the manual

     Setting this variable usually causes the next resize operation to
     pass the corresponding size hints to the window manager.  This
     means that this variable should be set only in a user's initial
     file; applications should never bind it temporarily.

So it's possible that Xnest or some other X component refuses to resize
your frame because the size hints were set up inappropriately.

Does it also fail when `frame-resize-pixelwise' is set to t in your
initial file?

Does it fail when you set `frame-resize-pixelwise' to t, request an
integral resize first and a second non-integral one afterwards?

martin

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Sat, 22 Aug 2015 10:50:59 +0000

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

Thanks for responding!

On Sat, Aug 22, 2015 at 6:40 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> When starting Emacs (GTK build) on an X server which has no window
>> manager (such as a newly-created Xnest session), setting
>> `frame-resize-pixelwise' to t followed by a resize operation often has
>> no effect.
>
> According to the manual
>
>      Setting this variable usually causes the next resize operation to
>      pass the corresponding size hints to the window manager.  This
>      means that this variable should be set only in a user's initial
>      file; applications should never bind it temporarily.

That documentation is outdated and does not apply to GTK builds in all
cases, I'm afraid. It is not the window manager that decides to honor
or dishonor frame-resize-pixelwise but GDK. See x_wm_set_size_hint and
gtk_window_move_resize (gtkwindow.c, in the GTK sources). In
particular, gtk_window_compute_configure_request calls
gtk_window_constrain_size which calls gdk_window_constrain_size which
calculates

  width = base_width + FLOOR (width - base_width, xinc);
  height = base_height + FLOOR (height - base_height, yinc);

(where FLOOR is defined as #define FLOOR(value, base)    ( ((gint)
((value) / (base))) * (base) ) )


> So it's possible that Xnest or some other X component refuses to resize
> your frame because the size hints were set up inappropriately.

I'm pretty sure that's not what's happening, but I'll be happy to
provide traces to demonstrate my analysis is correct...or to prove it
wrong, of course! The attached gdb log shows quite clearly that it's
GDK making the second (erroneous) call to XResizeWindow, not Xnest
(there is no window manager).

> Does it also fail when `frame-resize-pixelwise' is set to t in your
> initial file?

Yes, it does.

> Does it fail when you set `frame-resize-pixelwise' to t, request an
> integral resize first and a second non-integral one afterwards?

I'm not sure I fully understand how you define "integral". In short,
non-full-screen resize + redisplay + full-screen resize works, the
other combinations do not.

If I run this code (Xnest running on display :3):

DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t)
(set-frame-height (selected-frame) (1+ (frame-pixel-height
(selected-frame))) nil t) (redisplay) (set-frame-parameter
(selected-frame) 'fullscreen 'fullboth))"

Things work, but without the "(redisplay)" they don't. (So that's a
non-full-screen resize first, then a full-screen resize). Doing the
full-screen resize first breaks things.

I must also point out that without the "(redisplay)", there are
unexpected results: the full screen resize appears to be ignored
entirely.

But, again, I currently stand by my initial analysis of what's
happening. The problem is that we cannot simply do the right thing
because of the KWin bug...

[emacs-bug-008-gdb-log.txt (text/plain, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Sat, 22 Aug 2015 16:16:47 +0200

> Thanks for responding!

Thanks for investigating!

> On Sat, Aug 22, 2015 at 6:40 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>>> When starting Emacs (GTK build) on an X server which has no window
>>> manager (such as a newly-created Xnest session), setting
>>> `frame-resize-pixelwise' to t followed by a resize operation often has
>>> no effect.
>>
>> According to the manual
>>
>>       Setting this variable usually causes the next resize operation to
>>       pass the corresponding size hints to the window manager.  This
>>       means that this variable should be set only in a user's initial
>>       file; applications should never bind it temporarily.
>
> That documentation is outdated and does not apply to GTK builds in all
> cases, I'm afraid. It is not the window manager that decides to honor
> or dishonor frame-resize-pixelwise but GDK.

"Window manager" was an attempt to catch the behavior of all toolkits
including Windows which doesn't have a window manager either.  Feel free
to suggest a better term.

> See x_wm_set_size_hint and
> gtk_window_move_resize (gtkwindow.c, in the GTK sources). In
> particular, gtk_window_compute_configure_request calls
> gtk_window_constrain_size which calls gdk_window_constrain_size which
> calculates
>
>    width = base_width + FLOOR (width - base_width, xinc);
>    height = base_height + FLOOR (height - base_height, yinc);
>
> (where FLOOR is defined as #define FLOOR(value, base)    ( ((gint)
> ((value) / (base))) * (base) ) )

I can't find that in the version from

https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c

and also must admit that I have forgotten most of the GTK code by now.

IIRC base_width and base_height are somehow calculated from a minimum
size and what Emacs requested earlier.  If frame_resize_pixelwise is
true we _should_ have requested 1 from this

  size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
  size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);

Can you check how apparently an "integral" (the increment is a multiple
of either FRAME_COLUMN_WIDTH or FRAME_LINE_HEIGHT) value gets passed via
size_hints in your case?

>> So it's possible that Xnest or some other X component refuses to resize
>> your frame because the size hints were set up inappropriately.
>
> I'm pretty sure that's not what's happening, but I'll be happy to
> provide traces to demonstrate my analysis is correct...or to prove it
> wrong, of course! The attached gdb log shows quite clearly that it's
> GDK making the second (erroneous) call to XResizeWindow, not Xnest
> (there is no window manager).

OK.  I won't doubt what you say here.

>> Does it also fail when `frame-resize-pixelwise' is set to t in your
>> initial file?
>
> Yes, it does.

That's bad.  It can only mean that we send an integral resize request
_before_ Emacs reads the initial file and the subsequent "real" resize
request fails because the size hints have been already set up wrongly.

>> Does it fail when you set `frame-resize-pixelwise' to t, request an
>> integral resize first and a second non-integral one afterwards?
>
> I'm not sure I fully understand how you define "integral".

See above.  Also the "first and a second" above was meant to do this in
two consecutive commands (that is, with a redisplay in between).
Passing different size requests in one and the same command can have
unpredictable consequences (at least on other platforms).

> In short,
> non-full-screen resize + redisplay + full-screen resize works, the
> other combinations do not.
>
> If I run this code (Xnest running on display :3):
>
> DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t)
> (set-frame-height (selected-frame) (1+ (frame-pixel-height
> (selected-frame))) nil t) (redisplay) (set-frame-parameter
> (selected-frame) 'fullscreen 'fullboth))"
>
> Things work, but without the "(redisplay)" they don't. (So that's a
> non-full-screen resize first, then a full-screen resize). Doing the
> full-screen resize first breaks things.

"Breaks" in what sense?  That it does nothing or not fully resize?

> I must also point out that without the "(redisplay)", there are
> unexpected results: the full screen resize appears to be ignored
> entirely.

I'd have expected that.

> But, again, I currently stand by my initial analysis of what's
> happening. The problem is that we cannot simply do the right thing
> because of the KWin bug...

What is the "KWin bug"?

I'm probably too silly to give you a good advice.  However, in
xg_frame_set_char_size (which is responsible for the resize in the GTK
case) we could do the

x_wm_set_size_hint (f, 0, 0);

_before_ calling gtk_window_resize.  Could you play around with that?

BTW if you set `frame-size-history' to a non-nil value you should get a
list of frame resizing operations you can watch with the function
`frame--size-history'.  IIRC I found GDB occasionally not 100% reliable
to reproduce the actual history as of a normal, optimized build.

martin

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Sat, 22 Aug 2015 15:32:02 +0000

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

Let me just repeat my initial analysis, which I still believe is
correct and which might have gotten lost somewhere.

There are two problems:
(1) x_check_fullscreen (xterm.c) calls XResizeWindow without first
calling x_wm_set_size_hint (gtkutil.c), which would propagate the
`frame-resize-pixelwise' flag to have an effect on GTK/GDK
(2) x_wm_set_size_hint returns without propagating the
`frame-resize-pixelwise' flag when the frame's fullscreen property is
'maximized or 'fullboth.

The first appears to be simple oversight, but the second is
intentional to work around a KWin bug.

I've attached a patch which fixes things for me (at least when
tool-bar-mode is disabled :( ), but presumably breaks things for KWin
users, so it should not go in as it is until that matter has been
cleared; maybe that'll help clarify matters.

I take it something about that doesn't feel right to you, and that's
reason enough to investigate further.

On Sat, Aug 22, 2015 at 2:16 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>> On Sat, Aug 22, 2015 at 6:40 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>>>> When starting Emacs (GTK build) on an X server which has no window
>>>> manager (such as a newly-created Xnest session), setting
>>>> `frame-resize-pixelwise' to t followed by a resize operation often has
>>>> no effect.
>>>
>>> According to the manual
>>>
>>>       Setting this variable usually causes the next resize operation to
>>>       pass the corresponding size hints to the window manager.  This
>>>       means that this variable should be set only in a user's initial
>>>       file; applications should never bind it temporarily.
>>
>> That documentation is outdated and does not apply to GTK builds in all
>> cases, I'm afraid. It is not the window manager that decides to honor
>> or dishonor frame-resize-pixelwise but GDK.
>
> "Window manager" was an attempt to catch the behavior of all toolkits
> including Windows which doesn't have a window manager either.  Feel free
> to suggest a better term.

Oh, I see! That makes sense, thank you and sorry for my
narrow-mindedness in thinking only of X11 window managers.

>> See x_wm_set_size_hint and
>> gtk_window_move_resize (gtkwindow.c, in the GTK sources). In
>> particular, gtk_window_compute_configure_request calls
>> gtk_window_constrain_size which calls gdk_window_constrain_size which
>> calculates
>>
>>    width = base_width + FLOOR (width - base_width, xinc);
>>    height = base_height + FLOOR (height - base_height, yinc);
>>
>> (where FLOOR is defined as #define FLOOR(value, base)    ( ((gint)
>> ((value) / (base))) * (base) ) )
>
> I can't find that in the version from
>
> https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c

Try https://github.com/GNOME/gtk/blob/master/gdk/gdkwindow.c ?

> and also must admit that I have forgotten most of the GTK code by now.
>
> IIRC base_width and base_height are somehow calculated from a minimum
> size and what Emacs requested earlier.  If frame_resize_pixelwise is
> true we _should_ have requested 1 from this
>
>   size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH
> (f);
>   size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT
> (f);

We do hit that code (in gtkutil.c) twice: once during early
initialization, when frame_resize_pixelwise is still false, and once
after GDK has decided to resize us to not-quite-full-screen size, when
it's too late. We should hit it once more, from x_check_fullscreen,
but don't do so for the two reasons listed above.

> Can you check how apparently an "integral" (the increment is a multiple
> of either FRAME_COLUMN_WIDTH or FRAME_LINE_HEIGHT) value gets passed via
> size_hints in your case?

Oh, I see what you mean now. I'll investigate that next.

>>> So it's possible that Xnest or some other X component refuses to resize
>>> your frame because the size hints were set up inappropriately.
>>
>> I'm pretty sure that's not what's happening, but I'll be happy to
>> provide traces to demonstrate my analysis is correct...or to prove it
>> wrong, of course! The attached gdb log shows quite clearly that it's
>> GDK making the second (erroneous) call to XResizeWindow, not Xnest
>> (there is no window manager).
>
> OK.  I won't doubt what you say here.

Feel free to, of course, though I understand sifting through gdb logs
is best avoided unless it's absolutely necessary.

>>> Does it also fail when `frame-resize-pixelwise' is set to t in your
>>> initial file?
>>
>> Yes, it does.
>
> That's bad.  It can only mean that we send an integral resize request
> _before_ Emacs reads the initial file and the subsequent "real" resize
> request fails because the size hints have been already set up wrongly.

No, we call Fsetq and so on fine, I think it's just that we never call
x_set_wm_size_hints afterwards.

>>> Does it fail when you set `frame-resize-pixelwise' to t, request an
>>> integral resize first and a second non-integral one afterwards?
>>
>> I'm not sure I fully understand how you define "integral".
>
> See above.  Also the "first and a second" above was meant to do this in
> two consecutive commands (that is, with a redisplay in between).
> Passing different size requests in one and the same command can have
> unpredictable consequences (at least on other platforms).

Noted. Thanks for that piece of advice, that really helps me make
sense of what's going on.

>> In short,
>> non-full-screen resize + redisplay + full-screen resize works, the
>> other combinations do not.
>>
>> If I run this code (Xnest running on display :3):
>>
>> DISPLAY=:3 emacs -Q --eval "(progn (setq frame-resize-pixelwise t)
>> (set-frame-height (selected-frame) (1+ (frame-pixel-height
>> (selected-frame))) nil t) (redisplay) (set-frame-parameter
>> (selected-frame) 'fullscreen 'fullboth))"
>>
>> Things work, but without the "(redisplay)" they don't. (So that's a
>> non-full-screen resize first, then a full-screen resize). Doing the
>> full-screen resize first breaks things.
>
> "Breaks" in what sense?  That it does nothing or not fully resize?

It appears to ignore the fullscreen resize; as you point out, that's
as expected, by the "don't resize twice without a redisplay" rule.

>> I must also point out that without the "(redisplay)", there are
>> unexpected results: the full screen resize appears to be ignored
>> entirely.
>
> I'd have expected that.

Good, that's one less thing to worry about then.

>> But, again, I currently stand by my initial analysis of what's
>> happening. The problem is that we cannot simply do the right thing
>> because of the KWin bug...
>
> What is the "KWin bug"?

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14627, which introduced
the conditional which prevents us from calling x_wm_size_hints

> I'm probably too silly to give you a good advice.

Not at all, it's much appreciated.

> However, in
> xg_frame_set_char_size (which is responsible for the resize in the GTK
> case) we could do the

That's a very interesting point, because xg_frame_set_char_size never
appears to get called here after early initialization. Instead, we
call XResizeWindow directly, then GDK catches the ConfigureNotify and
decides it doesn't like it, so it sends another (erroneous)
XResizeWindow.

> x_wm_set_size_hint (f, 0, 0);
>
> _before_ calling gtk_window_resize.  Could you play around with that?
>
> BTW if you set `frame-size-history' to a non-nil value you should get a
> list of frame resizing operations you can watch with the function
> `frame--size-history'.  IIRC I found GDB occasionally not 100% reliable
> to reproduce the actual history as of a normal, optimized build.

Thanks, I never considered that possibility. I'm running an
unoptimized debug build (-O0 -g3), but there might be useful
information there. So far it appears not to contain anything
unexpected (I'm looking at the variable directly, the function appears
to have mysteriously vanished from the current git tree, except for a
reference in the documentation...)

Thanks for all your help!

[emacs-bug-008.diff (text/plain, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Sat, 22 Aug 2015 19:46:38 +0200

> Let me just repeat my initial analysis, which I still believe is
> correct and which might have gotten lost somewhere.
>
> There are two problems:
> (1) x_check_fullscreen (xterm.c) calls XResizeWindow without first
> calling x_wm_set_size_hint (gtkutil.c), which would propagate the
> `frame-resize-pixelwise' flag to have an effect on GTK/GDK

I understand that now.  You don't run do_ewmh_fullscreen.  So the bug
_only_ occurs when you want to make a fullscreen frame?  This was not
clear from you initial report.

> (2) x_wm_set_size_hint returns without propagating the
> `frame-resize-pixelwise' flag when the frame's fullscreen property is
> 'maximized or 'fullboth.
>
> The first appears to be simple oversight, but the second is
> intentional to work around a KWin bug.

I faintly remember that bug now.  What I don't understand is the remedy.
When we do

  fs_state = Fframe_parameter (frame, Qfullscreen);
  if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth))

the parameter has been already set but the frame is not yet fullscreen.
Does this shrinking occur when the frame is already fullscreen or does
it occur when a user wants to switch to fullscreen?

> I've attached a patch which fixes things for me (at least when
> tool-bar-mode is disabled :( ), but presumably breaks things for KWin
> users, so it should not go in as it is until that matter has been
> cleared; maybe that'll help clarify matters.

When worse comes to worse we could condition that somehow: Invent an
option which is off by default and call x_wm_set_size_hint when it's on.

> We do hit that code (in gtkutil.c) twice: once during early
> initialization, when frame_resize_pixelwise is still false, and once
> after GDK has decided to resize us to not-quite-full-screen size, when
> it's too late. We should hit it once more, from x_check_fullscreen,
> but don't do so for the two reasons listed above.

I see.  If in frame.c you initialize frame_resize_pixelwise to 1 then
everything works OK?

>> Can you check how apparently an "integral" (the increment is a multiple
>> of either FRAME_COLUMN_WIDTH or FRAME_LINE_HEIGHT) value gets passed via
>> size_hints in your case?
>
> Oh, I see what you mean now. I'll investigate that next.

Not necessary.  It won't help anyway.

>>>> So it's possible that Xnest or some other X component refuses to resize
>>>> your frame because the size hints were set up inappropriately.
>>>
>>> I'm pretty sure that's not what's happening, but I'll be happy to
>>> provide traces to demonstrate my analysis is correct...or to prove it
>>> wrong, of course! The attached gdb log shows quite clearly that it's
>>> GDK making the second (erroneous) call to XResizeWindow, not Xnest
>>> (there is no window manager).
>>
>> OK.  I won't doubt what you say here.
>
> Feel free to, of course, though I understand sifting through gdb logs
> is best avoided unless it's absolutely necessary.

Well... I didn't understand the problem at that time.

>>>> Does it also fail when `frame-resize-pixelwise' is set to t in your
>>>> initial file?
>>>
>>> Yes, it does.
>>
>> That's bad.  It can only mean that we send an integral resize request
>> _before_ Emacs reads the initial file and the subsequent "real" resize
>> request fails because the size hints have been already set up wrongly.
>
> No, we call Fsetq and so on fine, I think it's just that we never call
> x_set_wm_size_hints afterwards.

We could invent a function `set-frame-resize-pixelwise' which sends the
size hints (maybe iff when a frame is not fullscreen, or so to avoid the
KWin bug).

> It appears to ignore the fullscreen resize; as you point out, that's
> as expected, by the "don't resize twice without a redisplay" rule.

It's rather a don't resize and change the fullscreen status without a
redisplay.

>> However, in
>> xg_frame_set_char_size (which is responsible for the resize in the GTK
>> case) we could do the
>
> That's a very interesting point, because xg_frame_set_char_size never
> appears to get called here after early initialization. Instead, we
> call XResizeWindow directly, then GDK catches the ConfigureNotify and
> decides it doesn't like it, so it sends another (erroneous)
> XResizeWindow.

Interesting indeed.  Something's not right here, I'm afraid.  I'll have
to look into this.

martin

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Sun, 23 Aug 2015 09:45:07 +0000

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

Sorry this is getting a bit long, but unfortunately, another issue appeared.

On Sat, Aug 22, 2015 at 5:46 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> I understand that now.  You don't run do_ewmh_fullscreen.  So the bug
> _only_ occurs when you want to make a fullscreen frame?  This was not
> clear from you initial report.

Sorry about that. You're right, I've only seen the problem when I make
a fullscreen frame. That wasn't perfectly clear to me at the time, but
I should have tested better. Thank you for your patience.

>> (2) x_wm_set_size_hint returns without propagating the
>> `frame-resize-pixelwise' flag when the frame's fullscreen property is
>> 'maximized or 'fullboth.
>>
>> The first appears to be simple oversight, but the second is
>> intentional to work around a KWin bug.
>
> I faintly remember that bug now.  What I don't understand is the remedy.
> When we do
>
>   fs_state = Fframe_parameter (frame, Qfullscreen);
>   if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth))
>
> the parameter has been already set but the frame is not yet fullscreen.
> Does this shrinking occur when the frame is already fullscreen or does
> it occur when a user wants to switch to fullscreen?

I'm not a hundred percent certain; from reading the thread, I think
it's the former: the window is in full-screen mode and starts
shrinking. I've installed KWin but have been unable to produce buggy
behavior, so far, without the workaround in gtkutil.c.

>> I've attached a patch which fixes things for me (at least when
>> tool-bar-mode is disabled :( ), but presumably breaks things for KWin
>> users, so it should not go in as it is until that matter has been
>> cleared; maybe that'll help clarify matters.
>
> When worse comes to worse we could condition that somehow: Invent an
> option which is off by default and call x_wm_set_size_hint when it's on.

I do wonder how useful it is to support the case without a window
manager; unfortunately, I think it is useful, much as I'd enjoy all
that code going away and leaving things to the window manager.

Anyway, if x_check_fullscreen is supposed to work the way it currently
does, bypassing xg_frame_set_char_size, there's a third issue to add
to my list:

(3) x_check_fullscreen does not call store_frame_param, unlike
x_set_window_size_1, so the frame has its 'fullscreen parameter
cleared to nil by x_net_wm_state; the next `set-frame-font' call then
results in an integral frame size rather than the full screen.

If my understanding is correct, the best way forward is this:

 - skip the hints in maximized/fullscreen state if
wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it
might be KWin
 - otherwise, set the hints
 - call x_wm_set_size_hint from x_check_fullscreen
 - call store_frame_param from x_check_fullscreen

>> We do hit that code (in gtkutil.c) twice: once during early
>> initialization, when frame_resize_pixelwise is still false, and once
>> after GDK has decided to resize us to not-quite-full-screen size, when
>> it's too late. We should hit it once more, from x_check_fullscreen,
>> but don't do so for the two reasons listed above.
>
> I see.  If in frame.c you initialize frame_resize_pixelwise to 1 then
> everything works OK?

...Almost. Sorry. If I set frame_resize_pixelwise to 1 and run
`set-frame-font' afterwards, the frame loses its full-screen
resolution and changes to a similar resolution that's a multiple of
the character size, as far as I can tell. This is due to issue (3), I
believe. Similarly, we don't adjust for the tool bar size, which I
also believe is due to issue (3) (I keep forgetting about that one
since I don't usually use the tool bar).

I have attached the minimal patch (as far as I know) that works:
initialize frame_resize_pixelwise to 1, and fix issue (3). That works
both with a tool bar and with `set-frame-font' (I'm not in the habit
of running `set-frame-font', but it's run by the gconf code when
gnome-settings-daemon is active and specifies a system font).

>>>>> Does it also fail when `frame-resize-pixelwise' is set to t in your
>>>>> initial file?
>>>>
>>>> Yes, it does.
>>>
>>> That's bad.  It can only mean that we send an integral resize request
>>> _before_ Emacs reads the initial file and the subsequent "real" resize
>>> request fails because the size hints have been already set up wrongly.
>>
>> No, we call Fsetq and so on fine, I think it's just that we never call
>> x_set_wm_size_hints afterwards.
>
> We could invent a function `set-frame-resize-pixelwise' which sends the
> size hints (maybe iff when a frame is not fullscreen, or so to avoid the
> KWin bug).

How would that be different from x_wm_set_size_hints with FLAGS=0? I
suppose we could modify only the increments and leave the rest of the
size hints alone, but is that enough to prevent bad KWin behavior?

>> It appears to ignore the fullscreen resize; as you point out, that's
>> as expected, by the "don't resize twice without a redisplay" rule.
>
> It's rather a don't resize and change the fullscreen status without a
> redisplay.

Ah. Well, that doesn't really make sense anyway, so it's probably a
good rule :-)

>>> However, in
>>> xg_frame_set_char_size (which is responsible for the resize in the GTK
>>> case) we could do the
>>
>> That's a very interesting point, because xg_frame_set_char_size never
>> appears to get called here after early initialization. Instead, we
>> call XResizeWindow directly, then GDK catches the ConfigureNotify and
>> decides it doesn't like it, so it sends another (erroneous)
>> XResizeWindow.
> Interesting indeed.  Something's not right here, I'm afraid.  I'll have
> to look into this.

It seems like the code in x_check_fullscreen was intended to work
without a window manager (and without calling xg_frame_set_char_size),
but never did. It didn't call x_wm_set_size_hints and it didn't clean
up after x_net_wm_state by setting the 'fullscreen property again.

Thank you for your assistance in this, it's very much appreciated. If
you would like me to run more tests or provide debugging info, please
let me know, I'll do my best.

[emacs-bug-009.diff (text/plain, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Sun, 23 Aug 2015 13:12:29 +0200

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

> Sorry about that. You're right, I've only seen the problem when I make
> a fullscreen frame. That wasn't perfectly clear to me at the time, but
> I should have tested better. Thank you for your patience.

It's not immediately clear that the problem happens only with attempts
to make a fullscreen frame which, to be clear again, could mean any of
maximized, fullheight, fullwidth and fullboth.

So when you try to increase the height of a normal frame by one pixel,
which is the resize operation you send?  I suppose it's the last one
from x_set_window_size_1 so Emacs correctly passes the size hint with
frame_resize_pixelwise 1.  Right?

If this is the case, then Emacs should, for you, also handle fullwidth
and fullheight requests correctly via the first and second of the
requests in x_set_window_size_1.  Right?

So the two remaining cases Emacs can't handle for you are fullscreen and
maximized requests.  Right?

>> I faintly remember that bug now.

Rereading the corresponding thread I wonder how my memory could fail
so miserably.

> What I don't understand is the remedy.
>> When we do
>>
>>    fs_state = Fframe_parameter (frame, Qfullscreen);
>>    if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth))
>>
>> the parameter has been already set but the frame is not yet fullscreen.
>> Does this shrinking occur when the frame is already fullscreen or does
>> it occur when a user wants to switch to fullscreen?
>
> I'm not a hundred percent certain; from reading the thread, I think
> it's the former: the window is in full-screen mode and starts
> shrinking. I've installed KWin but have been unable to produce buggy
> behavior, so far, without the workaround in gtkutil.c.

I attach a patch that should handle the case where we want to switch
from a non-fullscreen to a fullscreen frame.  Please try it.
FRAME_OUTER_WINDOW (f) should probably be replaced by some GTK-specific
window but I don't yet know which one.

>> When worse comes to worse we could condition that somehow: Invent an
>> option which is off by default and call x_wm_set_size_hint when it's on.
>
> I do wonder how useful it is to support the case without a window
> manager; unfortunately, I think it is useful, much as I'd enjoy all
> that code going away and leaving things to the window manager.

I miss you here: Which "case" do you mean?

> Anyway, if x_check_fullscreen is supposed to work the way it currently
> does, bypassing xg_frame_set_char_size, there's a third issue to add
> to my list:
>
> (3) x_check_fullscreen does not call store_frame_param, unlike
> x_set_window_size_1, so the frame has its 'fullscreen parameter
> cleared to nil by x_net_wm_state; the next `set-frame-font' call then
> results in an integral frame size rather than the full screen.

Correct me if I'm wrong: We run x_check_fullscreen only when the window
manager doesn't support fullscreen natively.  WOW when we run
x_check_fullscreen, we emulate the behavior of a window manager by
calculating the respective sizes ourselves.

Now when Emacs sets the fullscreen frame parameter itself, this action
basically covers only what we get from the window manager.  A user who
wanted a fullscreen frame would have set the according frame parameter
already.  What am I missing?

> If my understanding is correct, the best way forward is this:
>
>   - skip the hints in maximized/fullscreen state if
> wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it
> might be KWin
>   - otherwise, set the hints

OK.  These can be done easily, maybe in combination with my patch.

>   - call x_wm_set_size_hint from x_check_fullscreen

OK.  Funnily we call a function x_wm_set_size_hint to handle a scenario
where there's no window manager.

>   - call store_frame_param from x_check_fullscreen

It might not harm but, as mentioned above, this should not be
necessary.  Or, if it is necessary because the parameters are not in
place yet, the bug seems to be elsewhere,

>> I see.  If in frame.c you initialize frame_resize_pixelwise to 1 then
>> everything works OK?
>
> ...Almost. Sorry. If I set frame_resize_pixelwise to 1 and run
> `set-frame-font' afterwards,

Hmm..  so you insist.  Can you tell me why `set-frame-font' can change a
fullscreen frame's size?

> the frame loses its full-screen
> resolution and changes to a similar resolution that's a multiple of
> the character size, as far as I can tell. This is due to issue (3), I
> believe. Similarly, we don't adjust for the tool bar size, which I
> also believe is due to issue (3) (I keep forgetting about that one
> since I don't usually use the tool bar).

Let's look into the toolbar issue later.  What we have to check first
is:

(1) You have a "correctly" maximized frame and `frame-resize-pixelwise'
    is non-nil.  What is the frame's fullscreen parameter's value?

(2) If that value is non-nil, how comes `set-frame-font' can change the
    frame size?

> I have attached the minimal patch (as far as I know) that works:
> initialize frame_resize_pixelwise to 1,

We can't do that.  I mentioned that only so you can check whether it
would work in principle.

> and fix issue (3). That works
> both with a tool bar and with `set-frame-font' (I'm not in the habit
> of running `set-frame-font', but it's run by the gconf code when
> gnome-settings-daemon is active and specifies a system font).

OK.

>> We could invent a function `set-frame-resize-pixelwise' which sends the
>> size hints (maybe iff when a frame is not fullscreen, or so to avoid the
>> KWin bug).
>
> How would that be different from x_wm_set_size_hints with FLAGS=0?

It would modify the increments accordingly.  That is
`set-frame-resize-pixelwise' with a non-nil ARG would set the increments
to 1 and with a nil ARG it would set them to the frame's column and line
heights.

> I
> suppose we could modify only the increments and leave the rest of the
> size hints alone, but is that enough to prevent bad KWin behavior?

You mean calling `set-frame-resize-pixelwise' in a fullscreen state on
KWin would produce the bug again.  You're probably right.  So this won't
help much.

> It seems like the code in x_check_fullscreen was intended to work
> without a window manager (and without calling xg_frame_set_char_size),

... that's my impression too ...

> but never did. It didn't call x_wm_set_size_hints and it didn't clean
> up after x_net_wm_state by setting the 'fullscreen property again.

Do I understand finally?  x_net_wm_state resets the fullscreen state to
nil via its store_frame_param?  That would be the missing link then.
But then there's no use to set the fullscreen parameter earlier.
x_net_wm_state would annihilate that anyway.

martin

[x_wm_size_hint.diff (text/plain, attachment)]

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Sun, 23 Aug 2015 12:20:27 +0000

Let me answer that email bottom-to-top, I think it makes most sense that way:

On Sun, Aug 23, 2015 at 11:12 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> but never did. It didn't call x_wm_set_size_hints and it didn't clean
>> up after x_net_wm_state by setting the 'fullscreen property again.
>
> Do I understand finally?  x_net_wm_state resets the fullscreen state to
> nil via its store_frame_param?  That would be the missing link then.

Indeed.

(Minor point of confusion here: there are two functions called
`x_net_wm_state' and `x_handle_net_wm_state' which appear to do the
same thing...)

> But then there's no use to set the fullscreen parameter earlier.
> x_net_wm_state would annihilate that anyway.

I think you're right for X, but other toolkits might need the generic
code that sets it earlier.

>> Sorry about that. You're right, I've only seen the problem when I make
>> a fullscreen frame. That wasn't perfectly clear to me at the time, but
>> I should have tested better. Thank you for your patience.
>
> It's not immediately clear that the problem happens only with attempts
> to make a fullscreen frame which, to be clear again, could mean any of
> maximized, fullheight, fullwidth and fullboth.

The problem appears with all of maximized, fullheight, fullwidth, and fullboth.

> So when you try to increase the height of a normal frame by one pixel,
> which is the resize operation you send?

set_frame_height calls adjust_frame_size which calls x_set_window_size
which calls xg_frame_set_char_size.
x_set_window_size_1 is NOT being called in this case.

>  I suppose it's the last one
> from x_set_window_size_1 so Emacs correctly passes the size hint with
> frame_resize_pixelwise 1.  Right?

No, x_set_window_size_1 never is called here.

It's the last case in xg_frame_set_char_size, which calls
gtk_window_resize FIRST, then calls x_wm_set_size_hints. I do not
understand why that works, but it appears to. (Is this another bug?
I'm seriously confused at this point).

> If this is the case, then Emacs should, for you, also handle fullwidth
> and fullheight requests correctly via the first and second of the
> requests in x_set_window_size_1.  Right?

No. x_set_window_size_1 isn't called at all. xg_frame_set_char_size
isn't called for fullscreen requests at all.

> So the two remaining cases Emacs can't handle for you are fullscreen and
> maximized requests.  Right?

No, it's all four fullscreen settings.

>> What I don't understand is the remedy.
>>> When we do
>>>
>>>    fs_state = Fframe_parameter (frame, Qfullscreen);
>>>    if (EQ (fs_state, Qmaximized) || EQ (fs_state, Qfullboth))
>>>
>>> the parameter has been already set but the frame is not yet fullscreen.
>>> Does this shrinking occur when the frame is already fullscreen or does
>>> it occur when a user wants to switch to fullscreen?
>>
>> I'm not a hundred percent certain; from reading the thread, I think
>> it's the former: the window is in full-screen mode and starts
>> shrinking. I've installed KWin but have been unable to produce buggy
>> behavior, so far, without the workaround in gtkutil.c.
>
> I attach a patch that should handle the case where we want to switch
> from a non-fullscreen to a fullscreen frame.  Please try it.

Th

> FRAME_OUTER_WINDOW (f) should probably be replaced by some GTK-specific
> window but I don't yet know which one.
>
>>> When worse comes to worse we could condition that somehow: Invent an
>>> option which is off by default and call x_wm_set_size_hint when it's on.
>>
>> I do wonder how useful it is to support the case without a window
>> manager; unfortunately, I think it is useful, much as I'd enjoy all
>> that code going away and leaving things to the window manager.
>
> I miss you here: Which "case" do you mean?

I was considering whether it might be best to remove the
no-window-manager code entirely, but I don't think we should.

>> Anyway, if x_check_fullscreen is supposed to work the way it currently
>> does, bypassing xg_frame_set_char_size, there's a third issue to add
>> to my list:
>>
>> (3) x_check_fullscreen does not call store_frame_param, unlike
>> x_set_window_size_1, so the frame has its 'fullscreen parameter
>> cleared to nil by x_net_wm_state; the next `set-frame-font' call then
>> results in an integral frame size rather than the full screen.
>
> Correct me if I'm wrong: We run x_check_fullscreen only when the window
> manager doesn't support fullscreen natively.

Right. x_check_fullscreen exits very early unless the window manager
fails to support fullscreen.

> WOW when we run
> x_check_fullscreen, we emulate the behavior of a window manager by
> calculating the respective sizes ourselves.

Correct.

> Now when Emacs sets the fullscreen frame parameter itself, this action
> basically covers only what we get from the window manager.  A user who
> wanted a fullscreen frame would have set the according frame parameter
> already.  What am I missing?

I think it's that x_net_wm_state clears the fullscreen flag in the
middle of our operation.

>> If my understanding is correct, the best way forward is this:
>>
>>   - skip the hints in maximized/fullscreen state if
>> wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it
>> might be KWin
>>   - otherwise, set the hints
>
> OK.  These can be done easily, maybe in combination with my patch.

I think your patch actually solves that problem: if there's no WM,
get_current_wm_state will always return FULLSCREEN_NONE, so we set the
size hints appropriately.

>>   - call x_wm_set_size_hint from x_check_fullscreen
>
> OK.  Funnily we call a function x_wm_set_size_hint to handle a scenario
> where there's no window manager.
>
>>   - call store_frame_param from x_check_fullscreen
>
> It might not harm but, as mentioned above, this should not be
> necessary.  Or, if it is necessary because the parameters are not in
> place yet, the bug seems to be elsewhere,

Again, I think it makes sense once you take into account x_net_wm_state.

>>> I see.  If in frame.c you initialize frame_resize_pixelwise to 1 then
>>> everything works OK?
>>
>> ...Almost. Sorry. If I set frame_resize_pixelwise to 1 and run
>> `set-frame-font' afterwards,
>
> Hmm..  so you insist.  Can you tell me why `set-frame-font' can change a
> fullscreen frame's size?

Missing link :-)

>> the frame loses its full-screen
>> resolution and changes to a similar resolution that's a multiple of
>> the character size, as far as I can tell. This is due to issue (3), I
>> believe. Similarly, we don't adjust for the tool bar size, which I
>> also believe is due to issue (3) (I keep forgetting about that one
>> since I don't usually use the tool bar).
>
> Let's look into the toolbar issue later.  What we have to check first
> is:
>
> (1) You have a "correctly" maximized frame and `frame-resize-pixelwise'
>     is non-nil.  What is the frame's fullscreen parameter's value?
>
> (2) If that value is non-nil, how comes `set-frame-font' can change the
>     frame size?
>
>> I have attached the minimal patch (as far as I know) that works:
>> initialize frame_resize_pixelwise to 1,
>
> We can't do that.  I mentioned that only so you can check whether it
> would work in principle.

Oh, I agree, but I was sufficiently confused I thought it important to
be sure what needed changing before actually working out how to do it
cleanly.

>>> We could invent a function `set-frame-resize-pixelwise' which sends the
>>> size hints (maybe iff when a frame is not fullscreen, or so to avoid the
>>> KWin bug).
>>
>> How would that be different from x_wm_set_size_hints with FLAGS=0?
>
> It would modify the increments accordingly.  That is
> `set-frame-resize-pixelwise' with a non-nil ARG would set the increments
> to 1 and with a nil ARG it would set them to the frame's column and line
> heights.
>
>> I
>> suppose we could modify only the increments and leave the rest of the
>> size hints alone, but is that enough to prevent bad KWin behavior?
>
> You mean calling `set-frame-resize-pixelwise' in a fullscreen state on
> KWin would produce the bug again.  You're probably right.  So this won't
> help much.





>
> martin

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Sun, 23 Aug 2015 12:29:30 +0000

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

Sorry, I accidentally sent that email half-finished.

On Sun, Aug 23, 2015 at 12:20 PM, Pip Cet <pipcet <at> gmail.com> wrote:
>>> I'm not a hundred percent certain; from reading the thread, I think
>>> it's the former: the window is in full-screen mode and starts
>>> shrinking. I've installed KWin but have been unable to produce buggy
>>> behavior, so far, without the workaround in gtkutil.c.
>>
>> I attach a patch that should handle the case where we want to switch
>> from a non-fullscreen to a fullscreen frame.  Please try it.

That patch has no effect, but that's consistent with my understanding
of the situation; it might have an effect on users of the buggy KWin
version.

I've attached a patch that combines your patch with the minor fixes I
suggested in the previous email. It appears to work here.

[0001-Fix-fullscreen-issue.patch (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Sun, 23 Aug 2015 15:10:53 +0200

>> Do I understand finally?  x_net_wm_state resets the fullscreen state to
>> nil via its store_frame_param?  That would be the missing link then.
>
> Indeed.

Aha.

> (Minor point of confusion here: there are two functions called
> `x_net_wm_state' and `x_handle_net_wm_state' which appear to do the
> same thing...)

The other one handles the sticky value.  I've no idea whether it's
useful, though.

> The problem appears with all of maximized, fullheight, fullwidth, and fullboth.

Because in all of these cases setting the size hint is suppressed and/or
the parameter is reset.  This is quite a mess.

>> So when you try to increase the height of a normal frame by one pixel,
>> which is the resize operation you send?
>
> set_frame_height calls adjust_frame_size which calls x_set_window_size
> which calls xg_frame_set_char_size.
> x_set_window_size_1 is NOT being called in this case.

Aha.

>>   I suppose it's the last one
>> from x_set_window_size_1 so Emacs correctly passes the size hint with
>> frame_resize_pixelwise 1.  Right?
>
> No, x_set_window_size_1 never is called here.

Obviously.

> It's the last case in xg_frame_set_char_size, which calls
> gtk_window_resize FIRST, then calls x_wm_set_size_hints. I do not
> understand why that works, but it appears to. (Is this another bug?
> I'm seriously confused at this point).

I too. But I already mentioned that in my second mail ;-)

>> If this is the case, then Emacs should, for you, also handle fullwidth
>> and fullheight requests correctly via the first and second of the
>> requests in x_set_window_size_1.  Right?
>
> No. x_set_window_size_1 isn't called at all. xg_frame_set_char_size
> isn't called for fullscreen requests at all.

OK

>> So the two remaining cases Emacs can't handle for you are fullscreen and
>> maximized requests.  Right?
>
> No, it's all four fullscreen settings.

OK

>>> I do wonder how useful it is to support the case without a window
>>> manager; unfortunately, I think it is useful, much as I'd enjoy all
>>> that code going away and leaving things to the window manager.
>>
>> I miss you here: Which "case" do you mean?
>
> I was considering whether it might be best to remove the
> no-window-manager code entirely, but I don't think we should.

IIRC we earlier never asked a window manager and emulated the fullscreen
stuff ourselves.  Currently we still emulate fullheight and fullwidth on
Windows for example.

>>> If my understanding is correct, the best way forward is this:
>>>
>>>    - skip the hints in maximized/fullscreen state if
>>> wm_supports(net_wm_state) || wm_supports(net_wm_state_fullscreen), it
>>> might be KWin
>>>    - otherwise, set the hints
>>
>> OK.  These can be done easily, maybe in combination with my patch.
>
> I think your patch actually solves that problem: if there's no WM,
> get_current_wm_state will always return FULLSCREEN_NONE,

... via is_hidden ...

> so we set the
> size hints appropriately.

Hopefully.  So let me summarize what's needed:

(1) x_check_fullscreen has to call x_wm_set_size_hint before it calls
    x_wm_set_size_hint.

(2) x_wm_set_size_hint should set the increments as long as the window
    is not fullscreen-something.

(3) x_check_fullscreen has to restore the fullscreen frame parameter
    mangled by x_net_wm_state.

(4) (Possibly unrelated) xg_frame_set_char_size should call
    x_wm_set_size_hint before calling gtk_window_resize.

If you come up with a patch for (1)-(3) I'll install it and we can see
what kind of breakage it gets us.

--- I see you've done that already. ---

We can do (4) later.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Sun, 23 Aug 2015 15:23:20 +0200

> I've attached a patch that combines your patch with the minor fixes I
> suggested in the previous email. It appears to work here.

Thanks.  This

+  lval = Qnil;
+  switch (f->want_fullscreen)
+    {
+    case FULLSCREEN_WIDTH:
+      lval = Qfullwidth;
+      break;
+    case FULLSCREEN_HEIGHT:
+      lval = Qfullheight;
+      break;
+    case FULLSCREEN_BOTH:
+      lval = Qfullboth;
+      break;
+    case FULLSCREEN_MAXIMIZED:
+      lval = Qmaximized;
+      break;
+    }

looks a bit ugly.  Can't we set lval in the switch above?
If f->want_fullscreen changed in between we'd get in hot water anyway.

(Also I'd like to keep the patch resonably small so I can install it as
a "tiny change".  Or do you have copyright papers signed for Emacs?)

martin

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Sun, 23 Aug 2015 13:47:58 +0000

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

On Sun, Aug 23, 2015 at 1:23 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>> I've attached a patch that combines your patch with the minor fixes I
>> suggested in the previous email. It appears to work here.
>
> Thanks.  This
>
> +  lval = Qnil;
> +  switch (f->want_fullscreen)
> +    {
> +    case FULLSCREEN_WIDTH:
> +      lval = Qfullwidth;
> +      break;
> +    case FULLSCREEN_HEIGHT:
> +      lval = Qfullheight;
> +      break;
> +    case FULLSCREEN_BOTH:
> +      lval = Qfullboth;
> +      break;
> +    case FULLSCREEN_MAXIMIZED:
> +      lval = Qmaximized;
> +      break;
> +    }
>
> looks a bit ugly.  Can't we set lval in the switch above?

I agree.

> If f->want_fullscreen changed in between we'd get in hot water anyway.
>
> (Also I'd like to keep the patch resonably small so I can install it as
> a "tiny change".  Or do you have copyright papers signed for Emacs?)

(No, but soon, hopefully.)

I've attached the patch with a suggested ChangeLog entry (though of
course you should change it to your own name).

[0001-Fix-full-screen-code-when-there-is-no-window-manager.patch (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Sun, 23 Aug 2015 16:09:33 +0200

> (No, but soon, hopefully.)

Please do that.  We might need it.

> I've attached the patch with a suggested ChangeLog entry (though of
> course you should change it to your own name).

Thinking about this twice: Could you please also send a patch that's
based on your earlier proposal, namely to "skip the hints in
maximized/fullscreen state if wm_supports(net_wm_state) ||
wm_supports(net_wm_state_fullscreen), it might be KWin" and leaves out
any of the changes I proposed.  I think it would be cleaner and not
change anything for KWin users who apparently are happy with the current
state of affairs.

Thanks, martin

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Sun, 23 Aug 2015 14:44:18 +0000

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

On Sun, Aug 23, 2015 at 2:09 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>> (No, but soon, hopefully.)
>
> Please do that.  We might need it.

I sent the email last week, so it's beyond my control :-)

>> I've attached the patch with a suggested ChangeLog entry (though of
>> course you should change it to your own name).
>
> Thinking about this twice: Could you please also send a patch that's
> based on your earlier proposal, namely to "skip the hints in
> maximized/fullscreen state if wm_supports(net_wm_state) ||
> wm_supports(net_wm_state_fullscreen), it might be KWin" and leaves out
> any of the changes I proposed.  I think it would be cleaner and not
> change anything for KWin users who apparently are happy with the current
> state of affairs.

Attached. I feel a bit uneasy about making wm_supports a global
symbol, maybe it should be x_wm_supports? In any case, please do let
me know what else needs changing and I'll be happy to do it.

Thanks again!

[0001-Fix-full-screen-code-when-there-is-no-window-manager.patch (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Sun, 23 Aug 2015 19:55:20 +0200

> I sent the email last week, so it's beyond my control :-)

Fine.

> Attached. I feel a bit uneasy about making wm_supports a global
> symbol, maybe it should be x_wm_supports?

x_wm_supports sounds indeed better.

> In any case, please do let
> me know what else needs changing and I'll be happy to do it.

Everything else is perfect now (IMHO).

martin

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Sun, 23 Aug 2015 19:43:27 +0000

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

On Sun, Aug 23, 2015 at 5:55 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>> Attached. I feel a bit uneasy about making wm_supports a global
>> symbol, maybe it should be x_wm_supports?
>
> x_wm_supports sounds indeed better.

Patch attached. Still works, too!

>> In any case, please do let
>> me know what else needs changing and I'll be happy to do it.
>
> Everything else is perfect now (IMHO).

Well, let's hope there won't be a flood of bug reports from KWin users.

Thanks again for all your help in this very confusing matter,
Pip

[0002-Rename-wm_supports-to-x_wm_supports.patch (text/x-patch, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 21317 <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK,
 no window manager)
Date: Mon, 24 Aug 2015 10:17:31 +0200

> Well, let's hope there won't be a flood of bug reports from KWin users.

Installed on master/trunk so let's wait for the flood.  Please have a
look and if everything's OK close the bug.

martin

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

From: Pip Cet <pipcet <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 21317-done <at> debbugs.gnu.org
Subject: Re: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no
 window manager)
Date: Mon, 24 Aug 2015 10:45:26 +0000

Everything seems to be working fine here, hopefully this will close
the bug properly.

Thank you again,
Pip

On Mon, Aug 24, 2015 at 8:17 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> Well, let's hope there won't be a flood of bug reports from KWin users.
>
> Installed on master/trunk so let's wait for the flood.  Please have a
> look and if everything's OK close the bug.
>
> martin

Previous Next

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