Proposal : ecosytem harmonization

[thiswillbeyourgithub]

Hi!

As I said earlier, I'm quite familiar with wasp-os on the Pinetime from Pine64. It's arguably the most successful micropython os on a hackable watch (albeit not that successful, it's quite niche :) ) so I think harmonizing some parts of the code to reduce the cost to port apps between them is not a bad idea.

Wasp-OS has some great features like :

• a simulator to quickly create apps without having to send them to the watch
• extensive documentation
• multiple watch support (all based on the same chip)
• a neat way to install apps as frozen bytecode or mpy or python (the storage space is way smaller)
• An app launcher as well as useful widgets (a "top bar" that displays the time and notifications like on android etc)
• a settings app

You can give it a go right away on your computer by cloning their repo then running make sim in the root. This will launch the simulator.

Before porting my own apps here's what I explored so far:

1. Out of principle I looked at porting wasp os on the twatch directly. It looks very dooable because AFAIU the main hurdle is getting micropython working and the display is the same as on waspos. But I frankly lack the skills to pull this off and have many more things on my plate so that was mostly out of curiosity.
2. I looked at adding the simulator to this repo. The code is actually quite simple and clever and it looks way easier than porting the OS. But I also lack the knowledge to understand a good part of the low level of both repo so I also can't pull it off. But frankly this looks easy if someone is interested, it's basically highjacking the PYTHONPATH to load local fake modules like micropython, machine, time etc and displaying in a window using sdl2.
3. Harmonizing the code architecture. The separation between tempos.py, scheduler.py is not really the same as on waspos so overhauling all of this was too much for too little IMO.
4. See below

Here's where I'm at now. I think harmonizing the "API" is what yields the most without hurting the authenticity of this repo and allowing to port apps more easily. By that I mean for example renaming the "g" module to "display", renaming the "setInterval" to waspos's alternative etc.

Here would be the tentative roadmap:

1. renaming the simple stuff like g, setInterval, ticks handling, etc
2. changing lightly the application life cycle to align more with the one from waspos (i.e. changing app_init by foreground etc)
3. adding docstrings to all functions.
4. Harmonizing the widgets API and adding more widgets
5. adding a central "launcher app" that is triggered when escaping from an app, and allows to swipe to other apps. This would be nicer I believe.

What do you think @jeffmer ? I think it would bring more apps to your OS, increase the visibility to your OS as well as to the twatch (which is incredible but not enough loved!) and be a good thing overall : 2 projects with a common API increase chances of more future watches aligning with this instead of having 3 standards :).

The goal is not to do a major overhaul of the code of course, but just to make it share the same language as waspos.

Can't wait to have your take on this :)

ps : wasp-os is also available on a few other watches, see their great doc

[jeffmer]

Hi, yes, I know about waspos and have looked at in some detail. The main constraint that waspos addresses is the small RAM size - 64K - of the RF52832. Thus the frozen code etc.

The design of tempos - short for temporal operating system - was influenced more by my experience with Espruino and it’s Bangle watches. So Tempos has a JavaScript like event model.

I have previously implemented a desktop like icon driven launcher for Bangle so I wanted to experiment with an architecture that selected apps directly by swiping as my experience is that launchers can be a bit fiddly for small devices.

I really like the simplicity of tempos where everything is an app with no special treatment of settings or launching.

Saying that, I think the best approach to running waspos apps would be a compatibility lib which mapped waspos to tempos primitives rather than changing the tempos primitives.

[thiswillbeyourgithub]

Saying that, I think the best approach to running waspos apps would be a compatibility lib which mapped waspos to tempos primitives rather than changing the tempos primitives.

Noted. I'll do that eventually then. Thanks