Discussion for Virtual Desktops and Activities future
Nate Graham
nate at kde.org
Tue Jul 17 14:36:59 BST 2018
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
>
More information about the Plasma-devel
mailing list