tag:blogger.com,1999:blog-6112936277054198647.post6709902849191712774..comments2024-03-12T00:42:06.642+10:00Comments on Who-T: Re-designing input methods with XKBPeter Huttererhttp://www.blogger.com/profile/17204066043271384535noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-6112936277054198647.post-37907003638532772982009-09-02T16:36:01.272+10:002009-09-02T16:36:01.272+10:00I think "inputting English on mobile phone nu...I think "inputting English on mobile phone number pad" is a good analog of what we, CJK input method developers encountered.<br /><br />Suppose you want to enter 'define' with T9 input method. This can be done by:<br />1. Switch to T9<br />2. Type 333463<br />3. You may need to use cursor keys to select correct candidate, i.e. 'define'.<br /><br />You mentioned that only number will be in the layout definition. But where shall we put these English alphabets? <br /><br />I did have some idea in my <a href="http://dingyichen.livejournal.com/15932.html" rel="nofollow">blog</a>. But it is far from perfect, so I am looking forward to hearing your opinion about how should we put English alphabet over a mobile phone keypad.definitehttps://www.blogger.com/profile/09277969879754791495noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-21084112841064637172009-09-01T12:34:38.866+10:002009-09-01T12:34:38.866+10:00> physical Wubi keyboards don't exist
Act...> physical Wubi keyboards don't exist <br /><br />Actually Ding-Yi Chen just showed me a photo of a Wubi keyboard and it seems Wubi stickers are also available, so I stand corrected - though they are pretty uncommon I think.Jens Petersenhttps://www.blogger.com/profile/14639055196795924638noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-26475724984311502652009-08-28T16:00:18.405+10:002009-08-28T16:00:18.405+10:00Actually, ibus-table have a compose table to deal ...Actually, ibus-table have a compose table to deal with compose key.<br /><br />BTW, I've post some opinions on http://dingyichen.livejournal.com/15676.html.<br /><br />Mind checking it out?definitehttps://www.blogger.com/profile/09277969879754791495noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-69124543808059082402009-08-27T01:34:08.761+10:002009-08-27T01:34:08.761+10:00Hi,
Sorry if this is a little off topic, but this...Hi,<br /><br />Sorry if this is a little off topic, but this interesting post reminds me of wildest dreams, and I wonder if this will be possible with XInput2.<br /><br />I possess and always dreamed to be able to use <b>at the same time</b> the following devices on my computer:<br />- 1 wireless mouse (9 buttons, 1 wheel)<br />- a wacom tablet<br />- 2 keyboards (1 wireless with a uk layout, 1 wired with a french layout)<br /><br />Most of the time I use an english keyboard since Unix being very qwerty friendly, that is what is the most efficient for me.<br /><br />But sometimes I have to type long french documents with a lot of accents and in that case it's more efficient to use a french keyboard:<br /><br />Since I'm using a qwerty layout most of the time, I tend to forget where the less used characters are. So it's more practical to switch to a different physical keyboard than changing the logical layout of the uk keyboard, as I have the keys right in front of my eyes.<br /><br />Of course I guess in a perfect world I should be able to type with several layouts without having a look at the keys, but I'm just human :)<br /><br />As a side note, I am not sure at what level the keyboard layout is supposed to be managed: i-e is it a property of the master device or of the slave device?<br /><br />To make things worse, I'm currently making a FTIR/wiimote device and I'd really love to make use of up to 4 fingers to control my htpc...<br /><br />So, will some of that be possible with XI2? What will be missing? What depend on other layers?<br /><br />Cheers,<br />GildasUnknownhttps://www.blogger.com/profile/17982448843964276851noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-52185127774822159132009-08-26T18:58:59.528+10:002009-08-26T18:58:59.528+10:00I hear real physical Wubi keyboards don't exis...I hear real physical Wubi keyboards don't exist so in that sense something like Zuiyin (for Chewing) is probably a better example, but I agree that once ibus-table (and ibus-m17n) supports non-ascii input it should be possible to handle Wubi say cleanly with an xkb layout. Of course that still leaves the question what exactly to do in Linux consoles (ibus-fbterm, etc).Jens Petersenhttps://www.blogger.com/profile/14639055196795924638noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-58982001077621152122009-08-24T22:21:19.551+10:002009-08-24T22:21:19.551+10:00After reading Kristian LPC presentation draft (htt...After reading Kristian LPC presentation draft (http://www.linuxplumbersconf.org/ocw/proposals/57), I wonder how the work you're doing on input (both keyboard and pointer) could be reusable in Wayland ?Unknownhttps://www.blogger.com/profile/05570042436259840265noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-89698407247555291692009-08-21T10:23:07.431+10:002009-08-21T10:23:07.431+10:00@Owen:
The UI is tricky to get right but it should...@Owen:<br />The UI is tricky to get right but it should - as you say - not be separate. <br />So yes, if a user selects a new IM, then this new layout should be reflected in the normal configuration tools as well and vice versa.<br /><br />If I look at the xkb configuration files, there are a many that represent one specific piece of hardware. This is simplified by the Linux kernel these days but they still exist.<br />Right now, an IM implementation needs to know about all possible variation of the hardware. There is a high chance that at least some of these variations these can be moved into keyboard layouts - similar to those already present.<br /><br />If I understood the Wubi layout correctly, there is one main component for each key. This could be the one stored in the layout. The IM method then receives this main component and combines it to the actual symbol based on previous or future symbols.<br /><br />Much in the same manner that the base component '3' is combined to a '♥' if the compose key and the < sign were pressed beforehand.<br />Wubi is more complex, but the principle looks the same to me.<br /><br /><br />The layout alone would be of no use for those needing proper characters, it is only in combination with the IM that the right symbol results.<br />The benefit from it is though that - if needed - a special layout can shuffle the physical location of these keys around without changes in the IM. The IM would still receive the same base characters and convert them accordingly.Peter Huttererhttps://www.blogger.com/profile/17204066043271384535noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-63374255129460588232009-08-21T09:34:35.802+10:002009-08-21T09:34:35.802+10:00Since you say "anything that uses alphabets i...Since you say "anything that uses alphabets is already covered by keysym tables anyway", I assume that you aren't thinking that keyboard layouts are 1-1 to input, methods but are somehow managed behind the scenes? That if the user picks an input method that *does* require a different layout, then we go off and add that layout to the user's keyboard?<br /><br />(It's clearly not OK for the user to have to select things in two different dialogs and have to have them correspond for things to work correctly.)<br /><br />I guess the interesting question here is whether the interesting non-phonetic layouts corresponds to physical hardware being sold somewhere. Whethere there's a finite process of standardization of what keysymbols are used and adding the layouts to xkb-config.<br /><br />Or are there going to be a continual stream of new input methods using the keyboard in new different ways?<br /><br />[ It's interesting to note that unlike normal XKB usage, the keysyms don't really correspond to what's printed on the key. A key on a physical Wubi keyboard will have multiple radicals printed on it, and which one the user meant has to be disambiguated by the input method. It can't be done at the XKB level. ]Unknownhttps://www.blogger.com/profile/14310588915332997933noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-15240338488683170462009-08-21T08:49:57.274+10:002009-08-21T08:49:57.274+10:00@Owen:
Thanks. I realise now that my original blog...@Owen:<br />Thanks. I realise now that my original blog wasn't precise enough.<br /><br />The division of IM and layouts should be that layouts specify what symbol is produced on a specific key. IM then takes these symbols and combines them according to the current setting - whatever that may be.<br /><br />So if IM wants latin characters for phonetic translation, then the layout should be a latin layout.<br /><br />If IM needs other characters as baseline, these should be represented by the layout too. <br />From the wikipedia wubi page: "The A key's shortcut character is 工.". I think that this should be rephrased that "The left-most key in the second row is 工". This is exactly what the layout should represent, in the same way as the us layout specifies "the left-most key in the second row is 'a'".<br /><br />The IM can then combine these symbols as they should be combined. The key though is that - when using Wubi - the IM doesn't listen for an "a", it listens for "工".<br /><br />At no point has the layout any control over what IM is used and when this IM activates. What can be implemented this way, is a dual-layout of "us,wubi" and depending if 'us' is the currenlty active one. IM either disables itself or automatically switches to phonetic translation. If 'wubi' is the active one, IM translates from the wubi characters.<br /><br />Trying to summarise it again: if you need to explain how to type the word "FOO", you would say "Hit F, hit O, hit O". This is independent of the layout.<br /><br />If you explain how to type '勹', you <br />you shouldn't need to say "hit third key from left, fourth key from right, top key from bottom". Instead, you should be able to say "Hit 金, hit 钅, hit 用" (I realize this isn't how you type '勹'). This again is independent of the layout.Peter Huttererhttps://www.blogger.com/profile/17204066043271384535noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-50014261743653983632009-08-21T08:20:45.212+10:002009-08-21T08:20:45.212+10:00User interface unification is very right. Switchin...User interface unification is very right. Switching between Japanese and English shouldn't be completely different from switching between Russian and English. But on a technological level it seems a lot more dubious to try and bind input methods to keyboard layouts. It's not uncommon to have input methods that work by having the user type the text phonetically on a Latin keyboard. That has to work whatever Latin keyboard is being used - qwerty, azerty, whever the punctuation is placed, etc. I don't see how you can make a hard association between keyboard layout and input method... the keyboard layout has its role to play, which is to translate the user's keypresses into what is printed on the key (the keysym), and can't be repurposed to handle knowing what method should be used of going from that keysym to the input text.<br /><br />The same complaint as the above applies to non-phonetic input methods - in my somewhat limited understanding, Chinese users are often not using a keyboard specifically intended for the input method that they are using. We can't assume that there is a single "Wubi" keyboard layout - (http://en.wikipedia.org/wiki/Wubi_method - picked at random from Wikipedia's list of Chinese input method) Now, the expectation of typing on an azerty keyboard is slightly differenty - the user actually is thinking of a physical organization of keys - so it's *more* like a different layout - but the rest of the keyboard still needs to follow whatever the keyboard model is that the user is using. (I doubt azerty keyboards have much usage in China anyways)<br /><br />It's a complex area, no doubt, and there are some interesting interactions. Hopefully a division of labor can be worked out where the input method doesn't have to worry about the details of the layout - where if the input method wants a q it can listen for that, and if it wants the second key on the second row it can listen for that, but I don't think "If you're trying to type Chinese, you shouldn't have a us layout" really captures the situation.Unknownhttps://www.blogger.com/profile/14310588915332997933noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-86750449483837844132009-08-21T07:59:34.970+10:002009-08-21T07:59:34.970+10:00@khc:
anything that uses alphabets is already cove...@khc:<br />anything that uses alphabets is already covered by keysym tables anyway. and in the end, these keysym tables are simply mappings from the phys. key location to the symbol. So for the second type, we just need to get the symbol tables as well.<br /><br />@glandium:<br />it's the first type you describe that needs a keyboard layout. and this layout simply specifies where each hiragana is located. the IM can then combine them as they are typed as required.<br />the second one is covered since for latin characters we have location-independent keymaps for all sorts of drivers and langugages.<br /><br /><br />note that not being able to speak Japanese myself, I might miss some details there.Peter Huttererhttps://www.blogger.com/profile/17204066043271384535noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-91986976115009076272009-08-21T05:13:57.276+10:002009-08-21T05:13:57.276+10:00I think it depends on what input method you are us...I think it depends on what input method you are using as well. Some input methods (those that are pinyin based, for example) uses alphabets and of course you want that to follow keyboard layout changes. Others (Bopomofo, Cangjie) that assign a symbol base on keyboard location probably want those symbols to stay the same regardless of keyboard layout.khchttps://www.blogger.com/profile/07481091721035993387noreply@blogger.comtag:blogger.com,1999:blog-6112936277054198647.post-27311316931398401072009-08-20T17:44:38.912+10:002009-08-20T17:44:38.912+10:00Actually, japanese is a kind of special case. Ther...Actually, japanese is a kind of special case. There are actually 2 ways of inputting japanese, each of which would imho fit in each scheme.<br />There are japanese hiragana written on keyboards, and they can be inputted directly, then IM would convert them to kanji if deemed necessary by the writer.<br />The second way involves combining latin characters to first form the hiragana, then possibly kanjis. There is no reason this method should require a japanese layout. There is no reason for a french keyboard owner to type 'hirqgqnq' to write 'ひらがな' while an us keyboard owner can type 'hiragana'.glandiumhttps://www.blogger.com/profile/00111150844502160018noreply@blogger.com