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: Sun, 23 Aug 2015 15:10:53 +0200 [thread overview]
Message-ID: <55D9C65D.1010201@gmx.at> (raw)
In-Reply-To: <CAOqdjBf+WOeQFup3ePBHQv_c-d8UAxJhiL+yTLTFrHmJpr-V9Q@mail.gmail.com>
>> 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
prev parent reply other threads:[~2015-08-23 13:10 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
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 [this message]
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=55D9C65D.1010201@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.