A little thing like an 'edit' button introduces cascading issues: • LÖVE (in combination with mobile restrictions) won't let me modify code files in place. I have to overlay my changes in a new location. • But now I can't pick up any upgrades to my app. Upgrades modify code files in place, but any overlay persists (otherwise you'd completely lose your changes after upgrading). • But hey I have a programmable editor here! I'll just create a new file called 'scratch' with a one-liner to blow away the overlay. (With my app user's hat on, I know in this case my changes are minor in a way that I don't with my app developer's hat on.) • (A few hours later.) Wait, now none of my changes are having any effect. And they're completely blown away when I go back to the code. • 🤦🏼 Oh it's that 'scratch' file still hanging around. So it needs to be a 2-liner. I have to make any changes I want to the file system -- and then delete 'scratch' to make this a one-time operation. • I could try to create a screen of helpers for this, along with a comment that says, "insert file system operations here" after which is a delete of 'scratch'. In this way I find myself playing meta-Sokoban.. 🙄 Tl;dr - the 'edit' button isn't really usable yet. I really don't want to go down the road of building a compare and merge flow 🙄

(With my app user's hat on, I know in this case my changes are minor in a way that I don't with my app developer's hat on.)

Not having distinct hats sounds a lot like convivial technology.

Oh you and your idealism 🙂 You can also think of it as compile time vs run-time. Convivial technology means I can go do unsafe things when I know what I'm doing, things I never want the computer to blindly do to me.

I think convivial technology implies that you are yourself responsible for judging the safety of whatever you do. Though that's not an aspect I remember Ivan Illich talk about.

I've been thinking some more about handling what are essentially merge conflicts when editing my .love files. As background, you can click 'edit' on my Carousel-based .love files (figure 1) to edit their source code right on your device (figure 2), whether it's a computer or mobile device. The question is how to preserve your edits in the face of changes to lower levels: either the LÖVE app or the .love file you're making changes to. It seems to me one essential constraint of my platform choice is: upgrading the LÖVE app on a mobile device will blow away all installed .love files. Nothing I can do about this, and luckily it happens rarely enough that maybe we can live with that. But it does mean we can't get too comfortable making edits on a mobile device. With that in mind, I'm trying out the following flow: • When you edit a file in my Carousel-based multi-file apps like sokoban.love, it highlights the file in red to show that it has local modifications. (figure 3) • Later if you switch to a new version of sokoban.love, you can choose to 'revert' the file and blow away your changes. (figure 4) • You can also 'stash' the file (figure 5) so it won't run but you also still have access to it. Stashed files receive an immutable version suffix, and get highlighted in a third color (figure 6). • Stashed files can be unstashed if you want to try them out after making edits. (figure 7) Still klunky, but feels like an improvement. And I'm trying to only show the new complexities when they're relevant, so most people won't have to care about them. Above all, the hope is that the red reminds people to not make too many changes on a mobile device. And yes, I've been thinking about Ink&Switch all week. Perhaps this needs CRDTs and collaborative editing. But making it more friendly might encourage more changes than this platform can candidly handle, given the restrictions of mobile platforms.

The more I look at Android, the more I am tempted to give up on it. Install Termux and live inside it, hoping that Google won't pull the rug under Termux too soon. And hope for more open mobile platforms, such as the various mobile Linux initiatives.

That gets me in the feels. Much of this happens on iOS as well, to be fair. The one area where Android is really worse is access to the save directory. On iOS the Files app will show you the save directory (because you get access to each app's local file system). On Android I don't know of any way for my app to share files with the outside world.

I don't know one either, and I suspect it's Google's intention to block on-device data sharing.

Many apps can read/write to a shared dir like Downloads. But LÖVE doesn't seem to support that yet. Probably requires some new and heinous Android API.

Vague memory: it’s an old API, which exists at the Java level but not for native apps. Which I guess LÖVE is.

I meant new relative to UNIX open/read/write..