Open torwag opened 4 years ago
Eeems
commented
4 years ago Blocked by #40
Would you be willing to draft an API for interacting with the dashboard? I'm not really certain that I'd want to use HTML5+JS for the dashboard as that would likely consume more power. I'd prefer to just call out to applications and ask them for updated information if they are registered to update dashboard information.
Eeems
commented
4 years ago The other option here would be to have a dashboard application that has its own API that you set as the auto start application with #41. We would then need an API for handling suspending with oxide.
torwag
commented
4 years ago The tricky part is the design of the dashboard, which needs to be flexible so that each and every user can customize it to their needs. Not sure if QT is able to do that in the same way HTML5+JS is able to do that. Yep could also be an external program.
Eeems
commented
4 years ago Ideally we don't try to overbuild at first, so having it be fairly generic in what it can display with limited to no customizability would be fine for an initial release. Longer term moving towards the higher flexibility is good. I just don't think it's a good idea to force it to do everything at first. Iterating to that point is probably better if we want to see something sooner. With that in mind, someone (I guess maybe me) should start working on defining v1 of the API needed for a basic dashboard.
Not sure if QT is able to do that in the same way HTML5+JS is able to do that. Yep could also be an external program.
Well Qt is QML+JS so I'm fairly certain they have things for handling HTML.
Eeems
commented
3 years ago @torwag looks like https://github.com/BHSPitMonkey/remarkable-lcars might provide you with the start of what you want.
Since day one of the rM I was wondering why they make not use of a more flexible suspend screen. As this screen stays active even if you run out of battery it could keep valuable information. It could be as simple as compile frequently needed information (phone-numbers, owner, office number, etc.) However, it could also contain dynamically created content like the next upcoming appointments from #42, news-feed (so you have something to read without switching your rM on, randomly generated vocabulary list (if you plan to learn a foreigner language), your todo-list, etc.
First I only thought about the suspend screen but thinking more about it, I would even prefer to have this as my usual start screen. Thus, there are not only icons to start different applications, but each and every application could provide some information which could be assembled in a dash-board directly on the home screen. The active home screen compared to the suspend screen would allow more frequently updatable information. E.g. traffic situation for the route home<->work, weather, stock/exchange/cryptocurrency market, auto-refreshing news feeds, externally triggered notifications, alarms/reminders, world clock.... I believe that most dashboards make use of an HTML5 and Javascript-framework, as this allow a very high flexibility from the users perspective. Might need discussion if this requires the development of an embedded browser component. However, it could be taken into account when it comes to #40 . As I could see that independent Apps use this API to offer certain information and oxide, uses them to compile the dashboard. If it comes to a web-based like system, however, most might expect something like a REST-API instead or together with a DBUS API.