GNU bug report logs -
#65183
29.1; Child frame moving and resizing problems
Previous Next
Full log
Message #17 received at 65183 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It seems that variables `x-gtk-resize-child-frames' and
`x-gtk-use-window-move' do not help with this.
I am using KDE with KWin (X11) version 5.27.7. I don't know where there is
any known issue on this platform.
From another perspective, is there a way to perform resize and move at the
same time?
(I mean, could the two steps be executed within a single redisplay cycle,
so that users would not see the intermediate changes?)
If these two steps are not done separately, the execution order would not
matter.
As I wrote in my first email, I can see the child frame being moved and
then resized
on my computer, even though the two steps happen very quickly.
martin rudalics <rudalics <at> gmx.at> 于2023年8月11日周五 08:06写道:
> >> 2. In the code I gave, `set-frame-size' should be executed before
> `set-frame-position'.
> >> But in fact, the child frame was first moved, and then resized. It is
> in the wrong order.
> >
> > I don't think you can trust the order in this case, as at least some
> > of the actual move/resize is performed by the window-manager.
>
> ... and Emacs only fills its text into the areas provided and exposed by
> the window manager. As a rule, never trust the order of execution in
> such case. Resizing child frames is already tricky enough with GTK3 and
> some window managers. We have the variable 'x-gtk-resize-child-frames'
> for that but setting it shouldn't change anything in the case at hand.
> Neither should 'x-gtk-use-window-move' help but you can still try.
>
> martin
>
[Message part 2 (text/html, inline)]
This bug report was last modified 1 year and 364 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.