GNU bug report logs - #14627
24.2; Vertical frame size shrinking

Previous Next

Full log

Message #95 received at 14627 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>, Jan Djärv
 <jan.h.d <at> swipnet.se>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 13 Feb 2015 19:23:43 +0100

> I've now updated and confirm that with the recipe I gave -- frame
> maximized with side by side windows, one containing an Info buffer --
> switching between the windows no longer causes the frame to shrink
> vertically.  The only oddity is that when the Info buffer is selected
> there is an empty space the width of the frame one line high below the
> minibuffer.

Does this still happen with current trunk/master?

> However, there is still a shrinking problem.  In KDE clicking the
> frame's (i.e. WM window's) maximize button with mouse-2 instead of
> mouse-1 maximizes the frame vertically but not horizontally.  When I do
> this, then split windows (either vertically or horizontally), open an
> Info buffer in one window and switch between the windows, then the frame
> still (i.e. even with your patch) shrinks vertically by one line for
> each switch back to the Info buffer.  If I drag the border of an
> unmaximized frame to make it vertically fill the desktop and repeat the
> recipe, no shrinking occurs.  And if I maximize the frame horizontally
> by clicking the maximize button with mouse-3 and repeat the recipe,
> there is also no shrinking.

And this?

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.