Interlisp
default screen settings for online, on Mac, on Linux ...
there was a problem with some X servers not reporting accurate screen size, and also maiko not doing the "right" thing to adjust when the reported size exceeded 2^21 bits.
We might be able to do better by recommending X servers; but for high-res displays what I think we could do is
if window.screen.width * window.screen.height > 2^21 then default the lisp width and height to a fraction of the screen's width and height such that if you run fullscreen and turn on scaling it will be a simple scale factor (1/2 2/3 3/4 4/5). This is just for the initial defaults for lisp screen size
if the screen size is less than or equal to 2^21 then default can be screen size.
Do you have a suggestion for how to decide if it's a high-res screen?
These are the reported screen dimensions from the X server on a mac, with two screens attached but moving the arrangement of the screens around:
dimensions: 2560x2318 pixels (677x613 millimeters)
dimensions: 2862x2318 pixels (756x613 millimeters)
dimensions: 4000x1418 pixels (1056x374 millimeters)
dimensions: 4000x1418 pixels (1058x375 millimeters)
dimensions: 4000x1570 pixels (1056x414 millimeters)
dimensions: 4000x2272 pixels (1056x599 millimeters)
My guess is that the browser running VNC has a better idea of the window dimensions and the window.screen dimensions as well.
see discussion at https://groups.google.com/d/msgid/interlisp/EBAFA6C5-E5EB-4151-B59B-998785C8FFAC%40gmail.com
It might be worth checking if pixel adjustments with VNC might be OK with 1/2, 2/3, 3/4, 4/5 screen size
What is the actual maximum size to run-medley? On my 4K display, using 2560x1536 gave a window with the bottom part (not carefully measured, but eyeballed at about the bottom quarter) random pixels. At 2560x1024 it works fine, so at least 125% of 2^21 pixels, but much less than 188% Since my display is 28 inches, it's about 160 DPI, so the default fonts are indeed too small. FONTSET(BIG T) is OK. I tried modifying DINFO creation of FREEMENU to replace the hard coded Helvetica font sizes with values based on DEFAULTFONT and BOLDFONT and this does result in a more readable DINFO graph, but the TEDIT manual pop ups are still using 80 dpi fonts, so are only marginally readable.
Issue #39 'support larger displays' has been one of those issues with too many moving parts. The display initialization code suffers from a failure of many X servers to report the actual individual screen sizes rather than the sum.
Better fonts (importing other raster fonts) is always just around the corner; it should be easy (says here) but when I've started there are lots of distractions.
In the short term I'd recommend running in full screen mode with pixel scaling. NoVNC seems to do a fine job).
It's unclear to me why you would have got anything useful when specifying sizes that would result in more than 2^21 bits on the display -- the startup code checks if display_width * display_height is greater than 2^21, and if it is, it changes the display_height to 2^21/display_width. (initdsp.c, init_display2(), called from ldsout.c).
If I start up medley telling it the Lisp screen size is 2560x1024, when it comes up running... SCREENWIDTH is 2048, SCREENHEIGHT is 1024 -- which matches up with the "no more than 2^21 pixels" rule and the adjustment I noted in the previous comment. Edit: No it doesn't match my comment above. That would have adjusted the height, but somewhere else it decided that 2048 was the maximum width, so the init_display2() check didn't fire.
You are right, it ends up 2048 wide despite telling run-medley 2560.
When I had said 2560x1536, the width came out the same (i.e. 2048), testing just now, 2048x1536 Interlisp says it has 2048x1024, but X put up a window 1536 high with junk in the bottom third.
So I think there is an fairly unimportant bug where X doesn't get told the truncated height.
I suggest putting a comment in run-medley and/or user notes about the 2Mpel and 2K width limits. Is there any undocumented height limit beyond the area limit?
I'm not aware of any limit to the height beyond the total area limit. It's annoying that it doesn't get back to X to get it right. Tracking down every place that has its fingers into that is a bit tricky -- different constraints came from different hardware and were resolved differently, and of course none of the huge/hi-res displays we have today existed when this code was written.
Perhaps this is a stale issue, but I dug in a little today and gave it a try. I'm running Medley on a fairly recent vanilla Linux Mint.
By editing the startup script in /usr/local/bin/medley and /usr/local/interlisp/medly/run-medley I saw that one could tweak the maiko startup params -sc (screen size) and -g (geometry), which got me as far as D-Van-Buer above. It's possible to increase the width but not the higiht. The window do get taller but with just random pixels outside of around 1024.
Looking in the maiko source, there is a file inc/xdefs.h where these constants are defined;
#define WIN_MAX_WIDTH 2048 #define WIN_MAX_HEIGHT 2048
Which I doubled in size and compiled a new ldex (and replaced the old one in /usr/local/interlisp/maiko with it - but no cigar. Was worth a try though.
Looking further in the Maiko code I also see in main.c that there is a very interesting argument called -pixelscale which looks like it should do what we want to do - scale the screen on higher resolution devices, if needed.
But when I try to use it, it gets ignored (by doctoring the run-medley script).
Hmm.. looking again I see this is for SDL only, and it's currently running X, so that's why.
Anyway, it seems that perhaps SDL is the answer, so I'll go read up on those issues I guess :)
Wowzers, it worked.
I had to installd libsdl2-dev (of couorse) and could then compile an sdl version of Maiko using './makeright sdl'. The I copied the resulting ldesdl file into the /us/local/interlisp/maiko direcotry, edited the run-medley script to make use of it and boom :)
I can now see the text, no need for il-fontset (which only work for some output anyhow) and we're ready to rock. This is very nice.
I notice that the SDL version of Maiko is not built by default. I would recommend that it do get built by default and at least can be enabled by a command-line argument when running the medley startup script.
If you (y'all) would like to go this route (and there might reasons for it not being enabled that I don't know about of course) then I could provide a PR for doctored startup scripts which can both enable sdl and enable scaling.
@psvensson, makeright doesn't have a default - you have to tell it x or sdl, and those scripts are set up to do just one or the other. If you build with CMake (and I suggest using cmake-gui so you can more easily see the options available if you're not into reading CMakeLists.txt files) then you can enable both X and SDL options, and it will build both ldex and ldesdl and the lde it creates will invoke one or the other based on a command-line switch (X by default, SDL if you give it --display SDL).
@nbriggs Thank you, yes that makes sense. I think I was wondering about adding support for sdl in the startup scripts. It would require ldesdl to be provided as part of the downloadble/installable.
I can make it work for me now, but I asked if you would be interesting in a PR that would also enabled it for other users. But then that would require ldesdl to be built and included as part of some kind of packing process, which I have not yet looked at.