Hi Naoyuki,
Naoyuki Ishimura wrote:
> Hi Darren,
>
> I'm RE of iiim keyboard layout emulation functionality.
>
> Are you talking about current physical keyboard detection
> mechanism which is base information for layout emulation?
> If so, user/system locale is not involved for that.
> It's detected by using ioctl as Takao said.
> So if user uses remote system and
> the physical keyboard type/layout does not match with the
> result, then he/she needs to set it manually with iiim-properties
> 'Keyboard' tab to use layout emulation functionality.
Is the user made aware of this - i.e. if it wasn't possible to detect are they
prompted or a notification icon shown?
> This should be enhanced in the future, but there is
> no public API (yet) which can be used for detecting user's physical
> keyboard type/layout as far as I know.
I don't know of one either other than the IOCTL mechanism you use.
>
> If you are talking about default emulation layout when you type
> IM trigger key, then yes it's determined by user's locale.
> The default emulation layout can be changed if you use other type
> of emulation with IM switcher and check
> "Set the last selection as default language" option
> in iiim-properties (General tab).
I think that this is ok.
>
> Sorry, if I'm talking different thing, but I'm not sure
> what 'select layout by type' means in iiim context.
What I'm referring to is variations of the physical layout of a keyboard - while
there are differences in layouts based on locales - e.g. QWERTY, AZERTY, etc.
even with a single QWERTY layout there can be significant variances in the
locations on the keyboard for other keys, e.g. double-quote (") and ("@"), euro,
punctuation characters, arrow keys, function keys, etc.
This is especially prominent with laptops where the keyboards are usually
squashed down to fit and as a result keys are moved around more. While there
appears to be a defacto PC standard which *most* PC keyboards maintain, if you
look at something like the MacBook Pro, it's layout is different enough to cause
pain for people that touch-type - and programmer more than document writers
given the use of symbols while coding.
A further step on this is whether we support different keyboard layouts
(variants) based on a laptop keyboard vs the attached USB keyboard - e.g. while
I could work to configure XKB and X to make my MacBook Pro keyboard work as
expected (symbols generated match picture on key) - if I then attach a Sun
keyboard then the keys generated there don't match the pictures on that keyboard
even if they are both English (UK) layouts.
>
> Regarding C (non UTF-8 or Asian) locale, the Input Method
> server (iiimd) is not running, and iiim functionality (including
> keyborad layout emulation) is not activated.
> It may be future enhancement, but current our priority is UTF-8
> locale.
Understood, but I'm wondering if it *could* be enabled now, without more work?
If not, then maybe the keyboard switcher applet could be used to fill that gap?
>
> BTW, iiim does not use XKB data at runtime, but uses XKB symbol data
> at iiim build time (/etc/iiim/layoutdata.xml).
> The reason is that we want to support non XKB env (Xsun default).
Agreed, but since Xsun is being EOL-ed then I think we can consider moving on
from that with Open Solaris and focus on Xorg for enhancements.
Thanks,
Darren.
