Description of problem: In the 18 Beta TC8 DVD installer, the items listed in the DE column are GNOME Desktop (default) KDE Plasma Workspaces Xfce Desktop LXDE Desktop Cinnamon Desktop MATE Desktop Sugar Desktop Environment Development and Creative Workstation Web Server Infrastructure Server Basic X Window System Minimal Install When "Basic X Window System" is chosen instead, these items are added in the add-ons column (some other GNOME-specific items are deleted): Firefox Web Browser GNOME Input Methods KDE Plasma Workspaces LXDE Legacy Fonts XMonad XMonad for GNOME Xfce Some of the DEs (Cinnamon, MATE, Sugar) are missing from this list. I'm not sure which items in the DE list are considered DEs, so please cross-check. Version-Release number of selected component (if applicable): anaconda-18.28 (from 18 Beta TC8)
This was never the intended design of that environment - the design was that it existed for people who want to install xmonad, openbox, and other things that aren't even desktops. In fact, I think adding two places where you can install desktops makes it even *more* confusing.
(In reply to comment #1) > This was never the intended design of that environment - the design was that > it existed for people who want to install xmonad, openbox, and other things > that aren't even desktops. > > In fact, I think adding two places where you can install desktops makes it > even *more* confusing. That's a shame. I had already verified that it works properly for installing both Gnome and KDE, and it's too bad that this useful, working feature will now be removed. (Of course, if the DE list used checkboxes like the add-ons list, the UI would be simpler than now - the same type of choice being allowed for both DEs and add-ons - *and* there would be no need to have the DEs in two places. But that simpler, more capable design would mean that users could easily install multiple DEs at install time, without jumping through hoops, and we can't have that.)
The list on the left *isn't a list of desktops*. It's a list of pre-assembled and reasonably tested configurations to install; it's why there's a web server, and an infrastructure server, and a design&development workstation, and so on. It *also* happens to have desktops, which correspond to the *spins*, not to the basic desktop groups. (And they're there not because offering a choice between them all is really that great, but, because, well, people get really bothered about their desktop not being offered.) The basic desktop groups are merely things that help build up those tested spins. By allowing arbitrary combinations of desktops, you break the 'tested' aspect (at least, until you greatly expand the amount of testing you do), and, IMO, not for a great reason. The idea is to design elegant things so the user can install and then commence to *doing* things with their desktop, not so the user can flip between them randomly.
(In reply to comment #3) > By allowing arbitrary combinations of desktops, you break the 'tested' > aspect (at least, until you greatly expand the amount of testing you do), > and, IMO, not for a great reason. The idea is to design elegant things so > the user can install and then commence to *doing* things with their desktop, > not so the user can flip between them randomly. Linux is a multiuser OS, different users in general use different desktops, and sometimes they need to use the same machine. So even if you assume that there is no legitimate reason for a single user to use multiple desktops, it doesn't follow that multiple desktops shouldn't be installed at once. Also, one may want the desktops not to actually work in each of them, but simply for their applications. Many KDE applications don't have perfect counterparts in Gnome, for example, but work perfectly well in Gnome. Also, as long as it's possible to install multiple desktops by *some* means, the testing issue exists. If it's a significant issue, the installer at least has the opportunity to give a warning (although oldUI never bothered to do that). If one uses yum groupinstall afterwards, there is no warning. As long as something risky is possible, better to encourage people to do it in an informed way (though I seriously question how big the risk is, having had multiple desktops installed for many years without any problems that I can recall). There's also a danger that making it harder to get multiple desktops in a clean install will push some people to doing upgrades instead, after having once gotten things set up the way they want. Upgrades are probably worse from the testing standpoint (even with only one desktop) than any kind of clean install, but we still support upgrades. Unlike multiple desktops, I *did* have trouble many years ago with upgrades and stopped doing them.
(In reply to comment #4) > (In reply to comment #3) > > > By allowing arbitrary combinations of desktops, you break the 'tested' > > aspect (at least, until you greatly expand the amount of testing you do), > > and, IMO, not for a great reason. The idea is to design elegant things so > > the user can install and then commence to *doing* things with their desktop, > > not so the user can flip between them randomly. > > Linux is a multiuser OS, different users in general use different desktops, > and sometimes they need to use the same machine. So even if you assume that > there is no legitimate reason for a single user to use multiple desktops, it > doesn't follow that multiple desktops shouldn't be installed at once. Linux users also may want/need different command shells, mail clients, URL grabbers, <insert other thing here>, but we do not expose that in anaconda either (and aren't going to); it is only exposed post-install, or via kickstart. > one may want the desktops not to actually work in each of them, but simply > for their applications. Many KDE applications don't have perfect > counterparts in Gnome, for example, but work perfectly well in Gnome. That may be true, but using the desktop groups as a proxy for their applications, as opposed to actually fixing the application install story... that's the wrong way to go about that problem. I guess it goes back to what Fedora *is*, what the products of it should be, and what the installer is designed for. If all people want is for Fedora to be is a collection of packages, and then the installer would allow you to pick and choose and reorganize any of them to your hearts content, then a different design for software selection might make sense. What this was designed for, however, was for something more along the lines of where the Fedora products are the spins, and what the DVD install offers you is a way to mimic the choice of spins via its package selection interface. (With the flexibility of offering some bits of choice via add-ons to those spins, or add-on repositories for those spins.)
https://git.fedorahosted.org/cgit/comps.git/commit/?id=a6af745040bdc7d36476ec76e0eea859be629e3d