-
-
Notifications
You must be signed in to change notification settings - Fork 29
Expose useful subfunctions in REGIONMANAGER #1336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
If a window is closed whose region is of an as-yet-unknown type, a new entry will be added implicitly to TYPED-REGIONS to that that region and future regions of that type can be recycled.
…d-region is also reshaped for reuse Also, the typed-region of a window is pushed on the front of the TYPED-REGIONS list when the window is closed, so the most recent region of that type will be used the next time. Recency seems more intuitive than primacy
2f5fa64 to
caa0546
Compare
masinter
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the one hand, this is "just LISPUSERS" and optional. But if we're going to bring this into standard practice, checking against other Lispusers packages
(TILED-SEDIT?) and Rooms. And, for everyone but especially for online users, readjusting window regions when reshaping the screen size (currently you do this by (LOGOUT) and then restarting).
|
There is more work to be done, but I think this is getting at some useful abstractions.
For typed-regions, one obvious extension is to allow a default window-size to be specified for each type, so that the user typically only has to pick the location. For me, I’m always dragging out windows that are much too large, filled with white space. So, a window for viewing a function (the tf command, analogout to pf) would default to something smaller than a region for viewing a file (the ts (tedit-see) command). In LFG, windows for dictionary entries would be smaller by default than windows for grammar rules. (It would be nice to have a function that estimates the window size based on the size of the object to be displayed, but that’s a harder problem.)
With respect to dependencies on screen-size changes, my intuition is that relocation would “fall out” if typed-regions could be specfied as relative regions, at least for relocation. This would also allow typed regions to default to locations relative to other regions, not just to the screen. A reasonable change to the size would be a lot trickier—fonts, layout, etc.
I haven’t yet tried to fold Sedit’s idiosyncratic window management into this more general scheme. But something like TILED-SEDIT might fall out if Sedit regions are specified relative to the last Sedit region. (Or, some of the features of TILED-SEDIT might be folded into this.)
… On Oct 18, 2023, at 7:36 AM, Larry Masinter ***@***.***> wrote:
@masinter approved this pull request.
On the one hand, this is "just LISPUSERS" and optional. But if we're going to bring this into standard practice, checking against other Lispusers packages
(TILED-SEDIT?) and Rooms. And, for everyone but especially for online users, readjusting window regions when reshaping the screen size (currently you do this by (LOGOUT) and then restarting).
—
Reply to this email directly, view it on GitHub <#1336 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJOFAEUOGSMD5YH33NDX77SOVAVCNFSM6AAAAAA5IYLPA6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTMOBVGI3TCNZRGM>.
You are receiving this because you authored the thread.
|
|
My comment was about REGIONMANAGER and whether or not it introduces any incompatibilities with older region management Lispusers packages that aren't normally loaded. How would we know? |
|
It doesn’t interfere with anything that worked before. It was never the case that the region parameter for any of these functions could be a non-NIL atom.
… On Oct 19, 2023, at 4:38 PM, Larry Masinter ***@***.***> wrote:
My comment was about REGIONMANAGER and whether or not it introduces any incompatibilities with older region management Lispusers packages that aren't normally loaded. How would we know?
—
Reply to this email directly, view it on GitHub <#1336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLR6O6KWP6GGPDCUSDYAG2V5AVCNFSM6AAAAAA5IYLPA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZRHA2DGNBYGI>.
You are receiving this because you authored the thread.
|
|
medley/rooms/ROOMS-WINDOW-HIDER contains an (ADVISE ATTACHWINDOW) I'm pretty sure the behavior will be different depending on the order of loading. |
|
Right, I think the ROOMS advice will wipe out (one way of invoking) the region manager extension, since it doesn’t include and pass the extra TAKEFROMCENTRAL argument. But if regionmanager is loaded after the advice, both should work as intended. This part of regionmanager hasn’t been used, although it would simplify the construction of applications with complicated attached window arrangements (like Filebrowser) and even region setups for windows that only have promptwindows attached.
I haven’t looked, but maybe whatever the advice in rooms is doing would also be more generally useful, and should therefore be provided in the basic attachwindow code. I think that adding the extra argument to the advice would make it order independent, as would driving the extension only through the window property.
Generally, I don’t like ADVICE (or the MOVD alternative) for system augmentations or incremental overrides. They both make it hard to figure out what code is actually running. I think there has been some discussion and maybe an issue somewhere about this.
… On Oct 20, 2023, at 8:28 PM, Larry Masinter ***@***.***> wrote:
medley/rooms/ROOMS-WINDOW-HIDER contains an (ADVISE ATTACHWINDOW)
while REGIONMANAGER avoids an ADVISE but is trying to do the equivalent by
(P (MOVD? 'ATTACHWINDOW 'ATTACHWINDOW.ORIG)
(MOVD 'RM-ATTACHWINDOW 'ATTACHWINDOW))
I'm pretty sure the behavior will be different depending on the order of loading.
—
Reply to this email directly, view it on GitHub <#1336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJGVGYNBP325RQZNQLYAM6NDAVCNFSM6AAAAAA5IYLPA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZTGYZTONJQGE>.
You are receiving this because you authored the thread.
|
|
I don't like ADVICE anywhere, because of (UNADVISE) -- it's useful while debugging and early development but shouldn't be used in deployed code. The MOVD alternative, defining NEW-FOO in terms of OLD-FOO and then (P (MOVD? 'FOO 'OLD-FOO) (MOVD 'NEW-FOO 'FOO)) has drawbacks as well MASTERSCOPE doesn't know about any of this -- you can move the P into an INIT-NEW-FOO function and change it to (P (INIT-NEW-FOO)) in the fileCOMS and change 'FOO to (FUNCTION FOO). A different way, with fewer difficulties, if is to use a variable NEW-FOO-ENABLED (if NEW-FOO-ENABLED then <... new way ... > else < ... old way ...>) BROWSER and Masterscope had this problem. And I think the MANAGER code uses ADVISE extensively. |
Clients can inject additional processing between getting and registering a region