[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#4543: window-full-height-p

From: martin rudalics
Subject: bug#4543: window-full-height-p
Date: Sun, 27 Sep 2009 09:49:28 +0200
User-agent: Thunderbird (Windows/20090302)

> We are looping: the more complex window configurations are irrelevant
> for the root window, I think.

Because I tried to come up with a simple, easily repeatable example that
does not need a more complex configuration.

> What I'm missing is how the code fragments you show are related to the
> problematic behavior when `scroll-bar-mode' is toggled.

Since I never understood the mechanism handling frame parameters I can
only conjecture that it's x_set_scroll_bar_width (the handler for the
scroll-bar-width parameter) calling change_frame_size which causes this.

But the basic problem is that handling scroll bar sizes on the frame
level cannot make sense because the mechanism doing that wouldn't know

(1) whether an individual window has scrollbars and how large they are,

(2) the number of side-by-side windows in any horizontal bisection of
    the frame.

Even if that knowledge were present, there still remain configurations
where adjusting the frame size can't DTRT.  Consider the following two
examples with slightly "more complex configurations":

Example 1: Split the window of a single-window frame into two windows
one above the other and remove the scrollbar in _one_ of the emanating
windows.  Toggle scroll-bar-mode.  Whatever toggling does to adjust the
frame size it will be wrong for one of the windows.

Example 2: Split the window of a single-window frame into two windows
one above the other.  Now split the upper window into two side-by-side
windows.  If you now toggle scroll-bar-mode and try to correctly account
for the scrollbars in the side-by-side windows, the lower window will
grow or shrink by an additional column.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]