Skip to content

Applets manager: Configure opens the wrong instance of multi-instance applets (wrong panel/monitor) #13882

Description

@AlexB7

Summary

Configuring a multi-instance applet from Panel right-click → Applets → Configure always opens the settings of the first instance (lowest instance id), regardless of which panel the manager was opened for. On a multi-monitor setup with one applet instance per panel, the user's edits land on a panel on a different monitor than the one they intended to configure — it looks like the applet's settings are "bleeding" across monitors.

Observed on Cinnamon 6.6.7 (Linux Mint 22.3, X11). Reproduced with CassiaWindowList@klangman and Grouped Window List but any multi-instance xlet is affected.

Steps to reproduce

  1. Multi-monitor setup, one panel per monitor; a multi-instance applet added to panel A (monitor A) and panel B (monitor B), with visibly different settings (e.g. window list behavior "grouped" on A vs "one-to-one" on B).
  2. Right-click panel B → Applets (or open System Settings → Applets and select panel B with the Previous/Next Panel buttons).
  3. Click Configure on the applet.

Expected: the settings dialog opens on panel B's instance; the highlighted applet and the highlighted panel agree.

Actual: the dialog shows panel A's instance ("grouped"), and two different highlights appear on two different monitors: the Applets manager highlights panel B (highlightPanel), while xlet-settings highlights the applet it actually opened — instance A on monitor A (highlightXlet). Any change made in the dialog is applied to panel A. Launching xlet-settings applet <uuid> -i <id> directly works correctly, which isolates the problem to the launch path.

Root cause

ExtensionCore.py launches the dialog with no instance id:

subprocess.Popen(['xlet-settings', self.extension_type, self.uuid])

even though the applets page knows exactly which panel is selected (panel_id, kept in sync with the panel context-menu argument and the Previous/Next Panel buttons). xlet-settings, receiving no -i, falls back to the first instance found.

Suggested fix

Pass an instance resolver from ManageSpicesPage to ManageSpicesRow; in configure(), append -i <instance> when the applet has an instance on the currently selected panel. ManageAppletsPage resolves it from enabled-applets (panel<id>:zone:pos:uuid:instance); desklet/extension/action pages keep the previous behavior. (Patch available.)

Related latent bug in xlet-settings.py

While debugging this, commit 769a754 ("cinnamon-settings: Clean up commandline argument handling", first shipped in 6.6) introduced:

self.instance_id = str(args.id)     # str(None) == "None", a truthy string
...
if self.instance_id and len(self.instance_info) > 1:   # "None" is truthy
    for info in self.instance_info:
        if info["id"] == self.instance_id:             # "None" never matches
            self.set_instance(info)
            break
else:
    self.set_instance(self.instance_info[0])           # intended no-id fallback, never reached

With no -i (or a stale/unmatched id), neither branch calls set_instance(). The failure is currently masked because load_instances() separately defaults selected_instance to the first instance, so the dialog still works — but:

  • -t <tab> is silently ignored when -i is absent or doesn't match (tab selection happens in set_instance()), a behavior regression from pre-6.6;
  • the code only works by accident of the load_instances() default; if that ever changes, selected_instance stays None and _on_proxy_ready / previous_instance / next_instance all raise.

Suggested fix: self.instance_id = str(args.id) if args.id is not None else None, plus a for/else fallback to set_instance(self.instance_info[0]) for unmatched ids. (Patch available.)

System info

  • Cinnamon 6.6.7
  • Linux Mint 22.3, X11 session
  • 2 monitors, one panel per monitor in the affected setup

Claude Fable 5 was used to find the root cause.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions