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 468B87D47; Thu, 27 Aug 2026 08:40:34 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 14D767D36; Thu, 27 Aug 2026 08:40:31 +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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) by atuin.qyliss.net (Postfix) with ESMTPS id 552EE7D33 for ; Thu, 27 Aug 2026 08:40:29 +0000 (UTC) Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id 2AB15EC024C; Thu, 27 Aug 2026 04:40:27 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Thu, 27 Aug 2026 04:40:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1787820027; x=1787906427; bh=h/DsF0/Rkc PHnS3ewRxmlXg6V4K+5PqaV4dyoAQ31x0=; b=Q/BuWaGDe0jVmGTOB6Cfmwt1+I DXyFubDwBrytycKVR1UiowJgYowIxcRBSefHP4nKA6S0PH7bRwfffVz7x7EsC+Dz lV4V/mZN0Y97jTcQ36pYH3lwuWVLrbeULnH/4qJYydnMHE+enQWqcWx3/YgHmRD/ lXYQi8qGHDQy53jjsHg4SL3KrK93iNXpjCmRSse5cSSwHW3We230oLsMvDAdXJwQ E0ivyc15u56X+nlYN1J7guEdIoCZFmghuskXkGU/LvX8g4b6EA92NX/VUDmCGPPM QNtbqnQftjktmdw8KomxaJUMqCSxteUh0Jx2aeD1kRIXXY2RxSipsFQlgVtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1787820027; x=1787906427; bh=h/DsF0/RkcPHnS3ewRxmlXg6V4K+5PqaV4d yoAQ31x0=; b=fG3WZ4LvAq1jgCwjQgiFJDqkAupeSx5BI2OPKOAQKoCMXsGW7fq 4WRh1trCVK9HsQ1sFXP60r2qxpIl7aindLxM/QjyZTwT7zhZo6DzMBm8fdL+gFhS U42AlZsw/p0h/rnCbW7jrgH7RCT0Uxyfj2QY3qbCF6uYmj0SIOLq1llW9s5eoeXI gDldl2L3s7N0Wvh1D4/+WKCEeRkal+1bXYHnCtd0uAYGGf9GiCkePMlsXVTYl2IQ bhKJ+RaDFTCijAB4FXXQ2WDNzZofV1zGlkEVaOZs6yBNiQacd6gn1PzXht9Nu3Sl 8PhsE3ybEM9kV8+B4pqve3wQVcBGwGjcFYA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGNDxmXkVLPVQzukGRcDzg4+WdBe+0oY7wMwqJ5SghtQGmWw4oBM6u+LNtex7rPMe Mqsh4J2ZmxQqoJE+XRzKTtwkscSUV5aEEjQecUp0VfZtrwjg7IsqF1G6LrJyCJPO+Be9uL Q5IXiD2cgfu6unvgIa1rXbfp8Go53ebuvOQ32PixAj5u+0i9WfPB/Eu3m+kKQkYhlbpwdK h5sBAUg5cVmfGdcwsJnbkGGyjuv49cdwaO//vjj7jclYT3bLQFAktKCLEBX3hmsItG8Cad O93UBvJljwT/kA9QznhTlcmXuuVPvBKuGmwxI9Yl2VGvWxJ9ji3B4+k3oY9OL70QMhkSS8 k9VuGPbt9+DBPQRDABvEaTc+OW8gq5yntLQLBlbmvBNrECxar9Hiu9M/BUFgLKTYbkx0ah qaikwUMHyicz+KrCMWbVnRqx+hXriMloaHiZiLhGGoONekE61Hp1MhyFO+557ChTOFOGOd I6nPI/eHmBGA21oCkSe4rokpfn9S6jjGwxZkf6u6ODQD2ku9tJDra2Vj4SR8ZTxZAeA0uZ zBIHO/qeZG6T706T8jnjntBi1QUNb5bW9GMsvwIn9+9zZgVHqpHHcfq1kTkkDu4E2Z9qVa ruNLctcWWoLrHbc4mDmGjg3yXo/P7VJJYZnX2gXDoVennwY8Camu4/a9RnUA X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Aug 2026 04:40:26 -0400 (EDT) Received: by fw12.qyliss.net (Postfix, from userid 1000) id 05EF4C81EDC0; Thu, 27 Aug 2026 10:40:24 +0200 (CEST) From: Alyssa Ross To: Vaida =?utf-8?Q?Plankyt=C4=97?= Subject: Re: UX: Initial use cases & actions In-Reply-To: References: <87cxw43fht.fsf@alyssa.is> Date: Thu, 27 Aug 2026 10:40:22 +0200 Message-ID: <87qzjk7y89.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Message-ID-Hash: Z6BHPEOVJX4CT2NBM4SGP3RJA3QZIGJR X-Message-ID-Hash: Z6BHPEOVJX4CT2NBM4SGP3RJA3QZIGJR X-MailFrom: hi@alyssa.is 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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vaida Plankyt=C4=97 writes: > 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 wr= ote: >> >> >> >> 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? Can you go into a bit more detail? It sounds good but I'm having a hard time picturing it. > 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. The folder behaviour? Yeah, that's true. No reason we can't have a folders of instances in the dock, _and_ a tabular launcher like this. > 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. Yeah, I don't think it would be used often. Would be fine to do it by right-clicking the dock icon or window decorations or something. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQGoGac7QfI+H5ZtFCZddwkt31pFQUCao/39gAKCRCZddwkt31p FdWMAQDObMCHMQN/ot3cF1xXgZPfez+OpjTmcn69gmCO3gYJQwEAmzci0kGMw4CU tSjrHbYxqNakRztfDuI+JZUuqo514AY= =HxjW -----END PGP SIGNATURE----- --=-=-=--