Couldn't we teach each Swoosh how to have its own set of favorites,=20
recents etc, but also how to inherit the "standard" or "default" set?=20
Then a Swoosh could be either an Activity or a Virtual Desktop.

Nate



On 07/17/2018 07:03 AM, Ivan =C4=8Cuki=C4=87 wrote:
> UI-wise:
>=20
> 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
>=20
> Marco's proposal, for the sake of simplicity, wants to
> - have multiple swooshes where favourits, recents etc. are per-swoosh,
> just prettier
>=20
> What's the benefit then? How would the concept be made clearer by this ch=
ange?
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> If the problem is only that switching activities is not pleasant - no
> desktop effects, etc. this is IMO the wrong way to tackle it.
>=20
>=20
> Implementation-wise
>=20
> 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.
>=20
> Having KWin control the activities, while KAMD is managing activities
> is a *bad* idea.
>=20
> Cheers,
> Ivan
>=20