Vaida Plankytė writes: > On Wed, Aug 5, 2026 at 5:07 PM Alyssa Ross wrote: >> >> Vaida Plankytė writes: >> >> > On Thu, Jul 30, 2026 at 12:04 PM Alyssa Ross wrote: >> >> >> >> Vaida Plankytė 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 | >> | ⤷ My configured Document Viewer | persistent | non-persistent | >> | Signal | persistent | non-persistent | >> | ⤷ 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.