Open tomodachi94 opened 5 months ago
Preliminary feedback from graphical OS developers is greatly appreciated.
Ready for general review.
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.
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 require
s the program and returns the table from it) make this more attractive?
programs should be able to use multiple icons for different sizes
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.
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 simplyrequire
s 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.
- 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 :)
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.
This is a proposal for uniform discovery and installation of graphical applications.
Rationale