Interlisp
Request for standard way of deciding whether a window is completely onscreen
Variables SCREENHEIGH and SCREENWIDTH are set when the system comes up in a new environment. But there is no standard function for deciding whether a given window is totally on screen, without rolling out 4 different comparisons each time.
(SUBREGIONP SCREENREGION (WINDOWREGION W)) would do it, but SCREENREGION doesn't automatically exist.
So the feature request is to add an event function that creates SCREENREGION when the system returns, or a function (SCREENREGION) that creates the screen region as needed.
Immediate uses: cleaner test for having Tedit/Sedit fix up their windows when they are partially off screen
it would seem like some kind of "screen region changed" eventfn would try to more globally move or resize windows so that they fit (if they can) rather than a local simulated annealing kind of process is generally called for. If the screen gets smaller then you try to move or move and reshape.
I'd like to leave in the possibility that we could reshape the screen while the system is running. that would be especially handy for online.
There are multiple screens - so you have to ask about the screen size of the screen on which a particular window is displayed. (WINDOWPROP W 'SCREEN) is the screen W is on, (SCREENBITMAP s) gives you the bitmap, from which you can probably pull a REGION...?
The screen also has a DISPLAY FDEV which has an EVENTFN, and if we were implementing Larry's idea about changing the Lisp screen size while it was running... that would probably be the place to hook a "screen region changed" event. Currently that (\DisplayEventFn) only handles the six BEFORE|AFTER x LOGOUT|MAKESYS|SYSOUT events. If a screen changed size there would be a bunch of work chasing down all the things like the bitmap and the window FDEV and so on that would need to get new size information.
So, maybe what is needed for the question “am I within my screen” is a function that takes a window as its argument? (WITHIN-SCREENP WINDOW) is true if WINDOW is within its own screen?
More complicated adjustments to screen changes would also be good, but the simpler challenge is to recognize that the bits that you think you are bltting, when you scroll, may not actually be there.
On Dec 20, 2023, at 5:56 PM, Nick Briggs @.***> wrote:
There are multiple screens - so you have to ask about the screen size of the screen on which a particular window is displayed. (WINDOWPROP W 'SCREEN) is the screen W is on, (SCREENBITMAP s) gives you the bitmap, from which you can probably pull a REGION...?
The screen also has a DISPLAY FDEV which has an EVENTFN, and if we were implementing Larry's idea about changing the Lisp screen size while it was running... that would probably be the place to hook a "screen region changed" event. Currently that (\DisplayEventFn) only handles the six BEFORE|AFTER x LOGOUT|MAKESYS|SYSOUT events. If a screen changed size there would be a bunch of work chasing down all the things like the bitmap and the window FDEV and so on that would need to get new size information.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1467#issuecomment-1865368189, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKASIX75PBRDX75JU3YKOJLVAVCNFSM6AAAAABA5JNCR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRVGM3DQMJYHE. You are receiving this because you authored the thread.
But, on further thought, if we are running with multiple screens, what do the variables SCREENWIDTH and SCREENHEIGHT tell you? What if one screen is bigger than another, and the window moves between them?
On Dec 20, 2023, at 7:38 PM, Ron Kaplan @.***> wrote:
So, maybe what is needed for the question “am I within my screen” is a function that takes a window as its argument? (WITHIN-SCREENP WINDOW) is true if WINDOW is within its own screen?
More complicated adjustments to screen changes would also be good, but the simpler challenge is to recognize that the bits that you think you are bltting, when you scroll, may not actually be there.
On Dec 20, 2023, at 5:56 PM, Nick Briggs @.***> wrote:
There are multiple screens - so you have to ask about the screen size of the screen on which a particular window is displayed. (WINDOWPROP W 'SCREEN) is the screen W is on, (SCREENBITMAP s) gives you the bitmap, from which you can probably pull a REGION...?
The screen also has a DISPLAY FDEV which has an EVENTFN, and if we were implementing Larry's idea about changing the Lisp screen size while it was running... that would probably be the place to hook a "screen region changed" event. Currently that (\DisplayEventFn) only handles the six BEFORE|AFTER x LOGOUT|MAKESYS|SYSOUT events. If a screen changed size there would be a bunch of work chasing down all the things like the bitmap and the window FDEV and so on that would need to get new size information.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1467#issuecomment-1865368189, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKASIX75PBRDX75JU3YKOJLVAVCNFSM6AAAAABA5JNCR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRVGM3DQMJYHE. You are receiving this because you authored the thread.
I believe that SCREENWIDTH and SCREENHEIGHT (now) refer to the (MAINSCREEN) (I haven't read through the WINDOW sources though. I don't believe that windows were ever able to move between the screens - they stayed on the screen they were created on [CREATEW's REGION argument can be a REGION (implicitly on the \CURSORSCREEN) or a SCREENREGION, or NIL]
Hmmm... A brief glance in the WINDOW source: there is a (\ONSCREENCLIPPINGREGION WINDOW), which returns a region which is the part of the windows clipping region that is on the screen...
I see that the SCREEN datatype has SCWIDTH and SCHEIGHT fields. In which case. Would those get changed if the window size changed dynamically (online or in browser)?
In which case, the various calculations that now use the variables SCREENHEIGHT and SCREENWIDTH should be replaced by function calls.
Something like (SCREEWIDTH W) giving the width of W’s screen or (MAINSCREEN) if W is NIL ?
On Dec 21, 2023, at 11:19 AM, Nick Briggs @.***> wrote:
Hmmm... A brief glance in the WINDOW source: there is a (\ONSCREENCLIPPINGREGION WINDOW), which returns a region which is the part of the windows clipping region that is on the screen...
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1467#issuecomment-1866814462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJMULUMIZPD4SY5IDXTYKSDTPAVCNFSM6AAAAABA5JNCR6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRWHAYTINBWGI. You are receiving this because you authored the thread.
Would those get changed if the window size changed dynamically (online or in browser)?
We don't have a design for dynamic resizing of the screen - but presumably they would have to.
I haven't traced through what happens to (and who is responsible for) the (MAINSCREEN) and SCREENWIDTH/SCREENHEIGHT changes when you logout and log back in with a different screen size. I notice that there are SUBRs for DSP-SCREENWIDTH and ...HEIGHT, and that they get called from LLDISPLAY in (UPDATESCREENDIMENSIONS). (\CreateScreenBitMap) deals with the screen bitmap and bashing the BITMAP object. I don't know if it's quite on the scale of rewriting TEdit, but dynamic sizing is sure not an easy thing to contemplate when one wants to get it right.
See in LLDISPLAY: \STARTDISPLAY and \MOVE.WINDOWS.ONTO.SCREEN and all the related stuff. SCREENWIDTH and SCREENHEIGHT are used to set the SCWIDTH and SCHEIGHT of the \MAINSCREEN.
i was thinking of something more like we were talking about for doing a SAVEVM when the X-server goes down or closes the X window -- fake some kind of keystroke interrupt character that calls SAVEVM.
But when it's a window size chain, safter saving the VM, immediately restart with the new size.
This is all stuff that is possible now. Type control-B, then (IL:LOGOUT) then restart medley. Yes, it does a lot of setup and shutdown work, but you don't change window sizes that often.