Red Hat / Fedora Anaconda Installer Shifting To A Web Based UI

[Michael]

From a different perspective, how difficult would it be to (re-)architect GTK so that it could compile for a "web" target?

GTK does/did have a HTML5 backend called "Broadway", but haven't heard of it in a few years so not sure it has seen much attention during GTK4 times...

https://www.phoronix.com/scan.php?pa...adway-Progress

[tehehe]

This is a good decision. Can't wait to see something usable. Fedora 37 perhaps?

[chocolate]

GTK does/did have a HTML5 backend called "Broadway", but haven't heard of it in a few years so not sure it has seen much attention during GTK4 times...

https://www.phoronix.com/scan.php?pa...adway-Progress

Thank you! Indeed, I recalled something like that existed and was wondering whether it had been progressing alongside GTK 4. Larsson's post, linked inside your article, sums up how I would have imagined it to work, more or less.

Purely out of curiosity, It would have been interesting to see that effort ultimately pan out and be backed by Red Hat for the purposes of Anaconda as well.

Cheers.

[Vistaus]

Because text mode installers make your eyes bleed from the ugliness.

Not pe se. I recently switched to Void and I have to say that their text-based installer looked quite pleasing.

[Vistaus]

we also have Bloated Browser, just look at Vivaldi,

Vivaldi can all that Firefox can, down to userCSS and userJS to customize the interface. So if Vivaldi is bloated, then so is Firefox.

[Vistaus]

From a different perspective, how difficult would it be to (re-)architect GTK so that it could compile for a "web" target?

Doesn't GTK already have that? I think it's called GTK Broadway.

Edit: never mind, your question was already answered by the person below you. Note to self: read ahead to see if someone else has already replied…

[Jabberwocky]

More race conditions for packer builds, sigh

[Anvil]

Vivaldi can all that Firefox can, down to userCSS and userJS to customize the interface. So if Vivaldi is bloated, then so is Firefox.

least with Firefox its not plain, its up to the user to enable other stuff if they desire to, where as Vivaldi a lot of what is there can be hidden with flags to enable them

[MartinK]

No, Electron will definitely not be used in any form or manner for the new Anaconda Web UI. :-)

The backend written in Python that does all the actual installer work will remain in place as will the existing text interface as well as automated installation support via kickstart. The Web UI will be developed in parallel with the existing GTK3/Python GUI and is not expected to become the default until it is sufficiently feature complete.

As much as possible of the Web UI will be built using existing & well proven Cockpit based tooling and the robust and widely used PatternFly web widget library. The Web UI will communicate with the Anaconda Python backend via DBus, as the current GTK3 GUI and the text interface already do. The various configuration screen you might find when you install cockpit on your machine basically do the same (they talk to various services, say Metwork Manager or Udisks - running on your machine via DBus, so the cockpit tech is a really good fit for this usecase.

when running locally (like the GTK3 GUI does at the moment) the cockpit-desktop tool will be used:

https://cockpit-project.org/guide/la...kpit-desktop.1

This is again already well used and working well so far + as its just a Python/GTK/Webkit combo, it does not really add any extra dependencies to the installation image as all of these things are already there (Python for Anaconda, GTK for the existing GTK UI, Webkit for the Yelp help viewer).

While its still quite early, performance of the Web UI does not seem to be really different from the existing GUI when running locally.

For remote access though, the Web UI has the potential to improve things quite a bit!

Current GUI remote access uses VNC, which is inefficient (sends bitmaps), does local rendering (putting more starin on the machine doing the installation), requires GUI libs locally installed (no headless images if you want remote GUI), insecure (limited password length, no encryption) and needs specific client software (VNC viewer).

In comparison a remote Web UI only really transfers a few bits here and there, could likely run of a first generation RPI as it does no local rendering, from a small image (no need to have X/Wayland, GTK, VNC server, etc. on the image) via encrypted connection (HTTPS) and effectively stateless GUI that (at least in theory) could be spawned in any installation phase. Say when your automated install somewhere on the net gets stuck or you want to provision the Fedora image you just put on an SD card for your new SBC via the Fedora ARM installer, without involving any serial consoles or temporary HDMI monitors.

[waxhead]

Because text mode installers make your eyes bleed from the ugliness.

...while your fingers rejoice from the usefulness... but seriously: If looks is so important for you - do you run an installer often enough that you really care? Would somebody be as stupid as not to try a distro (or whatever) just because the installer which is normally used once is not pretty enough?