From: martin rudalics <rudalics@gmx.at>
To: Pip Cet <pipcet@gmail.com>
Cc: 21317@debbugs.gnu.org
Subject: bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager)
Date: Sat, 22 Aug 2015 19:46:38 +0200 [thread overview]
Message-ID: <55D8B57E.3010400@gmx.at> (raw)
In-Reply-To: <CAOqdjBcJpWo-XzTe8Lt1BnOf2xxjkLD7nP0PahorS5qvEMK+mA@mail.gmail.com>
> 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
next prev parent reply other threads:[~2015-08-22 17:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 22:34 bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window manager) Pip Cet
2015-08-22 6:40 ` martin rudalics
2015-08-22 10:50 ` Pip Cet
2015-08-22 14:16 ` martin rudalics
2015-08-22 15:32 ` Pip Cet
2015-08-22 17:46 ` martin rudalics [this message]
2015-08-23 9:45 ` Pip Cet
2015-08-23 11:12 ` martin rudalics
2015-08-23 12:20 ` Pip Cet
2015-08-23 12:29 ` Pip Cet
2015-08-23 13:23 ` martin rudalics
2015-08-23 13:47 ` Pip Cet
2015-08-23 14:09 ` martin rudalics
2015-08-23 14:44 ` Pip Cet
2015-08-23 17:55 ` martin rudalics
2015-08-23 19:43 ` Pip Cet
2015-08-24 8:17 ` martin rudalics
2015-08-24 10:45 ` Pip Cet
2015-08-23 13:10 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55D8B57E.3010400@gmx.at \
--to=rudalics@gmx.at \
--cc=21317@debbugs.gnu.org \
--cc=pipcet@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.