Security / Usability: Enable "contexts" in the interface for task panel, system tray, etc

[t4777sd]

Proposals
Enable the ability to define "Contexts". A context, when selected, will filter the view of the "start menu" (application list), task bar, visible windows, and system tray. So, for example, the "work" context will be comprised of the "work" domain (possible to select more than one domains for this context) and "personal" context will be comprised of the "personal" domain

In the top-panel there will be a widget. In this widget it says the current context such as ALL (default current behavior) or "work". Clicking this will let the user select a context such as "work".

When this context is selected all windows, system trays, applications in the start menu, are hidden from view (filtered) if they do not belong to a domain in the "work" context.

Another way to think of Contexts is an extension of Workplaces (though that is only for windows not system tray, etc).

Rationale

Qubes includes lots of features to reduce user error. For example, it's not super easy to copy / paste between domains. Same with transferring files, etc. This ensures that users do not make accidental mistakes and compromise domains.

One area severely lacking is normal user input. For example, having both "work" and "personal" domain open at the same time (firefox). Having inspiration to search something, absently clicking the first firefox, and searching. Ooops, my personal thoughts were just searched in the "work" firefox (which may go over a proxy to a cororate network, etc).

Contexts prevents users from making these mistakes. It also cleans up the UI as almost 100% of the time most people don't need to see the "personal" file manager open while they are doing a task interacting with "work".

Another similar example would be an anonymous whonix browser and a normal brownser. Having them both visible at the same time creates a lot of potential for user error. A contexting solution would solve it.

What Needs to Modified To Implement

The primary modification for this is in the widgets that are in the panel-bar. That includes

• Application menu (whisker, standard app menu, etc)
• System Tray

In addition, there will need to be the creation of another very simple widget that just is a drop down selector:

• Context Switcher

The following likely do not need to modified but they are important to the proposal:

• Windows List (listing open window)
• Workspace Switcher (switching between groups of open windows)

It appears the window list already has the ability to show / hide and this also affect windows displayed via things like ALT-Tab.

This can be done by changing the windows "skip taskbar" or "skip pager" settings. The system tray may also have a similar mechanism implemented.

[airelemental]

You can implement the hiding of irrelevant windows by using devilspie2 to assign windows to workspaces according to their VM. For example, all windows in the personal VM open in the "personal" workspace, all windows from work VM open in the "work" workspace.

(In your devilspie2 script, you can find a window's VM by doing get_window_property("_QUBES_VMNAME")).

XFCE also allows setting a different wallpaper for each workspace, to remind you of context.

[airelemental]

You can implement the hiding of irrelevant windows by using devilspie2 to assign windows to workspaces according to their VM. For example, all windows in the personal VM open in the "personal" workspace, all windows from work VM open in the "work" workspace.

(In your devilspie2 script, you can find a window's VM by doing get_window_property("_QUBES_VMNAME")).

XFCE also allows setting a different wallpaper for each workspace, to remind you of context.

[unman]

Almost everything here can also be implemented in KDE using the somewhat neglected Activities feature.
You can configure the system to switch activities automatically when launching or switching qubes, colour code desktops, have different shortcuts and widgets per activity.
What you cant do (I think) is change system tray and menu per Activity - and in any case, that is not a good idea. Whatever Activity I may be doing I may want to check disk space, network etc. I may want to start a "personal" qube while looking at "work", etc etc. I dont see that your proposal for those features would help to reduce user error, and implementing them would make the system less convenient to use.

[unman]

Almost everything here can also be implemented in KDE using the somewhat neglected Activities feature.
You can configure the system to switch activities automatically when launching or switching qubes, colour code desktops, have different shortcuts and widgets per activity.
What you cant do (I think) is change system tray and menu per Activity - and in any case, that is not a good idea. Whatever Activity I may be doing I may want to check disk space, network etc. I may want to start a "personal" qube while looking at "work", etc etc. I dont see that your proposal for those features would help to reduce user error, and implementing them would make the system less convenient to use.

[t4777sd]

@unman under my proposal you would assign the relevant domains to the contexts. So, if you wanted whatever domain that provided a disk space system tray / menu item inside of "work" you would simply assign it to the "work" context. You could assign that specific domain to all contexts if you wanted (such as dom0).

Or, alternatively, in the context switcher simply switch to "ALL" which would provide the unfiltered view that exists now. for those special times you did not want to be in a context or when contexts created more friction than it helps solve. Keep in mind, "ALL" is the default. A user would have to specifically select a context if they wanted to be in it.

To start a personal item while in the work context would mean to go to the personal context. In the same way you must change positions when switching from playing the piano to the drums. It requires a context shift. If, for whatever reasons, a user found that annoying they would either create a melded context that included both work/personal domains or they would not drill-down into a context and instead conduct all their activity in the ALL context, which is the default view of the current Qubes desktop.

Basically, the idea of the proposal is to simply modify the panel-bar widgets to filter based on the program attributes (the domain it belongs). This is to reduce user-error when running multiple domains and also to reduce the friction of the interface. As, more often than not, all apps do not need to be visible when in different contexts.

In the interim though the devilspie2 pointed out by @airelemental will at least solve the window grouping issue even though it seems a bit cumbersome.

[t4777sd]

@unman under my proposal you would assign the relevant domains to the contexts. So, if you wanted whatever domain that provided a disk space system tray / menu item inside of "work" you would simply assign it to the "work" context. You could assign that specific domain to all contexts if you wanted (such as dom0).

Or, alternatively, in the context switcher simply switch to "ALL" which would provide the unfiltered view that exists now. for those special times you did not want to be in a context or when contexts created more friction than it helps solve. Keep in mind, "ALL" is the default. A user would have to specifically select a context if they wanted to be in it.

To start a personal item while in the work context would mean to go to the personal context. In the same way you must change positions when switching from playing the piano to the drums. It requires a context shift. If, for whatever reasons, a user found that annoying they would either create a melded context that included both work/personal domains or they would not drill-down into a context and instead conduct all their activity in the ALL context, which is the default view of the current Qubes desktop.

Basically, the idea of the proposal is to simply modify the panel-bar widgets to filter based on the program attributes (the domain it belongs). This is to reduce user-error when running multiple domains and also to reduce the friction of the interface. As, more often than not, all apps do not need to be visible when in different contexts.

In the interim though the devilspie2 pointed out by @airelemental will at least solve the window grouping issue even though it seems a bit cumbersome.

[unman]

@t4777sd Give KDE activities a try - it's straightforward and may address the issues that concern you without being cumbersome.
Personally, I'd find it annoying to switch contexts before starting items. I use keyboard shortcuts to open qubes or run applications, and it's handy to be able to start up and run programs with minimal impact on my current workspace. When I'm ready I can cycle activities.

[unman]

@t4777sd Give KDE activities a try - it's straightforward and may address the issues that concern you without being cumbersome.
Personally, I'd find it annoying to switch contexts before starting items. I use keyboard shortcuts to open qubes or run applications, and it's handy to be able to start up and run programs with minimal impact on my current workspace. When I'm ready I can cycle activities.