Software Standards

Hello, I'm here to propose some software standards. This post isn't supposed to be all about me, I want the community to come together to make sure we're not stepping on each others toes whenever we make software, games, ect. Currently it's sorta the wild west, so the only thing I can suggest (which I've done with SLATE) is that we put application installs and preferences inside of their own folder within the /appdata/ folder.

I don't want to make standards nobody is going to use, so please comment on this post to talk about any standards for anything that could be useful to everyone.

Personally a new standard I've been thinking of is creating a central libraries folder that software can prompt downloads for libraries it might need, so that no one has to reinvent the wheel every time they make an application (although it is so early I don't think this needs to be a focus yet).

Fancy seeing you here. I think a good versioning standard would probably be the first to-do, as that'd make dependency management a whole lot easier and could even just be printed in errors.

NO WAY! I thought you completely fell off the internet! Good to see you

Agreed, a versioning system would be good.

I'm surprised git (at least in a simple sense) isn't integrate yet :)

The /appdata/folder is actually already a standard mentioned in the documentation :)
https://www.lexaloffle.com/dl/docs/picotron_filesystem.html#Accessing_

"When running a cartridge locally (with userland permissions), /appdata is not mounted at a special location, and so all of the local programs use the same folder. It is considered courteous to keep data in a sub-folder named after the app (or author) if the cartridge is likely to be run in that context"

Personally I would suggest that programs should (if applicable) reopen windows at the size/place they were last closed at — it makes window management less tedious and is too application specific to be handled by the system without having a much more complicated API, which I feel wouldn't be in the spirit of Picotron

It would also be cool to have a standard for accent colors, though I hope this is just added officially to the themes.

I second git. A quick and ugly workaround could be ahk some git commands... Another option is to have a file. In picotron when git command is executed you write it to the file. Every 5s outside git script reads from file and executes it. Any ideas how you would go about writing git? Diff would require reviewing existing algos (what is your favorite?), any other big things to consider? Any other tools we should make?

A proper implementation of git would be a lot of work, but would be very cool. I think if we are making utils which many others will use, might be a good idea to have decently readable code :)

One of the limitations of lua is weak standard library. We could see what are some common functions being constantly used/implemented and create libraries with them. Assuming the library takes off, you could set an example of how things should be implemented and saved.

A strength of pico-8 and picotron is how simple and easy to get into they are, and how easy it is to share and modify things. Layering too much complexity in a slightly wrong way could affect both, so creating libraries, package managers etc should probably be done with Wayland level consideration and care ;)

The namespacing within appdata is a great idea. Someone had pointed out some of the docs I'd missed that had this idea and I've moved all my things to adopt it.

Beyond that, I see @ksting has created a manual viewer, named 'info' which is great, which has 3 options documentation standards I've copied from his post that I think are great and will be using:

• Make a file called [command]_manual.txt in the same folder as the command, where [command] is the name of the command. The utility will read whatever is in this text file.
• Make a file called manual.txt inside the command's .p64 folder, if the command is a .p64 to begin with
• Add a multiline comment to the top of the command's code (in [command].lua or main.lua)

I have also started creating an 'exports/' folder on my library and utility cartridges so there's always a single place to look for resources intended to be consumed by other code or carts. I rely on this for yotta which is a hacky package and dependency manager, and for a library that makes it easy for me to provide installers for CLI utilities (like 'new' and 'merge').

As for git and other powerful external utilities, I'm personally reticent to invite the outside software development world into our cozy little fantasy computer. In my day-to-day development work, I do of course use and love git, but I'm much more likely to use something that does version control in a more hacky and simple and joyous way, entirely from within Picotron. After all, we could all be running the latest typescript with three.js and pixi and git and npm and be making the same things we might want to make here... but that's not the point!

@TeamPuzel @ahrotahn

I think its important for these no brainer type things to start early and be as easy for anyone to implement as possible.

So I made a simple library called winStay that can be installed with or without Yotta that moves and resizes the window to the last position it was before being closed.