The great majority of my work at Endless is to (try to) tame GNOME Software and apply the changes that make it what we simply call “the App Center” (repo here) in the Endless OS.
This is a lot of work and usually I’d love to share more often what I am doing but end up neglecting the blog due to the lack of time. So here’s a summary of what I have done the past few months.
New App Tiles
From the times where it was called the App Store (and not based on GNOME Software like know), the Endless OS’s App Center used to have what we called internally as “app thumbnails”. These were images carefully produced for each app that Endless distributed, that worked as a way to provide some visual hint and attractiveness that is many times not achieved by the apps’ own icons. Here’s a screenshot of that version:
There was a couple of problems with “app thumbnails” like that: 1) we started shipping Flathub as a remote by default, and it’s simply not scalable to go and create an image for every app that is available in the repository; and 2) even if visually appealing, the app tiles make it a bit difficult to correctly display text on them, and depending on how apps appear next to each other, it can become visually quite bloated.
Thus the solution we came up with for the 2nd problem was to give dim a little bit the effect that the thumbnails have by placing a translucid layer on top of them, and to have a dedicated area for textual information. This means we still use app thumbnails for the apps that have it, but they will all seem a bit less intense and more alike.
That still leaves us with the first problem of not having thumbnails for most apps. For fixing that we create a background from the main colors presented in the app’s logo. The background is composed of 4 gradients, each with one of the icon’s main colors. Using the logos’ colors ensures there’s some harmony between the logos and their backgrounds, and I am very happy with the result:
Updates from USB and LAN
As you know, Endless’ mission is to give access to computers (and all that comes with them: knowledge, entertainment, productivity) to those who are often in remote areas, with very weak or innexistent connectivity. Maybe you’ve already heard that at Endless we’re developing an “asynchronous internet” and optimize the use of the little data connectivity some of our users have. So it’s only logical that we can give the possibility for users to share the data among themselves without an internet connection. To do that, we (more specifically Philip Withnall, kudos to him!) have implemented a way in ostree for local repositories to be found, particularly, repositories in removable drives (e.g. USB keys) and LAN. This means that e.g. a teacher’s computer in a class room can download app updates from the interwebs and the sudents’ computers will just get the updates through LAN (without the need for an external connection). In the case of the USB, as you probably guessed, a user can just set up a repository in a USB, and share the drive with friends.
For the USB case, in which the number of apps available may differ a lot from the user machine’s catalog, we need to show which of those apps are available, so when inserting the USB drive in the machine, the App Center should just pop up and show a new category “USB” with the apps that are contained in it. See the following screenshot:
One of our constant concerns is that our OS and apps run smoothly even on less powerful machines, since it’s what many of our users have. GNOME Software spawns a thread for every main operation that the user does, like installing or updating an app, and we’ve noticed that when a few of these operations are running in parallel, some machines will just freeze. Moreover, downloading a bunch of data in parallel may easily occupy the whole bandwidth without actually completing any of the downloads.
One can think of a lot of smart approaches for dealing with this, but for now we just implemented a restriction on the number of operations that can be run in parallel. This was implemented together with upstream and the number of possible operations in parallel is one per GB of RAM. You may argue this is good a heuristic as any other, but it gives a low number of operations for slower machines, while still allowing powerful machines to have multiple parallel operations.
For the Endless OS we just opted to limit this number to 1, but may revisit it later. Google Play also performs just one update/install at a time, so this is not such a crazy thing.
We need also to inform the user that an app is waiting for it’s turn to install/update, so in such cases an empty progress bar with a message is shown:
For consistency, we’ve changed also how we showed the “queued-for-install” state (a state that happens when the user clicks install and there’s no internet connection), to be consistent with the UI shown above.
Another push we’re taking together with upstream is auto-updates. GNOME Software has had something similar to auto-updates for a while, though it was more like auto-downloads. This was heavily based on the fact that it’s not very safe to just go and install new versions of packages right away (apps may be running… ). So it’s up to the user to choose when to (reboot and) install those.
Flatpak though, has no such problems. Apps can be updated even while running, as the way the new update replaces an existing version happens atomically, without touching the running app’s files.
So the ideal thing to do for Flatpak is to have real auto-updates (that is, download and deploy them right away). But since GNOME Software still has to support other sorts of app distribution, it required a bit of creativity when designing the new UI for this, which Allan Day kindly did, and very patiently with me and all my opinionated views of it 🙂
I have implemented auto-updates downstream first, without some of the niceties of the new mockups, since we needed them for our very-soo-to-come new version. But the idea is to do the real implementation upstream soon.
Surely enough, even when turned on, auto-updates only happen when on unmetered connections currently; and Philip Withnall is working on a creative solution for metered connections (soon to be announced).
This post is long enough so it’s not really sensible to enumerate all the fixes done in the last months. So I will just mention that recently we have fixed important issues (upstream as well) like installing new runtimes’ extensions when an app update needs them; cancelling auto updates/downloads when their running and the connection is switched to a metered one; setting an app as updatable if one of its runtime extensions has an update (otherwise it was not possible to install those extensions), etc.
If you’re still reading this, thank you! But especially thanks to Richard and Allan for their patience and leadership upstream!
Hope you liked this. I will try to keep the updates more frequent!