Bug 847500

(In reply to comment #0)
> An on-screen keyboard should be presented as part of the system, and should
> be fully integrated into the user experience. GNOME Shell already comes with
> an integrated on-screen keyboard: Eekboard shouldn't be necessary, provides
> overlapping functionality, and results in an extra application launcher.

First of all, I agree with not installing eekboard on default English system.

Currently it is installed as a dependency of ibus-m17n, which had required iok before to input Indic characters.  So I guess we could restrict the installation only for Indic languages.  Let me check comps.

> If the GNOME Shell on-screen keyboard is missing any necessary
> functionality, we should file bugs against it and get it up to scratch.

Actually I filed some bugs and patches some months ago but no response so far:

https://bugzilla.gnome.org/show_bug.cgi?id=673547
https://bugzilla.gnome.org/show_bug.cgi?id=673579

Is the component still actively maintained?

Note:- Following is just a feedback on upstream Caribou project not related to this bug.

Being the Caribou package maintainer in Fedora and my experience with contacting the upstream is *very very bad*, I will say first the upstream author should be reachable.
For me it looks like Caribou is now in maintenance phase where Gnome desktop team is fixing the issues and author is unresponsive.

(In reply to comment #1)
> (In reply to comment #0)
> > An on-screen keyboard should be presented as part of the system, and should
> > be fully integrated into the user experience. GNOME Shell already comes with
> > an integrated on-screen keyboard: Eekboard shouldn't be necessary, provides
> > overlapping functionality, and results in an extra application launcher.
> 
> First of all, I agree with not installing eekboard on default English system.
> 
> Currently it is installed as a dependency of ibus-m17n, which had required
> iok before to input Indic characters.  So I guess we could restrict the
> installation only for Indic languages.  Let me check comps.

The GNOME Shell on-screen keyboard should integrate with whatever input source is being used [1]. That said, it seems strange that eekboard is specifically tied to ibus-m17n. I'd be interested to know if there is a reason for this. Asking around, no one seems to be able to give me an answer to that.

> > If the GNOME Shell on-screen keyboard is missing any necessary
> > functionality, we should file bugs against it and get it up to scratch.
> 
> Actually I filed some bugs and patches some months ago but no response so
> far:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=673547
> https://bugzilla.gnome.org/show_bug.cgi?id=673579
> 
> Is the component still actively maintained?

Unfortunately not. I hope that that will changes in the future.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=681735

(In reply to comment #3)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > An on-screen keyboard should be presented as part of the system, and should
> > > be fully integrated into the user experience. GNOME Shell already comes with
> > > an integrated on-screen keyboard: Eekboard shouldn't be necessary, provides
> > > overlapping functionality, and results in an extra application launcher.
> > 
> > First of all, I agree with not installing eekboard on default English system.
> > 
> > Currently it is installed as a dependency of ibus-m17n, which had required
> > iok before to input Indic characters.  So I guess we could restrict the
> > installation only for Indic languages.  Let me check comps.
> 
> The GNOME Shell on-screen keyboard should integrate with whatever input
> source is being used [1]. That said, it seems strange that eekboard is
> specifically tied to ibus-m17n. I'd be interested to know if there is a
> reason for this. Asking around, no one seems to be able to give me an answer
> to that.

I know that would be ideal.  However, ibus-m17n (Indic) osk feature has been there since I took over the maintenance in 2010 (it used iok at that time), and if we simply remove the feature it will be a regression, unless GNOME provides a complete replacement.  IMO, the current GNOME Shell on-screen keyboard is not working well even under English system (see the 2nd bug reference below).

> > > If the GNOME Shell on-screen keyboard is missing any necessary
> > > functionality, we should file bugs against it and get it up to scratch.
> > 
> > Actually I filed some bugs and patches some months ago but no response so
> > far:
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=673547
> > https://bugzilla.gnome.org/show_bug.cgi?id=673579
> > 
> > Is the component still actively maintained?
> 
> Unfortunately not. I hope that that will changes in the future.
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=681735

Do you have any schedule for such an internationalized osk in GNOME?

OK, this bug was filed as a part of the F18 launcher purge activity, right?
https://fedoraproject.org/wiki/Design/F18_Launcher_Purge
I didn't get the background context from your initial comment.

If your imminent need is to remove the launcher icon, I could hide it with NotShowIn=GNOME; in the desktop file.

For other issues I would suggest to file a new bug, after GNOME Shell on-screen keyboard gets mature.

(In reply to comment #5)
> OK, this bug was filed as a part of the F18 launcher purge activity, right?
> https://fedoraproject.org/wiki/Design/F18_Launcher_Purge
> I didn't get the background context from your initial comment.

I felt that the bug stood on its own.

> If your imminent need is to remove the launcher icon, I could hide it with
> NotShowIn=GNOME; in the desktop file.
...

The problem with that approach - GNOME users will be unable to use Eekboard, should they want to.

(In reply to comment #6)
> > If your imminent need is to remove the launcher icon, I could hide it with
> > NotShowIn=GNOME; in the desktop file.
> ...
> 
> The problem with that approach - GNOME users will be unable to use Eekboard,
> should they want to.

fedora-iok.desktop already has that line.

Other way around is to split the eekboard package - ibus-m17n only requires eekboard library and the DBus service.  So we could subpackage eekboard frontend command (which is launched from the desktop file) and make ibus-m17n not depend on it.

(In reply to comment #7)
...
> Other way around is to split the eekboard package - ibus-m17n only requires
> eekboard library and the DBus service.  So we could subpackage eekboard
> frontend command (which is launched from the desktop file) and make
> ibus-m17n not depend on it.

What does ibus-m17n need that for exactly...?

(In reply to comment #7)
> (In reply to comment #6)
> > > If your imminent need is to remove the launcher icon, I could hide it with
> > > NotShowIn=GNOME; in the desktop file.
> > ...
> > 
> > The problem with that approach - GNOME users will be unable to use Eekboard,
> > should they want to.
> 
> fedora-iok.desktop already has that line.

because of bug 529125.

(In reply to comment #8)
> (In reply to comment #7)
> ...
> > Other way around is to split the eekboard package - ibus-m17n only requires
> > eekboard library and the DBus service.  So we could subpackage eekboard
> > frontend command (which is launched from the desktop file) and make
> > ibus-m17n not depend on it.
> 
> What does ibus-m17n need that for exactly...?

Indic osk UI.  eekboard UI is implemented in the DBus service and it can be accessed through the library, without eekboard command.

(In reply to comment #8)
> (In reply to comment #7)
> ...
> > Other way around is to split the eekboard package - ibus-m17n only requires
> > eekboard library and the DBus service.  So we could subpackage eekboard
> > frontend command (which is launched from the desktop file) and make
> > ibus-m17n not depend on it.
> 
> What does ibus-m17n need that for exactly...?

The iok application is developed for Inscript type of keymaps for Indic languages. These are default keymaps. Whenever Inscript keymap gets selected, ibus used to allow to show selected keymap in iok UI. But I think this has been stopped in F17 and now only eekboard UI used to come for Indic Inscript keymaps also.

(In reply to comment #11)
> Whenever Inscript keymap gets
> selected, ibus used to allow to show selected keymap in iok UI. But I think
> this has been stopped in F17 and now only eekboard UI used to come for Indic
> Inscript keymaps also.

Actually there is an option to use iok but it isn't working for now because of a minor bug.  Will fix it in the next update.

ibus-m17n-1.3.4-4.fc18,eekboard-1.0.8-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/ibus-m17n-1.3.4-4.fc18,eekboard-1.0.8-1.fc18

Package ibus-m17n-1.3.4-4.fc18, eekboard-1.0.8-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ibus-m17n-1.3.4-4.fc18 eekboard-1.0.8-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11896/ibus-m17n-1.3.4-4.fc18,eekboard-1.0.8-1.fc18
then log in and leave karma (feedback).

ibus-m17n-1.3.4-4.fc18, eekboard-1.0.8-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.