Proposal to reuse regions for windows of a given type

[rmkaplan]

In our current set up there is no conventional way to prespecify the default region to be used or reused for a window of a given type. Typically, you have to produce a ghost region every time.

The filebrowser is an obvious example: if you do FB *, you have drag out a region. If you close the window and do FB * again, you have to drag out another region. Similarly for SEE and EDIT windows from the filebrowser, and for the Tedit windows that my little lispusers package uses for command-line scrollable PF and SEE. All very clunky.

So here is a proposal: introduce a WINDOWTYPE property on windows. When you open a window with a specified type and don't provide an explicit region, pick a previously used but currently unused region for windows of that type, asking for a new region only if all previous windows are currently in use. Closing a window of a given type will mark its region as available.

This can be done by a simple extension to CREATEW: If the REGION argument is an atom X other than NIL (or if WINDOWTYPE X is on the PROPS list), then assume that X is a type specification and look it up in a global TYPED-WINDOWS-REGIONS list. Then extend CLOSEW so that the region for a window with the WINDOWTYPE property is put back on the list under its type when the window is closed. (Maybe with a submenu on Close that closes all windows of that window's type--clear out all the file browsers or SEE windows with one click)

A user's INIT could initialize TYPED-WINDOWS-REGIONS to a few preferred regions for built-in types, so that typically filebrowser, PF, etc. windows start out in canonical positions without doing the ghost region thing, until a region is needed that is not currently available for that type. The user could turn this behavior on and off for particular types (like FILEBROWSER) by putting a kind of different entry on the regions list.

So: a conservative extension of CREATEW and CLOSEW. Comments?

[masinter]

Rooms has a number of window categories. We've been neglecting it. I don't know much about it.... should we ask Austin to demo?

[masinter]

i'd worry that this is a situation where it's easy to imagine invariants that don't hold.
There is no need to change EVERY createw and then add a bunch of exceptions.
add a new entry 'RECREATEW' that re-uses old boundaries for a named window types and then selectively change the callers (SEDIT, TEDIT etc)

I'm not sure what ROOMS did

[masinter]

Binder1.pdf

[rmkaplan]

It’s just a different way of specifying the initial region, by an atom other than NIL when you can’t specify it in advance. The additional code wrapper provides an alternative to the ghost box and other ways of pinning down the region. Then closing just makes the region available to other windows by posting the region back on the list. (The only glitch is that a window can be reopened after it’s been closed but not collected, so another window of the same type might come up to overlap it (we don’t have finalize, do we?).) You might want to assign types to some windows for other purposes, without getting into the region caching (e.g. Inspectors, where the objects are of different sizes and so should have their own regions). WDHACKS has some kludgy ways of recognizing particular kinds of windows, e.g. by looking at their reshapefns, so it can close all windows of those particular types. A generic type-based closer with a generic menu could be written by looking at types systematically. Sedit seems to have its own strategy for reusing regions, seems to be the only multiwindow application that does that (DINFO remembers the single window). (Sedit is different in another way: its prompt window actually allows cursor-moving editing, copy-select, meta-V, which Tedit promptwindows don’t do.) Rooms is heavy duty, more than the dozen lines of code that this takes.

…

On Oct 26, 2021, at 9:34 PM, Larry Masinter ***@***.***> wrote: i'd worry that this is a situation where it's easy to imagine invariants that don't hold. There is no need to change EVERY createw and then add a bunch of exceptions. add a new entry 'RECREATEW' that re-uses old boundaries for a named window types and then selectively change the callers (SEDIT, TEDIT etc) I'm not sure what ROOMS did — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#552 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOD22JCXEFIE3KKECLUI56OFANCNFSM5GYOTH2A>.

[rmkaplan]

Looking more carefully, CREATEW is the wrong place to set up caching for an application's previous GETREGION (tedit, filebrowser, tedit-pf...). Windows/regions are the primitive building blocks of the user interface, but most applications deal with constellations of windows. A Tedit "window" consists of 2 separate windows, the main text window and the promptwindow above it. Filebrowser consists of the main browser window plus several other windows/menus that are attached in various ways.

These constellations are created with a single call to GETREGION, but then that region is explicitly divided up by arbitrary code to take into account the sizes and locations of the other pieces, and the main text/browing window then gets whatever is left. Thus, Tedit takes out the height of the promptwindow and allocates the remainder to the text window. If a cached region is supplied for the call to CREATEW for the main window, then it is a crapshoot whether or not the various satellites will lie in or outside that region. Or whether a part of the screen will be obscured in an unexpected way.

This is related to a similar issue in MODERNWINDOWS, where the ghost region for reshaping/moving has to be the union of the regions of all the satellites. But in that case we already have the window with all the links back and forth between the peripheral and central windows and tools for unioning or otherwise fiddling with the subregions, so we can create (mostly) the expected behavior (reshaping Sedit with an attached menu has always been screwed up).

So I now think that this caching notion, to reduce the clunkiness of managing repeated up-and-down operations on the desktop, requires an extension of GETREGION (or probably the underlying GETSCREENREGION), so that the caller can ask for a previously defined but currently unused region of a given type (filebrowser, tedit pf, tedit see...). That region will be divided up in various ways by current code, and it would be up to that code to eventually attach it to at least one of the windows in the constellation (the main one?) so that the generic close function can recognize it and recirculate it.

Alternatively (but requiring more design work) would be to implement the higher-level notion of a window-constellation as a bunch of satellite windows together with a declarative specification of the attachwindow arguments that would attach it to a to-be-constructed main window. Given such a specification and an intended region for the whole constellation, the size calculations that are currently done piecemeal in different applications could be centralized. And it would be the constellations' regions that are cached and recycled, not the region of any individual window.

(BTW: it seems like main windows and attached windows point back and forth to each other. Is that a storage leak?)

[masinter]

The places where modernize re-uses previous regions is pretty annoying when it's wrong.
Which is quite often, in my usage pattern. And the prompts in PROMPTWINDOW are often wrong.
Modern applications don't ask you to draw out a region: they guess and leave it up to you to adjust if the guess is wrong. We could have a default guess width and height depending not on history but for the case in hand (TEdit SEdit, etc.), and choose a corner lower left position depending on where there is room. (leave room for scroll bars).
Then FB could advertise its "shrink to fit" to start with.
If there's no room on the screen, offer to cascade, or shrink those not active.

[rmkaplan]

I don’t think Modernize does anything special with respect to regions, other than allowing the left button to move and reshape when clicked in various places. Various programs have their own strategies for prompting for new regions or reusing old ones, all a hodge-podge. Sedit is particularly idiosyncratic, tlispusers/TILED-SEDIT seems to be an early attempt at dealing with this. In the current epoch I tried to provide some general underlying tools and conventions for attacking these issues, in lispusers/REGIONMANAGER. It defines notions of typed regions (e.g. Tedit, FB…), relative regions, and constellations of regions (which are used to connect the prc-compare windows). My hope was that this would be the basis for less noxious behavior, but at that time I didn’t take the risk of going into the various prominent applications to make them aware of this (e.g. to have the file browser pass the region-type atom FILEBROWSER instead of NIL when it goes to get a window-region. If that is done, then its initial default regions could be set in advance, and new regions would be typed and reusable. It would be even better to do more of this automatically, as you suggest. Sedit could do a reasonable estimate of the region-size based on the size of the structure, Tedit could at least look at the margin-width, FB could look at the longest string in the filename column, etc. And then maybe a search for empty space, given the estimated region size.

…

On Apr 22, 2023, at 9:07 AM, Larry Masinter ***@***.***> wrote: The places where modernize re-uses previous regions is pretty annoying when it's wrong. Which is quite often, in my usage pattern. And the prompts in PROMPTWINDOW are often wrong. Modern applications don't ask you to draw out a region: they guess and leave it up to you to adjust if the guess is wrong. We could have a default guess width and height depending not on history but for the case in hand (TEdit SEdit, etc.), and choose a corner lower left position depending on where there is room. (leave room for scroll bars). Then FB could advertise its "shrink to fit" to start with. If there's no room on the screen, offer to cascade, or shrink those not active. — Reply to this email directly, view it on GitHub <#552 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJDOKSA5VZXVM676KLXCP62JANCNFSM5GYOTH2A>. You are receiving this because you authored the thread.

[masinter]

this is an area for experimentation. We need to add some abstractions.
the main impediment to adding more window management (auto-tiling, for example) is that too many windows aren't resizable without loss. And, in turn, that is mainly the fault of the exec windows not having a repaintfn. If we could save the tty T output for an event, we could use that to build tiling window manager.

it ins't a typescript it's better. The typescript could be recovered by writing to a dribble file and using that ...

=> discussion