2017年10月の
鯖の煮噌味
Saba no Nisomi


前月 / 翌月 / 目次 / 最新


2017.10.01(日)

12月末〜5月頭は、8月中旬〜12月末よりもちょっと短い。
 2020年の5月1〜5日はビッグサイトの一部が使えるとかなんとか>五輪の8月は「コミケ」困難…5月開催へ調整。さて、どうなる? てか、讀売は記事が遅い。


2017.10.05(木)

オモテに出ないコトもある。
 その昔、MacOS 9 から Mac OS X に移行したときの話。MacOS 9 まではウインドウの順序はアプリ単位で、アプリを切り替えるとそのアプリのウインドウがズババっと全部手前に来てました。Mac OS X では混在になっちゃいましてね。それがどぅにも馴染めなかったんですわ。で、使ってたのが X-Assist 。基本的には MacOS 9 までの『アップルメニュー』と同様な機能を提供してくれるんですが、ウインドウの挙動も同様にしてくれるとゆー代物。私としましてはウインドウの機能だけでイイんですが、まぁとにかくありがたや。そして今に至る、と。
 そんな X-Assist ですが、Mac をスリープ等で再起動させずに長期間使っていると、ウインドウが一括ではなく個々でしか手前に出て来なくなったりするんですわ。全部のアプリとゆーわけではなく、一部のアプリだけ。んー、謎。これはちょっと自前で検証してみようかと。太古の昔ならウインドウの情報は簡単に取得出来ましたが、今時は他のアプリの NSWindow やら NSApprication やらを弄るのはイロイロとアレだと思われるので取得は困難な模様。結局はアプリの切り替わりを NSWorkspaceDidActivateApplicationNotification で受けて、NSRunningApplication の activateWithOptions:(NSApplicationActivateAllWindows | NSApplicationActivateIgnoringOtherApps) を使うぐらいしか方法無いのかな? X-Assist でウインドウの挙動がおかしいときに自作アプリを試してみたら、同じ挙動。X-Assist も同じことしてるのかしらん? てか原因分からんちん。
 オモテ出ろ(仮称)/PNG/16KB 左端のアイコンが今回の作、オモテ出ろ(仮称)。
 オモテ出ろ(仮称)/PNG/30KB 機能は X-Assist 同様に。文言はテキトー。
とりあえず iMac を再起動して、しばらく拙作を試してみることに。


2017.10.14(土)

とりあえす、『取り消し/やり直し』は後回し。
 目がショボー。それはさておき。
 1週間以上経っちゃったけど、前回の拙作オモテ出ろ(仮称)のつづき。すべてのウインドウが手前に出て来なくなったアプリも、起ち上げ直せばきちんとウインドウは手前に出る。なんだか OS が悪い気がしてきた。んで、先週金曜に OS を Sierra から High Sierra にしてみたんですが、そしたらまったく問題無く、意図通りにウインドウが手前に。やっぱり OS っぽいなー。てなわけで、このまま拙作を常用することに。
 先月書いたプロパティリスト編集アプリは、NSOutlineView の謎動作に困惑しつつ、編集機能をちまちまと実装ちう。空欄をクリックすれば選択が解除されるのは分かるんですけど、何で NSOutlineViewSelectionDidChangeNotification の通知が発生しないのよ? outlineViewSelectionDidChange: が呼ばれないぢゃないかー。selecetedRow: も当てにならないし。私の使い方がおかしいのかな? ブツブツ....。今日はドラッグ&ドロップを...もぅ寝るか。


2017.10.21(土)

『取り消し/やり直し』は見た目にこだわると奥が深くて、今日も取り消し/やり直し。
 3日ほど前の話。選挙カーが来て「大変お騒がせして恐縮かと存じておりますが」と。........え?なに?と思った次第。あのウグイス嬢は今日も何処かの空の下で、恐縮かと存じちゃってるんですかねぇ。それはさておき。
 今日は期日前投票へ。投票所に行くと、エレベータに行列が。それを横目に階段を上って行くと、うぉ!階段に行列が。そしたら階上から下りて来た人たちが、その行列に並ぶぢゃないですか。エレベータ組が下りて来たのかww。いや笑い事ぢゃないな、年配の人ばかりだし。係の人も大変そうだし、仕方無いのかなー。仕方無いから、それもさておき。
 拙作オモテ出ろ(仮称)のつづき。意図通りに動かない事例が1件発生。もぅ諦めよう。諦めたから、それもさておき。
 プロパティリスト編集アプリのつづき。NSOutlineView の謎動作は他にもありまして。NSOutlineView 上の NSTextField でテキスト編集を始めても、controlTextDidBeginEditing: が呼ばれないの。あれこれ調べたら、テキスト編集終了時に呼ばれる controlTextDidEndEditing: に警告文があるぢゃないですか。ホントだ、ダブルクリックで編集開始すると、開始なのに終了通知が来る。なんだこれwww。てな感じに謎挙動の回避策を検討するのに時間を喰われてる気が。まぁなんとなく取り消し/やり直しを含めた編集機能を実装したんですけど、削除やら挿入やらのアニメーションまできちんとヤろうとするとナンですね。アレコレ気を使わないとイけなくて。また書き直しだー。


2017.10.27(金)

まだ終わらんよ!
 末広町の売場でハロウィンジャンボを購入。「当ててくれないと悪戯しちゃうぞー」なんてネットに書くと、脅迫と受け取られかねない今日この頃。もちろんそんな意思は毛頭無いですが、当ててくれると嬉しいです。それはさておき。
 まだヤってるプロパティリスト編集アプリのつづき。Xcode では Data や Date への入力の場合、値が適切か否かを判定してます。で、不適の際にはどのように処置をするかアラートを表示します。不適切な日付の例はこんな感じ。
 Xcode 9.0 での表示例/PNG/46KB Xcode (パクられ)。
まだ編集作業は継続中なので、この段階では他のテキストフィールドは編集不可。こんな処理を実現するには、編集の開始/終了の通知が便利。てか無いと困る。現状、開始で呼ばれるハズの controlTextDidBeginEditing: は呼ばれず、controlTextDidEndEditing: は開始/終了で呼ばれる困った事態。仕方がないので NSTextField の継承クラスの mouseDown: でクリックを捕まえることで開始を判定。で、その編集作業中は他のテキストフィールドはクリックを無視しようかと。そしたら他のテキストフィールドの mouseDown: の時点で、もぅそっちへフォーカスが移ってるぢゃないですか。の、情けない見た目の図。
 拙作 (パクリ) での表示例/PNG/42KB 拙作 (パクリ)
どしたらイイのよ? いっそのこと、最初から全部編集不可にする? てなわけで setEnabled:NO にしてみたら、それでも mouseDown: は呼ばれるんですねぇ。そこで編集開始の判定をして、それから setEnabled:YES にして親クラスの mouseDown: を呼ぶと、きちんとテキスト入力状態になってくれる。やったー。でも編集終了を正しく判定しないとダメだなー。クリック無視ぢゃなくて親ビューの mouseDown: を呼んで、一括してアウトラインビューの mouseDown: で編集終了にすればイイか。リターンキーでの編集終了は、controlTextDidEndEditing: でフォーカスの当たりが無いのを調べれば判定出来るっぽいなー。ぬぉ〜、やっと解決〜〜〜 (たぶん)。
 とまぁこんな感じでプロパティリスト編集アプリはほとんど完成の模様。でももぅ少し挙動を手直しして、そして動作確認をもっとヤらないとなー。それが終われば常用しよう。

前月 / 翌月 / 目次 / 最新


Top