emacs-devel
[Top][All Lists]
Advanced

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

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


From: martin rudalics
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Fri, 14 Feb 2020 10:52:48 +0100

> I think we have made out due diligence and studied the problem with some 
detail, and we can write the details out to the Mutter bug report.
>
> Maybe we'll have some luck, and one of the developers replies with a simple 
alternative fix? That happened to me before with other projects.
>
> I won't be holding my breath, of course.

I had a glimpse at

https://gitlab.gnome.org/GNOME/gnome-shell/issues/1733

but its Javascript use annoys me and I'm not very enthusiastic about
registering or signing in to post a reply.  So, if possible, please
pass along the information below to them.

Thanks, martin


Below find some additional informations wrt the issue at hand.

Emacs makes the child window via XReparentWindow and asks to resize it
via gtk_window_resize.  The initial resize request gives the child
window the expected initial size and position when it is subsequently
mapped.  Further resize requests fail however.  There's no visible
feedback after the gtk_window_resize request has been issued and Emacs
never receives a ConfigureNotify event for it.

The problem does not occur for Lucid, Motif and GTK2 builds, it happens
with GTK3 builds only.

The following two workarounds are currently tested:

(1) Use gdk_window_resize instead of gtk_window_resize.  This requires
to tweak our handling of ConfigureNotify events in a way that is
incompatible with other window managers.  Hence we would have to
special-case mutter in a very queer fashion.  What's worse, however, is
that the child window cannot be enlarged beyond its "initial" size -
apparently the one given to it when it was mapped for the first time.
So one has to make a child window very large initially in order to
handle all future resize requests.  We have no idea as to who manages
that "initial" size and refuses our requests to make the child window
larger.

(2) Make child windows temporarily invisible when resizing them.  This
means that for every resize request we have to invoke gtk_widget_hide
first, then apply gtk_window_resize and finally call gtk_widget_show_all
to show the window again.  This usually will cause the child window to
flicker whenever it gets resized.

Neither of these solutions appear satisfactory so your help in this
matter would be highly appreciated.

Thanks in advance



reply via email to

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