AppKit のクラスって普段 UIKit を触る人々から誤解を受けやすいが、中でも NSImage はその筆頭｡「UIImage なら cgImage プロパティで簡単に CGImage を取り出せるのになぜできない？｣｢representations ってなんだよ｣｢洗練された UIImage に比べて無駄に複雑｣｢これだから過去の遺物は...」などなど、言われてない被害妄想も簡単にできる。
だが実際にはよくできた設計の柔軟性のあるクラスで、正しい知識で使いこなすと UIImage は NSImage のほんの一部の機能しか提供していないのがわかってくる1。
最近 AppKit 用に作っていたフレームワークを UIKit でも使えるように変更作業をしたのだけど、UIImage だと該当する機能が存在しなくて大変だった。 ↩︎
AppKit で Label といえば、NSLabel ...ではなく NSTextField を使う。それを Auto Layout 1で扱うのが今日のテーマだ。
単純に配置するだけなら何も考えなくていいけど、必要な幅が長くなったら下の GIF アニメーションのように折り返したい。
こうやって上下左右に Constraint を追加しただけの単純なウインドウで考えてみよう：
個人的には Auto Layout は行単位のリストで完結することが多い iOS よりも環境設定ウインドウをはじめとして UI 部品が縦横方向に積み重なる Mac App でこそ活きる気がしている。言語ごとの変化まで考えるとこれがない世界には戻れない。 ↩︎
最近の Swift では Decodable に準拠したオブジェクトを簡単に JSON から変換できる。
struct Root: Decodable
{
let texts: [String]
let isFine: Bool
}
let root = try JSONDecoder().decode(Root.self, from: """
{
"texts": ["hello", "again"],
"isFine": true
}
""".data(using: .utf8)!)
root.texts //["hello", "again"]
root.isFine //true
上のようにあらかじめかっちりと定義した通りのデータが与えられるときは自動でやってくれて便利だけど、実際にはそうもいかなくて難しい。
例えば、次のようにバリエーションが複数ある場合：
protocol Parameter: Decodable
{
var type: ParameterType { get }
}
struct BoolParameter: Parameter
{
let type: ParameterType
let defaultValue: Bool
}
struct NumberParameter: Parameter
{
let type: ParameterType
let defaultValue: CGFloat
let minValue: CGFloat
let maxValue: CGFloat
}
enum ParameterType: String, Decodable
{
case bool
case number
}
BoolParameter と NumberParameter は同列な存在でどちらも Parameter に準拠させている。JSON では独自の型情報を定義できないので Parameter.type を用意して区別することにする。
Yosemite から AppleScript の代わりに使える JXA、せっかく JavaScript なのだから Promise が使えるかどうか実験してみよう。
const getWindowNames = async (appName) => {
const app = new Application(appName);
const windows = app.windows;
return windows.name();
}
const getFileNames = async (path) => {
const fileManager = $.NSFileManager.defaultManager;
let error = $();
const fileUrls = fileManager.contentsOfDirectoryAtURLIncludingPropertiesForKeysOptionsError($.NSURL.fileURLWithPath(path), [], 0, error);
return fileUrls.js.map(url => url.lastPathComponent.js);
}
let x = null;
Promise.all([
getFileNames("/System"),
getWindowNames("Finder"),
getWindowNames("Calendar")
]).then((result, error) => {
x = result;
});
const runLoop = $.NSRunLoop.currentRunLoop;
while (x === null) {
runLoop.runModeBeforeDate($.NSRunLoopCommonModes, $.NSDate.dateWithTimeIntervalSinceNow(0.001))
console.log("a")
}
x
Promise の完了を待つように Run Loop を回しているのがポイント。これがないとすぐに終了してしまうし、ただのループだとずっとぐるぐる、何も起きない。スクリプトエディタ内で気軽に動かしたいだけなので idle ハンドラは試さず。
関数を定義するときに async も使ってみたけど、どうだろう。
先ほど Frog's Hand 1.0.1 のリリース記事（→ 2019.5.31）を書いた。...短いですね。今月の記事ノルマのためだけに内容のない記事を書くのもあれなので技術的な視点から少しだけ補足説明。
macOS では1 CGEventTap という API2 でシステムに発生したイベントを横取り（フック）して別のイベントに置き換える3ことができるのだけど、そういうことをしているアプリケーションが何らかの原因で反応しなくなるとイベントをその先に送信できなくなり、システムがフリーズしたように操作を受け付けなくなってしまう。
そこでその手の API には安全機能がある。決められた時間内に処理が完了しなかった場合、システムはそのアプリケーションにフックさせるのを停止するのだ。
Frog's Hand も CGEventTap を使ってドラッグのマウスドラッグのイベントに対して処理をしているのだけど、普段は問題なく動作していても Mac がスリープしたりすると処理できないのか効果が切れてしまうことがあった。
その対策として定期的に発動するタイマーで CGEventTap が無効になっていないかを確認し、必要であれば有効にする処理を追加したのである。これで解決していればよいのだけれどいかがでしょうか。
年末に反省したのに（→ 2018.12.29）またもや青いカテゴリーの記事だ1。とはいえ、いつもみたいに Cocoa ネイティブの話だけではない。
快適に“ひ to り go と”を更新するため自分専用に作っている記事エディタがある。記事やデータベースのファイルはすべてローカルにあるものを編集し、あとから手動でサーバにコピーするから 1 台の Mac 内で完結しているのだけど2、CMS のエンジンにアクセスする都合上エディタも PHP（とクライアント側の小さな JavaScript）で動いている…というのは以前書いた通りだ。
Web ブラウザ内での使用感では飽き足らずそれをラップする Cocoa App まで作ったものの、WKWebView の中では POST でフォーム上のデータを送信する仕組みのため、記事を保存するたびに画面が真っ白になって再読み込みがかかりエディタやプレビューのスクロール位置がリセットされてしまうものだった。保存せずに記事を離れたりウインドウを閉じるときでも警告すら出てくれない。
macOS 上で macOS らしくない体験はすべてノイズだ。純粋なネイティブ App ではないものの改善の余地はある。ちょうど別件で最近の JavaScript 事情を勉強していたところなので、ES2017 までの新機能をふんだんに使って記事エディタの中身を作り直したのである。
あらゆるものをウインドウの表示範囲の中で無理やり完結しているのが Electron みたいな Web ベースで作られたデスクトップ App の気持ち悪さの一因3だと思う。WKWebView にさせる仕事がほとんどだとはいえ、せっかく Mac 専用に App を作るのだ。積極的にウインドウの外にもはみ出していこう！
NSAlert を JavaScript から使うこれだけ長い前置きを書いたもののこの記事で触れるのは NSAlert だ。これをシートとして表示するだけでずいぶんと Mac App らしくなる。好きなボタンを並べられるし、“保存しない”ボタンを command + delete で押せるようにするようなカスタマイズも簡単だ｡「保存しますか？」をネイティブなシートで表示させてみよう。