ちょいちょい「環境設定」→「セキュリティとプライバシー」→「アクセシビリティ」を開かせたいケースがあるが、openURL とかで Security.prefPane を開くだけだと「どこやねん」となりがちなので、アクセシビリティを設定するところまで一気に移動したくなる。

ScriptingBridge を使えばできるのだが、Objective-C でやる場合でもメソッド定義のヘッダファイルを生成して使うみたいな感じになっており、Swift からちょっと気軽に使おうと思うとダルくなってしまう。

フル機能を使うなら一度 Objective-C でラッパー書くのが正当だと思うが、一行も Objective-C を書きたくない気分のときは、プロトコルとエクステンションで必要なメソッドを強制的に定義してコンパイラを騙せば乘りきることができるようだ。

import Cocoa
import ScriptingBridge

// 元にないやつは optional にしないと extension でエラーになる
@objc protocol SBSystemPreferencesApplication {
    optional var panes: SBElementArray {get}
    func activate()
}


@objc protocol SBSystemPreferencesPane {
    optional var anchors: SBElementArray {get}
    optional var id: NSString {get}
    
}

@objc protocol SBSystemPreferencesAnchor {
    optional var name: NSString {get}
    optional func reveal() -> id_t
}

// protocol 定義を無理矢理使えるようにする
extension SBApplication : SBSystemPreferencesApplication {}
extension SBObject : SBSystemPreferencesPane, SBSystemPreferencesAnchor {}

struct Accessibility {
    static func checkAccessibilityEnabled(app: NSApplicationDelegate) {
        if AXIsProcessTrusted() != 1 {
            let alert = NSAlert()
            alert.messageText = "Require accessibility setting"
            alert.alertStyle = NSAlertStyle.CriticalAlertStyle
            alert.addButtonWithTitle("Open System Preference")
            alert.addButtonWithTitle("Quit")
            if alert.runModal() == 1000 {
                openSecurityPane()
                NSApplication.sharedApplication().terminate(app)
            } else {
                NSApplication.sharedApplication().terminate(app)
            }
        }
    }
    
    static func openSecurityPane() {
        // openURL 使うのが最も簡単だが、アクセシビリティの項目まで選択された状態で開くことができない
        // NSWorkspace.sharedWorkspace().openURL( NSURL.fileURLWithPath("/System/Library/PreferencePanes/Security.prefPane")! )
        
        // ScriptingBridge を使い、表示したいところまで自動で移動させる
        // open System Preference -> Security and Privacy -> Accessibility
        let prefs = SBApplication.applicationWithBundleIdentifier("com.apple.systempreferences")! as SBSystemPreferencesApplication
        prefs.activate()
        for pane_ in prefs.panes! {
            let pane = pane_ as SBSystemPreferencesPane
            if pane.id == "com.apple.preference.security" {
                for anchor_ in pane.anchors! {
                    let anchor = anchor_ as SBSystemPreferencesAnchor
                    if anchor.name == "Privacy_Accessibility" {
                        println(pane, anchor)
                        anchor.reveal!()
                        break
                    }
                }
                break
            }
        }
    }
}

フルサイズ5060万画素

ところで以前レンズの理論上の解像度限界というのを求めたことがあった。これは、絞りを絞るほど回折によってボケてしまうという物理的な絶対的制約からくる解像度限界だった。

フルサイズセンサ (36x24mm) で 8688x5792pixel だとすると、画素サイズは 約 0.00414mm なので、F7 波長500nm でのレイリー限界 0.00427mm よりも細かくなる。

高画素数になるということは、より回折にシビアなセンサーになるということになる。ある程度よりも (この機種の場合 F7 程度) 絞ってしまえば、いくら高画素でも解像度はあがらないので意味がない。

実際のところでは、回折ボケよりも手ぶれのほうが厳しい場合が多いように思われるが、とにかく回折による解像度の限界を感じやすくなる。

いろいろ確認していたところ、Chrome で Preview.app と色が違うことに気付いた。sRGB モニタで見ていると同じように見えるが、AdobeRGB 色域のモニタにウィンドウを移動するとかなり彩度が上がる。謎……

Google Chrome は ICC v4 には対応してないが、sRGB_IEC61966-2-1_black_scaled.icc は v2 なので、それが原因ではない。

結局、結論は「Google Chrome はプライマリディスプレイのプロファイルしか認識しない」だった。

マルチモニタ環境で、モニタごと別々の Chrome のウィンドウを置いておくと、プライマリモニタ以外は全て色がずれるので気をつけましょうという感じだった。

なお Safari だけがマルチモニタでのプロファイル適用に対応しているみたいだった。

USB 3.0 の伝送路における基本波が 2.5GHz なため、ISM バンドの 2.45GHz 帯 (2.4GHz〜2.5GHz)で電波障害が起きやすいという話。(波長の半分で1bit転送するのでデータレート的には5Gbps)

一応 USB 3.0 はEMI 対策として、スペクトラム拡散クロック (広い範囲にクロックを拡散することでピークを回避する) や、スプレッド処理 (信号経路には常にランダムのビットが流れるようにしてピークを防ぐ) をしているが、あまりに発生源とアンテナが近過ぎるとやはりダメらしい。

うちで使っているワイヤレスマウスも、USB 3.0 ハブに繋ぐとかなり挙動がおかしくてイライラする感じになる。

一定数以上のUSBデバイスを接続すると Mac が不安定になり、内蔵キーボード・トラックパッドなどが一切効かなくなる (USB バス全体が死ぬ感じ) という状況があり、よくわからないので、怪しいハブを止めたり、新しいハブを買ってみたりしていた。

そんななか、あるハブに替えたところバスが死ぬ前にエラーメッセージがでるパターンがようやく観測された。以下の通り (Console.app で USB を grep しながら見ていた)

the USB hardware ran out of device slots

このエラーメッセージで検索をかけたところ、まさにこの問題のことであろうFacebook のノートがひっかかった。

どうやら Haswell ではデフォルトだとたくさん繋ぐことができないらしい。このノートでもひとまずの解決方法が示されてはいるものの、USB 3.0 バスとの併用で疑問がある感じ。

リンクされているErgotron のドキュメントも読んだが、よくわからない。Haswell では25台以上はサポートしないと書いてあったり、もし30台以上のデバイスを繋ぐのであれば USB 3.0 デバイスは繋ぐなという感じのことが書いてある。

台数の根拠がよくわからないので、自分のところで追試を行なったが、「the USB hardware ran out of device slots」になるのは32台を超えたとき(32台までなら大丈夫)という感じだった。

そんなにいっぱい繋がないやろｗｗｗ とお思いだろうか？

system_profiler SPUSBDataType | grep 'Location ID' | wc -l

sudo nvram usb-options="%01%00%00%00"

sudo nvram -d usb-options

まとめ

USB 2.0 ですむ範囲のデバイスは USB 2.0 用のハブでまとめたほうが良い。今回のようなケースもそうだし、コスト的にもかなり安くすむ。USB 3.0 が必要なケースはそれほど多くない。カードリーダーや、HDD などぐらいだ。

また、DELL のディスプレイにはカジュアルに USB 3.0 ハブがついているが「せっかくだから…」と繋いでおいたりすると、上限を超えやすくなる。

というか根本的に127デバイスまでちゃんといけるようにしてほしい。

たとえば視力2.0の人が300ppiのディスプレーで十分に綺麗に（隣り合うピクセルを区別できない）見れる距離で使っていたとしたら、同じ鑑賞距離の場合視力1.0の人は半分の150ppiでも十分ということになってしまう。

というわけで、デスクトップのディスプレイを想定して鑑賞距離を50cm固定としたとき、各視力でどれぐらいのppiがあれば十分かを出してみた。

2K 24インチモニタの場合 96ppi なので、50cm の鑑賞距離の場合、視力 0.5 の人は 4K になっても気付きにくいということになる。