It’s quite some time since we created the current GTK based UI for Anaconda: the OS installer for Fedora, RHEL, CentOS. For a long time we (the Anaconda team) were looking for possibilities to modernize and improve the user experience. In this post, we would like to explain what we are working on, and—most of all—inform you about what you can expect in the future.
First, we need to express that we decided to share this information pretty early. We are currently at the stage where we have made the decisions. We have a ‘working prototype’ of the solution already available but don’t expect screenshots and demos yet!
What you can expect?
We will rewrite the new UI as a web browser-based UI using existing Cockpit technology. We are taking this approach because Cockpit is a mature solution with great support for the backend (Anaconda DBus). The Cockpit team is also providing us with great support and they have significant knowledge which we could use. We thank them for helping us a lot with the prototype and creating a foundation for the future development.
We also decided for this step to be consistent with the rest of the system. More and more projects have support in Cockpit. By this step we should make the system more consistent between different applications. The great UX improvement should be easier remote installations compared to the current VNC solution. You can expect a lot of other improvements but let’s wait and see :).
Furthermore, we are building the new UI on top of the Anaconda modularization effort which we are implementing quite some time now. It’s great to see the fruits of our work which helps us now with the creation of the new UI. That also means that users of Fedora shouldn’t be much impacted by the changes during development of the new UI. A big part of Anaconda is now Anaconda modules with DBus APIs and we are reusing that API. We haven’t yet decided the approach for upstream development. We will tell you more about this in the future.
At the current state, we cannot communicate yet the expected day of the new UI or the minimum viable product availability. However, we will make sure to keep you informed about our progress from time to time, ensuring you know what to expect
We are thrilled about this new change and hopefully you are too! We look forward to give you something to play with!
I’ll admit that I bounced of from Anaconda, so I may not fully understand the current state, but what I would like to do in future is to be able to plug in extra steps during installation without rebuilding the whole installer. Is switching to Cockpit also involves thinking about some extra API that will provide such capability?
Even current Anaconda can be extended with addons, which can add extra screens as well as handle custom kickstart data. The expectation is that this capability will be in place with the Web UI as well.
As for where to run the Web via locally - this turned out to be rather simple and straightforward!
Basically, the Cockpit project had to solve the same issue and created the cockpit-desktop tool:
This is what will mostly likely by used to run the new Web UI locally and it pretty much ticks all the boxes. Furthermore, its just a simple Python wrapper over Webkit and as we both already have Python and Webkit (used to show help pages in the current GUI) on the media, it does not really make the installation image any larger, even with the existing GTK3 GUI still in place!
I think it makes sense to get closer to a single GUI.
However, I also think that we should be making Linux systems more declarative and reprovisionable by default - that’s the emphasis with CoreOS for example, and interactive GUI changes cut against that.
In particular, I never understood why Anaconda didn’t at least have a button somewhere that let you type in a URL for e.g. a partial kickstart file (which are generally declarative except for the giant gaping exception of %post. That would make it easier to do things like use the GUI for disk setup, but otherwise use kickstart for other things).
It’s been a long time since I actually used this for work, but, when I did… while there’s no GUI for it, it actually does do exactly this, and if you provide one on the boot command line (at $previousjob, we had it in our PXE configuration) it will skip everything it can get from the Kickstart file.
Yes, I know that. But you have to do it before starting anaconda at all, in an unfriendly environment. If you typo the URL, you have to restart the whole thing. You can’t interactively edit it. etc.
BTW, the Web UI being essential stateless turns out to be quite a boon for development. With the current GTK UI we effectively have to reboot a VM every time we change the GUI code we are working on. With the Web UI we are finding that we can just rsync the Web UI code to the running VM and reload the web UI page in a locally running browser and BAM all the changes are instantly there.
Loading a kickstart file at runtime is a bit more involved than this but theoretically not that much, so I can imagine that being added with the new UI, possibly even with an option to check and edit content of the file that’s fetched (or even just copy paste it outright, much more robust with remote Web UI than with VNC).
It isn’t possible to launch the GTK-based UI separately? Of course, that wouldn’t be exactly right for installation purposes but should work for testing the GUI side of things.
It would be really helpful for Fedora on mobile devices if this new GUI was designed to work on small touchscreen devices without a keyboard. I would love to be able to install Fedora onto my Pinephone Pro from an SD card or USB drive with LUKS setup using the same process as my x86-64 laptop. Is this going to be taken into account for the new GUI?
