ホットキー変更対応(3) modifieierキーの表現

commandキーやoptionキーなどを表現する必要があるが、これはどうやって表示するのだろうか？


いろいろ調べているとホットキーを扱うライブラリがあった。
Homegrown Developer Tools

ソースコードが配布されており中を見ると参考になるコードが見つかった。
PTKeyCombo.m

+ (NSString*)_stringForModifiers: (long)modifiers
{
 static unichar modToChar[4][2] =
 {
  { cmdKey,   kCommandUnicode },
  { optionKey, kOptionUnicode },
  { controlKey, kControlUnicode },
  { shiftKey,  kShiftUnicode }
 };
  :

なるほど文字コードが割当られていて定数定義されているのか。
サンプルアプリを作って試してみる。

AppController.m

#import "AppController.h"
#import <Carbon/Carbon.h>


@implementation AppController

- (void)awakeFromNib
{
 NSLog(@"%C", kCommandUnicode);
 NSLog(@"%C", kOptionUnicode);
 NSLog(@"%C", kControlUnicode);
 NSLog(@"%C", kShiftUnicode);
}

@end

デバッガコンソールへ４種類のmodifierキーを表示させる。実行してみよう。


出た。
よしこれを使おう。


参考
HotKeysLib3 - Cocoaでホットキー

SimpleCapバグ修正 - マルチスクリーン（２）

マルチスクリーンの特定のケースでウィンドウキャプチャがおかしかった件が解決した（ウィンドウを選択した時に表示される画像がずれる）。
以前の対応で座標変換がもれていたのが原因。

座標変換を入れてやるとなおった。

-(NSImage*)image
{
 if (!_image) {
  NSRect rect = _rect;
  rect.origin = [CoordinateConverter convertFromLocalToCGWindowPoint:rect.origin];
  CGImageRef cgimage = CGWindowListCreateImage(NSRectToCGRect(rect),
//*old*  CGImageRef cgimage = CGWindowListCreateImage(NSRectToCGRect(_rect),
　：

マルチスクリーンには手を焼かされた。

SimpleCapバグ修正 - マルチスクリーン

SYさんよりマルチスクリーンでバグがあるとの報告を受けた。
SimpleCap その後 〜コメント〜

マルチスクリーンでメニューバーが存在する画面のサイズが他よりも小さい場合に現象が発生する。例えば下記のケース。


以前、マルチスクリーンを手直した時にはこのケースは試していなかったので気がつかなかった。


調べると原因は [NSScreen mainScreen] の動作を誤解していることにあった。
NSScreen Class Reference - mainScreen

てっきりこのメソッドはメニューバーのある画面を返すものとばかり思っていたのだがそうではなく、リファレンスによるとキーボードイベントを受け付けるウィンドウが存在するスクリーンが "main screen"とのこと。

メニューバーを含むウィンドウは

The screen containing the menu bar is always the first object (index 0) in the array returned by the screens method. 

と書いてあった。つまり [NSScreen screens] で返される配列の最初のスクリーンがメニューバーを持つということ。そういえば以前読んだような気もする。


これらを元に座標系変換の実装を下記のように修正した。

（誤） NSRect m_frame = [[NSScreen mainScreen] frame];
（正） NSRect m_frame = [[[NSScreen screens] objectAtIndex:0] frame];

これでなおった。やれやれ。
座標変換のロジックが間違ってなかっただけ良かった。


SimpleCapにおけるマルチスクリーンでの座標変換ロジックはこのあたりで紹介している。
β版バグ修正 - マルチスクリーン
β版バグ修正 - マルチスクリーン（その２）

- - - -
直しているうちに別のバグを発見した。
やはりマルチスクリーンで利用している時にスクリーン配置の特定のケースで、ウィンドウキャプチャの表示がおかしいことがわかった。

ホットキー変更対応(2) ユーザインターフェイス

ホットキーは１つだけなのでそんなに凝ったユーザインターフェイスは要らない。

システム環境設定のようなものでいいかな。

ホットキー変更対応(1) 仕様

SimpleCapのホットキー変更の要望対応に入る。

現行の仕様は、option+command+0 を押すとステータスバーのメニューが開く様になっている。このキーは固定で変更できない。これを変更もしくは無効にできるようにする。

やりたいことをまとめると：
1. ホットキーを自由に変更できる
2. 無効にできる
3. デフォルト(option+command+0)に戻せる

これを実現するには：
1. プリファレンスに変更用インターフェイスを用意する
2. プリファレンスの保存、復帰の実装を用意する
3. ユーザが変更した時に変更する（＝直前のホットキーを解除し、新規に登録する）実装を用意する


細かい所は作りながら詰めていこう。

WebKit検証(36) - キャッシュをクリアする（成功）

（キャッシュクリアの続き）

NSURLCache を調べてみた。

NSURLCache Class Reference

まず以前のサンプルコードに "Dump Cache" と "Clear Cache" ボタンを追加する（右下）。


コードはこう。
AppController.m

- (IBAction)dumpCache:(id)sender
{
 NSURLCache* cache = [NSURLCache sharedURLCache];
 NSLog(@"currentDiskUsage: %d", [cache currentDiskUsage]);
 NSLog(@"diskCapacity: %d", [cache diskCapacity]);
 NSLog(@"currentMemoryUsage: %d", [cache currentMemoryUsage]);
 NSLog(@"memoryCapacity: %d", [cache memoryCapacity]);
}

- (IBAction)clearCache:(id)sender
{
 NSURLCache* cache = [NSURLCache sharedURLCache];
 [cache removeAllCachedResponses];
}

実行してAppleのページを開いた後のキャッシュファイルの状態はこう。


"Dump Cache"ボタンを押すと、currentDiskUsage: の値が一致している。メモリは使っていないことがわかる。


次に "Clear Cache"ボタンを押してみる。


おお、サイズが小さくなった。

"Dump Cache" で確認。


しつこく sqlite3 コマンドでテーブルの中身を調べてみる。cfurl_cache_response と cfurl_cache_blob_data は空だ。


うまくいったようだ。

まとめ：
- WebView で開いたページのキャッシュは [NSURLCache removeAllCachedResponses] でクリアできる。
- ファイルは削除されない（SQLiteデータベースのレコードが削除される）


- - - -
長々と引っ張ったがやっとキャッシュをクリアすることができた。ちょっとうれしい。

キャッシュ調査（さらに続く）

引き続き調査。NS系ネットワークライブラリを調べてみたところキャッシュに関する記述が出て来た。

URL Loading System

URL Loading System Overview - Cache Management

抄訳
・キャッシュはディスクとメモリを使う。
・キャッシュはアプリケーションごとに格納される。
・キャッシュは NSURLConnection もしくは NSURLDownload によって使われる
・キャッシュポリシーは NSURLRequest 初期化時に決められる
・NSURLCache クラスを使ってキャッシュサイズや、ディスク上の保存位置を設定できる
・NSCachedURLResponse を使うとキャッシュされたコンテンツへアクセスすることができる
・NSCachedURLResponse は NSURLResponse とコンテンツデータをカプセル化している
・現行は http/https のリクエストがキャッシュされる（httpsリクエストはディスクにキャッシュされることはない）
・NSURLConnection の connection:willCacheResponse: デリゲートメソッドを使って、キャッシュの挙動を制御することができる


Using NSURLConnection - Controlling Response Caching


Understanding Cache Access

-> NSURLRequest でキャッシュポリシー (NSURLRequestCachePolicy) を決める


WebKit、WebCore、ネットワークライブラリの解説はHMDT木下さんの資料が参考になる。
Web Kitプログラミング解説と、 その実例としての シイラプロジェクト紹介 (PDF)


で、NSURLCache に辿り着く。
これはまた明日。