ken300 thanks for stressing the need for consistency. The keyboard layout switcher is a part of the default desktop experience and a consistent system tray experience really makes the desktop feel more polished.

I don't switch keyboard layouts myself, so it would be great if someone who does could comment on the usability issues. Is it common to switch the keyboard layout with the mouse? Then the old approach is more convenient. But if everyone uses keyboard shortcuts to switch the layout, then a more inefficient mouse navigation doesn't matter.

Here's my perceived pros and cons for both approaches.

Popup on left-click
Pros:
- Consistency with the default system tray applets
- Place for more eye-candy or utility like the preview-functionality and a KCM-shortcut
- Mouse wheel can still be used for fast layout switching
Cons:
- Two clicks to change the layout instead of one
- Right-click menu becomes unnecessary because all functionality can be put in the popup

Switch layout on left-click
Pros:
- Doesn't change old behavior. Everything works as before
- More efficient, you can change layout with one click or by scrolling the mouse
- A layout list is provided in the right-click menu
Cons:
- Inconsistent with the default system tray applets
- Keyboard layout preview will be four clicks away (right click->configure (opens KCM)->choose layout-> click preview)

I think the choice boils down to consistency-efficiency tradeoffs, so it could go either way. I'm a little bit torn on which approach is better, now I'm slightly more in favor of the popup on left-click. I'm especially interested in input from you who switch keyboard layouts.

Edit: correcting terminology for SNI - system tray applet

Thanks for the great overview. Perhaps we can add a third option that mixes both: left click = toggle, right = context menu with access to pop up (I would expect this behaviour for all those icons). If you want, we could run a short survey. Perhaps the majority of users decides for either efficiency or consistency.

The current implementation already fits quite well with the panel and scales gracefully. Thanks again kdeuserk for the mockups!





Heiko, doing a survey is a good idea, I'll see if I figure out how to do one

I feel that your proposed third option would only bring more inconsistency because now there's two ways to access the popup for systray icons.

I opened a poll https://forum.kde.org/viewtopic.php?f=285&t=122819.

Vote! Vote! Vote!

Edit: add more enthusiasm

myrjola wrote:The current implementation already fits quite well with the panel and scales gracefully. Thanks again kdeuserk for the mockups!

Great job, thanks for implementing this! Though the stroke width of the key shape fitted the old (5.0) system tray better, but I am really satisfied with the result!

It seems that this design has one drawback:




If we use wide letters like 'm' the text gets pretty much unreadable with the small panel sizes I prefer. Should we consider a fallback after the text size falls below a certain font size? Or maybe I should just invest in a hidpi display

In the second picture the rectangle is also smaller than the other icons, I should also fix that before release.

myrjola wrote:It seems that this design has one drawback:




If we use wide letters like 'm' the text gets pretty much unreadable with the small panel sizes I prefer. Should we consider a fallback after the text size falls below a certain font size? Or maybe I should just invest in a hidpi display

If the font size can't be scaled individually try to adjust the font size to the width of the widest letters, so that it looks okay. Removing the key frame will yield to an even more unbalanced look.

Probably better solution: Simply print all strings in capital letters:



SVG: https://drive.google.com/uc?export=down ... zhBc0pSVlU

From the ratio capital letters seem to be generally more suitable, but additionally scaling up the font considering the ratio of an individual string would be the optimal solution, since you can see the "FI" looks much smaller, despite the same font size.

EDIT: sorry for the mouse pointer in one of the mockups, but I am too lazy to correct it.

myrjola wrote:Popup on left-click
Pros:
- Consistency with the default SNIs

No it isn't, Status Notifier Items never show a popup on left click.

Maybe we're may be mixing terminologies. SNIs are generated items icons in the sys-tray that communicate representation and interaction to another application over DBus.
http://www.freedesktop.org/wiki/Specifi ... ifierItem/. Applets are the ones (usually) with popups.

The system tray is a mix of applets and SNIs. It's mostly (deliberately) impossible to tell which is which.

Also we will continue to have a mix (Skype, new message in KTp, new item in Akregator, any SNI or legacy QSystemTray icon). It's /impossible/ to make all of them all behave the same as the plasmoids.

When implementing this, please remember to get rid of the following options in the keyboard layout KCM:
- Show flag
- Show label
- Show label on flag

As it's now always "Show label", all of them should be removed.
A kconf update to ensure the corresponding setting is dropped from config files might make sense.

david_edmundson wrote:

myrjola wrote:Popup on left-click
Pros:
- Consistency with the default SNIs

No it isn't, Status Notifier Items never show a popup on left click.

Maybe we're may be mixing terminologies. SNIs are generated items icons in the sys-tray that communicate representation and interaction to another application over DBus.
http://www.freedesktop.org/wiki/Specifi ... ifierItem/. Applets are the ones (usually) with popups.

The system tray is a mix of applets and SNIs. It's mostly (deliberately) impossible to tell which is which.

Also we will continue to have a mix (Skype, new message in KTp, new item in Akregator, any SNI or legacy QSystemTray icon). It's /impossible/ to make all of them all behave the same as the plasmoids.

Thanks for clarifying David! I have used the wrong terminology. As it turns out almost all the items that sit in the system tray in a fresh plasma5 session are applets, I'm speaking of the device notifier, clipboard, power management and media player. All of those have popups, so I think the point of consistency still stands as the new layout switcher also is an applet.

It looks like the vote is already going this way, but I thought I'd pop-in with my two cents anyway to put some feedback to my vote;

Switching keyboard layouts on left click would be a completely silent operation triggered by the mouse, which affects the keyboard. If a user was unaware they accidentally clicked on the indicator, or forgot that they had, they might begin typing only to realize they were working with the wrong layout. With having the popup triggered, it's a subtle method of confirming their action; they do need to click their specific layout they desire or cancel the operation. If the user is concerned about having a hyper-efficient desktop, then binding a hotkey to set languages would be the way to go - as they would never need to leave the keyboard.

On another note; The keyboard layout design is absolutely wonderful, and I love the functionality touch of having the 'type to test' box. I kind of gimaced when I saw the starting point thinking "where the devil could it go?"; excellent work adding the perfect balance of functionality and flair.

Switching keyboard layouts on left click would be a completely silent operation triggered by the mouse

There's a massive OSD.

david_edmundson wrote:

Switching keyboard layouts on left click would be a completely silent operation triggered by the mouse

There's a massive OSD.

I'll admit I don't use the widget - I'm locked into US keyboard layouts - but is there an actual on-screen notification (a la when the volume changes) when the button is clicked? Or is it just the widget indicator itself? I apologise if I was completely wrong in that statement.

Anyway, I guess my main thought is that if changing the keyboard layout is a more cognitive process then the user will be less likely to pass over a mistaken click, and be more likely to remember they changed the layout if they had done it right before leaving the table.

Kver wrote:

david_edmundson wrote:

Switching keyboard layouts on left click would be a completely silent operation triggered by the mouse

There's a massive OSD.

I'll admit I don't use the widget - I'm locked into US keyboard layouts - but is there an actual on-screen notification (a la when the volume changes) when the button is clicked?

Plasma developers sometimes forget that not everybody outside of Plasma may know what "OSD" means . OSD = On-Screen Display, so yes, those are the things that show up right in the middle of the screen e.g. when volume or screen brightness is changed.

colomar wrote:Plasma developers sometimes forget that not everybody outside of Plasma may know what "OSD" means . OSD = On-Screen Display, so yes, those are the things that show up right in the middle of the screen e.g. when volume or screen brightness is changed.

Welp, I've embarrassed myself. Time to leave and never come back again.

Anyway, glad to understand the feedback mechanisms; Either way, for consistency' sake it appears like the poll is landsliding to click->popup, which for the most part seems like the standard mechanism for these sorts of things. From what I understand the switcher worked the other way before (click changes the language); but I don't think the behaviour change would be disruptive, as the options would become immediately apparent once the popup is sprung anyway.