Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-16 Thread AWASHIRO Ikuya
Hi Sebastien,

On Wed, 13 Nov 2013 16:04:14 +0100
Sebastien Bacher sebastien.bac...@canonical.com wrote:

 Did we loose our indicator in the ibus 1.4-1.5 transition? We should 
 add it back in that's the case, yes
This is the dropped patch.
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/ibus/saucy/revision/56#debian/patches/05_appindicator.patch

 That's a topic that is going to be discussed at vUDS next week:
 http://summit.ubuntu.com/uds-1311/meeting/21984/desktop-1311-default-imf-review/
I see.
Many Japanese users dislike IBus 1.5. Some Japanese users say it is 
a crap. Of course I don't think so.
Such users switch to Fcitx or uim which is default input method
on Debian.
Fcitx(fcitx and fcitx-mozc) is well-worked, well-translated
for Japanese users.
IBus 1.5 is not bad. But I found some issues.
If these problems will be fixed, IBus 1.5 will make better than now 
hopefully.

Thanks,
-- 
AWASHIRO Ikuya
ik...@fruitsbasket.info / ik...@oooug.jp / iku...@gmail.com
GPG fingerprint:
1A19 AD66 C53F 2250 3537 1A9D 3A53 2C1D 20AB CC8A

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-13 Thread AWASHIRO Ikuya
Hi Sebastien,

On Tue, 12 Nov 2013 16:02:11 +0100
Sebastien Bacher sebastien.bac...@canonical.com wrote:

 - we stop using our new keyboard indicator/get back to an UI which is 
 not what our design document recommend
What does it mean?
 * Someone will write indicator patch for IBus 1.5.
 * We use IBus embedded icon on Unity.
 * We switch back to IBus 1.4.
 * We switch to Fcitx from IBus.
 * or another idea?

Regards,
-- 
AWASHIRO Ikuya
ik...@fruitsbasket.info / ik...@oooug.jp / iku...@gmail.com
GPG fingerprint:
1A19 AD66 C53F 2250 3537 1A9D 3A53 2C1D 20AB CC8A

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-13 Thread Sebastien Bacher

Hi,

Le 13/11/2013 13:40, AWASHIRO Ikuya a écrit :

What does it mean?
  * Someone will write indicator patch for IBus 1.5.
Did we loose our indicator in the ibus 1.4-1.5 transition? We should 
add it back in that's the case, yes



  * We use IBus embedded icon on Unity.
  * We switch back to IBus 1.4.

Those are not likely to happen no

  * We switch to Fcitx from IBus.


That's a topic that is going to be discussed at vUDS next week:
http://summit.ubuntu.com/uds-1311/meeting/21984/desktop-1311-default-imf-review/

Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-13 Thread Sebastien Bacher

Le 12/11/2013 17:55, Gunnar Hjalmarsson a écrit :

Possibly a solution worth exploring for the Unity LTS.


Hey Gunnar,

Thanks for the suggestion. I would prefer avoiding trying a new solution 
though, especially during a LTS cycle. We have basically 2 options we 
experimented with, it would make sense to just go with one of those...


Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-13 Thread Loïc Minier
On Tue, Nov 12, 2013, Sebastien Bacher wrote:
 *  keep pushing forward to try to solve those issues (e.g move the
 keygrabbing to compiz, look at where we stand there).
 
 That should give us a mostly working system, but:
 - it means increasing changes before a LTS, which has potential to
 create new issues
 - we are not sure that applications are going to be fixed before the
 LTS, and how much of an annoyance that's going to be for our users
 - we are spending more efforts on trying to fix things for
 Unity7/xorg, for a problem that is going to go away with Unity8/Mir
 (things are going to work differently under Mir/wayland)

How will the Mir/Wayland approach look like?  Could we leverage it for
Unity 7?

 * roll back to what we had until 13.04

We can't ship Unity 8 in the desktop for 14.04 due to the dependency on
Mir, so since we picked the ship known good / stable stack in 14.04
desktop approach, it would be consistent to pick the good / stable old
way of switching keyboard layouts and handling shortcuts -- unless it's
a lot of work to rollback, in comparison to moving to the new world.

From a risk point of view, the second option seems like the safest one,
but from an efforts point of view this depends on how much work it is to
produce an Unity 8 image with a new keyboard layouts / shortcuts
solution + finding a solution for Ubuntu Desktop.

-- 
Loïc Minier

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-13 Thread Sebastien Bacher

Le 13/11/2013 17:49, Loïc Minier a écrit :

How will the Mir/Wayland approach look like?  Could we leverage it for
Unity 7?
I expect the approach in the new world to be similar to the recent 
work. It should be easier under Mir/Wayland since we are not going to 
have to fight with X grabs and xkb limitations there (e.g Mir should be 
watching for those events and sending the signal to do the action 
associated to the keybinding).


That's a topic that should be discussed with the Mir/Unity8 though ... 
do you know if that's on the roadmap for this cycle (handling of 
external keyboards and layouts/input methods/keybindings on the desktop)?



unless it's
a lot of work to rollback, in comparison to moving to the new world.
Well, we are almost done with the work we have been doing. The issue is 
that we are hitting the problems I listed, especially the ones with apps 
like libreoffice that require to fix the applications. I expect 
applications are not going to be an issue in touch because there is less 
legacy and the ones newly written or using the standard toolkits 
shouldn't have those issues.


Rollback is not that much work in any case.

 From a risk point of view, the second option seems like the safest one,
but from an efforts point of view this depends on how much work it is to
produce an Unity 8 image with a new keyboard layouts / shortcuts
solution + finding a solution for Ubuntu Desktop.
The solutions are going to be different in both setups (since the input 
stack used is not the same), it also depends on the input method 
framework we are going to use (there is still the ongoing ibus or fcitx 
discussion, with a session at vUDS next week)


Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-13 Thread Loïc Minier
On Wed, Nov 13, 2013, Sebastien Bacher wrote:
 That's a topic that should be discussed with the Mir/Unity8 though
 ... do you know if that's on the roadmap for this cycle (handling of
 external keyboards and layouts/input methods/keybindings on the
 desktop)?

(I don't know whether this is on the roadmap)

-- 
Loïc Minier

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-12 Thread Sebastien Bacher

Le 12/11/2013 16:02, Sebastien Bacher a écrit :
- it means basically adding back revert patches to 
gnome-settings-daemon/gnome-control-center, that's not really elegant 
but we had those until previous cycle and it was working 


Seems I forgot to add a note there ... we already have plans to have a 
second version of those packages in the archive for Unity (that's going 
to unblock some GNOME remix work), which means the revert would be Unity 
specific and not create issues for gnome-shell users


Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: Handling of layout/input methods in Unity: what should we do for the LTS?

2013-11-12 Thread Gunnar Hjalmarsson
On 2013-11-12 16:02, Sebastien Bacher wrote:

snip

 * Since Ubuntu 13.10
 
 - GNOME merged both concepts to provide an unified experience [1]

Xubuntu 13.10 integrates keyboard layouts and input methods using IBus.
Probably the GNOME changes haven't much to do with it; maybe IBus 1.5 has.

Anyway, via the IBus indicator I can easily switch between English (US),
Swedish, Chinese, and Korean. Haven't tested shortcuts, though.

Possibly a solution worth exploring for the Unity LTS.

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel