Xochitl is reporting 88% battery, and I'm still seeing 100%. It looks like there is either a bug with passing the battery level to the UI, or the code that I borrowed from previous projects is broken.

https://github.com/Eeems/oxide/blob/89398fe768183f27966a0066beb8916649edaca4/applications/button-capture/main.cpp#L235-L247

Now that we have something that runs "behind" xochtil, one could have multiple users environment. Basically a small program, which bindmounts USER_A to /root or USER_B to /root and make the user selectable during a login screen of oxide together with #15, multiple people could share a rM, keeping their own data. Not sure if this works for the sync with the rM server (e.g. can you create more than one account for a single rM unit).
Anti-thesis to this would be given by Gollum "My PRECIOUS!!!!"

The temperature is not being saved or loaded it looks like:
https://github.com/Eeems/oxide/blob/a0d50952caa822ed70cecb23a66e19a42b184d54/applications/oxide/controller.cpp#L16

Not sure about why the battery percent setting is failing.

Similar to #14 I think it would be a good idea to have an application external to xochtil that can also display screenshots if they don't want to use xochitl syncronization. I think the following is a good feature list for it:

• View screenshots.
• Delete screenshots.
• Execute a script on the screenshot.
• Create a copy of a screenshot to draw on.

I like oxide for bringing me the desktop like environment
I like remux for being rather non-invasive and enabling me to quickly switch between concurrent running apps.
Why not getting the best of both worlds.
Using oxide as a desktop environment to do settings, starting applications, etc. and use remux as the task-manager to switch between different apps.
Ultimately, if remux could even get to the point of a split view (2 programs side by side) and oxide focuses on the ui experience, we would have a very interesting combination.

https://github.com/Eeems/oxide/blob/d1665ff4a39378af0c137ece572a96377f9b98c0/applications/system-service/wifiapi.h#L184-L189

This issue was generated by todo based on a TODO comment in d1665ff. It's been assigned to @Eeems because they committed the code.

When in xochitl, invoke erode via long middle button press. Clicking on an area that has a xochitl UI element directly behind will cause xochitl to register the press, rather than being blocked by erode

Likely there should just be a longer animation delay before calling controller.sleep()

https://github.com/Eeems/oxide/blob/80684fecb12063eb8a42f6aed275e4f69e221ee9/applications/launcher/controller.h#L232-L237

This issue was generated by todo based on a TODO comment in 80684fe. It's been assigned to @Eeems because they committed the code.

In preparation for #11 I think that applications should be sorted by name. This removes the need to order them with configuration file names. Technically this remove a feature for users, but 11 will add it back in a better way. I'm fine with the loss of a feature in the short term if I'm replacing it with a better one in the longer term.

As we get more close to having a repro. It would be nice to switch to the package repro.
The manual download and unpacking can not only go horrible wrong and it prevents updates via the package manager and creates conflicts with other packages, as they are not aware of oxide (mark a package as conflicting in the package description)

https://github.com/Eeems/oxide/blob/89398fe768183f27966a0066beb8916649edaca4/applications/button-capture/main.cpp#L233

Hi.

First thanks for this awesome piece of software.

When the system gets shutdown from xochtil (after being in sleep mode for X hours), the reMarkable isn't shutdown but xochtil is closed and the remarkable get back to the oxide screen, which goes into sleep mode. The reMarkable is never shut down, draining a lot of battery.

Would it be possible to add a configurable auto-shutdown feature so that after X hours or minutes in sleep mode, the remarkable is shut down automatically?

If this feature is implemented, the ability to easily setup a custom screen when the remarkable is off would be great.

Thanks!

https://github.com/Eeems/oxide/blob/6a7c1064ecabd4c018381325e2486df79a8d5d98/applications/button-capture/main.cpp#L245-L250

This issue was generated by todo based on a Todo comment in 6a7c106. It's been assigned to @Eeems because they committed the code.

Screenshots should be stored into xochitl by default. Likely in a Screenshots folder. The folder should be configurable, as well as if the feature should be enabled or not.

• Basic network selection pane
• Scan button
• On/off button
• Allow entering passwords for new networks
• Signal strength display
• Sort by connected, known+available, signal, known (The sorting needs to handle sending move signals for the UI to update)
• Ensure there are no issues with scrolling the list

https://gist.github.com/Eeems/728d4ec836b156d880ce521ab50e5d40

• General API
• Apps/Multitasking API (#13)
• Wifi API
• Power (Battery/Charger) API
• Screenshot API
• Notifications API (#27)
• System API

If the Home Screen Icons setting isn't set to the default. After a reboot if you open the options dialog it will show the default value instead of the actual setting.

This is likely because the value setting in the qml isn't pulling from the controller, and is instead set to 6.
https://github.com/Eeems/oxide/blob/a0d50952caa822ed70cecb23a66e19a42b184d54/applications/oxide/main.qml#L387-L396

Also, should be fixed for the font size and sleep after settings
https://github.com/Eeems/oxide/blob/a0d50952caa822ed70cecb23a66e19a42b184d54/applications/oxide/main.qml#L405-L414

https://github.com/Eeems/oxide/blob/a0d50952caa822ed70cecb23a66e19a42b184d54/applications/oxide/main.qml#L324-L333

To mimic just the standard behaviour some people might like to start xochitl right from starting the tablet. Oxide would still be there, returning with a long keypress but you would end up in the xochitl man window directly after start. That might be usefull if you use the rM 99% of the time for note-taking and would like to avoid the additional click during start-up. It might also speed up the process from cold start --> note-taking.
That implies that it works well together with #15

https://github.com/Eeems/oxide/blob/80684fecb12063eb8a42f6aed275e4f69e221ee9/applications/launcher/controller.h#L225-L230

This issue was generated by todo based on a TODO comment in 80684fe. It's been assigned to @Eeems because they committed the code.

Seems to be a bit of a weak spot if you have a password on xochitl to protect important data, but one can start e,g, a shell terminal just without any password.

The new power API allows for selecting a power state of Normal or PowerSave. Right now all this does is allow applications to react to the power state. The following should be done out of box:

• When in a power state of PowerSave
  • Tarnish should increase the polling frequency on all of it's checks.
  • Oxide should do what it can to limit CPU usage
  • Tarnish should attempt to change device settings to save power (Disable a core on rM2? Change the cpu governor (https://wiki.archlinux.org/index.php/CPU_frequency_scaling#Scaling_governors)?
• There should be some sort of user interface for toggling the requested power state.
• Maybe we should add a performance state?

Add installation instructions for how to install oxide from entware.

currently, the package is in testing (on rmkit repo) but will make it's way to testing -> stable in the main one over time

i think it would be great if oxide (and other launchers) implement multi-tasking. this issue could track progress towards it. currently, oxide implements level 0 of multi-tasking. the next level (1) is having an app suspended while another app runs, similar to how a shell might work. level 2 is to have true multi-tasking where two apps can be running at the same time.

for level 1, a scheme that might work is:

• oxide is primary service on boot
• when oxide is called up, it: 1) pauses all apps with SIGSTOP and 2) takes a screenshot and saves it for the currently running app
• when oxide switches to a new app, it executes that app.
• when oxide switches to an already running app, it places the screenshot onto the framebuffer and then gives the app the SIGCONT

there are a couple intricacies around:

1. clearing the input queue when switching apps
2. detecting which app is running (when multiple apps are running but paused)

https://github.com/Eeems/oxide/blob/723152eaf899c3d60786e6be066077349c64627f/applications/system-service/wifiapi.h#L120-L124

This issue was generated by todo based on a TODO comment in 723152e. It's been assigned to @Eeems because they committed the code.

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.

when using xochitl + proc explorer, when clicking in the top left, xochitl seems to get an event. need to correctly pause and flush events away from xochitl

• Notifications drawer at the top.
• Dbus API for managing notifications.
• Draw incoming notifications overtop of running application, and then hide it.

0000044 didn't include code to start the UI update timer and accidentally broke this.

https://github.com/Eeems/oxide/blob/93d87cc885ec94bcf4485b85ff08a7b7dda4bdfd/applications/button-capture/main.cpp#L259-L264

This issue was generated by todo based on a Todo comment in 93d87cc. It's been assigned to @Eeems because they committed the code.

https://github.com/Eeems/oxide/blob/89398fe768183f27966a0066beb8916649edaca4/applications/button-capture/main.cpp#L229-L232

This issue was generated by todo based on a TODO comment in 89398fe. It's been assigned to @Eeems because they committed the code.

If a app doesn't specifiy otherwise (maybe because it wants to allow long pressing the left button for other purposes), holding the left button should kill the pid that it spawned by default.

One could use either SIGINT or SIGTERM for that.

• SIGINT a signal to gracefully exit that can be sent from the terminal (CTRL+C)
• SIGTERM also a signal to gracefully exit (used by the kill command)

See this for more.

When the user presses the Wi-Fi toggle, it may not be apparent that anything is happening until after a few seconds. This might make them press again (thinking the UI is unresponsive), resetting it back to the original state. Having a faster response would be beneficial to show that the action was received.

https://github.com/Eeems/oxide/blob/6a7c1064ecabd4c018381325e2486df79a8d5d98/applications/button-capture/main.cpp#L255-L260

This issue was generated by todo based on a Todo comment in 6a7c106. It's been assigned to @Eeems because they committed the code.

The rM2 has different device pathes and hence it requires some adaption to run oxide on the rM2.

A file-tree of the sys folder rM2 was provided by @ddvk is here:
tree.txt