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]

Preliminary feedback from graphical OS developers is greatly appreciated.

[tomodachi94]

Ready for general review.

[tomodachi94]

• [x] Todo: include examples of valid app specs.

[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?

[Rainb0wSkeppy]

programs should be able to use multiple icons for different sizes

[tomodachi94]

programs should be able to use multiple icons for different sizes

@Rainb0wSkeppy : fixed by making Icon into an array, where the keys are pixel sizes and the values are paths to the icons.

[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]

1. it should support text icons

You earlier defined this as "stuff like bimg", but I thought this was already covered by bitmap images. Could you clarify what you're asking for?

Your other two suggestions have been integrated :)

[tomodachi94]

Apologies, I now understand what you mean by text images :facepalm:

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.