Bug 460125 - Allow Plasmoids to define toggle actions that will be displayed interactively in the expanded view
Summary: Allow Plasmoids to define toggle actions that will be displayed interactively...
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: System Tray (show other bugs)
Version: master
Platform: Other Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-08 15:47 UTC by tantalising
Modified: 2024-08-10 10:16 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
split button (7.59 KB, image/png)
2022-10-08 15:47 UTC, tantalising
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tantalising 2022-10-08 15:47:11 UTC
Created attachment 152646 [details]
split button

SUMMARY
Improvements for system tray.


DETAILS

The system tray currently is not very useful for things that can be turned on and off.
Sometimes the user wants to just quickly change things and turn things on and off.
First I will give an example of why current approach is insufficient.

Take for example the bluetooth. To turn it on, we need three clicks currently.
One to enter the tray, one to reach the full representation and one to activate it.
Maybe one more to close the tray.

This can definitely be improved if we let the user just click it to toggle it on or off.

Now here's some faq that I thing should be useful to readers.

1. How do I access the full view? No this is just insane, this is blah blah ...

Ans: The current design reflects that this fact was taken into consideration and
that's why the default action is to take you to the full view. But think again. This
is the reason we can't peacefully toggle things on and off. This can be solved. Not
by redirecting you to a second page and annoying you by demanding a show of your click
skill. A new representation has to be created for this. Let's call this split button
since anyway the compact view does look like buttons. The split button has two regions
divided by a divider or anything you want. The left side let you click and toggle things
on and off and the right side takes you to the full representation. This fixes both
the issues of toggling and accessing the full view.

2. What about things that can't toggled ? like power settings? Haha got you.

Ans: Anything can be toggled if you have enough imagination. I admit there are
some items that aren't suitable for toggling. The solution is rather easy.
We don't represent them using the split button. They take you directly to the
full view. Though I would like to stress that many things that look like there
is no on and off state, actually have an on and off state. Let's take some
examples:

    i. The power settings compact view can be made to show an item or text for performance mode. It
        will switch to power saving mode once we click it. The full view is
        still there to let you do more advanced things and also so that non-power
        users are not bothered by making all things only in the full view.

    ii. The vault can have two states. Locked and unlocked. This will be very convenient
        since that is what is to be done most of the time once a vault is created.
        (unrelated side note: vault is still buggy)


3. There's already the middle click to toggle things. What about that? You just don't know enough.

    Ans: I know about that terrible hack. Yes that's right. We users expect to do things with
    straightforward manners. Toggling things is something will be used frequently. assigning something
    like middle click that is only used by mostly power users is neither good nor very obvious.
    Certainly middle click does things that are somewhat advanced and should not be used carelessly
    anywhere. Make it do something useful. The middle click here does not make sense. It is here
    because the current design could not accommodate for a quick toggle. The split button solves this,
    is far more better, highly visible and to the point.

4. But there are really something that can't be toggled here. You know about lock keys status? Lol.

Ans: I would like to ask what an lock keys status doing here in the system tray. They are indicators.
They should only appear in the panel to show some status but should neither have a compact representation
nor have a full representation. If you disagree, that's fine. It won't be terrible to keep it in the
expanded tray, but it does not pose any threat to the split button idea. It won't just have a split representation
and will just stare at you.

5. You are suggesting too much changes.

Ans: I am just elaborating my concerns. The changes suggested by me here are really small. Give us the split
representation and let us use that to toggle things that are togglable. Everything else remains same.
Every thing! You can use the tray the way you used. No drastic change. You still can access the split
view the same way. My suggestion adds to the current design, and does not change it.


Now Let's talk about one more issue that can be solved as well and it's best to talk about it here.
The system tray has a specific behaviour that is just too frustrating. Let's again talk about bluetooth.
When you want to turn it on, you can get find it in the expanded tray. Once done it is now in the panel and
not anymore in the tray. There's nothing wrong in showing up in the panel. Actually that's great and let
you access the full view of it because it is now relevant. The problem is its disappearance from the expanded
view. It still should be there. We expect things to stay in the same place, not magically teleporting and
vanishing. Its staying is important because an user expects rightfully that they can turn off something in the
same place where they turned it on. It's not nice to move things around and make the user play hide and seek.

This suggestion again may attract some concerns, so let just address them.

1. This is totally wrong thing to do. Why would I want to access the same thing in the panel and also in the
    tray? This results in duplication of controls.

    Ans: You are not actually accessing the same thing! The panel one let you access the full view while the
    tray one let you access the compact view and optionally let you turn it off. It is really important to
    make controls static. People have full rights to find the things where they initially accessed them. This
    is ux wise really bad not to let them have that.

2. If we keep showing them in the expanded tray always, then there will not be enough space for everybody.

Ans: Not really. In my tray I still have enough space left and I am almost sure this is the case for others
as well. If we really make the tray full then that's not something to lose someone's mind over. This is a very
standard problem and has standard solutions. We can show the overflowing items in a different page. Like one
used in app menus. We can also make that area scrollable which is even nicer. Truth be told, the current plasma
pop ups are pathetically small. Anyway we don't still need to worry about overflowing items since it is
not going to happen.

I strongly believe that these suggestions will improve the experience and certainly will address the current
chaotic and dynamic state of the tray. This will centralize things and make users less guessing about where their controls
have gone. I hope they will get implemented and the sooner the better. Have a nice day!
Comment 1 Nate Graham 2022-10-10 17:41:43 UTC
So basically, for the small number of Plasmoids that do have a clear "turn me on or off" state, we split its button into two: a "toggle me" button and a "take me to the full view" button? That kind of makes sense and would seem to avoid most of the problems described in https://community.kde.org/Get_Involved/Design/Lessons_Learned#Why_not_a_Control_Center.3F.

I think it could be implemented a bit more simply than adding a whole new Representation type, though: we could add new metadata to Plasmoids to allow them to expose a toggle action at their root item, and if the System Tray sees that, it simply draws a new "toggle me" button in the corner of the item in the expanded view, or draws the button as a split button as you've described.

I could see this making sense for any Plasmoid where you can currently middle-click it to toggle something:
- Audio Volume (mute/unmute)
- Bluetooth (turn on/off)
- Media Player (pause/unpause)
- Notifications (enter/exit Do Not Disturb mode)

Essentially, we bubble up the middle-click functionality into a visible UI. And it might make sense to implement for a new that don't currently have middle-click-to-toggle-something functionality:
- Battery & Brightness (Manually inhibit/uninhibit sleep and screen locking; maybe a borderline case as I'm not sure how common this functionality is for people to actually use?)
- Networks (enter/exit Airplane Mode)

For the rest, no toggle action really makes sense IMO because the content is inherently geared towards displaying multiple things.

Regardless, all of this would give us two-click "toggle things" functionality as with a Control center, without losing the richness of the full views.
Comment 2 tantalising 2022-10-11 05:54:09 UTC
(In reply to Nate Graham from comment #1)
> So basically, for the small number of Plasmoids that do have a clear "turn
> me on or off" state, we split its button into two: a "toggle me" button and
> a "take me to the full view" button? That kind of makes sense and would seem
> to avoid most of the problems described in
> https://community.kde.org/Get_Involved/Design/
> Lessons_Learned#Why_not_a_Control_Center.3F.
> 
> I think it could be implemented a bit more simply than adding a whole new
> Representation type, though: we could add new metadata to Plasmoids to allow
> them to expose a toggle action at their root item, and if the System Tray
> sees that, it simply draws a new "toggle me" button in the corner of the
> item in the expanded view, or draws the button as a split button as you've
> described.
> 
> I could see this making sense for any Plasmoid where you can currently
> middle-click it to toggle something:
> - Audio Volume (mute/unmute)
> - Bluetooth (turn on/off)
> - Media Player (pause/unpause)
> - Notifications (enter/exit Do Not Disturb mode)
> 
> Essentially, we bubble up the middle-click functionality into a visible UI.
> And it might make sense to implement for a new that don't currently have
> middle-click-to-toggle-something functionality:
> - Battery & Brightness (Manually inhibit/uninhibit sleep and screen locking;
> maybe a borderline case as I'm not sure how common this functionality is for
> people to actually use?)
> - Networks (enter/exit Airplane Mode)
> 
> For the rest, no toggle action really makes sense IMO because the content is
> inherently geared towards displaying multiple things.
> 
> Regardless, all of this would give us two-click "toggle things"
> functionality as with a Control center, without losing the richness of the
> full views.

Thanks for understanding. I would like add two more things in the list of items that are togglable. The wifi and the hotspot. They are already in the networks applet but I think they should also be available as a dummy button in the expanded tray.  They both redirect you to the networks applet full representation when split button is pressed. It will hopefully make things more clear.  A power saving mode should also be helpful for laptop users.  The expanded view will have more fine tuned controls. Maybe we can now reconsider adding a brightness slider as well. At least in my desktop I don't have one and I need one when surrounding environment is too dark. 

I would also like to know your opinion about the static controls things. I think that is important. You can use the night color to see how it
keep changing places when done outside of automatic start up time.

The implementation of split view can be made more simple I think. What about the applet itself shows the split button in the compact representation? In that way an applet can do this whenever they want and it becomes really simple.