CCSMB-11: Desktop Application Discovery

[tomodachi94]

This is a proposal for uniform discovery and installation of graphical applications.

Rationale

Currently, most ComputerCraft graphical operating systems, windowing and desktop management systems, and application launchers (collectively "target software") define their own method of discovering and launching applications. The behavior and expectations for each piece of target software vary wildly; for example, some target software expects programs to manage their own windowing through system-specific APIs, while other target software manages it entirely for all programs. Additionally, installation scripts and package managers ("software management tooling") contains wildly inconsistent behavior, varying from not defining any sort of application discovery, containing support for one or two specific target softwares, or attempting to maintain support for all target software.

The purpose of this specification is to standardize behavior for installing, discovering, and launching graphical applications, enabling greater interoperability in all target software and software management tooling.

[tomodachi94]

Ready for general review.

[MCJack123]

Personally, I think this is a bit too premature, as there's only one actually fully functional graphical shell available, which is likely not going to use this standard. I'm also planning on using a different approach in Phoenix that's within the application file itself.

[tomodachi94]

there's only one actually fully functional graphical shell available

Could you name it? Off the top of my head, there's LevelOS, Opus, and (discontinued) Dragonstone, along with the countless ones available in the forums. Additionally, there are far too many CC package managers to name fully (I tried making a very incomplete list).

I'm also planning on using a different approach in Phoenix that's within the application file itself.

Would permitting specs to be embedded in files (provided they have a file in /etc/ccsmb/applications that simply requires the program and returns the table from it) make this more attractive?

[MCJack123]

there's only one actually fully functional graphical shell available

Could you name it? Off the top of my head, there's LevelOS, Opus, and (discontinued) Dragonstone, along with the countless ones available in the forums.

I said functional (lol). LevelOS is that one, and Opus is kind of a special case I guess - it has a "UI", though it isn't really used much anymore. Anything on the forums is irrelevant, since they're all old and/or non-functional for actual useful purposes.

I'm also planning on using a different approach in Phoenix that's within the application file itself.

Would permitting specs to be embedded in files (provided they have a file in /etc/ccsmb/applications that simply requires the program and returns the table from it) make this more attractive?

I'll at the very least be using header comments of some sort, and probably macOS-like package folder structures, and maybe even custom packed executables. It'll probably be TOML-based since it's simpler to write, and I already have a parser for it. I'm not against allowing explicit descriptions separately - I just think it's a little bit dirty, and a hack that Linux people needed to throw together because they couldn't agree on a proper rich executable format.

[tomodachi94]

Apologies, I now understand what you mean by text images 🤦

I have removed the Type field in favor of just the Format field. The Format field is also now a MIME type instead of a file extension.

[Rainb0wSkeppy]

maybe you should mention that the path must start with a / and must not end with a /, the same way as in ccsmb-10