Compensate for flat tire displays

[MagneFire]

Currently AsteroidOS provides a flatTireHeight property in DeviceInfo. This is used across various places in the code to provide some compensation for the flat tire. Examples are:

• asteroid-launcher: It overflows everything to make it seem that a perfectly round display is used.
• asteroid-flashlight: centers the icon based on the flat tire height.

There are two important things to keep in mind in this case:

• The homescreen/watchface are always overflowing to the flat tire area.
• Apps never overflow to the flat tire area.

There are a couple of problems with the current approach:

• Center indicators are not actually centered, but slightly higher up.
• The watchface is slightly cut off at the bottom.
• App launcher might have missing information at the bottom.

Solving asteroid-launcher issues

For now, the elements flowing on top of the flat tire have been deemed acceptable. Though a future issues might be created if need be.

Solving asteroid apps issues

There are a couple of approaches that could solve the issues for apps:

1. Let apps overflow to the flat tire area.
2. Provide a new 'visual' anchor.
3. Let developers fix it manually.

It's worth noting what the goals are:

• Apps should never break by default. (i.e. you cannot use an app because you cannot click a button that's off screen)
• No need for developers to adjust for flat tires or provide a means with minimal changes required.

Let apps overflow to the flat tire area.

Advantages of this method are:

• Apps look good by default.
• No need for developers to adjust for flat tires.

Disadvantages are:

• Apps can break.

Provide a new 'visual' anchor.

Advantages of this method are:

• Apps never break.
• Minimal effort needed by developers.

Disadvantages are:

• Only works for QML components where the size matches the screen size.
• Hard to implement as the QML anchoring system doesn't provide a means to override/extend it.

Let developers fix it manually.

Advantages of this method are:

• Apps never break.
• Straightforward to implement.

Disadvantages are:

• Developers need to be aware of the flat tire and adjust accordingly.

@dodoradio may have further comments on the matter.

Conclusion

While extending the anchoring system might sound like the desirable solution. Some research has shown that it's hard to extend the traditional (left, right, verticalCenter, etc) anchors. Hence, leaving this up to the developer might be the more desirable solution. This means that apps look less than optimal on flat tire displays (off center), but providing examples and/or abstractions could help with this.

[dodoradio]

I personally support requiring developers to handle this manually. Firstly, not a lot of code is required to do this. Small changes such as anchors.verticalCenterOffset: DeviceInfo.flatTyreHeight/2 (for fixing items that are not centered) and height: Dims.h (for items that should fill the entire display height) are all that is needed in most cases.

• Making all apps overflow the edges of the screen will require manual intervention to put important items back on screen. This just inverts the problem, rather than fixing it.
• Adding a new set of anchors is something I am strongly against. There are two ways of doing it:

1. Provide a new set of anchor lines only in org.asteroid.controls' application item. This is very limited as these anchors will only be accessible to direct children of the element, making it difficult to use in complex applications, requiring manual use of DeviceInfo.flatTyreHeight for the rest of the item tree. My argument against this implementation is that it provides a 'correct method' of anchoring to the display edges that actually only works for a very limited number of basic applications.
2. Modify the qt item to have all items carry anchors for the edges of the display. This is technically difficult to implement, likely requiring patching of qt libraries, but should be achievable. However, it also seems to be completely against the qml anchoring paradigm, and seems to be (compared to all other items in qml) a hacky solution.

I think it is simpler and more correct to fix these issues manually case-by-case instead of creating a framework that provides limited abstraction for a small number of very simple situations.