←back to thread

511 points ayaros | 2 comments | | HN request time: 0.518s | source

https://lisagui.com/info.html

This is a web OS I wrote in vanilla JS that looks like the Apple Lisa Office System (1983-85), with other contemporaneous influences and additional improvements and features. It's currently in alpha and isn't remotely bug free. I had been holding off on posting this here until it was somewhat presentable and useful. Please note; the Lisa conforms more literally to the desktop metaphor than most modern GUIs - some of the important differences are mentioned in the readme.

This is a complete recreation of the UI in JS; it all renders to a single canvas element. It's not a CSS theme, and not an emulator ported to JS. None of the code is written by Apple. I'll be happy to elaborate more in the comments, but the short version is the entire UI is defined outside the DOM using JS objects. Thus, every interface element - menus, windows, controls, and even typefaces - was recreated from scratch. There are no font files - I wrote my own typesetting system, which supports combining multiple text styles and generates new glyph variants on the fly.

Many of the technical decisions I made were motivated by a desire to have this look the same in every browser. That's harder to do with the DOM and CSS, and why I moved as much logic as I could to JS. Also, the only part of the project outside of vanilla JS and standard web APIs is the Gulp toolkit, which I'm using as a minification/build tool. No vibe coding was used to make this!

This is based on a UI from the 80s, and won't work well on your phone. If you insist on running it that way, turn on trackpad mode in the touchscreen settings panel of the preferences app. For best results, install it as a PWA (add it to your home screen). Also there are some odd Android bugs; the native touchscreen keyboard is currently broken, and there's an issue with the cursor when dragging windows.

I realize there's not a whole lot to do within LisaGUI right now; I've got a big list of additional features and apps I'll be adding in the future. I've been working on this project for a while, and I'm eager to hear people's feedback and answer questions about it.

Show context
ayaros ◴[] No.44483280[source]
The Lisa doesn't have square pixels, so the canvas is scaled to be 1.5x as high as it is wide. This generally looks fine on high-dpi displays, because there's technically twice as much space to render with (pixels are 2px wide by 3px high). However, things will look distorted on a lower resolution display (where pixels are 1px wide by 1.5px high). That's just a compromise I made when designing this.

The good news is, if you have a large enough low-dpi display, and you make the window big enough, the automatic integer scaling settings will kick in, and the pixels themselves will be displayed larger. This can be forced via the preferences app (under the display options). If you screw this up, then restart LisaGUI while holding the shift key to reset the scaling settings.

EDIT: Unrelated to this, there are a couple minor bugs with PWAs on iOS relating to the positioning of the canvas. These can be resolved by rotating your device to a different orientation and then rotating it back to the original position... but this is annoying.

EDIT 2: To close windows, just double click the icon in the titlebar! This "collapses the window back into an icon."

replies(1): >>44484710 #
ivape ◴[] No.44484710[source]
How do you handle dynamic window/font scaling regardless of browser size (you get it for free with html mostly).
replies(2): >>44484971 #>>44494279 #
1. socalgal2 ◴[] No.44494279[source]
The short answer is, you can't

If we're talking about pixel perfect rendering there are various issues in the Web APIs that conspire against you.

devicePixelRatio (dpr) - This is supposed to tell you how many CSS pixels = one device pixel. This particular demo ignores it. On my Windows PC my dpr is 1.25 and the site looks horrendous with every other pixel 4th pixel of a font being double wide (or something along those lines). Not dissing the demo, it's cool. It's uncommon for Web devs to be aware of these issues as like 99.99% are on a Mac and never set zoom to anything other then 100%

The idea was supposed to be, you could take the CSS size and multiply by devicePixelRatio to get the display size. Unfortunately that does not work for various reasons.

There's zoom. Firefox and Chrome change the devicePixelRatio in response to zooming. Safari does not. Even if Safari supported this it's not enough. You can maybe repo how bad the site looks on my Windows PC on a Mac by zooming in on any browser (pick zoom from the menus, not pinch to zoom - see below)

Next there is pixel snapping. The short version is, imagine your window is 3 pixels wide and you ask the browser to make 2 elements side by side each 50% wide. If you check the CSS width both elements will say they are 1.5 pixels wide (getContentBoundingRect().width). But the browser won't display a 1.5 pixel element. I will snap one element 2 pixels and the other 1 pixel. To find out which is which you're supposed to use ResizeObserver with devicePixelContentBoxSize, but again Safari doesn't support this. It's not just with splits, that just the easiest way to demo the issue. Get this wrong and your checkerboard background will have a stripe somewhere where the checkerboard is missing a row or column.

Next there is pinch to zoom. It's separate and reported no where in the Web API AFAICT. The browsers will re-render text/svg to a higher resolution when you pinch to zoom but they don't pass that info to the page so it can not re-render canvases in response.

So: tl;dr, you can't - partly because of Safari. Partly because the Web is missing functionality

replies(1): >>44495527 #
2. ayaros ◴[] No.44495527[source]
I should clarify I'm indeed not using the api call to get device pixel ratio; I forgot I had ended up not needing it because all that code is stuff I wrote about a year ago, lol