Open nhjschulz opened 3 months ago
Means the view provides configuration parameters, which needs to be stored in the plugin related configuration fiile. Consider that these parameters are view depended which is decided at compile time. Here a new concept might be necessary to avoid having configuration parameters e.g. in a 32x8 DateTime configuration which are useless. I am curious about the concept.
Can we add a (REST?) call to query the resolution from JS in the plugin-HTML pages ? The page can then present view dependend options. From a concept perspective I imagine 2 Settings groups, a "generic" and a resolution dependent one below it(if needed)
Someting like this
function getViewResolution(pluginUid) {
disableUI();
return utils.makeRequest({
method: "GET",
url: "/rest/api/v1/display/getinfo,
isJsonResponse: true
}).then(function(rsp) {
configureUI(rsp)
}
function configureUI(rsp) {
if (rsp.resolution.x >= 64 && rsp.resolution >= 64){
setVisible( options64x64);
enable(options64x64)
}
}
Can we add a (REST?) call to query the resolution from JS in the plugin-HTML pages ?
Yes, this can easily be done. Consider that the plugin itself has to differeniate as well. In the OpenWeatherPlugin I used a static function with a constexpr return parameter to decide at compile whether the forecast feature is enabled or not. This is very important as we are with the 4 MB flash modules over 99%.
A simple variant is to use the pixelix.json and provide two kind of HTML files, which are copied to the filesystem depended on the resolution.
64x64 pixel support feature an analogue clock for the DateAndTime plugin. But the way it is drawn is hardocded. You cannot change colors or the seconds indication.
Drawing properties like colors, and mode shall be accessible over REST / WEB UI.
UI shall make it clear that this is only foe 64x64 displays.