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

[martin rudalics]

> 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