Another day, another Crostini feature comes to light. So far, we have the Linux Terminal installer, Files app integration, and Material Design cues already rounding out the Linux app experience. As we continue to uncover clues by the day, it seems development of the Crostini Project is full steam ahead today is no different. Each clue we uncover continues to push the entire experience closer to something I believe will be delivered to developers and general users alike.
So, what are we seeing today? Quite a bit, honestly. There are multiple commits around this same theme: handling app icons for Linux apps on your Chromebook. If Google wants users to actually use this great new ability on their Chromebooks, these containered apps really need to behave just like their Chrome/Web app brethren. For example, whatever the delivery method ends up being (Chrome extensions, Play Store, Web Store, or something new), once I install an app on my Chromebook, I expect to be able to find it in my app launcher, see it on the shelf when open, and pin it to the shelf if I choose.
I’d like to be able to search it in the app drawer, too, if I’m making requests. Turns out, all that is already in the works.
App Icons
Currently, if you check out the video we put together of Inkscape running in a container on the Pixelbook, you’ll notice there is no app icon. If I minimize the window, there’s no way to pull it back up apart from the Chrome window I have open. As a matter of fact, it is basically tied completely to that instance of the Chrome Shell. From an end-user’s perspective, this isn’t a working solution. It was fun to tinker with, but I quickly went back to using Gravit Designer instead of this odd version of Inkscape.
One thing that would have greatly helped and probably caused me to start considering using Inkscape again in this way would have been an app icon. An app icon I can see in the shelf when I minimize/maximize the app, when I want to pin it to my shelf, or when I want to find it in the app launcher would make using Inkscape via Crostini much easier and reasonable. It sounds like a small thing, but this is a huge UI necessity.
And it is coming
App Icons
First, there’s this commit that shows the Chromium team working to define the container app’s icon straight from Linux:
Add launcher icons for Crostini applications
This updates the Crostini launcher integration so that it includes the icons. Icons are stored in the user’s storage directory and the file path for the icons is generated based on the app_id. We use the CrostiniManager for requesting the icons from the Linux container. Resizing of returned icons is performed if we do not get the size/scale factor we requested from Linux.
So, quite clearly, just like they would in a Linux distro, apps are able to define their corresponding icon. Nothing special needed from the app, just Crostini being able to find that icon and use it to display when the app is being leveraged.
Searchable Apps In The App Drawer
Second to having the app icon on the shelf is the ability to see the icon in the app drawer and be able to search it. This commit clearly references this in the works as well:
Add basic search for Crostini apps
Add support for searching in the App List for Crostini Apps. This only does a search over app names, not e.g. executable names or keywords in the desktop file. As we use the AppSearchProvider, this also makes apps show up in the app list’s list of recently launched apps.
Again, fairly standard here, but very necessary if they want Linux apps to behave natively. If I install an app, I expect to see it in my app drawer and I expect to be able to search in that app drawer for the app as well. It seems this will also work for the recent apps section of the app drawer, too, so that’s a win.
Native Actions on Launch
Moving on, with proper icons in the tray, able to be pinned and searched, we are getting pretty close to a very native experience across the board. However, there are a few other things needed. Small, but still very important, is the behavior of an app when launched from the app drawer. In this commit, you can see that this behavior is being considered and worked on as well:
Dismiss the app launcher when launching a Crostini app
As it may take several seconds for the Crostini container to spin up, dismiss the app launcher so there is some sort of user feedback when tapping an app. Eventually we should show a spinner or something.
This brings up a thing I’d not thought about, but clearly the developers behind Crostini certainly are: with each Linux app launched, you may have a few seconds of waiting while the container gets started. As the app drawer is dismissed after the click, it seems something in the way of an animation will happen as the user waits for the container to appear. Thoughtful, needed, and yet another step towards a more native experience for users.
Native Window Bar
Last one for today. If you watch that video up top again, you’ll see that Inkscape launches with a dark gray title bar. It doesn’t look bad, but it certainly doesn’t look native. This commit is dealing with that small change and will make sure that Crostini containers launch with the #F2F2F2 title bar color like other Chrome OS apps.
pdate SOMMELIER_FRAME_COLOR to match ChromeOS window titlebars
This changes the color to #F2F2F2 to match the native titlebars. The foreground color (i.e. the button color) still need to be updated.
For now, that’s all. These changes are coming fast and often, so be sure to keep checking back here for the latest developments on the Crostini project. At this rate, it really feels like we might hear something official about all this at Google I/O in a couple weeks. The current schedule doesn’t show anything specific, but I’m beginning to think this whole movement has taken on a life of its own and might make its way into Google’s event one way or another. We’ll see what the next few weeks bring and, as always, we’ll keep digging.
