Couldn't we teach each Swoosh how to have its own set of favorites,
recents etc, but also how to inherit the "standard" or "default" set?
Then a Swoosh could be either an Activity or a Virtual Desktop.
Nate
On 07/17/2018 07:03 AM, Ivan Čukić wrote:
UI-wise:
We currently (let's pretend) have two options for the users (I've
replaced the terms activity and VD with 'swoosh' inspired by the
former Mozilla problem):
- have multiple swooshes where favourites, recents etc. are shared
- have multiple swooshes where favorties, recents are per-swoosh
Marco's proposal, for the sake of simplicity, wants to
- have multiple swooshes where favourits, recents etc. are per-swoosh,
just prettier
What's the benefit then? How would the concept be made clearer by this change?
Even pretending we have just two cases (since everyone thinks that the
group C does not exist), the proposed solution just erases one of
them.
I don't think that a bad implementation of something in kwin that was
created by a former Plasma developer and that none of us want to touch
is a good enough reason for removing a group of users.
I really don't see this as a concept simplification. Especially since
we tried to make no VDs, only activities to be the default. If the aim is
to force the users to use activities because they are cool, I think
we need a different aim.
If the problem is only that switching activities is not pleasant - no
desktop effects, etc. this is IMO the wrong way to tackle it.
Implementation-wise
In Plasma 5, KAMD is the only entity that manages activities for a
reason. We have had so many problems in Plasma 4 when Plasma wanted to
do the same thing that KAMD does. Just remember the 'let's create a
new activity for every user login' bug that we had.
Having KWin control the activities, while KAMD is managing activities
is a *bad* idea.
Cheers,
Ivan
