Bug 847500 - Don't install Eekboard by default in the desktop spin
Don't install Eekboard by default in the desktop spin
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: eekboard (Show other bugs)
rawhide
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: Daiki Ueno
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-12 07:14 EDT by Allan Day
Modified: 2012-09-17 18:13 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-17 18:13:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Allan Day 2012-08-12 07:14:18 EDT
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.

If the GNOME Shell on-screen keyboard is missing any necessary functionality, we should file bugs against it and get it up to scratch.
Comment 1 Daiki Ueno 2012-08-12 21:06:01 EDT
(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?
Comment 2 Parag Nemade 2012-08-12 23:36:26 EDT
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.
Comment 3 Allan Day 2012-08-13 05:30:47 EDT
(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
Comment 4 Daiki Ueno 2012-08-13 09:17:47 EDT
(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?
Comment 5 Daiki Ueno 2012-08-13 22:05:21 EDT
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.
Comment 6 Allan Day 2012-08-14 04:37:03 EDT
(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.
Comment 7 Daiki Ueno 2012-08-14 04:53:40 EDT
(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.
Comment 8 Allan Day 2012-08-14 04:57:18 EDT
(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...?
Comment 9 Parag Nemade 2012-08-14 05:02:56 EDT
(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.
Comment 10 Daiki Ueno 2012-08-14 05:08:43 EDT
(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.
Comment 11 Parag Nemade 2012-08-14 05:30:19 EDT
(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.
Comment 12 Daiki Ueno 2012-08-14 09:29:24 EDT
(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.
Comment 13 Fedora Update System 2012-08-15 05:40:57 EDT
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
Comment 14 Fedora Update System 2012-08-15 11:58:02 EDT
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).
Comment 15 Fedora Update System 2012-09-17 18:13:29 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.