The current way to specify hardware support is not very intuitive from an app developer PoV. As an app dev I know what kinds of controls and screen sizes I've tested and work, which ones I've tested and don't work, and which ones I haven't tested.
The current syntax uses recommends and requires. The latter makes sense to me as-is, but recommends is basically used to mean tested and works. There's no concept of tested and doesn't work or not tested.
I wonder if we could rename recommends to verified or something similar and have an additional group called unsupported for things we know don't work (e.g. if I know the app currently isn't keyboard accessible). Anything not included would then automatically count towards not tested, so all groups would be covered.
Whether or not apps should/could additionally recommend an ideal setup (e.g. Blender could recommend a mouse and keyboard with numpad) even though the app is usable with different setups is a separate question, but I think that's a much more niche use case than defining what hardware the developer knows works/doesn't work.
The current way to specify hardware support is not very intuitive from an app developer PoV. As an app dev I know what kinds of controls and screen sizes I've tested and work, which ones I've tested and don't work, and which ones I haven't tested.
The current syntax uses
recommendsandrequires. The latter makes sense to me as-is, but recommends is basically used to meantested and works. There's no concept oftested and doesn't workornot tested.I wonder if we could rename
recommendstoverifiedor something similar and have an additional group calledunsupportedfor things we know don't work (e.g. if I know the app currently isn't keyboard accessible). Anything not included would then automatically count towards not tested, so all groups would be covered.Whether or not apps should/could additionally recommend an ideal setup (e.g. Blender could recommend a mouse and keyboard with numpad) even though the app is usable with different setups is a separate question, but I think that's a much more niche use case than defining what hardware the developer knows works/doesn't work.
cc @Exalm
The text was updated successfully, but these errors were encountered: