Integrating Multipass with the Desktop
Multipass 0.9 is about to be released and 0.10 shouldn’t be long after that. Some of the many improvements and bug fixes the new releases will bring are the result of a push to better integrate Multipass with different desktop environments. For logistic reasons, the effects will spread over two releases. This post provides an overview of what is involved.
GUI
Since version 0.7, Multipass comes with a windowless GUI client, alongside the fully-fledged CLI one. At this stage, it takes the form of a “status icon”, offering a quick view of existing instances and a point-and-click handle on common operations. For now, the user can start/stop instances and open shells into them. With time, we intend to expand the GUI, giving it windows and covering many more operations.
 |
|---|
| Multipass GUI with VMs |
Desktop integration on multiple platforms
The GUI is available on all the platforms where Multipass itself can be installed: Linux’s multiple flavors, Microsoft Windows, and macOS. We have been working to improve how it integrates in the respective desktop environments. To that end, we provide launchers, application icons, tweaked installers, and a new autostart feature, keeping the aim at a smooth UX that balances consistency with and across platforms.
Different interfaces
Every platform has its own UI paradigms, methodologies, and even nomenclatures. Fortunately, most of what goes into making a GUI is common to multiple desktop environments, allowing Multipass to leverage the Qt framework to abstract most of it. For instance, GNOME’s “status icons” match “taskbar icons” in Windows and macOS’s “status menus”. Even though some details may differ (e.g. supported mouse clicks and position in the UI), they essentially play the same role, which Qt wraps in a QSystemTrayIcon class. However, some platform-specific setup is needed to make it work properly.
Take macOS. There, an application goes beyond the mere executable – it isn’t complete without a special file tree where we tell the OS about the app’s properties. We’ll stop putting the GUI binary in the PATH because it is not self-contained. The command open runs the application from the terminal: open -a Multipass.
Icons
The same approach allows specifying the app’s icons in macOS. Once the file structure is placed in the central Applications folder, it becomes available system-wide, with a Launchpad icon. In contrast, Windows requires no files beyond the executable (with its own dependencies). The .exe can be customized with an icon, just like any other file. We do this in batch when building the application – no one clicking through the Windows interface 
Then, when installing, we create a shortcut in the Start Menu, which picks up the icon automatically.
The situation in Linux is somewhere in between, and it is where the best balance lies, in my opinion. The status icon works just as well when launched directly from the executable, but a .desktop file must be installed to register the application with the desktop environment. However, this file goes on top of the binary, as a thin and purely additive layer, to decouple desktop integration details from functionality. The app’s behavior does not depend on it.
Autostart
To enrich the UX, the Multipass GUI now starts automatically when the user logs in. To deactivate this, run multipass set client.gui.autostart=false (true to reactivate). However, on Linux and macOS, this behavior only takes effect after a Multipass client (GUI or CLI) is run manually a first time.
The reason is technical. Unlike a daemon, a GUI is meant for direct user interaction, so it runs under a specific user ID. These platforms therefore offer a per-user interface to autostart apps, involving a certain file in a specific user location. Another user without that file would not get the app auto-started. But a single user triggers the installation of the app on the system, so that is not the right moment to install the autostart file. The next possible occasion our code runs is when the user actually runs the application. This may change in the future if snaps add support for user-level hooks.
The scenario differs in Windows, where a single system-wide registry key allows auto-starting applications when any user logs in. But fear not, we made sure each user can still decide whether they want the application to autostart freely! The autostart switch is still a per-user setting 
We may revisit the current implementation to simplify the setup code. That should not impact the interface that we now lay out, with the possible exception of the first-manual-run requirement.
Conclusion
One of our key ambitions is for Multipass to offer a productive and rewarding user experience. The graphical client tries to shorten the distance, putting Ubuntu VMs a couple of clicks away. With the upcoming releases we try to take another step in that direction by integrating seamlessly with the host OS, while offering a coherent experience in the different platforms.