We won't be bundling with Electron any more, instead we'll ship the html/js files themselves.

As for the menu, I will write a library file that will exist across all of our tools and draw an interactive menu in the application view.

To do this properly, I don't want to use npm, I wrote a little dependencies manager to make sure all our lib files are in sync across the applications.

Let's see how that works out.

@neauoire write a packager to embed the js in the html.

@peregrine I mean, is there an advantage to that, sounds like it will just make it hard for someone to fix/modify the app?

@neauoire source can be multiple files. What you ship to end user would be one file to avoid asking people to unzip or untar.

@peregrine I kind of like the idea of shipping the source so people can change it themselves.

@peregrine I take back what I said, I think your idea is brilliant.

@neauoire it would be nice for the less technical crowd and those using itch.

@peregrine Oh 0_o, no that won't be possible. It'll just make a super mess if I try to put all the css, and svgs, and etc in a single file. It's a nice idea tho. I could do that with Noodle.

@neauoire the way most websites work nowadays nobody is reading the source anyways. Kinda like tiddlywiki.

@peregrine Not sure if I'm a fan of that. But I'll keep that in mind, I like the idea of shipping a single file. I just need to make it so it remains readable. It's important to me.

@neauoire @peregrine sort of?

this script is linux-specifc, but a small cross platform program that does something similar could be feasible.

#!/bin/sh # mount tar file somewhere archivemount -o readonly "$image" "$rootfs_path/" # setup an overlay so you can write things down mount -t overlay overlay -o "lowerdir=$rootfs_path/,upperdir=$data_path/,workdir=$work_path/" "$chroot_path/" # execute your program inside of a chroot chroot $chroot_path $bin_start

most tar files are wrapped in some other container (.tar.gz, .tar.lzma, &c.), so it wouldn’t be so strange to cat a launcher program and a tar file and have it execute some predefined binary inside of the archive. it could possibly also support dumping the tar archive to another path.

AppImage and flatpak have a similar UX (double click the program.exe or launcher program.exe), but the toolchains are pretty large. i’ve ported a lot of programs to alpine linux and i didn’t have the patience to port flatpak or AppImage. somebody else got to it, but it isn’t a small program at all. on the other hand mounting and executing a tar file in this sort of hacky way actually results in a much smaller toolchain, which boils down to tar and a launcher program.

@xj9 @neauoire @peregrine appimage is actually a lot smaller than you seem to be assuming
it's basically an ELF payload cat'd with a squashfs image
the next type of runtime is currently being discussed (here - come in and participate!
someone already suggested .zip as an alternative to squashfs

re: small, it's mostly that there's a lot of meta-work
actual storage space doesn't bother me very much though - storage is plentiful, and it's basically static-linking-lite (e.g for programs that can't do it properly because c ecosystem)
@xj9 @neauoire @peregrine isn't appimage +x the image and then run like a normal executable? from what i remember it's just a squashfs file with a loader stub bolted in that mounts the squash and runs a shell script inside the filesystem.
Sign in to participate in the conversation

Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them. Check out our Patreon to see our donations.