Bug 366033

Summary:	Imrove The Activity Switcher user interaction
Product:	[Plasma] plasmashell	Reporter:	Michail Vourlakos <mvourlakos>
Component:	Activity Switcher sidebar	Assignee:	Ivan Čukić <ivan.cukic>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	plasma-bugs-null
Priority:	NOR
Version First Reported In:	5.7.2
Target Milestone:	1.0
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Michail Vourlakos 2016-07-24 12:15:23 UTC

In the current implementation  when the user activates an activity the activity switcher hides itself, there are some issues with this:
1) in this way it is very difficult for a user to walkthrough in its activited activities, he has to activate the next one and in order to go to another must open the activity switcher again
2) when the user closes its current activity the user is going in an activity who he hasnt selected to go
3) when the user activates a closed activity the closed activity is activited and the activity switcher hides itself even though the user may not want to work currently with that activity.

this approach is a little bit of an enforcement for the user to know every time exactly in what activity to work on.

I propose a little bit more aggresive approach which is similar to the widgets explorer one.
The widget explorer does not hide itself if the user does not decide to close it from its close button.

For the activity switcher a better approach I think is the mouse hovering. If the mouse is inside the activity switcher then the activity switcher is not hiding until ther user leaces the activity switcher. I think this would make much easier to use the activity switcher and activities as a consequence.

regards,
michail

 

Reproducible: Always

Comment 1 Michail Vourlakos 2016-07-24 12:17:46 UTC

*fix: the activity switcher is not hiding until ther user leaves  from the activity switcher

Comment 2 Ivan Čukić 2016-07-24 14:33:28 UTC

Hi Michail,

The activity switcher is designed to work like a switcher (window switcher for example - alt+tab, present windows...) and not like a browser (widget explorer).

This was discussed a few times now, and the consensus was that the main use-case is that the user knows which activity to switch to. That is where all the design issues came from.

It would be possible to have an alternative switcher that behaves like you'd want, but this is not likely to change in the default one.

Comment 3 Michail Vourlakos 2016-07-24 14:41:15 UTC

Hello Ivan,

I see... So this is based in the fact tha the user would use Meta+Tab something to switch between activities and not use the mouse... I see...

How would it be possible to have and alternative one, Ivan ? From where should I start from coding point of view?

thanks again,
michail

Comment 4 Ivan Čukić 2016-07-25 07:55:07 UTC

> So this is based in the fact tha the user would use Meta+Tab something to switch between
> activities and not use the mouse... I see... 

Not only that. The present windows kwin effect is used with a mouse - you get an overview of all windows, you know which one to switch to, and you select it. That window gets focus and you exit the present windows effect.

You can use QML or QWidgets, whichever you are more comfortable with. If you are using QWidgets, you can use the KActivities::ActivitiesModel class to show activities in a QListView or something like that (you would probably need to pass it through a sorting proxy model to order them by name), while for QML you have also the option to use ActivitySwitcher.Backend.runningActivitiesModel() which is used in the regular switcher.

You can find the QML part of the code of the normal switcher in plasma-desktop/desktoppackage/contents/activitymanager