AquaSKK

Mac で SKK と言えば、AquaSKK (4.7.4)

OS 側の完璧な設定方法は次の通り：

設定 > キーボード > 入力ソース

入力ソースの設定

1. 英語は [＠] ASCII を追加
2. 日本語は [ア] カタカナ、[あ] ひらかな、[英] 全角英数、[ｶﾅ] 半角カナ、[あ] 日本語（※1）を追加（※2）
3. ABC を削除

本当は削除したいのだが、以前の macOS ではできたが、Big Sur ではできないようだ。

4. [あ] 日本語 を削除

macOS 標準の旧ことえり系はローマ字入力もかな入力もすべて削除可能。

5. 以上で（英語を除いて）SKK のみの入力モード間での切り替えとなる。

※1 [Ａ] ABC は macOS デフォルトの英語用キーボード

※2 AquaSKK 統合は選択しない

その他

  • メニューバーに入力メニューを表示：ON（設定 > キーボード > 入力ソース）
  • caps lock ⇄ control の入替：「設定 > キーボード > キーボード」の右下の「修飾キー」において設定
  • 入力ソースの切り替えショートカットキー：デフォルト（Control + Space）（設定 > キーボード > ショートカット）
  • 文頭を自動的に大文字にする：OFF（設定 > キーボード > ユーザ辞書）

辞書ファイルの管理

普通に辞書登録していってもいいのだが、この場合はユーザー辞書（~/Library/Application Support/AquaSKK/skk-jisyo.utf8）に蓄積されてしまう。ユーザー辞書は、過去の変換実績からの変換候補の表示順序のデータを記憶することが本来の目的であり、純粋な辞書ファイルとしては、未整理で見辛い。

そこで、自前の辞書ファイル ~/.skk-jisyo（テキストファイル）に手動でエントリーを追加することにしている。Aqua-SKK の環境設定のデフォルトではこのファイルの辞書の種類は EUC-JP になっているので、UTF-8 に変更している。

自前で辞書ファイルを作成・編集する場合に、フォーマットは、各エントリーが「ひらがな /平仮名/」という形で、さらに、「;; okuri-ari entries.」「;; okuri-nasi entries.」によるカテゴリー分けは必要なので、そこには注意する：

;; okuri-ari entries.
よi /良/酔/善/
;; okuri-nasi entries.
かんじ /漢字/

その他、

  • ユーザー辞書に誤登録された漢字を削除 → Shift + x で yes/no で yes をタイプ
  • 通常のユーザー辞書登録時に、コピー＆ペーストしようとしても、SKK の外側にコピーされてしまう → Ctrl + y でペースト

コメント

コメントを投稿

このブログの人気の投稿

Mac → Mac のメールアカウントの移行

イメージ
旧 Mac（MacBook 12inch Early 2015）から新 Mac（MacBook Air M1）へメールアカウントを移行した。IMAP なので、データをエクスポート＆インポートするような必要はなく、新 Mac 側でメールアカウントをセットアップするだけである。それもメールアカウントの設定自体、iCloud で管理しているので、新 Mac 側で iCloud へサインインした段階で復旧される。 メールの動作に不具合が発生 ところが、メールの動作に不具合が発生した。削除したはずのメールが何度も何度も受信ボックスに戻ってくる。 仕方ないので、一旦メールアカウントを iCloud に保存された設定も含めて削除して、改めて手動で設定し直した。すると問題は解消された。 IMAP アカウントの設定 Gmail などのテンプレートにあるアカウントの場合は問題ないと思うが、その他の一般の IMAP アカウントを設定する場合、デフォルトでは、メールボックスの設定がうまくいっていなかった。メールサーバーに元からある受信・送信済・ゴミ箱・迷惑メールが使われず、新たなメールボックスがそれぞれ作られてしまうので、手動で設定し直して、重複するものを削除する手間が必要だった。 @sakura.ne.jp（独自ドメインメール）: IMAP を使っているのでポート番号などのサーバ設定等は細かく設定し直す必要があり、単に iCloud からの復旧されたデフォルト設定のままでは上手く機能しない。旧マシン（macOS）の各設定画面を記録しておいてそれを参考にすると復旧しやすい。 @gmail.com: メールボックスなどの反映に少々のタイムラグがある。そのままでも大丈夫だと思うが、メールボックスの割り当ては再設定し直した方がより確実かもしれない。 署名の設定 署名もデータ自体は残っているものの、アカウントとの紐付けが復元されなかったので、改めて手動で設定し直す必要があった。すべての署名からアカウント毎にドラッグして移動した上、「署名を選択」で該当署名を選択しておくことで、メール作成時に自動で署名が入るようになる。
続きを読む

WireGuard の OpenWrt での運用

イメージ
VPN と言えば、以前は OpenVPN だったが、最近のトレンドは WireGuard （言うなれば、Apache に対する nginx のような？）。先日まで OpenVPN の設定を徹底的にやり込んで納得行く状態が確立できた ばかりなので、引き続き、VPN のこと自体にある程度フレッシュな知見がある今のうちにと思って、手がけてみることにした。 ソフトウェア R7800（hnyman ビルド）では、デフォルトで wireguard-tools、kmod-wireguard、luci-app-wireguard、luci-proto-wireguard がインストールされていたので、wireguard のみ、LuCI から追加でインストールした。 鍵ペアの用意 mkdir -p /etc/wireguard cd /etc/wireguard wg genkey | tee privatekey | wg pubkey > publickey /etc/wireguard/privatekey と /etc/wireguard/publickey が生成される。さらに、おまけとして presharedkey も使う場合には： wg genpsk > presharedkey /etc/wireguard/presharedkey を生成する。 以上のファイルのパーミッションを念のため、600 にしておく。 chmod 600 *key ネットワークインターフェースの追加 Network > Interfaces で WireGuard 用の論理ネットワークインターフェースを追加する。プロトコルを WireGuard VPN にするのがポイント。名前は wg0 にしておいた。 OpenWrt では、LuCI では専用のメニューが用意されている OpenVPN と違い、WireGuard はこの Network の Interface としての設定ですべてを管理するようになっているようだ（つまり /etc/config/network に記載される）。 Private Key の欄に /etc/wireguard/privatekey の内容をコピー＆ペースト Listen port: 5182
続きを読む

LiveData と MutableLiveData の使い分け

イメージ
observe 関係の場合は、できるだけ ViewModel と View（Activity 含む）の関係を疎にして、一方通行の関係がいいと思う。つまり、ViewModel 内部では MutableLiveData 扱いのデータを LiveData にして外側、つまり View 側に対してさらす形である。 private MutableLiveData<T> mData; public LiveData<T> getData() { return mData; } 一方、user action を ViewModel に入力する場合はどうするのがいいか？ この場合は、user action の影響を受ける LiveData は、View/Activity からの入力で変化することが当然であるから、上の observe の場合のように MutableLiveData を getter で隠蔽することは冗長である。なので、public な MutableLiveData を getter を介さずに直接さらしてしまえばいいと思う。 public MutableLiveData<T> mData; そうして、当該 MutableLiveData に関する処理を、無理矢理 ViewModel に置かずに、素直に、View/Activity 内で処理を記述するのが、 実は 適切だと思う。 というのも、user action によって処理を分けたいのは、View/Activity 側の都合であって、ViewModel 側の場合ではないケースが考えられるからである。通常、user action を受け付けるのは、Activity が active すなわち、onResume から onPause の間のライフサイクルにおいてである。なので、その間のみ処理を行って、それ以外のタイミングでは処理を停止しているような形にするのが望ましい。そうなると、それらの処理の主となるコードは、Activity 側の各ライフサイクルに応じたメソッドに配置して、処理の結果変更を受ける変数のみ、MutableLiveData として ViewModel 内に所属させておくのがストレートなコード表現になるわけである。 サンプ
続きを読む