Re: MS Windows Frame Maximize in .emacs (again)

[David Kastrup]

Juanma Barranquero <address@hidden> writes:

> On 6/9/05, LENNART BORGMAN <address@hidden> wrote:
>
>> I see, that is what I thought. But changing the size of a maximized
>> window on w32 confuses the w32 window handler a bit I guess. It
>> would be good to avoid this.
>
> Removing the full-lines restriction is perhaps too large a change
> for the freeze period.  Making maximized frames do-the-right-thing
> is OTOH worthwhile. All this IMO, of course.

One problem is that toggling tool-bar-mode and menu-bar-mode will
change the size of the frame, and that is a definitive nuisance.

In principle, we need to record whenever a geometry specification is
heeded whether, at the time of the instantiation of the geometry,
tool-bar and menu-bar have been on.  Then whenever the setting of
tool-bar-mode and menu-bar-mode is changed, the frame size needs to
get recalculated, by always rounding down any fractional lines
resulting from a change of the setting _from_ the original
instantiation, and by always rounding up any fractional lines
resulting from a change _to_ the original instantiation.  And the
fractional lines resulting from a change in menu bar and toolbar have
to be maintained separately, and menu bar and toolbar have to have a
height of at least one default window line.

And then we have window managers which behave strangely when docking
and undocking the toolbar and stuff.

I am not convinced that it would not be the least invasive fix to just
allow fractional window heights and thus be not forced to resize the
frame at all on such events.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum