Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 26.02.2020 19:30, martin rudalics wrote:
>  > I could ask why not omit the call to gtk_window_resize when 
> (totalwidth == gwidth && totalheight == gheight), but that would 
> probably only affect performance.
>
> You mean like in the attached?  It hardly affects performance here.

That's what I meant, yes. After testing it, I'm also not sure if there's 
a real performance improvement there. But maybe this change wouldn't 
hurt either.

> I meanwhile did a full GNOME installation here, a somewhat nightmarish
> experience trying to get a system menu and task bar, recovering all the
> stolen key bindings, disabling the trackers ...  It strongly reminds me
> of Windows 10 where I never managed to fix all relevant issues.

Personally, I don't use the system menu, or a task bar. Only a dock on 
the left. But then again, I'm using the Unite extension that makes it 
behave like Ubuntu's Unity.

> Anyway, AFAICT the hide during resizing approach seems to be the only
> halfway working alternative at the moment.

That, or the patch using the obsolete gtk_container_set_resize_mode. I'm 
not 100% sure which is the best choice (you seem to be favoring the 
hiding approach, judging by the next paragraph), but the other one seems 
to provide a better experience in the use case I'm looking at. 
Especially when combined with (setq x-wait-for-event-timeout 0.0).

> It's also the only one that
> can show a scroll bar on a child frame (not necessarily right away but
> after one resize operation at least).  Which hints at some outer-window
> vs edit-window snafu but so far I have no idea where to look.

FWIW, I'm pretty sure 99.9% of users of child frames out there aren't 
going to enable scroll bars.