Add another nice to have feature coming to Project Crostini: There will be a dedicated folder for Linux apps in the Chrome OS app launcher according to this code change in the works. The title of the code change says it all: “Create crostini app folder and add all Crostini apps to it.”
Interestingly, an explanatory comment in the change request indicates that existing Linux apps won’t be moved into this dedicated folder, so there may be a little manual work on the part of folks who installed Linux software prior to this change.
I have tested this update on hardware and it does not cause breaks with existing apps. They will not be moved to the folder, but the users can move them in if they wish.
However, going forward, I’d expect all newly installed Linux apps to automatically be added to the folder.
The change is part of making Linux apps on Chromebooks appear to be more native: In the early days of Project Crostini — just a few months ago — we didn’t even have app shortcuts at all. Instead, you’d have to launch your Linux software from a command line terminal in most cases. Then we got app shortcuts to ease the process.
Once this code change makes its way through testing and implementation, there should be a single folder in the Chrome OS app launcher that contains start-up shortcuts for these apps in one central, easy to find, location. Progress!
8 Comments
Are all those App-Launcher issues fixed by now? Folder that don’t keep in place you put them? They get rearranged with any restart. Folder names also vanish with every restart.
Yes, that sort of thing is massively, INCREDIBLY unprofessional. It’s the sort of thing that would be utterly humiliating to show off to corporate decision-makers. In my experience, Chrome OS 67 fixes the worst of the apps launcher issues. At least it doesn’t seem to erase the folder names anymore. But shortcuts and folders still don’t stay where you put them. And, it sometimes takes a while for the folder names to appear underneath the folder icons after a boot up. Can’t see why Google doesn’t get this. Maybe the increased attention of late is a sign that they are maybe turning the corner.
Makes a lot of sense to make apps launcher shortcuts a very high priority — not just for Linux apps but other all other types of apps, including Web apps, PWAs, Android apps, Linux aps, and whatever else type of app is coming to Chrome OS. Next to Chrome browser, the apps launcher is the feature with which Chrome OS users primarily interact. Like the browser, the apps launcher should unify the bits and pieces into a system. It should be fast, easy, and FUN to access, use, and maintain. The apps launcher should be highly attractive, reliable, and predictable. It should never feel like an add-on, an afterthought, or the equivalent of any of a plethora of available launcher and “speed dial” extensions.
Well, if I have understood the writer correctly, this is something that mightn’t make much sense in my view. Although, I don’t see this as very important this change seems to reintroduce demarcation lines that were being blurred, with good reason, by the standard Chrome OS app launcher UI. If Linux apps always run in a vm/container assuring the safety of the underlying kernel why do we additionally need directory/folder based demarcations in the App Launcher that look quite a lot like exceptions from the point of view of the standard Chrome OS launcher UI.
App grouping, including named grouping if a user desires that, has been around for a while in Android and Chrome OS with “folders” formed from users dragging and dropping Launcher apps on top of one another with each such gesture causing an increase in the number of apps contained within a particular folder. These app groups/folders are normally based on similarity/relatedness of app function (as determined by a user). Would Linux applications form a natural unity based on similarity/relatedness of app function? I doubt it. Furthermore, if the Linux application folder mentioned in the article is anything like a classical folder it will be sharply at odds with the common Android and Chrome OS App Launcher conventions. Currently nothing like a true directory structure exists (or at least obviously exists) within the App Launcher. And, why on earth would we need that?
Personally, I wouldn’t be greatly impressed with a separate Linux directory in the file system either but something like that would at least (potentially) have a justification. If Linux requires the use of a different file system to Chrome OS and thus a second file system needs to be created on a separate partition then any merging of files within a unitary directory structure would be impractical.
This is groundbreaking stuff, and there’s probably a lot of ambivalence. The separate apps launcher folder is probably a cautionary, intermediate step in the overall right direction. There was some initial ambivalence about shortcuts for Play Store apps as well. Some of the icons for Google Web apps acquired a tiny Google emblem to make it easier for users to distinguish those shortcuts from the otherwise identical icon for the installed Android version of the same app. Seems kinda silly now.
Yes, you make a good point. We shall have to see how this progresses over time.
There is a very major demarcation line already between Linux and Android/Chrome Apps.
The legacy “stores” for Linux are *package* repositories. The packages are described for Linux developers, not end consumers.
Even if Google were to develop a unified “store” that could install Chrome, Android and Linux it would still take *years* for the developers of Linux to come up with the material to promote their software to a consumer oriented marketplace rather than to Linux system assemblers.
Providing easy access to the Linux package repositories, as is, strikes me as a better interim goal.
If the mechanism for finding and installing Linux apps is separate it only makes sense that the default location to install their desktop icons would also be separate.
I don’t think you have proved the proposition in your last sentence. Hiding the complexity you recount seems to me to be the better strategy for UX consistency. Still, like Cajun Moses you make very compelling points. If UX wrinkles are the cost of getting this operational in the short run then it would be worth paying. All of this can be ironed out later.