+1 overall

There's already several things in the system tray with a keyboard icon (all different keyboards! xD)

Maybe we could make something a bit more recognizable?

In D22535#497694, @apol wrote:

There's already several things in the system tray with a keyboard icon (all different keyboards! xD)
Maybe we could make something a bit more recognizable?

1. Keyboard layout: kimpanel/fcitx/ibus also provide keyborad layout as option, but I don't know if they are the same backend. In Windows/macOS, keyboard layout and IME are the same tray icon.
2. Keyboard indicator: can be a small icon over the keyboard icon.
3. Virtualkeyboard: kimpanel/fcitx/ibus also provide virtual keyboard, but it looks very old style .

In D22535#501839, @ngraham wrote:

• The settings window needs to actually offer a way to add and configure input methods. When I look at this very barebones settings window, I have no idea what to do:
  

That configuration is from kcm_fcitx module. I guess I can just plug it in here.

I have no idea what it is or where it comes from. ...Which is kind of my point: if you're going to put this in the System Tray, it needs to have a UI suitable for novice users and people who know nothing about input methods. :)

The configuration should be in System Settings, not in this applet, as they're system-global and override keyboard layout settings.

The 2018 GSoC work started to implement this and got far, and also made kimpanel replace the existing tray keyboard layout indicator in the process and update the OSD and all the other system parts to understand input methods and switch between then. We should look into leveraging at least the applet changes right now and merging them with this patch.

As for the conceptual change: It's a change I also suggested once, but was veto'd by the kimpanel maintainer at the time who was strongly of the opinion that every icon needs to be visible at all times. The discussion between him, me and @mart at the time was to spawn multiple SNIs and teach the tray to sort them together. I think this is workable but still advocate a single icon by default unless others are explicitly enabled.

To catch this up to the GSoC status:

https://medium.com/@mujjingun_23509/google-summer-of-code-porting-keyboard-kcm-to-qt-quick-part-2-30c115771722
https://medium.com/@mujjingun_23509/google-summer-of-code-porting-keyboard-kcm-to-qt-quick-part-2-30c115771722

Repo:

https://cgit.kde.org/clones/plasma-desktop/gpark/gsoc-kcm-keyboard-revamp.git/?h=new_keyboard_kcm

There were nice videos showing the improved kimpanel and the switching w/ OSD and KCM open and everything being in sync somewhere, too, but I can't find them off-hand.

To be clear: I'm not saying this patch is bad, but rather that we're in the fortunate position that it doesn't need to be pushed into slaying the configuration beast all alone as the above response did. It's not correct, and also not necessary because there's an existing body of work to leverage!

Between @gpark, @guoyunhe, me and others, the right thing to do is form a team to advance this together, and make this patch part of it. A good place to organize this effort can be around T11054. Please add yourself there @guoyunhe :)

Thanks @hein ! I will check the GSoC project and see if I can continue with that. I see the original author of Kimpanel is @xuetianweng . Let's listen to his opinion.

Here's a video demonstrating the GSoC project's results:

+1,000 for having you guys become the KDE "Input Method dream team". FWIW I am super supportive of T11054 and sincerely hope it gets chosen. It's critically important.

@gpark I am trying to pull all your changes into this patch. If I understand correctly, your work is in new_keyboard_kcm branch of repo https://cgit.kde.org/clones/plasma-desktop/gpark/gsoc-kcm-keyboard-revamp.git ?

I tried to merge @gpark 's branch. It is compiled but I cannot reproduce the UI as shown in demo video. I am not sure how it is connected. So I leave that part untouched for now. I hope I can get in touch with @gpark to understand how the code works. Then we can make another patch for KCM and OSD modules.

In this patch, I will only implement the system tray icon, context menu, and expanded widget. Keep it small. So I can make it with my very limited C++/Qt5/KF5 knowledge.

Did you delete the old KCM first? If not, it will take precedence and you won't see the new one. The old one is located in the following location:

• Ubuntu-based distros: [install prefix]/usr/lib/x86_64-linux-gnu/qt5/plugins/kcm_keyboard.so
• Other distros: [install prefix]/usr/lib/qt/plugins/kcm_keyboard.so

Regardless, I'm super excited to see @gpark's work get revived!

In D22535#509917, @ngraham wrote:

Did you delete the old KCM first? If not, it will take precedence and you won't see the new one. The old one is located in the following location:

• Ubuntu-based distros: [install prefix]/usr/lib/x86_64-linux-gnu/qt5/plugins/kcm_keyboard.so
• Other distros: [install prefix]/usr/lib/qt/plugins/kcm_keyboard.so
  
  Regardless, I'm super excited to see @gpark's work get revived!

No, I didn't know that. Thanks for the tip, will keep trying!

Making the layout of status panel:

Added context menu actions to configure keyboard and fcitx. @ngraham do we KCM of ibus or scim?

Uploaded latest code. It is unfinished. Just for anyone who may accidentally be interested.

What works:

1. Make the widget a system tray icon.
2. The system tray icon can show current input method.
3. Right click the system tray icon, context menu allow you to configure keyboard and input method (Fcitx).

What doesn't work:

1. Switch input method. ( @gpark 's work implemented that)
2. Switch fullwidth/halfwidth.
3. Switch punction.
4. Virtual keyboard.

The main difficulty I had is state jumping:

When you click the system tray icon, the text field loses focus. Then you are not configuring input method for that field anymore.

An idea for possible solution:

1. When you click the system tray icon, the state of KIMPanel will lock, remaining the state of your previous input field.
2. When you perform changes of input method, fullwidth, punction, etc., the change will not be performed immediately.
3. When you go back to input field, switching to the previous input method, the change will be applied.