Skip to content

Instantly share code, notes, and snippets.

@joseivanlopez

joseivanlopez/agama-desktop-selection.md

Last active March 18, 2026 16:15
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save joseivanlopez/71b43e531770b0a9e8c27256e10bc4b8 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save joseivanlopez/71b43e531770b0a9e8c27256e10bc4b8 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
agama-desktop-selection.md

RFC: Desktop Environment Selection Mechanism

1. Abstract

This document proposes a mechanism to enhance Desktop Environment (DE) selection within the Agama Software configuration. By flagging specific patterns in the product metadata, Agama can distinguish graphical environments from standard software packages, allowing the UI to present them prominently.

2. Motivation

Currently, selecting a desktop environment requires users to find specific items within a flat list of software patterns. As a primary installation decision, this choice should be visually distinct and easily accessible. Leveraging the existing user_patterns structure allows us to categorize these choices without altering the underlying configuration schema.

3. Proposed Changes

3.1 Product Definition Extension

We propose adding an optional boolean desktop field to the user_patterns collection in the product definition (e.g., tumbleweed.yaml).

Example tumbleweed.yaml:

id: Tumbleweed
user_patterns:
  - name: office
  - name: gnome
    desktop: true      # Used by UI to promote this pattern
    selected: true     # Default selection, if desired
  - name: kde
    desktop: true
  - name: xfce
    desktop: true

3.2 JSON Configuration

This proposal is backward-compatible and requires no changes to the config.json schema. Selected desktops are stored simply as pattern names within the software.patterns array.

Example config.json:

{
  "product": "Tumbleweed",
  "software": {
    "patterns": ["kde", "office"]
  }
}

3.3 User Interface Integration

The "Desktop" selection will be integrated into the Software configuration workflow but will be visually prominent to highlight its importance.

3.3.1 Software Summary (Overview Page)

  • Visual Hint: The summary will explicitly list selected desktops (e.g., "Desktops: KDE Plasma").
  • Validation/Alerts: If no pattern marked desktop: true is selected, the summary may display a non-blocking info alert (e.g., "No desktop environment selected").

3.3.2 Software Selection Page

The available desktops will be offered as part of the software selection, probably presenting desktops in a prominent way. The page will display the name, icon, and description of patterns flagged as desktop: true.

The UI will support selecting multiple desktops.

To ensure a rich UI, the patterns used as desktops should ideally provide an icon and a localized description.

3.3.3 Confirmation popup

The confirmation popup will include an alert if no pattern marked desktop: true is selected.

@jreidinger
Copy link

jreidinger commented Mar 17, 2026

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

@imobachgs
Copy link

imobachgs commented Mar 17, 2026 •
edited by joseivanlopez
Loading

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?

@joseivanlopez
Copy link
Author

joseivanlopez commented Mar 18, 2026 •
edited
Loading

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.

@joseivanlopez
Copy link
Author

joseivanlopez commented Mar 18, 2026

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.

  1. I would allow to select multiple desktops.

Ok

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

@ancorgs
Copy link

ancorgs commented Mar 18, 2026 

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.

@joseivanlopez
Copy link
Author

joseivanlopez commented Mar 18, 2026 •
edited
Loading

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

@jreidinger
Copy link

jreidinger commented Mar 18, 2026

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment