Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Posted Nov 12, 2024 20:29 UTC (Tue) by intelfx (subscriber, #130118)In reply to: Please stop shoehorning everything into HTML/CSS/JS by kreijack
Parent article: Anaconda’s new "Web UI" (Fedora Magazine)
Anaconda _is_ written in Python, though. Gtk in fact does have bindings for a huge set of languages, thanks to the entire GLib ecosystem thing.
Posted Nov 12, 2024 22:00 UTC (Tue)
by kreijack (guest, #43513)
[Link] (8 responses)
> Anaconda _is_ written in Python, though. Gtk in fact does have bindings for a huge set of languages, thanks to the entire GLib ecosystem thing.
True... I didn't do my homework :-(
So, the only other explanation is that I am too old to understand why an HTML based gui is more attractive than a python/GTK based one....
Posted Nov 13, 2024 2:05 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (3 responses)
As someone in a sibling comment said, it's likely that web-devs are extremely easier to come by than someone proficient in Gtk.
According to the article, it's also "easier to update and maintain" than a Gtk desktop application, and while it makes no technical sense — sadly, web technologies are simply where all the mindshare is. It's literally "more attractive", much to the disappointment of those of us who prefer actual native applications.
Posted Nov 13, 2024 6:43 UTC (Wed)
by Lennie (subscriber, #49641)
[Link] (2 responses)
In Debian the steps, everything on the screen is the same in the text UI-based installer.
Debian basically has a questions/decision tree system for the user to answer to know what actions to do, you can use a GUI or text UI or even CLI-like UI to ask/answer the same questions (or use a bootstrap 'preseed' config file to skip the question/answer).
I think when it comes to web interfaces, I think it would maybe be useful to have a web interface to help make a preseed file to help with automating installing lots of systems.
[1] https://www.debian.org/releases/bookworm/example-preseed.txt
Posted Nov 13, 2024 12:42 UTC (Wed)
by m4rtink (guest, #95458)
[Link]
Anaconda also has a TUI - it can be seen on this older screenshot from Fedora Magazine for example:
It is also possible to fully automate the installation using kickstart:
Other things can be configured via boot options:
Or configuration files:
GUI is only one of the possible ways of interacting with the installer. :)
Posted Nov 13, 2024 14:38 UTC (Wed)
by smcv (subscriber, #53363)
[Link]
The reason Debian eventually gained one is: internationalization. For languages that are written with a small alphabet (Latin, Cyrillic, Greek) it's fairly easy to set up a TUI in the console character grid, but for languages with lots of characters (notably Chinese/Japanese/Korean) or languages that rely on letter-shaping (Arabic), you really need a fully-featured graphics library to be able to draw legible text.
Making new users feel more at home ("this looks difficult, like a thing for hackers" vs. "this looks a bit like Windows/macOS, how hard can it be?") is a side benefit of offering a GUI installer, but quite an important one IMO: first impressions do matter.
Posted Nov 13, 2024 2:05 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Yeah, I think this is a generational thing, when you think of a GUI app you think of UI toolkits like GTK/Qt/Win32/Cocoa/etc. but over the last decade or so the development standards have flipped and now the vast vast majority of new GUI app development uses web tech (HTML/CSS/JS) and the majority uses some Single-Page-App (SPA) framework like React/Angular/Vue/etc or in this case the in-house framework PatternFly. I think the reasoning has flipped, if you want a GUI the simplest and most well trodden way is using web tech and only if special needs justify it do you use a traditional UI toolkit like GTK or Qt, the path for running Firefox in kiosk mode is well trodden and it makes your app network agnostic, run locally, run remotely, same difference. Firefox replaces the Xserver in modern computing ;-)
As far as how many developers are competent in web vs GTK, there are hundreds of thousands, probably millions of people who are competent developers with web tech, with a vibrant ecosystem supporting it, the number of people worldwide who can program with GTK (in python or C or anything) could probably fit on a single (large) passenger train.
Posted Nov 13, 2024 14:29 UTC (Wed)
by jzb (editor, #7867)
[Link] (2 responses)
I'm curious if you read the article or Garrett's response in the comments? The article explained in some detail why they wanted to pursue this as a web UI rather than GTK. Here's a snippet: GTK 3 is still currently maintained, but it’s old and showing its age. It won’t be maintained forever. Porting to GTK 4 (and possibly GNOME’s special widget set, libadwaita) will require a lot of effort to adapt to the changes and would require a massive effort to rewrite much of the frontend, especially as Anaconda has many custom GTK widgets. Since we’d likely have to rewrite a lot of the frontend anyway, we took another approach and have taken advantage of the modularization efforts to retool the frontend to have a web-based interface instead. The Cockpit team has been providing a web-based interface for Linux systems for managing systems for many years in the Cockpit web console, so it made sense to reuse Cockpit as a base and its web-based widget set, PatternFly, as a starting point for the next generation of Anaconda too.
Posted Nov 15, 2024 18:38 UTC (Fri)
by kreijack (guest, #43513)
[Link] (1 responses)
Not really, the article explained that in any case they had to rewrote a lot of code, so switching to a web base front end was no so expensive; but the same is true for switching to (e.g.) rust based code (o whichever toolkit you prefer).
I have to point out that I am not arguing the fedora decision; I am only wondering if we reached the point were writing a (non trivial) gui in a web browser is (absolutely) better than writing a gui in C/C++ in a case where *the "remote access" is not a "first" requirement*.
I want to be very clear to a point, I programmed a javascript UI (very simple for what matters), and I found it a friendly language to program. However my feeling was also that due to the lack a lot of "safety" (e.g. type checking) that other language provides, it is not good for big program; at least if we don't consider other aspects. E.g. if I have to program a front-end of a program that run on a server, which must be execute in any PC, yes a browser+javascript is a very good compromise, and may be the best choice.
However I am surprise that the same choice was taken for an installer. Again I am not arguing the other choice or blaming javascript as language; I am only guessing if the correct prospective is that the other are worse. And in this case I am curious about the other opinion.
Posted Nov 15, 2024 19:14 UTC (Fri)
by jzb (editor, #7867)
[Link]
the article explained that in any case they had to rewrote a lot of code, so switching to a web base front end was no so expensive; but the same is true for switching to (e.g.) rust based code They also explained the choice of a web-based interface: The Cockpit team has been providing a web-based interface for Linux systems for managing systems for many years in the Cockpit web console, so it made sense to reuse Cockpit as a base and its web-based widget set, PatternFly, as a starting point for the next generation of Anaconda too. I suppose they didn't go into a blow-by-blow comparision of that approach vs. Rust or whatever, but it's pretty clear they chose tooling they were already familiar with that is in use for other system management tools. We covered Cockpit in March. They also mention the use case of remote installs in the future—which makes sense since there are many instances when an admin may want to install Linux on a system they'll never be in the same room with and a TUI is not seen as friendly. Also, Red Hat has been investing in Patternfly for UIs for a long time now, I'm not at all surprised to see it employed in an installer because the alternative would be "use Patternfly here, here, and here, but not the installer". If you assume the folks working on Anaconda also work on other UIs, it would be weird to expect them to use Patternfly everywhere but the installer. However I am surprise that the same choice was taken for an installer. Fedora isn't alone here. We covered openSUSE's new installer, Agama, in August, which also has a web-based interface. Ubuntu, I think, uses Flutter, but I can see why that wouldn't have appealed to Fedora or SUSE.
Posted Nov 13, 2024 5:24 UTC (Wed)
by azumanga (subscriber, #90158)
[Link] (3 responses)
From their FAQ, can we use PyGObject (which is the base library) with the official Python release, rather than via msys2 (which I don't imagine anaconda wants to build on)?
https://gnome.pages.gitlab.gnome.org/pygobject/guide/faq....
Yes, except you have to use some unofficial sourceforge project, and also that sourceforge project last released in 2017 and has been officially abandoned for 4 years at this point.
Posted Nov 13, 2024 6:41 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (2 responses)
How is running anything on Windows relevant to Anaconda, the RHEL/Fedora installer?
Posted Nov 14, 2024 1:41 UTC (Thu)
by azumanga (subscriber, #90158)
[Link] (1 responses)
Posted Nov 14, 2024 11:44 UTC (Thu)
by m4rtink (guest, #95458)
[Link]
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
https://fedoramagazine.org/wp-content/uploads/2017/07/tui...
https://docs.fedoraproject.org/en-US/fedora/f36/install-g...
https://anaconda-installer.readthedocs.io/en/latest/boot-options.html
https://anaconda-installer.readthedocs.io/en/latest/configuration-files.html
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS
Please stop shoehorning everything into HTML/CSS/JS