bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21317: 25.0.50; frame-resize-pixelwise has no effect (GTK, no window


From: martin rudalics
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

>> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]