Virtual Desktop and Activities future: Tree proposal

[Roman Gilg]

The solution aims at providing all functionality today with Activities
and VDs, but extents and generalizes the concept by looking at them as
nodes of a tree structure, which can be freely traversed and
manipulated by the user.

Would not lead to lost functionality and would provide in theory a
massively more generic system of work organisation, but would be a
large change. Also while it could be a huge success, it could also
happen that a deeper tree structure in the end is needed by only very
few people (compare with example use case below).

-----------
Motivation:
-----------
The idea is to keep the two different concepts of VDs and Activities,
and expand upon this by defining them as nodes of a tree structure.

--------------------------
Terminology / Definitions:
--------------------------
Work container:
A set of graphical surfaces and additional data.

Activity Tree:
Tree structure with work containers as nodes.

Virtual Desktop (VD):
A leaf of the Activity tree. Defines a full screen area to be
displayed at a certain point in time. For simplicity we assume full
screen means stretched over all phyisical screens.

Activity:
A node of the Activity tree with height 1 (all its children are VDs).

Active/activated work container:
The work container currently being presented to the user.

--------
Remarks:
--------
* The term work container could be replaced with Activity and Activity
not name only nodes with height 1. I have just used given it a
different name here to make it easily comparable with the current
concept, because:
* In case the tree consists of only VDs and Activities, it represents
the current Activity and VD model.
* A VD can become an Activity by adding children. An Activity can
become a VD by removing all its children. An Activity becomes an
abstract work container with height 2 if one of its VD children
becomes an Activity.
* There can be arbitrary many work containers, but there has to be at least one.
* An Activity has at least one child.
* VD count is in {1, inf)
* Activity count is in {0, VD count}.
* In our simple case: there can only be ever one VD displayed in full
screen at the same time.
* For every physical screen there must be at every point in time in
each Activity exactly one active VD covering it (in our special case
of full screen meaning stretched over all physical screens this is
obviously fulfilled).

--------
Example:
--------
User A is a project manager by trade and begins a job at a new
company. She receives a company laptop for her new job, whch she can
also use at home. Therefore on the first day she creates expclitiy two
Activities "Job" and "Home" to separate job stuff from her free time
activities. For her work she needed in the past often to interact with
multiple applications, so she creates a second VD in the Job activity.
At home she normally only uses the laptop for casual surfing, so she
doesn't change the default VD count of 1 for the Home Activity.

The next day she gets informed that she has to manage projects alpha,
beta, gamma. For each of these projects she creates an Activity alpha,
beta, gamma in the Job work container (by doing that "Job" is no
longer an Activity in the above sense but is only an abstract work
container any more).

In the next week she realizes that project alpha is a rather huge
project and she can identify two subprojects xi, tau of alpha. She
puts all xi related stuff on the first VD and all tau related stuff on
the second VD in the alpha Activity. Through an ui she can now promote
these VDs to become Activities through giving a name to the VD.
Automatically for each of these new Activities two VDs are created as
their leafs.

-----------------------------
KWin/KWayland implementation:
-----------------------------
General:
* Knows about work containers together with the complete tree
structure of all of them.
* Broadcasts the current tree structure on change (and on bind through
client) to clients.

Switching:
* KWin switches the active work container, i.e. the work container
currently presented.
* KWin gets told by workspace which work container it should switch to
or via Keyboard shortcut and/or effects internally.
* Broadcasts the currently active work container on switch/bind.

Tree structure:
* Work container objects have a link to their parent container, that
is set by workspace.
* There is one special work container, the root work container being
at the tree root node. It always exists and can't be changed by
workspace.
* A work container without a link set is not valid, unless it's the
root work container.

---------------------------------
kactivitymanagerd implementation:
---------------------------------
* Listens for tree and active work container changes.
* Initiates work container switches by sending a request to change
active work container (this could be proxied by libtaksmanager).

------------------------------
libtaskmanager implementation:
------------------------------
* Listens for tree and active work container changes.
* Can tell KWin which work container to activate.

-----------------
User interaction:
-----------------
* VDs/leafs are depicted like before in full screen.
* Activities and abstract work containers have to be presented in an
overview. Interaction patterns have to be determined.
* Overview must allow the user to traverse horizontally and vertically
in the tree.

-------------------
Questions/Problems:
-------------------
* Can a work container with children still hold surfaces and data on
its own, which are not associated with one of its children?
* Having the complete Activity tree in the compositor is not nice. Can
we have only the the current child tree, work container with children
or work container alone in the compositor?