[03:43] <happyaron> attente: I don't think ibus is activated at login screen, except for setting xkb. am I correct?
[03:45] <attente> happyaron, yes. it's actually just g-s-d changing the xkb groups right now
[03:46] <happyaron> ok, great
[03:49] <attente> happyaron, i'm still not sure if it's a good idea to do the switch to fcitx this cycle given that it's an LTS and we don't really know how the non-IM people will take it
[03:50] <happyaron> attente: me neither, but I do doubt how many setups would have multiple keyboard layouts at the same time. :)
[03:51] <attente> happyaron, yeah, i agree that they are probably far and few...
[03:52] <happyaron> I think non-IM people would prefer to be able to change layout in g-c-c, rather than in a separate tool. but all my worries are at the interaction level, not technical parts.
[03:52] <happyaron> so we may end up to do some homework about the configuration UI.
[03:55] <happyaron> csslayer: what do you think? Fcitx for non-IM user, when they have the need of switching among layouts?
[04:03] <csslayer> at least I think there's only one layout needed for one user :| ..
[04:05] <csslayer> attente: if it's just xkb layouts, and g-s-d is doing that, I guess it would be simpler if fcitx just pushes layout info to account service and still let g-s-d do that
[04:14] <attente> csslayer, in the user's session though, if they're only using keyboard layouts, should x be handling that? or would we have fcitx do that as well?
[04:17] <csslayer> attente: well.. my idea is always let to imf handle all layout, but from the feedback there are still some cases doesn't get covered very well.
[04:19] <csslayer> attente: if people only mainly one layout, and use another layout in order to just type some other languages (just like use another im) -> I think fcitx can do this well right now
[04:21] <csslayer> if people change the main layout permentantly frequently (one tells me that he use jp at home and fr at work), it's not convenient with fcitx
[04:22] <csslayer> so I'd also like to change the way that how fcitx handles layout to cover more cases.. I posted the idea on fcitx's maillist but it's not implemented yet
[04:22] <attente> csslayer, sorry, i don't quite understand, what's the difference between those two scenarios?
[04:23] <attente> csslayer, one thing that irked me a bit was that there are two different triggers, one to enable fcitx and another to cycle IMs in fcitx
[04:26] <csslayer> attente: in the first case, say your native language is English, but you need to talk with some French colleague, thus you only use french layout when needed. Like, you only use french in one im window but always use English in other window.
[04:26] <attente> csslayer, ah, understood
[04:27] <csslayer> attente: in the second case, he uses different layout because he use different physical keyboard which is printed with different key, thus when he work, even if he types japanese, he still use the fr layout (at some level mozc is compatible with fr)
[04:30] <csslayer> when he get back to home, he connect a different keyboard (say he uses laptop keyboard at home and another usb keyboard at work), and that's why he changes the layout.
[04:32] <csslayer> attente: actually I really hate the cycle key.. it's there because it's always there.
[04:33] <attente> csslayer, is that second case common? it sounds like it'd be pretty uncommon
[04:34] <attente> csslayer, i guess the cycle key is useful if you're using more than one IM, no?
[04:35] <csslayer> attente: I don't really know, some raises this workflow on fcitx mail list. but even the intention is not that, I can guess one changes layout permentantly for different environment.
[04:37] <csslayer> attente: actually.. fcitx has a better way to choose im (though it's not enabled by default), cycle is too confusing to me. You can use a hotkey to list all im and choose it with number.
[04:39] <csslayer> I don't know who raises this cycle idea first.. but it will make your operation depends on some local state, say, if you have three im, you will never know what's the next one after press cycle if you switch between windows frequently.
[04:39] <attente> while that sounds convenient, we may get complaints from users who are used to switching between us and ru using ctrl+shift, or ctrl+ctrl, or any other modifier-only key bindings
[04:40]  * happyaron which is working on my Debian stable setup for fcitx. just fyi
[04:40] <csslayer> attente: yes, I also aware of that.
[04:40] <attente> csslayer, the cycling is a legacy of how x11 implemented the group switching itself i guess
[04:41] <attente> happyaron, no question, you definitely sold me on fcitx over ibus at the uds session :)
[04:42] <happyaron> :)
[04:42] <attente> two major concerns that are lingering in my mind are: 1. will it make the russian/greek/arab users happy, and 2. stability for the LTS
[04:43] <csslayer> attente: if we want to migrate now, a not too aggressive way is to totally disable the fcitx layout feature. then fcitx will knows nothing about the layout and will just handle im
[04:43] <attente> csslayer, ok, so we do that and revert the gnome-ibus integration under unity
[04:45] <csslayer> attente: or.. I will work on this idea for some more time, which IMHO can make everyone happy: https://groups.google.com/forum/#!topic/fcitx-dev/dRqoihxxLPo
[04:47] <csslayer> attente: well.. the previous way is just like revert the integration and uses ibus 1.4 (if we just comparing the workflow instead of features)
[04:51] <attente> csslayer, so it would be fcitx under unity, ibus under gnome-shell?
[04:52] <happyaron> what do you mean by this?
[04:52] <csslayer> attente: what do you mean by revert integration actually?.. (revert only unity part? or also add --disable-ibus in gnome package?)
[04:53] <attente> happyaron, csslayer, reverting back to before g-s-d and g-c-c switched to using "input sources" in the region panel
[04:53] <attente> back to when keyboard layouts were purely handled in X
[04:54] <attente> so the user could configure at most 4 at a time
[04:54] <happyaron> attente: I tsee. then I believe under gnome-shell it does not matter which is used by the user.
[04:55] <happyaron> and even fcitx would have a little better experience if they have the kimpanel GS plugin installed.
[04:55] <happyaron> we can optionally package it and add it to Recommends of gnome-shell.
[04:55] <attente> happyaron, except gnome integrates ibus in g-s-d and g-c-c
[04:56] <attente> it adds another minor issue of how does im-config work at that point if it then depends on what shell is logged into
[04:56] <happyaron> attente: why?
[04:57] <csslayer> attente: ah, ok, which version of gnome you're using right now? https://bugzilla.gnome.org/show_bug.cgi?id=707652 .. well there're some hardcoded environment variable (It's even unrelated if integration is enabled or not..)
[04:57] <ubot2> Gnome bug 707652 in keyboard "Don't start and set ibus related environment if GTK_IM_MODULE is set." [Normal,Unconfirmed]
[04:58] <attente> csslayer, we're on g-s-d 3.8.6 and g-c-c 3.6.3 right now
[04:59] <csslayer> attente: actually they extract some code from g-s-d.. and put them in the script that starts g-s-d.. but didn't do the same check as in old c code..
[04:59] <attente> happyaron, if i do 'im-config -n fcitx' under unity, then log into gnome-shell, which framework is used?
[04:59] <happyaron> attente: fcitx
[05:00] <attente> so if fcitx is default in 14.04 under unity
[05:00] <attente> and the user prefers gnome-shell
[05:00] <csslayer> attente: so I mean it might breaks other imf for qt and xim program if ibus is installed.
[05:02] <happyaron> attente:  it's not needed to switch the imf when user log into gnome-shell, but derivative/flavors may keep ibus as default if they use gnome-shell.
[05:02] <csslayer> attente: you might want to take a look of my patch in that report .. you hit some problem in testing :/ just want to mention this.
[05:04] <happyaron> attente: if the user really wants to use ibus, he/she can change it using language-selector or im-config. there wouldn't be significant problem using fcitx if we disables the ibus integration in gnome.
[05:05] <happyaron> as said just now, the experience can be slightly better than ibus without the integration.
[05:05] <attente> happyaron, but if a user logs into gnome-shell and selects his input sources throught the g-c-c region panel, it won't work because fcitx is the configured framework, no?
[05:07] <happyaron> attente: sure it won't work, but when ibus integration is disabled user won't be able to see that much configuration in g-c-c?
[05:08] <attente> happyaron, ok, i guess i should explain my thought process
[05:08] <happyaron> appreciated, :)
[05:08] <attente> my thoughts were we would revert back only in the unity fork of g-s-d and g-c-c
[05:08] <attente> not on the gnome-side
[05:09] <attente> so the gnome-side would still keep its region panel more or less intact as it was intended by upstream, as well as the input sources behaviour
[05:09] <attente> but because im-config operates at an environment level, this is more or less not possible any more
[05:10] <attente> because as soon as we set fcitx as the default, that panel no longer works in gnome-shell
[05:13] <happyaron> do you think sending a notification is ok, telling the user they would need to switch to ibus to get that working?
[05:15] <attente> happyaron, that might not be the only problem, because the user might also switch between the two shells every so often
[05:18] <happyaron> attente: most of them won't be happy to change imf everytime between the two shells. Once a user is faimiliar with an imf, he won't want to change it just for a reginonal tab stuff.
[05:19] <attente> yep, i agree
[05:20] <happyaron> what I'm thinking about is pushing a notification on user's first login to gnome-shell, just like what ibus did for the Super+Space change.
[05:20] <attente> i'm not sure if notifying the user that they need to switch to ibus and log out and log back in is an ideal solution in the first case
[05:21] <happyaron> maybe at the first time of accessing the region panel?
[05:21] <happyaron> show some characters at the panel when the IMF isn't ibus, describing the situation.
[05:21] <attente> yeah, i guess that's better than nothing
[05:22] <attente> yeah, actually that might work well
[05:22] <attente> so at that point, if they're using ibus under gnome-shell and switch back to unity
[05:22] <attente> fcitx is no longer working since ibus is im-config'd
[05:23] <happyaron> we can give a similar text in unity's g-c-c or somewhere.
[05:24] <attente> well, assuming they don't start trying to use fcitx immediately thinking it was already configured the last time they logged into unity :P
[05:25] <happyaron> push a notification on next login when imf is changed?
[05:25] <attente> and under unity, if we give that message, we're basically saying, don't use ibus under unity
[05:26] <attente> happyaron, so they log in, and then they get a notification saying to log out and log in again?
[05:26] <happyaron> no, just tell them current imf is ibus, which "you" just made the change.
[05:27] <happyaron> and I suggest that not very much people will be confused, they will stick to either fcitx or ibus on both shells, and ignore the notification thinking it's information only.
[05:30] <attente> happyaron, i do hope it's not that confusing for most users
[05:30] <attente> and i hope it's only a minor annoyance
[05:31] <happyaron> to be honest, I doubt how many people would switch to ibus under GNOME if fcitx is working well.
[05:32] <happyaron> and if he/she really likes ibus, then he/shell would want use ibus under unity as well.
[05:32] <happyaron> for those who don't care that much about imf, they are unlikely to change the default when it's working.
[05:33] <coderguy22296> fist of all, what is ibus?
[05:34] <attente> coderguy22296, ibus is an input method framework for typing chinese, japanese, korean, etc characters
[05:35] <attente> happyaron, you're probably right, but if i knew nothing about this situation, i might try messing around with the region panel at some point, and wonder why i can't type chinese
[05:36] <happyaron> attente: that would need some work on writing a good text we will show on the region panel, telling what's going on using simple words.
[05:37] <coderguy22296> that sounds good
[05:40] <coderguy22296> srry about that^ , just testing irc on a diff device
[05:44] <coderguy22296> here is my issue, do you think it could be a quick fix: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1253885
[05:44] <ubot2> Launchpad bug 1253885 in xorg (Ubuntu) "I noticed a 1-2 pixel shift to the right in the desktop's display area" [Undecided,New]
[05:57] <coder_guy22296> hey guys
[05:59] <happyaron> attente: is it good time to make a decision?
[06:00] <attente> happyaron, i think you're right
[06:00] <attente> i guess i'm just overthinking things
[06:01] <happyaron> :)
[06:01] <attente> plus, it's 1 am where i am too :P
[06:02] <happyaron> attente: go to bed and have a nice weekend (for the remaining time)!
[06:02] <happyaron> let's create a detailed plan next Monday.
[06:02] <attente> happyaron, yep, let's do that
[06:02] <attente> thanks :)
[06:03] <happyaron> :)
[06:03] <coder_guy22296> could one of you guys look at this bug that ive found?
=== rainbowdash` is now known as Mapley
=== Mapley is now known as rainbowdash`
[17:50] <Laney> chrisccoulson: can you switch the depends on ttf-wqy-zenhei and ttf-arphic-ukai to fonts-... in your next firefox(-testsuite) upload please?
=== Ursinha is now known as Ursinha-afk
=== Guest66951 is now known as Mapley