Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KeyboardLayoutApplet: does not show all layouts #1785

Closed
baraclese opened this issue Mar 29, 2019 · 11 comments
Closed

KeyboardLayoutApplet: does not show all layouts #1785

baraclese opened this issue Mar 29, 2019 · 11 comments

Comments

@baraclese
Copy link

With the latest gnome stack on arch linux the keyboard layout applet does not show the layout "Japanese (Kana Kanji)" but I can still switch to it and use it via win+space.

Budgie version

budgie-desktop 10.5 (git-38b69f05619f0b1a681276dc258929f2fcb7a750)

Operating system

Arch Linux

Description

Adding the language "Japanese (Kana Kanji)" in the Gnome Control Panel (Region & Language) results in these messages:

budgie-panel[2007]: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
budgie-panel[2007]: KeyboardLayoutApplet.vala:428: Error adding source ibus|kkc: Unknown input method: id
budgie-wm[6379]: Couldn't upload new XKB keyboard description

Selecting the language via the keyboard shortcut results in:
budgie-panel[2007]: KeyboardLayoutApplet.vala:486: WARNING: Missing child in layout!!

@tista500
Copy link

tista500 commented Apr 13, 2019

Same issue +1 (Ubuntu Disco, IBus 1.5.19 built with Vala 0.44.x).

This may or may not be related to IBus change? : ibus/ibus@4d7c1e0

@fossfreedom,

I know you're extremely busy for testing Disco Budgie currently, but if you had time to check IBus in Disco, please concern the Vala and IBus upstream changes, too...

Regards.

EDIT
Remove 2 diffs (no sense).

@tista500
Copy link

I'm sorry I was wrong... :(
Reverting to IBus packages build with legacy Vala was the way as an only workaround?

@tista500
Copy link

These diffs make sense? : https://paste.ubuntu.com/p/fbM69vznkf/

@fossfreedom
Copy link
Contributor

fossfreedom commented Apr 14, 2019 via email

@tista500
Copy link

I have added English US to my English GB via Language & Region settings on 19.04 and I see both layouts to be selected in the keyboard layout applet.

Original reporter and me are talking about IM engine instead of keyboard layout, then Original reporter uses IBus-kkc engine:

  • Install Japanese IBus-kkc engine: sudo apt install ibus-kkc
  • Logout and logback in to restart IBus daemon (or simply run ibus-daemon -rd?)
  • Add ibus-kkc engine via G-C-C like this ("Japanese (Kana Kanji)" is ibus-kkc engine) :
    Screenshot from 2019-04-15 00-04-49
    And gsettings key org.gnome.desktop.input-sources sources should be like this: [('xkb', 'us'), ('ibus', 'kkc')]
  • Check and verify the ibus-kkc was shown in KeyboardLayoutApplet popover's layout list and applet tuned to "JA" from "US" when switched input-sources to ibus-kkc:
    Screenshot from 2019-04-15 00-14-09

Regards.

@fossfreedom
Copy link
Contributor

ack - can reproduce - it also crashed budgie-wm ibus_engine_desc_get_layout_variant.

will try to have a look at your patch and also the above to see why the crash happens - busy with 19.04 release matters though....

@fossfreedom
Copy link
Contributor

fossfreedom commented Apr 18, 2019

ok - I don't fully understand the valac changes that is causing this - but it appears to be variable scope changes.

attached is a diff for the mutter330reduxII branch (i.e. you can apply it on the source for 19.04 UB) that at first glance seems to resolve this matter + fixes the crash in budgie-wm when creating non xkb layouts.

Really need to understand why the scope changes causes this issue and if there is a cleaner way to resolve before doing a formal PR

Note - I've slightly rejigged the src/wm/ibus.vala to be consistent with src/applets/keyboard-layout/KeyboardLayoutApplet.vala - there is comments in the code from Ikey that the code is naughtily copy-pasted between the two modules ... but seems to have got out of sync at some-point.

output.diff.txt

EDIT (25/04) - this isnt the solution - it may fix the display of non xkb sources - but if you have an xkb source it stays with the fallback US keyboard e.g. en_GB reverts to US - but when you delete the japanese layout then en_GB starts working

@tista500
Copy link

attached is a diff for the mutter330reduxII branch (i.e. you can apply it on the source for 19.04 UB) that at first glance seems to resolve this matter + fixes the crash in budgie-wm when creating non xkb layouts.

Worked for me (Vala 0.44.3, IBus 1.5.19). Thanks.

@quycao
Copy link

quycao commented Oct 5, 2019

attached is a diff for the mutter330reduxII branch (i.e. you can apply it on the source for 19.04 UB) that at first glance seems to resolve this matter + fixes the crash in budgie-wm when creating non xkb layouts.

Worked for me (Vala 0.44.3, IBus 1.5.19). Thanks.

How can you fixed it, please guide me in detail. Many people get same problem.
#1823
#1850
Many thanks.

@patrickdark
Copy link

I have a similar problem in Solus 4 Budgie; Chewing (ibus-chewing) and New Zhuyin (ibus-libzhuyin), two traditional Chinese input methods, aren't listed in the Keyboard Layout applet after installation making Chinese character input methods unusable. I filed an issue on that--probably in the wrong place--at https://dev.getsol.us/T8445.

One can cycle to these Input Sources using the Meta (Windows) + Spacebar keys, at least; ibus-chewing displays a blue icon indicating that it's selected whereas ibus-libzhuyin displays nothing to indicate that it's selected. The wrong Input Source indicator displays in the applet in both cases because neither Input Source is listed.

Unfortunately, the Input Sources are nevertheless unusable because the character selection overlay can't be made to appear, so there's no way to select the desired characters

@solus-project solus-project deleted a comment from quycao Apr 26, 2020
@shedaniel
Copy link

Any updates on this? The patch worked for me but would like to know why it is not merged into the project itself? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants