2020-07-27

 Mac, Windowsを両方使用している環境で共通利用できるキーボード配列を検討してみる。
 無論、Mac歴の長い筆者に最適な前提とする。

 先ず、Apple標準キーボードやApple拡張キーボードの配列を再確認してみる。

 最下段を観察すると以下の配列である。

標準
[Control]
[Shift]
[Caps][Option][Command][`][SPACE][\][←][→][↓][↑]

拡張
[Caps]
[Shift]
[Control][Option/Alt][Command][SPACE][Command][Option/Alt][Control]

 Mac OSではショートカット入力で最も使用頻度が高いのは[Command]キーであり、Mac OSに慣れていると「ショートカット入力をするには、スペースバー隣接キーを押下」が標準的な動きである。

 所謂106キーボードでは以下の様な配列が多いと思う。

[Caps]
[Shift]
[Control][GUI][Alt][Space][Alt][App][Control]

 Mac OSで106キーボードを認識させた場合の標準定義は[GUI=Command][Alt=Option]となっており親指隣接キーが入れ替わった状態になる。この2種類のキーを入れ替える事でWindows用キーボードをMacに接続した場合の違和感は消える。(この入替はMac OSでも必要と考えている様でOS標準機能で入替可能)

 ここで発生するのがWindows OSも併用している場合の違和感である。Windowsでショートカット入力で最も使用頻度が高いのは[Control]であり、Mac OS操作時とWindows OS操作時でショートカット操作で押すキーの場所が異なる、という厄介な事になってしまう。(続く?)

2020-07-22

 職場でアプリチームから「開発機をリース返却するのでHDDを全消去」という要望が来た。
 サーバはHPE製品で、intelligent provisioning機能を起動してRAID設定とディスク消去すれば良いので、安請け合い。

 ところが、intelligent provisioningが起動しない。電源投入後F10を押下するとintelligent provisioningへ遷移する筈だが、そのままスルーして光学メディアによる起動を試行してしまう。
 HPEのサポートサイトを確認すると、intelligent provisioningの更新用.isoが提供されているので、これをUSBメモリに焼いて起動、intelligent provisioningを再導入せよとある。これを試したのだが、本体NVramへの書込に失敗した旨のエラーで導入できない。

 困ったところで思い出したのはGPartedである。これはdebian linuxにパーティショニング用ソフトを追加したlive linuxである。debian LinuxではHW RAIDも各種サポートしている。
 GPartedを起動して、既存パーティションを破壊。1パーティションに変更する。
 その後に、GPartedに含まれるshellを起動、shredコマンドで当該パーティションを安全に消去すれば良い。
 ディスク消去と言えばDbanがあるが、こちらはHW RAIDへの対応が無いのでサーバには使えない。

 一つ失念していたのは、shredコマンドをオプション無しで実行してしまった事である。-vオプションを付与しておけば進捗が見えるのだが、どの程度で終わるのか判らない状態である。また、標準で3回ランダムデータ書込するのだが、最近の高密度ディスクであれば1回の書込で十分である。
 何と言っても1TB HDD x12本で実容量10TB(消去速度向上のためRAID 0設定に変更)もあるので、4連休で何とか終わって欲しい....。

2020-07-21

 チラシの裏です。
 iris keyboardからF13,F14を送出、Windows IMEをon/offができる様になった。
 しかし、Mac OSからRDP接続すると、上記のキーコンビネーションが利用できない。

 Mac OSでKarabiner-Elementsを設定してF13,F14をLang2,1へ割当しているので、これを一時的に解除。
 Mac OSからRDPでWindowsへ接続。
 Keymillで観測すると、F13はPrint Screen、F14は無反応であった。

 調査する(Link pdf)と、Mac OSの拡張キーボードはPrint Screen Keyは存在しない。F12の隣はF13が位置している。Windows Keyboardでは当該箇所はPrint Screenが位置している。Mac OSではiris keyboardのF13がPrint Screenとして認識されており、これがRDPを伝わってWindowsでPrint Screenとして認識されている様子。
 しかしながら、F14がScroll lockとして認識されないのは謎。

2020-07-18

 時間があったので、iris keyboardのキー配列を再考してみた。

 この手の鍵盤を使って判ったのが親指の可動範囲は想像以上に狭い事である。

 最下部に3個+1個の親指用鍵盤があるが、一番押し易い3個並んでいる中央のキーは良いが、残りは意外に押しづらいものである。

 そこで、この一番押し易いキーには何をさせるかが悩みどころである。
 色々なサイトを眺めると、IME切替「変換」「無変換」、レイヤ切替「Lower」「Raise」、入力頻度の高い「Space」「Enter」のどれか複数が陣取っている様だ。
 当初の実装は「TapでSpace、HoldでLower」「TapでEnter、HoldでLower」としていたが、IME切替がどうしても欲しくなって来た。時々強制的にIME onにするアプリが増えている気もするので。

 次に、上記の人気3種類をどの様に2個のキーに実装するかである。
 試行錯誤と妥協の結果は次の通り。

左中央「TapでSpace、HoldでLower、このキーをHoldして右中央キーを押すとIME on」
右中央「TapでEnter、HoldでLower、このキーをHoldして左中央キーを押すとIME off」

 当初はTap danceによる入力も考えたが、Tap Danceは意外に操作時間が必要と判ったので、上記の設定が一番良さそうである。

 次に、レイヤロックの配置を再検討した。
 従来は、10key、カーソルレイアは存在したが、「LowerまたはRaise + 右親指右端」の組み合わせで意外に使いづらいので、色々試してみた。

 新配置は、「Lower Hold」+「反対側Lower Double tap  or  Raise Double Tap」で特定レイヤをロックする設計とした。これにより、Adjust以外の全レイヤをロック可能とした。
 また、当方環境ではLEDが実装されていないので、レイヤロックの判別が難しく、レイヤ位置が判らなくなった時の為に「Lower Hold」+「ALT or GUI Double Tap」でロック解除する設計とした。

 実装は以下を参考にしている。

https://okapies.hateblo.jp/entry/2019/02/02/133953
http://leopardgecko.hatenablog.com/entry/2019/01/04/131410






 上記がdefault配置である。キー前面がHold時挙動。
 Shiftキーは2個あるが、変則仕様。
 右ShiftはTapでバックスラッシュ、+ 左Shiftでパイプ、HoldでShiftの複合としている。キー数が少ないので、JIS配列の真似である。
 左ShiftはTriple tapでCaps Lockとしている。
 Shiftキーは通常Tap動作が不要であり、他のキーを押下する際にHold出来れば良いので上記の設定としている。

---追加---

 右手側にCTRLが少ないので、左手側対象位置の「'」にHOLD時CTLを追加した。
 ブラウザのタブ切替でCTL+TABを頻繁に使用するので便利。




 上記がLowerレイヤである。キー右上はTap Dance操作の挙動となる。Lowerキーは2個あるので、Lowerキーに割当されている機能は反対側のLowerをHoldして指定する。
  例えば、右LowerをHoldした時に左Lowerの機能は次の通り。

Tap...F13(OS機能でIME off)
Hold...Space(余り無いが、スペースキーリピート)
Double Tap...Numpad layer lock




 上記がRaiseレイヤである。主にFunction Key入力を想定。


 余り美しく無いコードは以下。

https://github.com/7k2mpa/qmk_firmware/tree/master/keyboards/keebio/iris/keymaps/7k2mpa

2020-07-17

 何を当たり前の事を言っているんだと思われますが、qmkで嵌ったの備忘録。

 その1

 筆者はThinkPadの英語配列キーボードモデルを使用している。この機種はBIOS上でCaps LockをCTRLに置換してくれる機能がある。この機能設定ではOSからはCaps Lockは存在していないと扱われ、物理キーの押下でCaps Lock状態には出来ない。
 ここで外部キーボードとしてiris keyboardを接続するとどうなるか?
 iris keyboardのCaps Lockキーを押下してもCTRL扱いになってしまうのであった。

 筆者のqmk設定は左shift 3連続でCaps Lockコードを送出する設定だがWindowsで確認するとCTRLキー押下になっていた。
 この辺の仕組は謎であるがUSBキーボード経由の操作でもBIOSでキーコードが置換されているのだろう。


 その2

 上記の様に英語配列キーボードとなっているため、本体のキーボード上には「変換」「無変換」キーは存在しない。
 日本語IMEのon/offの明示的なon,offとして「変換」「無変換」を割当する技がある。
 ThinkPad本体に「変換」「無変換」キーが無くても、外付キーボードに「変換」「無変換」キーが存在すれば、IMEの明示的なon,offが出来るのでは?と期待したが、駄目である。
 「VK_OEM_PA1」としてOSからは認識されてしまい、このキーコードはIMEの制御用キーとして定義できない。
 よってiris keyboardでは「F13」「F14」を送出するように設定して、IME on,offを前述のキーに割当する。

2020-07-08

 以下は筆者の独自研究が含まれています。

 Microsoft製品、特にOffice系製品はUI設計が悪化する一方である。

 初期のOffice(Office 2003辺りまで)ではメニューに関して良くも悪くもMacと似た様なキー操作体系を取っていた。
 Mac OSであれば、コマンドキー押し下げに、何らかのキーを押す。例えば、Command + Qはアプリの終了とガイドラインがあり、それに沿った実装が原則。
 WindowsもCtrl + Xが大概はアプリ終了のショートカットである。
 この時代のショートカット(メニュー呼び出し)は「何らかのmodifer keyを押しっぱなしにする」「特定のキーを押す」という操作が基本であった。

 この原則が怪しくなるのがOffice 2007辺りである。(バージョンは忘れた)
 リボンインタフェースが採用されたのだが、この代償が大きかった。コマンド呼び出し方法が追加されただけであれば問題は無かった。リボンインタフェースを非表示にすれば良い。

 どうも、Microsoftとしては「メニューのコマンドとショートカットを覚えるのは難しいから、リボンインタフェースのボタンをマウスで押させれば良い」と考えている節がある。

 キーボードショートカットは従でマウスが主と考えたのだろうが、Office製品のExcel、Wordではキーボード操作が主だと思うのだ。頻繁にマウスとキーボードとの持ち替えは辛いものがある。また、マウスを主としてリボンインタフェースを使うにしても、アイコンのメタファーが不適切で(独自研究)アイコンを押すと何が起きるのかよく判らない。

 さらに大きな問題はショートカットキーが大幅に変更された事だ。
 ここで「Ctrl + 1文字」のショートカットキー操作体系が崩れた。従来の「Ctrl + 1文字」のショートカットの一部が、「Altを1度押す。プルダウンメニューを選択する1文字を押す。プルダウンメニューから目的のコマンドを選択する1文字を押す」という3アクションに変更されてしまったのだ。 これでショートカットの操作方法が2種類になってしまった。


 そしてとどめはOffice 2010辺りから導入されたメニューバーの一番左にある謎アイコンである。
 Windows,Macに限らず長年、メニューバーの文字部分を押すとプルダウンメニューが表示される、という伝統であったが、一番左の謎アイコンはプルダウンメニューではなく、初期設定等の新ウィンドウが表示される。これでUIとしての一貫性も無くなってしまった。

 Mac OSも近年はUI一貫性が崩れているが、キー操作の一貫性は残っている。

 無論、タブレット端末時代を踏まえるとキーボード前提のUIは、という意見も判るのだがOAの世界では教育コストも馬鹿にならないのでUIの一貫性は重要だと思う。

2020-07-01

 数年間HP MicroServer & NAS4Free によるファイルサーバを運用してきたがRACのJava対応やHWサポート期限を考慮して次期HWによる更新を行った。

MB:ASRock X470D4U
Memory:Crucial CT16G4DFD8266.C16FD1 x2 32GB実装
Case:Cooler Master CM690
Power:Antec NeoEco 550Gold
CPU:Ryzen 1600AF







自己紹介

自分の写真
東京都, Japan
憂鬱な凍死家です。こちらではmixiとは異なり固めの話題中心です。

Total Page View

Categories

Powered by Blogger.

Popular Posts

Blog Archive