From here on out I only want to work on UI polish and accessibility. Let's see how long it can stay running without incompatibilities that require upgrades.
Achievement unlocked: I've built an app large enough that it crashes my programming environment that puts all the code on a spatial surface.
Or spread out enough, rather. It's not really about lines of code, just how much area the code occupies.
The problem: I do this snazzy initial animation (see video) that takes in the whole thing before zooming back in somewhere.
That animation works by drawing the whole surface to an in-memory canvas before transforming it. Turns out drawing to a canvas still uses the video card, and I don't have enough video RAM for a virtual "monitor" of this resolution.
Every color I use in the editor needs more sliders to customize :grimace: Right now there are 3 other colors: comments, scrollbars and those borders around the editor. Maybe I need a dropdown :grimace: Or just punt.
Progress on a lightweight programming environment for both computers and mobile devices. Modifiable live while it runs (though not on mobile devices).
The seed design constraint here was to structurally prevent the pop-up keyboard on a touchscreen from ever blocking my typing. That led to a multi-line commandline editor in the top half, fixing the non-editable output buffer in the bottom half. Independent commands/scripts then expanded in the only other direction available: left/right.
Generating gets a little subtle. I thought I was done, but the totals were >10. Trying to fix that generated invalid puzzles, and I had to ping-pong a bit between the two.
All through, it was nice to try out different straight-line solutions and animate them as I tested.
I seem to have renewed my collaboration for a tablet-friendly programming environment. For the current version, my partner led and pushed for preserving LÖVE primitives. For example, the LÖVE event loop calls functions you define called love.draw, love.keypressed, etc., and it seems desirable to continue to support those for familiarity's sake. This can seem impossible if the environment is also built in LÖVE and uses those same functions for providing its infrastructure, but since Lua is a dynamic environment there are tricks to make it work reasonably nicely.
Lately I've been taking the lead on a riff of that project, and I find I'm advocating strongly to not do this. I want to define new handlers like shell.draw and shell.keypressed that programs within my environment will have to call. And I finally figured out why I feel so strongly about this:
LÖVE has a function to return the bounds of the device/window. You typically can draw between x coordinates 0 and some width. And this information is often used to draw UI elements near the edges and corners. So should we now override functions like line to adjust coordinates and keep them in the client area? There's a lot of surface area to cover here. Bugs will inevitably happen, and when they do our attempts to create a seamless abstraction will cause more confusion.
Ranting more broadly, the desire for a "seamless experience" is a disease. The provider wants to "own the customer relationship," so that the user can forget there's anything in the universe but themselves and the app. Just like a casino. I'd rather not pretend we can wish the universe away with its possibility of errors. Let's me and the user treat each other as grown-ups, and not hide irreducible complexity in our supply chains. Here are the functions I provide, here are the functions LÖVE provides. I recommend you use my stuff where possible, but you don't have to. Yes, it's confusing. Welcome.
