Hide improper qubes from selection

[ben-grande]

Improve filters of several comboboxes to show only valid options:

• Templates nor disposable templates shouldn't be used:

  • as service qubes
  • have devices assigned to it
  • GPG key qube

• Minimal template may lack some packages and services, improve filter:

  • "updatevm" requires "supported-rpc.qube.TemplateDownload"
  • "split-gpg" requires "supported-rpc.qube.Gpg"
  • every model using VMSubsetPolicyHandler will check "service_name"

---

Requires: QubesOS/qubes-core-admin-client#411
Requires: #291 (this PR provides fallbacks in case the qube is outside of filter but is the default setting, it allows loading the icon)

---

Reusing same video from #291 (comment), which also hides internal qubes.

Video to show the differences, will also help checking if everything is as expected.

2026-02-13-113856.webm

---

TODO:

• improve u2f commit message: Hide internal qubes from selection #291 (comment)
• update update_vm_calls(): Hide internal qubes from selection #291 (comment)
• fix tests

[ben-grande]

PipelineRetry

[marmarta]

Ok, so, I still have some doubts about particular choices here, but I think that the biggest problem I see through testing is that the user has no chance of understanding why a given qube does not appear as an option in the dropdown. And that's not great for rules that are really pretty opaque and require explaining. An idea for explaining that comes to me that does not involve paragraphs and paragraphs of text is listing those qubes in the dropdown but grayed out and with a tooltip why a given qube is decreed ineligible, but this is difficult to do. Any ideas?

[marmarta]

marmarek has another idea that I think might make sense, but I'm not sure how to implement it without dying inside: separate the list of qubes into two sections, the second of which is something like Not Recommended (with a header that describes it); however I recall trying to do unselectable headers in GtkComboBoxes and it was pretty painful.

[ben-grande]

Ok, so, I still have some doubts about particular choices here, but I think that the biggest problem I see through testing is that the user has no chance of understanding why a given qube does not appear as an option in the dropdown. And that's not great for rules that are really pretty opaque and require explaining.

But from the user point of view, they just want to see options that are viable. If it is not viable, I think that this explanation suffices. Cause, well, there may a lot of reasons "if conditions" of why a qube is not being shown, so I don't think it is proper to explain why, would add a lot of text. You agree with that in the next quoted text:

An idea for explaining that comes to me that does not involve paragraphs and paragraphs of text is listing those qubes in the dropdown but grayed out and with a tooltip why a given qube is decreed ineligible, but this is difficult to do. Any ideas?

marmarek has another idea that I think might make sense, but I'm not sure how to implement it without dying inside: separate the list of qubes into two sections, the second of which is something like Not Recommended (with a header that describes it); however I recall trying to do unselectable headers in GtkComboBoxes and it was pretty painful.

I would not like the dropdown to be filled with invalid options again, but if this is done, I would say that it should be unselectable as most are not simply "not recommended", they are invalid options. The only "not recommended" is qubes excluded because of the "internal" feature.

[ben-grande]

PipelineRetryFailed

[ben-grande]

PipelineRetry

[ben-grande]

PipelineRetryFailed

[marmarta]

But the problem is that a user does not come to this config window with zero pre-existing notions. If someone goes there to switch the clockvm to a certain qube, and can't find that qube in the dropdown, they need to be able to tell why this is so without googling. If the "invalid configuration options" (i would say a lot of your proposals are not invalid, they will work, they might be unwise but will not render the system unfunctional) are not understandable, the GUI needs to explain them, and I don't have a good idea how to explain it clearly. Thus, to accept this PR, it needs a better idea on how to communicate those limitations for each dropdown.

[ben-grande]

@valpackett Do you have any recommendations on how to accomplish this?

[ben-grande]

PipelineRetryFailed

[marmarta]

I have another proposal: what do you think about showing a warning label in red if the user picks an not recommended qube for a given dropdown?

[valpackett]

It's actually not hard to add a non-interactable item to a combobox:

example code

import gi
gi.require_version("Gtk", "3.0")
from gi.repository import Gtk

class ComboBoxWindow(Gtk.Window):
    def __init__(self):
        super().__init__(title="ComboBox Example")
        self.set_border_width(10)

        qube_store = Gtk.ListStore(str)
        qubes = [
            "sys-net",
            "sys-firewall",
            "sys-usb",
            "--- Not recommended ---",
            "personal",
            "work",
            "disp1",
            "disp2",
        ]
        for qube in qubes:
            qube_store.append([qube])

        qube_combo = Gtk.ComboBox.new_with_model(qube_store)
        qube_combo.connect("changed", self.on_qube_combo_changed)
        renderer_text = Gtk.CellRendererText()
        qube_combo.set_cell_data_func(renderer_text, self.render_row)
        qube_combo.pack_start(renderer_text, True)
        qube_combo.add_attribute(renderer_text, "text", 0)
        qube_combo.set_active(0)

        vbox = Gtk.Box(orientation=Gtk.Orientation.VERTICAL, spacing=6)
        vbox.pack_start(qube_combo, False, False, 0)
        self.add(vbox)

    def render_row(self, combo, cell, model, iter):
        qube = model[iter][0]
        cell.set_sensitive(not qube.startswith("---"))

    def on_qube_combo_changed(self, combo):
        tree_iter = combo.get_active_iter()
        if tree_iter is not None:
            model = combo.get_model()
            qube = model[tree_iter][0]
            print("Selected: qube=%s" % qube)

win = ComboBoxWindow()
win.connect("destroy", Gtk.main_quit)
win.show_all()
Gtk.main()

Combining that with the warning label when a bad choice is selected might be okay?..

[ben-grande]

It's actually not hard to add a non-interactable item to a combobox:

Sure, not hard, just needs to find the right incantation. Thanks for the response.

I will think how this can be done with the filter_function and other filters added in different sections of the classes, because there is not a single place to filter the qubes, sometimes they are spread.

---

About the warning label, I think it should be on each row, so the user knows before selecting such option, that it is not recommended.

[valpackett]

About the warning label, I think it should be on each row

I thought what @marmarta meant by warning label was a larger (couple sentences) explanation of "why what you've selected doesn't make sense". That doesn't fit inline on the rows :)

Putting the "(Not Recommended)" on each "bad" row instead of having a separator item sounds like too much visual noise to me… though since we want to discourage here, that might be used on purpose (?)

[marmarta]

Yeah, I was thinking about a separate section of Not Recommended qubes, preferably each with a tooltip explaining why it is not recommended. Definitely not on each row, this will look very bad.

A warning label would be something like a label put below the dropdown, that is shown if the user selects a non-recommended qube, to warn them that the consequences of that choice might be X, Y and Z. Similarly as we do in qube settings, if you have netvm set to none and default dispvm set to a networked vm, you get a warning.

[marmarta]

Actually maybe this is a solution? If you select a qube that would cause some problems, show an explanation mark icon next to a dropdown (and/or a label) that explains why this is a potentially bad choice.

[ben-grande]

Discussed with Marta and it seems that the most pressing issue is that disposable templates should be still be shown, but marked as not recommended. Other things can be added easily, once the mechanism to mark "not recommended" is done.

Marta proposed: leave the dropdown as is, but if a user selects a potentially dangerous option, show a red label saying "This is potentially insecure because X, Y, Z". Also no popups.

I am thinking of doing two filters. The first one is to include qubes in the list. The second one is to check if qube is not recommended, and if so, add a label on the side of the dropdown (not on each row), explaining why it is not a good idea to use such qube.

The second filter could simply apend text to a list for each condition it matches (when it shouldn't). Example:

def is_clockvm_prudent(qube)
    not_recommended = []
    if is_dispvm_template:
        not_recommended.append("Qube is a disposable template")
    if is_template:
        not_recommended.append("Qube is a template")
    return " ".join(not_recommended)

[ben-grande]

About how to show the warning:

• Simple combos are easy to handle, a .problem_box below them is fine. This works for clockvm and updatevm (Dom0 update proxy).
• Complex setups that involves many qube rows, such as split gpg, device assignments, it can be near each qube row. It can be:
  • on top/bottom of everything, but this loses some context. It would look similar to "unexpected policy file contents" with the rules below.
  • an icon with tooltip on each row (inserted rows, not in the dropdown).

The important part is to keep this consistent. I don't see icons with tooltips being used here like in the Qube Manager. I think this was a design decision to use just red boxes, keeping it consistent and information is shown instead of hovering the mouse.