RFC: Desktop Environment Selection Mechanism

[joseivanlopez]

1. Abstract

This document proposes a mechanism for Desktop Environment (DE) selection within Agama. By introducing a selection strategy in the product metadata and enhancing the visibility of DE-related patterns, we aim to prevent accidental "text-mode" installations and improve the user onboarding experience.

2. Motivation

Currently, Agama does not guide the user about the desktop selection. Selecting a desktop is easily overlooked, ending with an installed system which starts in text-mode. As a primary installation decision, the selection of the desktop should be visually prominent and easily accessible.

3. Proposed Changes

3.1 Product Definition Extension

We propose adding a desktop_selection property to the product definition to define the enforcement policy.

Desktop Selection Strategies:

• optional: Suitable for server-oriented products. No warnings or alerts if a DE is not selected.
• suggested: The product suggests a DE. Displays an info alert in the summary and a confirmation prompt if none are selected.

Example tumbleweed.yaml:

id: Tumbleweed
desktop_selection: suggested
user_patterns:
  - name: gnome
    selected: true     # Allows the product to select DEs by default
  - name: kde
  - name: office       # Standard pattern

3.2 JSON Configuration

The JSON configuration remains backward-compatible. The selected desktops are stored within the software.patterns array. No schema changes are required.

3.3 User Interface Integration

3.3.1 Software Summary

The Software section in the main overview will show the DE state:

• Success State: Lists the selected DEs clearly (e.g., GNOME Desktop).

• Warning State: If DE selection is suggested and none are selected, an inline alert informs the user that no desktop is selected.

3.3.2 Software Selection Page

The software UI will be revamped and will offert a proper desktop selection. The design of this new UI is not defined yet, but it will allow to easily select one or multiple desktop environments. The UI will be populated with the icon, name and description from the desktop patterns.

Note

Existing pattern names and descriptions may require sanitization to ensure they are appropriate for the selection UI.

Current UI for selecting patterns which will be improved.

3.3.3 Confirmation Workflow

For products with suggested desktop selection, triggering the "Install" action without a selected desktop will add an alert to the confirmation dialog. This dialog provides a final opportunity to return to the software selection or proceed with a headless installation.

[dgdavid]

Warning State: If DE selection is suggested and none are selected, an inline alert informs the user that no desktop is selected.

Just to clarify: DEs are suggested but not required. Therefore, there will be no warning state and no alert when none are selected other than the reminder shown at confirmation, which should be more than enough. What is rendered in the overview is an informative summary with either, the selected desktop or the absence of one (“No desktop selected”). Warnings are reserved only for issues that block the installation, and the absence of a DE does not block anything. In fact, still a perfectly valid choice.

[lkocman]

This looks great! You've nailed the requirement for a neutral, unselected state while adding a smart safeguard to prevent users from skipping the desktop by mistake. I like that desktop_selection: optional -> suggested affects where to display or not the warning. Thanks for the hard work on this!

[lslezak]

Just a technical note, do we need the extra desktop flag in the configuration?

id: Tumbleweed
desktop_selection: suggested
user_patterns:
  - name: gnome
    desktop: true      # Identifies this pattern as a DE
    selected: true     # Allows the product to povide a default DE
  - name: kde
    desktop: true
  - name: office       # Standard pattern

I mean, all desktop environments use the "Graphical Environments" pattern category. Instead of that flag we could use this information.

The only drawback is that the category will be known after refreshing the repositories (or registering in SLES). If we need that information earlier then the flag is a must.

[joseivanlopez]

Just a technical note, do we need the extra desktop flag in the configuration?

I think we don't need it. It was proposed at the beginning of this document, but I think we can discard that flag.

[imobachgs]

Included in Agama 21.