https://bugs.kde.org/show_bug.cgi?id=458924

            Bug ID: 458924
           Summary: Clarify respective responsibilities of activities and
                    virtual desktops
           Product: kactivitymanagerd
           Version: unspecified
          Platform: Other
                OS: All
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: general
          Assignee: ivan.cu...@kde.org
          Reporter: aldo-pub...@laposte.net
                CC: plasma-b...@kde.org
  Target Milestone: ---

TL;DR: Plasma does not need both virtual desktops and activities (as a more
evolved alternative). Instead both concepts should have clearly defined and
separate roles: desktops for window management and activities for semantic
desktop (only). In this setting, it should be possible to semantically
associate a virtual desktop to an activity (as you would associate a document).

First, I would like to apologize, as I do not know whether here is the place to
make such an elaborate suggestion, but I do not really know where to start
either... (probably I should directly discuss with whichever developer is
currently interested in this part of plasma, but I am not familiar enough with
the project... ). Also maybe this issue should not be reported to
kactivitymanagerd component, as it is a transversal one (please feel free to
move it to wherever it should be discussed!).

So I believe current situation with respect to activities and virtual desktop
is less than ideal (anyway I am not very satisfied!).

On one side, we have virtual desktops:

- old concept, shared by many X11 (and now Wayland) window managers
- each window has, in its properties, the desktop number it belongs to
- various apps from different desktop environments are desktop-aware in a
compatible way
- they are well supported in plasma/kwin, with nice switching effect and
convenient integration (window title bar context menu, task manager and virtual
desktop plamoid)
- but overall they are quite poor in features

On the other side, there are the plasma activities:

- like virtual desktops, they can contain windows...
- ... but they also contain associated documents and various stuff. Power
management is also activity aware.
- newer concept (although not that new now!)
- kde plasma-centric. Non-plasma apps are totally oblivious to the concept
(when you restore your firefox windows after it crashed or after you rebooted,
they all appear in current activity disregarding where the windows used to be
before, for instance).
- even kde stuff does not fully support activities everywhere it makes sense
(various reported issues)
- features similar to virtual desktops, needs to get re-implemented separately
(for instance the activity manager plasmoid, analogous to the desktop manager
plasmoid)... sadly often it is done in a less polished way (many kwin
animations for desktop switching, none for activity switching) or not at all
(kwin has many shortcuts for navigating desktops or presenting windows from
current desktop, but not their counterpart for activities).

While it appears activities were initially meant to replace virtual desktops,
after all these years, we are not yet at a stage where they can efficiently do
so. Even if many issues could be fixed, given some love, there would still
remain the main standing issue with the non-kde world.

As a consequence, if you want everything (full support and semantic desktop
features), currently you need to use both activities and virtual concepts.
Unfortunately, doing so does not resolve everything and it adds a useless layer
of complexity, which is hard to mentally adapt to. Also this adds constraints
that do not make sense semantically (such as being forced to use the same
number of desktops in each activity; or, if we look at it with the opposite
mental model, being forced to have the same activities on each desktop!).

Moreover as long as plasma uses both concepts, many features need to be
duplicated which wastes a lot of developer time.

At this point, wouldn't the only reasonable thing to totally drop window
management from activities and only keep the semantic stuff?
What I have in mind is that an activity should not be a kind of virtual desktop
on steroids, but just container for :

- as it is already the case: documents, files, folders, tasks and some relevant
settings (e.g. power management settings)... and not windows!
- but also a set of virtual desktops (so that every virtual desktop is
associated to some activity)

When you switch to a desktop, you also automatically switch to the activity it
belongs to, hence:

- all the activity switching and window management features can be removed
(activity manager plasmoid, keyboard shortcuts) so that their (often more
polished) virtual desktop counterparts can be used instead;
- non-kde apps who know how to deal with virtual desktops (remembering where
they belong, for instance), also work smoothly with activities (activity
membership entails from virtual desktop membership).

Would that make sense?

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to