Hi Darren,
>> 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?
Unfortunately no, as iiim does not know if auto detect result is
wrong... (ioctl returns some info anyway)
> 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.
Yes, I know the variation in the same language version of layout
is causing confusion, and some issues have filed actually.
We're adding such variations (like Czech/Qwerty to Czech) as request
(filed issue) based for now.
And I'm planning adding user customizable layout emulation feature
to iiim. (I will send spec in the near future)
>> 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?
Execute 'iiimx -iiimd' will activate some features, but such environment
is not supported now.
>> 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.
Yes, it could be, although I'm not willing to develop iiim for S10U? and
OpenSolaris separately.
Thanks,
Naoyuki
