Re: moving window handling into lisp

[grischka <grishka@gmx.de>]

martin rudalics wrote:
>  > The distributed fuzzy-machine cannot be simplified because it defends
>  > itself by, well, being distributed.
> 
> The weak point of that machine is the size_window routine which IIUC is
> called by most of these distributed components.

It is true that it can weaken the machine if only one routine exists
to access some fundamental functionality.  In such case it would try
to force the implementation of other routines to do somehow the same
thing, just not quite.

There are signs that it has already started to do so with size_window,
e.g. the out-factored shrink_window with a ratio formula somehow
different from the one used for enlarging (as we know by now).

>  >>  > Me thinks there are much more thoughts spend on 'window-min-height'
>  >>  > now than there possibly were at the time when it was first 
> introduced.
>  >>
>  >> Not really.  Any window-manager has to deal with the possibility that a
>  >> window gets to small when its parent-window shrinks.  All we can do is
>  >> make such cases occur rarely, in practice.
>  >
>  > Window-managers don't deal with shrinking parent windows.  They deal
>  > with fixed desktop/root windows.
> 
> I obviously meant "any Emacs window-manager" here.  I don't even know
> whether desktop window-managers use concepts like parent-windows or the
> split-window paradigm.
> 
>  > With individual applications it's called "layout-manager", which exist
>  > in the various GUI toolkits.
>  >
>  > layout-managers are invisible containers that allow you to place
>  > components like widgets or windows of other layout-managers within,
>  > and to set a policy how these components are arranged, such as "box",
>  > "grid", "flow", ...
>  >
>  > The concept of min-size exists too, though individually for each
>  > component, and it actually means what it says, that is "keep this
>  > thing at least that large".  Consequently a case of "too small" can
>  > never happen.
> 
> So if a component doesn't fit it's iconified in some sense of that word?

"Doesn't fit" can only mean that the component can't cope with the
situation by automatic adjustment.

In that case the user is expected to fix the situation manually,
either by configuring the interface, (e.g. removing other components),
or by upgrading the display hardware (such as when you can't see the
OK buttons on some dialogs more frequently).

In any case, iconification (in any sense of the word) belongs to manual
configuration, not to automatic adjustments.

--- grischka

> 
> martin
>