Bug 928645

Current GNOME 3.8 UI does not setup a default Input Source
(kbd layout) for new users, which leads to somewhat strange UI experience.  Worse for some locales (languages) it means
that one is not able to input ASCII characters without having
to tweak the Input Sources.
This is also a regression compared to Fedora 18/GNOME 3.6,
which defaulted to the system keyboard layout.

Proposing as a F19 Beta Blocker.

*** Bug 956458 has been marked as a duplicate of this bug. ***

The list coming up empty will be fixed by https://bugzilla.redhat.com/show_bug.cgi?id=958714 .

Have the anaconda folks accepted that bug, though, or have you just filed it? Seems important to make sure everyone's on the same page here.

(In reply to comment #4)
> Have the anaconda folks accepted that bug, though, or have you just filed
> it? Seems important to make sure everyone's on the same page here.

Yes, I spoke with Vratislav on IRC.

Discussed at 2013-05-06 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-06/f19beta-blocker-review-3.2013-05-06-16.02.log.txt . We're definitely worried about this one, but it doesn't seem like this report makes it clearly precisely what the *practical* impact of this bug is. It would help a lot if we could make that clear.

So, say you're a Japanese (or whatever) user, and you make a normal choice at the keyboard layout spoke in anaconda. What do you choose? What keyboard layout actually winds up being used during gnome-initial-setup and first login? What are the practical consequences of this? Are we talking minor inconvenience, complete inability to create a user account, or what? Thanks!

We're also interested to see what the impact of the fix for 958714 will be on this bug.

(In reply to comment #6)
> So, say you're a Japanese (or whatever) user, and you make a normal choice
> at the keyboard layout spoke in anaconda. What do you choose?

Since anaconda only provides XKB keymaps as options (i.e. no IBus engines) such a user will most likely choose either the US layout or the Japanase layout which is an ASCII layout with some minor differences to the US layout in punctuation key locations.

> What keyboard
> layout actually winds up being used during gnome-initial-setup and first
> login?

The layouts chosen in anaconda. In our case above either US or Japanese or even both.

> What are the practical consequences of this? Are we talking minor
> inconvenience, complete inability to create a user account, or what? Thanks!

So in F19 there are actually 2 ways to create user accounts. During installation in anaconda or, if you don't do it there, during a special run of gnome-initial-setup that GDM runs when there are no users created yet.

In the first case GDM comes up normally and the layouts available there are the ones configured in anaconda. When the user logs into this account the "regular" gnome-initial-setup runs and again those same layouts are there but now the user can add more layouts or input methods (in case any IBus IMEs are installed). I.e. our Japanese user can now add Japanese (Anthy) and start using it right away.

In the case where the user account isn't created in anaconda GDM initially presents the "expanded" gnome-initial-setup that allows you to create an account. But as far as input methods are concerned it works as described above.

> We're also interested to see what the impact of the fix for 958714 will be
> on this bug.

Just that the list won't come up empty as it does now.

That's pretty much as I saw it, yes. Okay. So what's the bug here?

If anything, Mike's report is two bugs:

#1 - the g-i-s input list comes up empty, it should show whatever was selected in anaconda.

Okay, we have a bug for that already, that's 958714.

#2 - we don't magically set up proper Japanese input configuration in anaconda when you pick Japanese as your language.

Yes? If so, this bug is effectively just for #2, and we should change the summary, and it kinda becomes an RFE, because that's quite a complex thing for us to do. For a start, we'd need to add the iBus input methods to anaconda and make sure they work, then we could start thinking about getting them selected automatically.

If I'm wrong, can someone please define precisely what it is this bug is for, and how it differs from 958714?

(In reply to comment #8)
> That's pretty much as I saw it, yes. Okay. So what's the bug here?
> 
> If anything, Mike's report is two bugs:
> 
> #1 - the g-i-s input list comes up empty, it should show whatever was
> selected in anaconda.
> 
> Okay, we have a bug for that already, that's 958714.
> 
> #2 - we don't magically set up proper Japanese input configuration in
> anaconda when you pick Japanese as your language.
> 
> Yes? If so, this bug is effectively just for #2,

Yes, to me it looks like only #2 remains if bug#958714 is fixed.

> summary, and it kinda becomes an RFE, because that's quite a complex thing
> for us to do.

I think a Japanese input method was setup automatically on f18 after
an installation in Japanese though, if I remember correctly.

> For a start, we'd need to add the iBus input methods to
> anaconda and make sure they work, then we could start thinking about getting
> them selected automatically.

Did  f18 do this using anaconda?

"I think a Japanese input method was setup automatically on f18 after an installation in Japanese though, if I remember correctly."

Really? Hmm, that must have been GNOME being smart based on the language, I guess, because anaconda just sets up the layouts it shows on the keyboard spoke. I guess we need to look at it more closely.

Discussed at 2013-05-08 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-08/f19beta-blocker-review-4.2013-05-08-16.00.log.txt . This doesn't look like a blocker - 958714 is probably a stronger candidate - but we're still not quite sure what all the issues are here, so we're punting it for clarification and testing, esp. with the 958714 fix when it comes.

OK, so both Rui and myself now understand this bug to cover the issue with GNOME's automatic setup of IMEs for certain languages no longer working. The issue with the g-i-s input method dialog coming up empty is a bug in anaconda and is filed as #958714. Updating summary.

*** Bug 958716 has been marked as a duplicate of this bug. ***

Do we know yet for sure whether the IME configuration magic is entirely broken, or have people only tested Japanese so far?

I believe it is not supported yet and in fact currently IMEs cannot be
added from g-i-s, which probably also blocks this.

We really need an upstream bug for this I guess.
Anyone know if there is one?

Jens: well this bug says 'g-i-s', but the functionality was present in GNOME in 3.6, Rui tells me; it is/was done by gnome-settings-daemon. So I wouldn't expect an appropriate IME to show up in g-i-s in F19 at present, necessarily, but we would kinda expect an appropriate IME to show up once you finish g-i-s and go into the desktop.

It's presumably a question for upstream whether, now we have g-i-s, it makes sense to move this from g-s-d out into g-i-s. But we should probably check what precisely the current situation is.

The bug for adding IMEs to g-i-s is #950688; it's marked as ON_QA.

Discussed at 2013-05-13 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-13/f19beta-blocker-review-5.2013-05-13-16.00.log.txt . Now we're clear on what is broken and what is working, we're happy rejecting this bug as a blocker: it'd be nice to have IMEs configured 'magically' for users of appropriate languages, but if we don't, that clearly doesn't violate the criteria.

i believe Rui is working on moving that functionality to g-i-s for F19.

Not sure if it is in gnome-initial-setup-0.10-1.fc19.

I did get the Japanese input method "Kana Kanji" (ibus-kkc) automatically
after a netinstall  of Fedora-19-Beta-TC4-x86_64-netinst.iso.

gnome-initial-setup-0.9-2.fc19.x86_64

mike: so you just did an install in Japanese, didn't add any input methods during the relevant step of g-i-s, but you had KKC configured when you logged into your desktop?

Discussed at 2013-05-15 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-05-15/f19beta-blocker-review-6.2013-05-15-16.02.html . Accepted as a freeze exception bug as it would be good to have this function in Beta for testing. Whether we pull a fix if one shows up, though, depends on how invasive it is, how late it is, and how well it's tested.

Note: I built a live image with the latest everything today, and found that if I picked Japanese language in gnome-initial-setup, the KKC IME was shown on the input method screen. However, if I left that screen without touching anything and completed g-i-s, KKC didn't actually appear to be enabled either for the rest of g-i-s, or for the user session I was eventually logged into.

(In reply to comment #20)
> mike: so you just did an install in Japanese, didn't add any input methods
> during the relevant step of g-i-s, but you had KKC configured when you
> logged into your desktop?

Yes.

I didn't see any IMEs setup by default recently,
I think this is fixed by gnome-initial-setup-0.10-1.fc19
for Japanese at least.

Jens: well, see my result from comment #21. It didn't quite work for me.

As yes thanks, Rui mentioned this bug to me earlier on irc.

I installed Fedora 19 Beta TC4, then manually updated to gnome-initial-setup-0.10-1.fc19 build. I can see this bug is now fixed with this update.

parag: see if the IME that's shown in g-i-s is actually configured for your user when you complete it - c#21.

(In reply to comment #21)
> Note: I built a live image with the latest everything today, and found that
> if I picked Japanese language in gnome-initial-setup, the KKC IME was shown
> on the input method screen. However, if I left that screen without touching
> anything and completed g-i-s, KKC didn't actually appear to be enabled
> either for the rest of g-i-s, or for the user session I was eventually
> logged into.

Yeah, there's a bug there. Do we need to have it fixed for the beta or can it go in afterwards?

AcceptedFreezeException means that we can choose to pull a fix into Beta if it looks safe, but we aren't blocking on it.

*** Bug 962699 has been marked as a duplicate of this bug. ***

The current g-i-s update in bodhi should fix this.

That's https://admin.fedoraproject.org/updates/FEDORA-2013-8488/gnome-initial-setup-0.10-3.fc19 . It will be in Beta RC3. Setting ON_QA.

Confirmed that latest g-i-s fixes this. It's still doing its little dance when you run it in Japanese, but it works :)

Thanks - looks good to me too for Japanese input.

Chinese and Marathi looks OK as well.

This should be closed then....