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

[martin rudalics <rudalics@gmx.at>]

 > https://github.com/tumashu/company-posframe/issues/2
 >
 > Mutter is singled out as a cause, HiDPI or not.

OK.  Has anyone tried with a non-GTK build so we can exclude GTK
dependencies too?  Has anyone tried with NS (here GNUstep doesn't even
build at the moment)?

 > Andrey Orst said that he tried it with Mate desktop (using a fork of Metacity), and didn't see this problem here.

OK.

One more thing to try.  In x_wm_set_size_hint we don't set size hints
for child windows here (around line 1404 of gtkutil.c):

   if (NILP (Vafter_init_time)
       || !FRAME_GTK_OUTER_WIDGET (f)
       || FRAME_PARENT_FRAME (f))
     return;

I forgot why, maybe it broke something or caused some weird behavior.  I
should have had a reason back then and forgot to comment it.

Replace that with

   if (NILP (Vafter_init_time)
       || !FRAME_GTK_OUTER_WIDGET (f))
/**       || FRAME_PARENT_FRAME (f)) **/
     return;

and rebuild (it builds and runs without problems here).  Make sure to
run with 'frame-resize-pixelwise' t.  To the best of my knowledge we do
set size hints for non-GTK builds ...

 >  > Could we find at least one guru able to build mutter so she or
 >  > he can debug it - I don't have the faintest idea how to do that.
 >
 > I've posted that question.

Thanks.  I have no great hope that anyone will answer.

 > Should we start commenting on that issue?

Politely so, yes.  Always keep in mind that our way of using GTK is a
peculiar one and that child frames are a somewhat underdeveloped issue,
mostly used for modal dialogues, centered on their parent, never
changing size and the like.

 > Maybe you could start with a more comprehensive explanation
 > there. Using terms that Mutter developers would understand more easily
 > (meaning, not Lisp code).

Will do as soon as I know answers to the questions above.

 > Florian seems to be subscribed to that issue, BTW.

That's why I mentioned him.

martin