月別: 2015年5月

Macbook Proにテンキーを

Macbook Proのキーボードからの数字入力も慣れてくればそれほどの苦痛ではなくなってきたのですが、エクセルなどで大量のデータ入力などの際には、さすがに音を上げてしまいます。
あれこれとUSBだとかワイヤレスだとかのテンキーを探してみたりもしたのですが、いまいち納得ができません。commandキーやoptionキーなどとの組み合わせで機能するのかなど、不安要素は幾つかあります。
そんな時、5〜6年前くらいでしたか、iPod Touchでテンキー入力ができていた記憶が蘇ってきました。結局、iPod Touchの置き場所というか配置がマウスの位置とかぶるので定着はしなかったのですが、今回はなんとか工夫のしようもありそうです。
で、発掘した(?)のがiPod Touchの第1世代でした。iTunesで見るとプロダクトタイプが「iPod1,1」となっていますので、間違いなく第1世代ですね。となると、春頃に買った記憶があるので2008年春のことですね。すっかり第1世代はパスして第2世代を買ったと思っていたのですが、記憶っていい加減なものです。

■掘り起こしたはいいが、果たして使えるのか?

完全にバッテリーも上がっていましたが接続するとも問題なく通電でき、充電もできたので、iTunesでリストアしました。できるんですねこんな古い機種でも。リストアできる最新OSが3.1.3で、現役だった頃のアプリケーション類はほとんど消えています。現行のiOSのバージョンが8.3ですからこのギャップがどうなるのか?
先ずは、現役のアプリケーションの中から、テンキー機能のものを探してみることにしました。

・iNumKeyPadFree – WiFi numeric keypad
<https://itunes.apple.com/jp/app/inumkeypadfree-wifi-numeric/id358638852?mt=8>
<http://www.mbpowertools.net/iDevices/Home.html>
<http://www.mbpowertools.net/iDevices/Download.html>

screen480x480_programView1_273431.png

先ずはフリーバージョンがあるというので試しにインストールしてみました。Num Lockが付いていて、オフィス系では便利かもしれないなと思いつつ繋いでみました。iOS 3.1.3で動作すること自体が驚きなのですが、それなりに起動して、Macbook Proと接続できました。
ところが、入力をMacbook Pro側に反映させるタイムラグがものすごいことになります。
適当に10桁入力すると最初の1桁目が反映されるのに数秒、残りは取りこぼしも発生し、軽く30秒は無反応の後に歩くくらいの感覚で反映されます。う〜ん、実に、使えません。多分、iOS 3.1.3でハードウェアが2007年のものだというころに原因があるのでしょう。現行のiOS搭載マシンではきちんと動作するんだと思います。

・NumPad Remote<http://mediaware.sk/ware/?page_id=487>

iNumKeyPadFreeで若干くじけてしまったので、試用もできないまま、360円を支払う気になれません。他に手立てが亡くなった時にもう一回考えます。

・NumberKey Connect.app – NumberKey Free<http://www.forest.impress.co.jp/docs/review/20091215_335847.html>

写真

2009年に使っていたのは「NumberKey Free」という名前でした。あのバルミューダがリリースしていたんですね。バルミューダのサポートページ<http://www.balmuda.com/jp/support/category/numberkey>は見つけて、NumberKey Connect.appはダウンロードしたのですが、「.ipa」ファイルがどうしても見つけられません。
2009年当時のバックアップディスクを掘り出すことにしました。
無事ゴミの山からのサルベージに成功して、「NumberKey Free.ipa」ファイルをインストールしてみると、案の定というか予想通りというか無事動作しました。2009年作のNumberKey Connect.appがOS X 10.10 Yosemiteで動作するのも嬉しいところです。
こちらはタイムラグもなく、command、option、shiftキーとのコンビネーションも機能します。

■iNumKeyPadFreeの名誉回復のために再インストール

iPad2であれば動くのではないかと思い、一旦捨てたiNumKeyPadFreeを接続用のアプリケーション「iReceiver.app」と併せて再度ダウンロードしてインストールしてみました。
iPad2では問題なく動作しました。
いま一度と思い、iPod Touch 1st gen.にも入れてみたところ、今度は正常に動作し、タイムラグもなく動きました。
前回のギクシャクはなんだったんだろうという結果です。
「Num lock」を使えば、カーソルキーとしても機能しますので、その辺がメリットであればこれもありでしょう。
1点残念なことは「*」キーが「(」に変わってしまうことで、現時点で解決策が見当たりません。

結論として、多分(?)「NumberKey Free」を使うことになるでしょう。
「NumKeyPadFree」は、iPod Touch 1st gen.の画面ではキーサイズが小さく感じます。
iPhone5, 6では問題ないのでしょうね。

広告

TextWrangler.app / BBEdit.appで日本語の文字種変換をやってみる

長い間TextWrangler.appを使い続けていて、機能面で不足を感じていた訳ではないのですが、つい出来心(?)でBBEdit.appにアップデートしてしまいました(次のメジャーアップデートの際に、有料でアップデートするかどうか悩ましいところです…)。
有難いことに、スクリプトは(ほぼ?)完全互換のようで、TextWranglerr.app用に書いたものは全てBBEdit.appで動作します。逆も然り。
AppleScriptではScript内の‘Tell application …’以下の名称をTextWranglerからBBEditに変更するだけです。

現在、mi.appでやれることはほぼBBEdit.appでもやれるようにしていますが、日本語の文字種変換だけ手付かずのままでした。

BB

日本語の文字種変換は、対応していないアプリケーションでも「サービス」に対応していれば、‘CharConvX.app’<http://www5.wind.ne.jp/miko/>を使えば実現できてしまうので、それはそれでいいかな、と放置していたわけです。

で、結局‘sed’を使ってみることにしました。

set vString1 to "アイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワヲンァィゥェォャュョッー・「」。、゚゙"
set vString2 to "アイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワヲンァィゥェォャュョッー・「」。、゜゛"

tell application "BBEdit" --BBEditをTextWranglerに置き換えればTextWrangler.appで動作します
	activate
	if (selection of text window 1 as string) is not "" then
		replace "ヴ" using "ヴ" searching in selection of project window 1
		replace "ガ" using "ガ" searching in selection of project window 1
		replace "ギ" using "ギ" searching in selection of project window 1
		replace "グ" using "グ" searching in selection of project window 1
		replace "ゲ" using "ゲ" searching in selection of project window 1
		replace "ゴ" using "ゴ" searching in selection of project window 1
		replace "ザ" using "ザ" searching in selection of project window 1
		replace "ジ" using "ジ" searching in selection of project window 1
		replace "ズ" using "ズ" searching in selection of project window 1
		replace "ゼ" using "ゼ" searching in selection of project window 1
		replace "ゾ" using "ゾ" searching in selection of project window 1
		replace "ダ" using "ダ" searching in selection of project window 1
		replace "ヂ" using "ヂ" searching in selection of project window 1
		replace "ヅ" using "ヅ" searching in selection of project window 1
		replace "デ" using "デ" searching in selection of project window 1
		replace "ド" using "ド" searching in selection of project window 1
		replace "バ" using "バ" searching in selection of project window 1
		replace "ビ" using "ビ" searching in selection of project window 1
		replace "ブ" using "ブ" searching in selection of project window 1
		replace "ベ" using "ベ" searching in selection of project window 1
		replace "ボ" using "ボ" searching in selection of project window 1
		replace "パ" using "パ" searching in selection of project window 1
		replace "ピ" using "ピ" searching in selection of project window 1
		replace "プ" using "プ" searching in selection of project window 1
		replace "ペ" using "ペ" searching in selection of project window 1
		replace "ポ" using "ポ" searching in selection of project window 1
		set PreString to (selection of text window 1 as string)
		set the clipboard to my Sed_y(PreString, vString1, vString2)
		delay 0.1
		paste
	else
		display notification "文字列を選択してから実行しましょう。" with title "Notification" subtitle ""
	end if
end tell

to Sed_y(TheString, SString1, SString2)
	do shell script "export LANG=ja_JP.UTF-8; " & "echo " & quoted form of TheString & " | sed -e 'y/" & SString1 & "/" & SString2 & "/'"
end Sed_y

半角カタカナの濁音・半濁音については、半角カタカナが2文字に換算されるので‘sed’のルーチン枠内では変換できないので、無骨に1文字ずつ置換をしています。逆方向の変換は変数を逆にすればOKです。
このやり方をベースにすれば、全角英数字⇄半角英数字の変換も容易です。

言語環境を’en’にしてみると、都合のいいことも悪いことも…

OS Xは最初のバージョンが出てきたときから、マルチランゲージと言われていました。
確かにそれぞれの言語ごとのパッケージではなく1パッケージに複数の言語環境がパッケージされていましたから、各言語ごとに異なるパッケージを購入する必要がないということは素晴らしいことでした。
しかし、実際に、例えば‘en’環境の下で‘日本語’アプリケーションを使おうとすると、メニューなどのUIが追随しなくて正常に動作しないものや、インストール時に‘日本語’を選べないアプリケーションが多くありました。
まがりなりにも‘マルチランゲージ’と言えるのはFinderとInputMethodくらいしかないじゃないかと悪態をつきたくなるような状態が結構長く続いたので、OS X 10.6, 7くらいまではそれなりに試してがっかりを繰り返したのですが、その後、諦めきってしまったのでわざわざ‘en’環境にしてみることもなかったのです。
ところが、ついうっかりOS X 10.10 Yosemiteに切り替えてしまって、余りのメモリ使用に関して”富豪主義”というか”大喰らい”というか、あればあるほど喰らうんだねえおまえはと言いたくなる有様にうんざりしてしまったので、ものは試しで‘en’環境にしてみました。

en1

うん、ちゃんとマルチランゲージだわ。Finderだけじゃないですね。
Adobe系のアプリケーションがきちんと動作することにはびっくりしました。(なんと、CS3がまともに動作します)

そもそも、Photoshop、Illustratorなどは英語マニュアルで覚えましたので、変なローカライズメニューの方が辛かったりします。

設定した言語と地域の情報は、‘~/Library/Preferences/.GlobalPreferences.plist’にそれぞれ‘AppleLanguages’、‘AppleLocale’キーとして保存されます。
それぞれのアプリケーションは、‘AppleLanguages’キーを読んでUIエレメンツを差し替える仕組みのようです。

■言語環境を’en’にしてみて、都合が良かったこと
数値データとして裏打ちできないのですが、確実に起動時と運転時のメモリ使用量が減ってきます。
日本語リソースがどの程度キャッシュされるのか、比較データを示せないのが残念ですが、クールブートしたときのメモリ使用量が明らかに減って来るのと、その後の変化を見てみても‘ja’環境よりはメモリ使用量が減っています。

■出てきた不具合
幾つかのアプリケーションで、‘en’環境では不具合が出るものが見つかりました。

  • Safariの不具合

Firefoxなどと異なって、Safariはアプリケーションサイドでの言語設定ができません。

en2

図は、確認くんのページですが、赤線の部分のように‘en-us’と表示されます。
従って、ブラウザの言語設定を読んで、ログイン制限をかけているサイトではアクセスできない所が出てきます。
私の場合も、プロバイダのログイン画面から先に進めなくなってしまいました。
対処としては、言語設定を変更できるFirefoxなどのブラウザに切り替えるという手があります。
もう一つは、Safariの言語設定を強引に切り替えるという方法もありでしょう。
探してみたところ、‘default write…’でSafariの言語設定を書き換える方法がみつかりました。

$ defaults write com.apple.Safari AppleLanguages -array ‘ja’

‘~/Library/Preferences/com.apple.Safari.plist’ファイルに‘AppleLanguages’を書き加えるという手法です。

設定を元に戻すのは、

$ defaults delete com.apple.Safari AppleLanguages -array ‘ja’

で、システム側の言語設定に切り替わります(アプリケーションの再起動は必要です)。

  • mi.appの「ツール」コマンドの不具合

‘<<<TRANSLITERATE-REGEXP-SELECTED()’が正常動作しなくなりました。()の中に文字種変換のフィルタ名を挿入して使うのですが、英語名で入れても動作しません。(ver. 3.0.0b8)
ここは諦めて(素直に)mi.appの言語設定を書き換えることにしました。
方法はSafariと同じようなことです。

$ defaults write net.mimikaki.mi AppleLanguages -array ‘ja’

‘~/Library/Preferences/net.mimikaki.mi.plist’ファイルが対象です。

これは、‘defaults write…’ではなく‘plutil’コマンドを使うこともできます。
例えば、こんな風になります。

$ plutil -insert ‘AppleLanguages’ -xml ‘ja’ ~/Library/Preferences/net.mimikaki.mi.plist

通常使用時には、システムの言語設定を読んでいますので、‘AppleLanguages’キーを‘~/Library/Preferences/net.mimikaki.mi.plist’ファイルは持っていないので、オプションは‘-insert’でOKです(書き換えの場合は‘-replace’でないとエラーとなります。‘defaults write…’の方が間違いがないでしょうね)。

設定を元に戻すのは、

$ defaults delete net.mimikaki.mi AppleLanguages -array ‘ja’

で、システム側の言語設定に切り替わります(アプリケーションの再起動は必要です)。