One issue I have found with the Pinephone is that, due to its relatively underpowered processor, there are often long delays while applications are processing data, without any visual feedback. It looks as if the machine is frozen, and it is sometimes unclear if it will eventually come good, or whether it has locked up completely, leading to a poor user experience.
This issue was overcome in the first generation Windows/Mac GUIs by using the "busy"/"hourglass" cursor to indicate that the machine is currently processing data. A similar function is served, in various implementations, on many Linux systems by the "CPU load meter", which shows a rolling graph of the CPU load over the past minute or two. I decided that a CPU meter for the PinePhone would be highly desirable. However, looking around, I couldn't find any existing software that was suitable.
I therefore had a go at implementing a CPU load meter of my own. I started with the code for the "wmload" meter, and applied some patches that were necessary to correctly display the load for a multi-CPU system. (This shows the age of the original code!) Then, using the existing Phosh plugins as an example, I was able to develop a tiny CPU load meter in the top status bar. The code is pretty rough - just a proof-of-concept at present, but if you'd like to try it, you can download the patch against phosh e120671 2025-01-26.
![Load meter in the status bar]](images/load-meter.png)
However, it was a bit frustrating having to code this - CPU load meters and other system monitoring widgets have been a solved problem for at least 25 years now, and it was a pity having to repeat all the effort. For many years, I ran the WindowMaker window manager, and its system of dockapps worked well. This got me thinking: A dockapp is about the same size as an application icon in Phosh, and it would be pretty neat if there was a way of adding dockapps to the home screen. Of course, some that relied on interacting with tiny buttons would not be practical on a touchscreen, and others that used outdated APIs and discontinued web services would need updating, but I figured that at least some of the existing dockapps would be useful. I realised that interfacing the apps with Phosh could potentially be quite involved, but I decided to at least do some preliminary investigation.
The original dockapps use a quite simple interface with the window manager. Each dockapp runs in its own process, and creates a normal X11 window which is then "swallowed" into the dock by the window manager. This is quite flexible, as it does not require that the apps be written using a particular language or framework. However, a major complication is the fact that Phosh is running on top of Wayland, not X11. While there is a compatibility layer that works fairly well, it appears that it will not extend to this use case. As a first step, I had a look for any other instances of where out-of-process windows were displayed within another application, hoping that I could copy the code and see how it was done. However, this was a dead end. I looked at the "preview" feature of XScreenSaver, but that didn't appear to be working on Wayland. And the "task switching" view in Phosh does not use true embedded windows - rather, it appears to take a screen capture from when the application was last activated, which isn't updated in real time.
I then did some more research, and discovered that Wayland supports the concept of a "nested compositor". If I understand this correctly, this is approximately equivalent to the functionality of the "Xnest" X11 server, and would theoretically allow for the Phosh home screen to contain a nested compositor, which would then allow a dockapp to be displayed through the X11 emulation layer. I tried some experiments with the wakefield code, but didn't have any success with it - it opened a new window, but I couldn't get it to display any content.
At this point it was looking fairly unlikely that it would be possible to directly use unmodified dockapps with Phosh. It would be necessary to define some other interface by which the dockapp and Phosh could communicate. Ideally, this would still permit the dockapp to run in a separate process, but it might be necessary to code the dockapp as a plugin for Phosh. This would obviously be a lot of work, as every dockapp of interest would have to be modified individually (although it might be possible to hook libdockapp somehow), and so I decided not to pursue this further at present.
However, another thought occurred to me. While creating some custom application icons for the Phosh home screen, I had noticed that it was not necessary to restart Phosh in order for the new icon to appear. Some further testing showed that Phosh monitors the .desktop entry files corresponding to the icons on the home screen, and if the modification time of one of these files changes, both the .desktop file, and any icon images that it references, are reloaded!
So, here was a way of providing dynamically updated content on the home screen. While it would not allow any interactivity, other than launching an application when the icon was touched, it would be fine for read-only status displays at least. One such application would be an implementation of wmgrabimage, which displays an image downloaded from a specified URL, which is periodically updated. This is handy for monitoring live data, without the overhead of opening a browser (which is significant on the PinePhone).
For a minimal implementation, it would be possible to manually create the .desktop entry, then download the file with curl and touch the .desktop file from a cron job. However, in order to make setting it up easier, I have developed phoshgrabimage.py, which automates this process. Instructions are inside the script. The .desktop file is automatically created when the program is run, and is deleted if the program exits, preventing "stale" icons from being left around. The process of starting an application at login on Phosh is slightly convoluted, requiring the creation of another .desktop file, so this is also automated.
![Grabbing rain radar maps with phoshgrabimage]](images/phoshgrabimage.png)
Grabbing rain radar maps from the Australian Bureau of Meteorology with phoshgrabimage
With a proof-of-concept dockapp produced, I then went on to make a hacked version of wmload, periodically generating an updated graph image and writing it to a file. This did actually work, but I discovered that there was a significant overhead to updating the icon - the GUI would freeze for a second or so, and with the load meter updating every five seconds, it wasn't really practical unfortunately. It sort of defeats the purpose a bit if the CPU load meter is responsible for a significant proportion of the CPU load!
![wmload running in the Phosh home screen]](images/wmload.png)
wmload running in the Phosh home screen. Unfortunately, this turned out to not be very practical.
In summary, it is possible to provide dynamic content on the Phosh home, provided that it does not have to update too often. With so much realtime data being published on the web, there is a large class of information that would be useful to display on the home screen, and I have described a simple way of doing so.
![]()
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
loopgain.net