agama-desktop-selection.md

RFC: Desktop Environment Selection Mechanism

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. Additionally, individual patterns within user_patterns will use a desktop: true flag to identify which patterns populate the DE selection UI.

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
    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

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.

I'm not sure about giving "desktop" such a prominent space in the Agama configuration (global config). I have not put much thinking into it yet, so I don't have an alternative to offer. But I kind of like the idea of sticking somehow to pattern selection.

For example, I see nothing wrong in selecting several desktops for the same installation.

I agree with ancor...and I would probably make it UI only feature. I would not expose it in config...desktop is basically just pattern...so I am for having UI that force user to decide what to select, but I would not limit user. So from me ideally:

1. user is forced to select desktop if desktop selection is required in product definition
2. I would not limit user to later change it in software selection ( like select more desktops, etc. )
3. I would make Server ( aka no desktop ) option part of that selection already like it was in Leap15

I have a few comments:

1. I will never force the user to select a desktop. We should only display a warning if the user has not selected a desktop.
2. I would allow to select multiple desktops.
3. I would not offer the desktops in the software selection page. In my opinion in makes things confusing.

About the configuration file, I do not have a strong opinion. If selecting a desktop implies adding more than one pattern, like in the examples, how the UI would behave if I load a configuration with only one of those patterns?

Thanks guys for your feedback. The main complains I see are: a) selecting more than one desktop, and b) avoid defining desktops in the product file:

a) Selecting more than one desktop is not a problem, we only need to change the config schema:

{
  "desktops": ["kde", "gnome"]
}

b) If we don't want to have the desktop definitions in the product file, then we need:

• Some way to know what pattern represents a desktop.
• Each desktop would have to be installed with a single pattern, otherwise it would be impossible to know whether a specific desktop is selected o not.

I have a few comments:

1. I will never force the user to select a desktop. We should only display a warning if the user has not selected a desktop.

It makes sense. If there are desktops available and none of them is selected, then the UI could show a warning.

2. I would allow to select multiple desktops.

Ok

3. I would not offer the desktops in the software selection page. In my opinion in makes things confusing.

I agree.

About the configuration file, I do not have a strong opinion. If selecting a desktop implies adding more than one pattern, like in the examples, how the UI would behave if I load a configuration with only one of those patterns?

I think this is the main point to clarify. How far we can go for inferring desktops from available patterns.

3. I would not offer the desktops in the software selection page. In my opinion in makes things confusing.

But there is a strong connection between selecting desktops and the final installation size (which is an information that is now displayed in the software section).

Selecting one (or several) desktops have a very direct and noticeable impact in the selection of software so I feel it should be somehow connected.

Selecting one (or several) desktops have a very direct and noticeable impact in the selection of software so I feel it should be somehow connected.

I think it would be a problem if the software page only shows the size of the selected patterns, but it shows the size of the whole installation (including packages selected by other services).

Just one note about "4.2 Pattern Metadata". User patterns does not have metadata now. I am not sure if we should add it as it is already part of zypp metadata. I would use just zypp ones and if they are not sufficient we can extend it.
Overall I would say it looks good to me.