Originally posted by chocolate
View Post
Announcement
Collapse
No announcement yet.
Red Hat / Fedora Anaconda Installer Shifting To A Web Based UI
Collapse
X
-
Michael Larabel
https://www.michaellarabel.com/
- Likes 6
-
Originally posted by Michael View Post
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
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.
Comment
-
Originally posted by chocolate View PostFrom a different perspective, how difficult would it be to (re-)architect GTK so that it could compile for a "web" target?
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…Last edited by Vistaus; 12 January 2022, 12:31 PM.
- Likes 1
Comment
-
Originally posted by Vistaus View Post
Vivaldi can all that Firefox can, down to userCSS and userJS to customize the interface. So if Vivaldi is bloated, then so is Firefox.
Comment
-
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:
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.
- Likes 7
Comment
-
Originally posted by Mez' View PostBecause text mode installers make your eyes bleed from the ugliness.
http://www.dirtcellar.net
- Likes 1
Comment
Comment