From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 466304644; Wed, 19 Aug 2026 10:08:41 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 83A0D4633; Wed, 19 Aug 2026 10:08:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) by atuin.qyliss.net (Postfix) with ESMTPS id EC72B4630 for ; Wed, 19 Aug 2026 10:08:37 +0000 (UTC) Received: by mail-vs1-xe31.google.com with SMTP id ada2fe7eead31-74ac3ea9c60so269897137.1 for ; Wed, 19 Aug 2026 03:08:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1787134111; cv=none; d=google.com; s=arc-20260327; b=aRYq7GGd/tBPwoLqvcZe1g3zl/5G2xvnm3eW0kPcqwCToZ2VdPXtCIjnCVwQ6cK9tm Zj9RcoXhWDMrHt0frzNPPbOGS0CM+HSqfN6wRyItZMO835eBCpPlBz8ifqe0sa0FyJ7X 0TY53fTSn3kYSqPs9MyICKeEwkSzxNPqrPKzxOk7i6A8HnhD0cYbyZwz4diuKO3Y3fS1 uYD/wbHJbFGmO0i8sQx+VJXTK3mbuLfFHSsqi3qtCy84C6YesRdj3ygjtubC+j4b3fBs d4JsqxBuVOwXMekgBdM4KT033XaTsFJW1rtMerzRHwdsYli5DumvIWTRvghcK/57m74f BLyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=zb8HIaCPjgmFLRJmx2COIuF5WMqD6QKh8flitaBQDHg=; fh=yMGRd5TP38CK4dSDtrxYzpMiJyqOSczUTIbb/EEwNQI=; b=YT9CEKanpU2mnII6CAnvsaPhZP/93UBtNObzjjzQYf9bM92Rj7ybs18tJoxHDz5/a3 2Di9UJqU+3/fArs2XYdQE6LSWkfbWwbZzw70EfUn+SYEKADSQLOl4SUQGogyYNxzvDkI u2Jra01GMVVxzrUkvM8xBUz4KOm/lUOp91Kxzh/6WBLCAYnw/Lc7hQBj3mLNRc8lJ5oa Mf1L3GIYyJV5JfPsTFR/T3Eo7DJLI6CRwCJm6/BW7MgZvPjdQjPQpZV5JrCKRoFQ7FBB Dd/5dYqqdUmyndJeKvUtGhLtNDzkPqhsk6NhD/JAtd23dyqWJCGjUOPq7sqIeGVzrdGu DgyQ==; darn=spectrum-os.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787134111; x=1787738911; darn=spectrum-os.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=zb8HIaCPjgmFLRJmx2COIuF5WMqD6QKh8flitaBQDHg=; b=ADeys/0CZv40Vsos1RBGio8h/F32+XiaCg9UFUQvyr+cZyX2+V+8DJC0aTOgclD98I JrPZbDN74+k9yovgsSBDce7gTgdwqOnXg0QV7k4hDxlQ+KWufmNc2kl5k1EjFJ3slC2m rpQb9lvgWhJeOLjX9Xx0wWgIm1AmjvfgFUCwHveL1pHDAobQAfpA7FlE+TqtnJe9dyfF oX1m4ZBbIFtZs6IBUX/aNMApK2xb2/prWJQmyw6pqmeUdEFY8b7yJOB5yVI8fltUnSK2 lyaZG94jgpMIDru2eToktjbeadVzMzxeALA5VfKlN8lpCQdlumDVVj3KTKZuAVaU7R2Y vVaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787134111; x=1787738911; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=zb8HIaCPjgmFLRJmx2COIuF5WMqD6QKh8flitaBQDHg=; b=luStS2rqj9gaVqooZ+gOtQ1yIpPYeRgZAWbgK8181Y5nkvfIbvtrpiG2JAgq6owtbG 6f3jixLSC8xz7Tg5V35kebN41Uo6AAd1tseBp60y0k6u1ArNp8FNlPLF9scVQwCYTWsp m/Gnx/o1oplyk+weKYaIJnZtlpjcEIavZ8YBiuouR8qfpPVL5wm0mvJ43Jv6KNGIcVRV 8lyL0RmawVyWbOwmABI+y7E9Dy7HznSxYY8vGqpbszVIc7BJJrRDLjd4QSW+y6LayH4i oqIvRmlrDI89vwq46MSF2YDILyemULv8T1ZePv8HYV800EeyNtthnhHYJC1DLiOkSshU JgSg== X-Gm-Message-State: AOJu0Yw4nHN9cSEViW4u7ox48p3CC8n5oVgJJ2itXcTyVmGEma5q6pCk OaKybQWS6Phz1tlzeTvJqoAQFRT9DfLNoVXekHiN99/VYIc732NaeGGeq2o1/g++GFcANS34O81 xwBSm9n5gpzwQQ0og0NKtXx0ewxxS0ngBFu/J X-Gm-Gg: AR+sD12roX7htoLokZAzHTVUERS78pA7dUr0l0lHto6BOHqEQ5J3HvbutVmFL0T760v b2zh7TCx6OFsbsu2/+Uxy//68giS74VCvhJ0qPP60oFUIQmk6EkXB7ubU/O5E4QLCyb1/csDhoG J+8naxtrV/ozh1KMxTmFUeALlJ/HDi8njaHpakB/ad37CiDPFVN0lqpU73IHyZls6JgMxJphRGa SdCMjQwX/KsDLPaIKGxAYSBDQvVEXJA6lQhdlko6nYBb+KtRhhaB0jPKqpOT9SmoxOXpXhxuwmH KtKTkYxvF0VnKKeZG29BmeCR2TeKUhKi+KoCRZm+Mh7YxD9aKt87IDmIJbW4P8mkTI3m7uGZ4QM = X-Received: by 2002:a05:6102:8615:10b0:778:721:53db with SMTP id ada2fe7eead31-77807215556mr452963137.0.1787134111267; Wed, 19 Aug 2026 03:08:31 -0700 (PDT) MIME-Version: 1.0 References: <87cxw43fht.fsf@alyssa.is> In-Reply-To: From: =?UTF-8?Q?Vaida_Plankyt=C4=97?= Date: Wed, 19 Aug 2026 11:07:54 +0100 X-Gm-Features: AcwNN1UCKhbv_pJO5UpaHyYV0zTN4NhQwSd-bDe6ytHIZGgCw93wgV34DfZFtGg Message-ID: Subject: Re: UX: Initial use cases & actions To: Alyssa Ross Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: FCJOEH3TNRDNIUWIYBTBXZ7KWFTJZVMB X-Message-ID-Hash: FCJOEH3TNRDNIUWIYBTBXZ7KWFTJZVMB X-MailFrom: vaidaplankyte@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.10 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Aug 5, 2026 at 5:07=E2=80=AFPM Alyssa Ross wrote: > > Vaida Plankyt=C4=97 writes: > > > On Thu, Jul 30, 2026 at 12:04=E2=80=AFPM Alyssa Ross wro= te: > >> > >> Vaida Plankyt=C4=97 writes: > > Regarding default actions: > > > > It seems use cases where you'd want to primarily use a persistent or a > > non-persistent VM are both equally likely. We could allow for a user > > setting on a persistent VM that determines whether the persistent > > version, or a non-persistent new instance based on it, are launched by > > default; both actions would still be available as secondary actions > > (i.e. right-click options menu). This would be convenient and avoid > > users that almost always want a non-persistent to not have to always > > right-click to access the option on a persistent. The downside is in > > having different default behaviour across VMs, but if we visually > > distinguish well between different types, then maybe having a default > > behaviour dictated by the user for that instance's use case is less > > risky? > > > > We could also ensure sensible defaults for this. Making persistent VMs > > start with this setting set to "launch a non-persistent instance", if > > we feel this would be safer than the other way around? Cognitively, > > having to go into the options menu to access the action of opening the > > persistent instance itself rather than it being the default action > > isn't too bad, as it's equivalent to "i'm editing the settings of a > > template". Users that want to always launch it as persistent can just > > switch it to the alternate behaviour. > > I wonder whether we might be able to have a UI that makes each option > equally convenient to use. I'm not sure how you'd do it with a > dock-like interface, but if you imagine a classic Windows Start menu: > > | Document Viewer | persistent | non-persistent | > | =E2=A4=B7 My configured Document Viewer | persistent | non-persistent | > | Signal | persistent | non-persistent | > | =E2=A4=B7 Signal (Alyssa Ross identity) | persistent | non-persistent | > > No additional clicks introduced by adding the persistent/not > differentiation, because we take advantage of two dimensions. What do > you think? Oh, that's a neat idea! I like that it groups apps based on their base app. Also, I know we discussed previously that if we take the "grouping shortcuts into folders" approach, users could neatly separate out different contexts (work/personal/etc)-- but if we supported some sort of tagging for apps, then users could filter the list of apps from this launcher instead, which seems much more slick. Perhaps each tag could be linked with a specific colour that also affects the window decoration, for additional differentiation? A slight difference between the two actions we'd want to ensure is clear is you'd be /opening/ the persistent app, but /creating and opening a new/ non-persistent app. It might be worth making that explicit in the action labels: "open persistent" and "new non-persistent" or such. Once an app is open and visible in the dock or pinned, we could still support the behaviour we've been discussing, for easy access. There's a related additional UC we had discussed: UC4: Duplication of a Persistent app, for separate persistent uses * AKA "I want to set up an app the way I want it, then duplicate it to configure two instances with different accounts", e.g. two Thunderbird accounts * "Duplicate" action on a Persistent app creates a copy as a Persistent app, treated as entirely separate * If we implement Persistent apps to have autosave, then duplicating an app before making complex changes is a way to back it up in case of mistakes * Potential addition: supporting duplicating a Non-Persistent app, if it's technically safe, easy to implement, and useful It doesn't seem like duplicate needs to be a top-level action the same way as "open persistent" and "new non-persistent" are (even though it technically is the more correct analogous action to "new non-persistent)? It could be relegated to a context menu, or we could explore having all three actions visible if we think it's likely to be used more regularly.