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

[martin rudalics]

> GNUstep what? I'm hesitant to install the dependencies, whatever they are.

Forget it.  It can be useful for checking dependencies when implementing
new features.  One cannot do practical work with it IME.  What I meant
was rather whether anyone see problms like yours on NS-based machines.

> Still, a good question. I did a Lucid toolkit build and, lo and behold, the 
bug went away. Also it's blazing fast:
>
> (benchmark 200 '(resize-test test-frame))
> => 0.007s

So is it usable?  In your other mail you seemed to indicate that it's
still flickering.  And can you resize child frames by dragging their
borders with it?

If it _is_ usable, the problem is not with mutter but with GTK (maybe in
connection with mutter) or our interpretation of GTK.  To make very sure
you could also try a Motif build (it had very few dependencies when I
installed it, IIRC).

In either case this is the most important finding we had so far.  I
should have asked you earlier.

> That didn't help, however. With either value of frame-resize-pixelwise.
>
> Did 'make bootstrap', to make doubly sure.

I have to go through our GTK code once more.  Maybe I find a similar
discrepancy.  For example, does anything change when you set
'x-gtk-use-window-move' to nil?

> It appears that they work okay in other desktop environments, though. It 
might also turn out to be a GTK problem.
>
> FTR, my GTK version is 3.24.8.

Mine is 3.22.11 and I'm always reluctant to upgrade my environment.  For
every problem upgrading fixes, I usually get three new ones.  Does your
GTK still have the

(emacs:2053): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 
'extra_space >= 0' failed

problem?  I see it here when starting emacs -Q from a terminal and use
the mouse to shrink the Emacs GUI frame to something less than the tool
bar width.

martin