年越しそばと初詣は絶対に欠かせない: Cocoa

ラベル Cocoa の投稿を表示しています。すべての投稿を表示

2013年3月16日

Cocoa Emacs 24.3 構築 (2013/03版)

暫く使っている Cocoa Emacs を更新していなかったので、24.3 に上げてみた。
当てるパッチは inline patch とポップアップフリーズ対応パッチくらい。
24.3 には既にフルスクリーン実装が入っているので、よく使われているフルスクリーンパッチは外した。
普通に安定してる。。。良い事。
但し、フルスクリーン時に、ツールバー表示をトグルすると上下に変な隙間が出て、変だ。
どうしたもんだかなぁ

2011年6月5日

Cocoa Emacs 23 構築 (2011/06版)

定期的にCocoa Emacs 23 を構築して使っていた。今日も定期作業とおもって、構築したらビルドが失敗してしまった。。。
どうしたもんだかなぁ

2010年5月26日

Cocoa Emacs のフレームをSpaces のワークスペースの上下左右に飛ばす。

個人的な使い方の問題だろうが、emacs に凝っていた頃は仮想ディスクトップ毎にフレームを置いた使い方をしていた。

emacs のフレームを仮想ディスクトップの上下左右に飛ばす

この使い方の要は、elisp からフレームを任意の位置、任意のワークスペースに移動できる事であった。

既に MacOSX では仮想ディスクトップが Spaces としてサポートされている。位置移動はできるようだが、ワークスペースの移動はどうもわからない。。。

マウスでチマチマ動かすのは、ちょっといただけない。。。

どうしたもんだろう？

Quartz のなんか

MacOSX の仮想ディスクトップは Leopard で初めてお目見えしたが、結構前から Window Server (Quartz Compositor/Core Graphics Services/Quartz Window Services...一体いくつの名称があるんだか。。。)には実装されていたそうである。 Tiger の時代から仮想ディスクトップがサードパーティのものがあったのはそういう訳らしい。

で、コイツのAPIのほとんどが今でも非公開になっている。。。断片的には、スクリーンキャプチャ用途レベルのものが公開されている。。。なんとも厄介。

先人が調べ尽くした結果として、最後のリンクの先の内容が、特定のウィンドウを任意のワークスペースに移動する方法らしい。

模式コードは次のようになる。(CGSPrivate.hは一番目のリンク先にあるもの)

#import <CGSPrivate.h>
...
NSWindow *win = ...;
CGSConnection cid = _CGSDefaultConnection();
CGSWindow wid = [win windowNumber]; // ?
CGSMoveWorkspaceWindowList(cid, &wid, 1, workspace);

CGSを解析した作られた CGSPrivate.h でのCGSWindow と Appleから出ているドキュメントに出てくる CGWindowID とは window server 内で割り振られた番号で同じ実体と思われるが、 NSWindow の windowNumber のドキュメントには、それとは違うと書かれている。混ぜても動いたから多分良いかと思われるが、、、ここいらはぼかしたい内容なのかなぁ。。。分からんなぁ林檎は。

まぁ、ここまで分かれば、出来たも同然〜。

で、適当にコマンドを作ってみた。

cgsutil.m

Emacs.appの改造

(frame-parameters)には window-id があるから、Cocoa Emacs では多分コイツがフレームウィンドウの CGWindowID のはずで、コイツと飛ばしたい workspace 番号を適当に作ったコマンドに渡して、お仕舞いかなぁ。

わぁーい。らくちん。

はぅ。。。

Cocoa Emacs では window-id の値は、1から単調増になるように割り振った全く意味の無い番号でした。

仕様が無いので、次の追加機能を付けるパッチ(~~emacs-23-cgs-workspace.diff~~) を作ってみた。

フレームパラメータns-window-idに、CGWindowIDと思われる値
~~フレームパラメータns-workspace-idに、フレームのworkspace番号~~
フレームを指定のworkspaceに移動する関数 (set-frame-ns-workspace FRAME WORKSPACE)

まぁ、最初の一つだけで十分だが、後二つは組込まなくてもいいかも。

まとめ

上のパッチを適用した Emacs.app に適当な elispを書くと、１コマンドで複数のフレームを特定のワークスペース／特定の位置に開く事が出来るようになった。

うん〜〜。快適じゃ。

はぅ。。。

Cocoa Emacs で８フレームも開くと、キー入力が引っ掛かるようになり、Emacsプロセス自体のCPU利用率もイマイチ高い。イベント処理方法にまだ難があるのかなぁ。

４フレームくらいで抑えないとスムーズに使えないかなぁ。。。

追記 (2010/06/16)

複数のフレームを開いたときCPU利用率が高くなるのは、本パッチ内のframe-paramaters にワークスペース番号を追加するのが原因だった。。。frame-parameters の取得は不随に起きるらしくのでどうも軽くなくては行けない。

なので、workspace番号は取得関数から得るように変更し、workspace 絡みの部分を分けたパッチにしてみた。

emacs-23-cg-window-id.diff
- フレームパラメータns-window-idに、CGWindowIDと思われる値
emacs-23-cgs-workspace.diff
- 指定フレームのworkspaceを取得する関数 (frame-ns-workspace FRAME)
- フレームを指定のworkspaceに移動する関数 (set-frame-ns-workspace FRAME WORKSPACE)

ふむ。
８フレームを開いても、キー入力が引っ掛かる症状は無くなった！！
すごく快適〜ん。

パッチを切ったり張ったり入れ替えたりする(1)のに、git rebase -i は極めて便利。git 優秀だなぁ

2010年5月12日

Cocoa Emacs が落ちる

Cocoa Emacs は安定していると思ったが、どうもポップアップダイアログが出ると暫くして落ちてしまう。

flymake をチマチマ使えるように設定を弄ったら、時々でるポップアップに刺さる。。。

しようがないので、gdbで追っかけてみた。

調べてみたら、次のような簡単な処理でも、ポップアップが出て暫くしてEmacsが落ちるようである。

どうも inline patch 側での処理抜けらしい。。。こんな感じに修正すると落ちなくなった

うん、すこぶる快適

2010年5月7日

Emacs23 のフォント設定

新し目の Emacs ではフォントエンジンの改良が進んでおり、 antialiasing が効いた奇麗な表示が出来る。また、沢山の種類のフォントを扱えるようになっている。

プログラムの編集等をしてると等幅フォントが必要である。特に、日本人としてはASCII文字と日本語文字の幅が 1:2 である事が強く望ましい

まぁ、いくつか設定方法が流れてるので、コピペして使えば良いのだが。。。みんなどうやって見やすい設定を探してるのだろうか？

疑問に思ったので、次のような機能のelispを書いてみた

my-sample-ascii.el

my-sample-ascii: 既定のフェース default/bold/italic/bold-italic それぞれで同じメッセージを同一のバッファに出力する
my-sample-face-size: defaultのフェースを継承し(書体を引き継ぎ)、高さが 6〜20ptのフェースを作成し、同じメッセージを同一のバッファに出力する

適当にdefaultフェースを設定した後だが、CocoaEmacs/NTEmacs/Emacs(onUbuntu)での、 my-sample-face-sizeの結果は次のようになる

いくつか設定してみたが、全ての pt で、1:2 に揃うフォントの組み合わせはほんとに稀で、日常的に使うサイズに合わせて、サイズの微調節が必要のようである。やはり、IPAフォントの恩恵は結構でかいなぁ。

今現在、いい感じに設定できたのは次の通り。

まとめ

なんか Emacs をガンガン使い倒したくなってきた！！

追加 (2010/11/03)

VMware 上の X で画面サイズの変化で dpi が変化し pt 単位でフォント指定すると、実際のフォントの大きさがまちまちになるので、明示的にpixel単位？で指定する方法に切り替えてみた。

2010年5月1日

Cocoa Emacs 64bit版を作ってみる

最近、また Emacs にはまっている。

ここ数年は vi やら eclipse やら JeditX やら xcode やらを広く浅く使っていて、いまいちスッキリしない感じで、まぁ年なのか諦めていた。 Snow Leopardにアップグレードを期に、ちょっと設定等を手入れしてMacOSX/Windowsで使い出したらすこぶる手になじむ。。。

はて、なんでEmacsを使うのを忘れていたのかんなぁ。。。

そう、当時 Emacs 20か 21 (mule-2.3だったかもしれん、、、)だったかなぁ。 UTF8/Unicodeを使う為にはMule-UCSとかいうパッケージが必要で、そいつを組み合わせると普通に使えるのだが、起動も動作ももっさりしていまいちだった。。。

今日のEmacsはサクッとUnicode系の一群のcoding-systemが使えて、それなりに軽快に動作する。

良い時代になったなぁ。。。

MacOSX 上の定番は CarbonEmacsで、かなりしっかりメンテナンスされており、実に安定している。ただ、ベースにしてるのがEmacs22だったり、Carbonベースだったり、32bitバージョンだったり、本当に細かく気になる人が気になる程度。

ふと気づくと本家 Emacs では既に 64bit Cocoa版が構築でき、かつ日常作業で問題ならないくらいは安定してるらしい(1,2)。また、フォントの等幅調節設定や日本語入力等のinline patchなどが入手が可能で、ほぼ CarbonEmacs を置き換えて使えるレベルになっている(と思う)。

なので、Cocoa Emacs 64bit を構築してみる。

ソースを取ってくる

うん、一番の難関は Bazaar という分散VCSを使う事かもしれない。。。準オフィシャルなGitレポジトリがあるので、Gitに慣れてる場合はこっちを使うのが吉。僕は、へたれなので git の方を使った。

Bazaar レポジトリ: http://bzr.savannah.gnu.org/r/emacs/trunk/
Git レポジトリ: git://repo.or.cz/emacs.git

取り敢えず、ローカルネットに emacs.git のミラーレポジトリを立てて、そのマシン上でフォークして個人用の共用レポジトリを作る。その個人用レポジトリから作業マシンに複製を展開する。また、継続的にupstreamを追っかけるため、ミラーレポジトリもリモートとして登録する。

% ssh server               # ローカルネットの server にログイン
% cd /git
% git clone --mirror git://repo.or.cz/emacs.git
% git clone --bare --reference emacs.git emacs.git emacs-my.git
...
% ssh client               # 作業マシンにログイン
% cd ~/work
% git clone git+ssh://server/git/emacs-my.git emacs
% cd emacs
% git remote add upstream git+ssh://server/git/emacs.git
% git fetch upstream

個人用レポジトリを挟んだのは、バックアップを意図してなんだが、、、git使いはそんな事はしないのかなぁ。。。分からんなぁ。。。

パッチをあてる

続いてMacEmacs JP から inline_patch を取って当てる。

% ssh client               # 作業マシンにログイン
% cd ~/work/emacs
% git checkout -b topic EMACS_PRETEST_23_1_96  # 次いでに topic ブランチも作っとく
% pathc -p0 < emacs-inline.patch

構築する

あとは、configure/make で問題が無ければ nextstep/Emacs.app の場所で 64bit Cocoa Emacs が構築される。

% ssh client               # 作業マシンにログイン
% cd ~/work/emacs
% eval "$(PATH= /usr/libexec/path_helper -s)"  # PATHをクリーンにする
% ./configure --with-ns
% make install
% open nextstep/Emacs.app                      # Emacsの実行確認

なんともあっけなく構築できた。ただ、僕は masterブランチの方にパッチを丁寧に当てた物(24.0.50とか)を使っている。すこぶる快適。

定期的追っかける

まぁ、忘れそうなので次いでに書いとく。

ミラーレポジトリは次のコマンドで更新する。

% ssh server               # server にログイン
% cd /git/emacs.git
% git fetch

そして、作業レポジトリで upstream を追っかけるには

% ssh client           # 作業マシンにログイン
% cd ~/work/emacs
% git fetch upstream
% git rebase upstream/master topic    # upstream 先端に rebase
% git push origin :topic              # topicブランチを削除し、
% git push origin topic:topic         # 新しくtopicブランチをプッシュ

いまいち Git の使い方に慣れない/分からないので、間違ってるかもしれん。。。

そういえば、github にも Emacsのミラーレポジトリが上がってるので、そのうち生えてくるかもしれん。。。

それにしても覚える事が次から次と現れて、知恵熱が出っぱなしだなぁ。。。

初期設定のemacs.elはまた次回。

追記 (2010/05/06)

フォント以外の設定は、殆ど定型文っぽいので以下の用に設定した。

フォントの設定は「Emacs23 のフォント設定」を参照

追記 (2010/05/12)

どうもポップアップダイアログが出たとき落ちる問題にはパッチが必要。

2008年3月16日

MediaWiki から MoinMoin への移行ツール

技術のメモ書き用に、自宅内にMediaWiki を立てているのだが、イマイチ使い勝手がよく無さげなので、別の Wiki システムを探ってみた。内部的にUTF-8を使ってて、編集の履歴が見れて、そんなやつが良い。

MoinMoin が結構良さげなので移行してみた。

問題は MediaWiki に書き貯めた文書片を MoinMoin の形式に変換するのは手動では面倒である。

なので、ヘボイ変換ツールでも書いてみた。

ソースコード ~~WikiConverter20080316.zip~~

MediaWiki の書式で変換できるのは一部のみ(リスト、整形済みテキスト、テーブル)である。うまく行かない場合は、ソースコード内の convert.rb を変更する必要がある。というか、自前で変更しないと使い物にはならないかも。

CUIでは一行スクリプトや書捨てスクリプトがよく作られる。そいつのGUI版と考えれば、書捨てGUIもあっても良いと思う。β版でもα版でもなく、こいつはそんなもんだ。

まぁ、Cocoa / CoreData / WebKit 万歳と言う話かなぁ。

Wiki 書式の変換ライブラリってのはないのかぇ。。。。

2008年3月7日

iPhone SDK on PowerMac G5 って動くのかぁ

当ブログは全く今時の話題を書かない「端っこブログ」なのだが、iPhone SDK ベータを取り上げたい。

iPhone SDK は、Mac OSX 10.5.2 以降の Intel-Mac 上で動く。

はて、PowerPC 上では動か無いのかぁ。

Apple めぇ。

普通にインストールすると、iPhone 関連のパッケージはインストールされない。なので、以下のパケージを手動で追加する。 Xcode3.1があるディレクトリを指定する必要がある。

AspenDocumentation.pkg
AspenHostSideTools.pkg
AspenSDKHeadersAndLibs.pkg
AspenSimulatorPlatform.pkg
AspenSystemComponents.pkg
DeveloperDiskImage.pkg

と、適当にプロジェクトを作ってビルドするとPPCベースのバイナリが普通にできるようである。

シミュレーション用の互換ライブラリ群にはちゃんと PPC 用のコードも含まれている。

$ cd /Developer/Platforms/AspenSimulator.platform
$ cd ./Developer/SDKs/AspenSimulator1.2.sdk
$ cd ./System/Library/Frameworks/UIKit.framework
$ file UIKit
UIKit: Mach-O universal binary with 2 architectures
UIKit (for architecture ppc7400):   Mach-O dynamically linked shared library ppc
UIKit (for architecture i386):  Mach-O dynamically linked shared library i386

なんだろう？正式版では PowerPC でもサポートされるのだろうか？それとも削除されるのだろうか？

なんかまた端っこの話題でしたね。

追記(2008/07/22)

iPhone SDK の最終版が公開されていので、同様に試した。含まれているパッケージ名は Aspen ⇒ iPhone に変更になっているだけで、シミュレーション用の互換ライブラリも ppc 用も含まれている。

大きな違いは！！

Xcode のGUIから下記エラーが出て構築できなかった。。。

No architectures to compile for (ARCHS=ppc, VALID_ARCHS=i386).

どうも、GUIからは VALID_ARCHSが固定値になってるようである。実際、適当な設定をして xcodebuild コマンドをターミナルから直打ちすれば構築はでき、シミュレータでの動作確認ぐらいはできるようである。

Appleは、本格的に PowerPC 上での開発を縮小する意思表示なんだろうなぁ。。。

本当に残念だ。。。。Mac Pro への買い替え時なのかぁ！？

2008年2月23日

Leopard 上の NSTreeController は挙動不審？

Leopard において NSTreeController の挙動が素直でない現象に出くわした。 Tiger で同じバイナリは素直な動作をするので、バグなのか、仕様の変更なのか。。。さっぱいり分からない。

途中まで Tiger 上で開発して放り投げておいたものを、Leopard 上で再開した途端、地雷原に突っ込みまくっている。。。

でだ、問題は NSTreeController は、childrenKeyPath の先のモデルを、Array として扱うのか、Set として扱うのか？

簡単なサンプルを作ってみた。

~~MoiView.zip~~

モデルに Core Data を使わずにNSMutableDictionary を使い、newObject/newChildObject で単純な初期を行う。このとき children には NSMutableArray のインスタンスを割り当てている。
NSTreeController と NSOutlineView を一般的な binding をしてある。
五つのボタンのそれぞれのアクションに、NSTreeController のadd:/addChild:/addInsert:/addInsertChild:/remove: を接続して、同時に、それぞれのボタンの enabled に canXXX をbindingする。
別のボタンに、NSTreeController に rearrangedObjects を実行するアクションを接続する。
こちの挙動の対処の有無のチェックボックスをつける。

トップレベルに追加(add:)や挿入(insert:)を沢山した後、rearrangedObjects を呼び出しても、項目の順序は変化しない。これは、Tiger でも Leopard でも同じ。

トップレベルよりしたの階層で、追加(add:/addChild:)や、挿入(insert:/insertChild:)を沢山した後、rearrangedObjects を呼び出すと、項目の順序は変化しないはずなのだが、僕のLeopard の環境では変化する。

再現性もある。モデル上では insert:はadd:として、insertChild:はaddChild:として振る舞う。。。

でだ、問題は insertObject:atArrangedObjectIndexPath:でも同じように、モデル上では indexpathで指定された階層の最後尾に追加される。。。

ビューとモデルでは違うのは分かるが、Core Data を使わずに適当なクラスを使っているのだから、childrenKeyPath の先を Array として扱って、挿入位置もモデルに反映してほしいのだが、、、。

~~困った。仕様なのか、バグなのか、環境なのか、分からん。~~ 最初の話だが、childrenKeyPath の先は、Core Data のエンティティを使う場合は Set であり、クラスを使う場合は出来る限りArray であると思うのだが、違ったのか？ ~~まぁ、抜け道はあるから良いのだけども。そのうち、なんか出てくるかぁ。~~

追記 (2008/06/21)

MacOSX 10.5.3 になって直ぐには確認していないので、どの時点で改良されたか分からないが、近々の最新状態で確認したところ、insert系のビューとモデルの操作の奇妙な差異が改善された。

どうもバグだったらしい。

要求条件が「MacOSX 10.5.3 以上」とか見るが、どうもこれらの原因なのかなぁ。。。

よきことかなぁ。

2008年2月20日

Cocoa Binding の canAdd はいつ呼ばれるのか？

NSArrayController/NSTreeController の canAdd/canInsert が呼ばれるタイミングが、素直ではないような気がする。

仕様なのだろうか？

canRemove や canAddChild/canInsertChild などは、それぞれのコントローラの選択(selection)が変化した毎に呼ばれる。

canAdd/canInsertも同じようなタイミングで呼ばれると思うのだが、呼ばれない、、、何故！

素直な期待を満たす動作にするためには、それぞれの派生コントローラを作って、KVOを使って下記のようにしてみた。

@interface CustomController : NSArrayController {  
}
@end

@implementation CustomController

- (void)awakeFromNib
{
    [self addObserver:self
           forKeyPath:@"selection"
              options:0 context:nil];
}

- (void) observeValueForKeyPath:(NSString *)keyPath
                   ofObject:(id)object
                     change:(NSDictionary *)change
                    context:(void *)context
{
    if ([keyPath isEqualToString:@"selection"]) {
        [self willChangeValueForKey:@"canAdd"];
        [self didChangeValueForKey:@"canAdd"];
        [self willChangeValueForKey:@"canInsert"];
        [self didChangeValueForKey:@"canInsert"];
    }
    [super observeValueForKeyPath:keyPath ofObject:object change:change context:context];
}
@end

setKeys:triggerChangeNotificationsForDependentKey:を使っても同じことが出来ると思うが、同じ動作は実現できなかった、、、canAdd/canInsert は Controller Key だからなのかぁ。そもそも canRemove はどうしてるのだろうかぁ、、、

全く分からん。

2006年8月6日

NSImageでWindowsアイコンデータを扱う

通称 Favicon をCocoaで扱いたかった。元データはWindows アイコンファイル仕様(.ico)がBase64化されてテキスト文字列になっていた。なので Base64デコードして、何か仕様のpixelデータ列に変換してNSImageに喰わせる必要があるかと思っていた。

が、 Base64デコードした後のWindowsアイコンデータのバイト列を元にNSDataを作成して、initWithData:で初期化すればお望みにNSImageが得られて、表示放題のようだ。またアイコンデータに限らず、MacOSXで扱える全ての画像形式(JPEG,PNG,等々)をNSDataに入れられれば、形式を自動認識してNSImageを生成出来るようである。

これも、Quartzの恩恵らしい。何ともすばらしい。

あとは、キャッシュの方法をマスタすればNSImageは恐れるに足らない。

2006年3月29日

ソースコードのエンコードと genstrings

Cocoa環境のアプリをローカライズする場合、ソースコード内でローカライズ対象のメッセージ文字列@"message"を直接書かずに、次のようなマクロを挟む形で書く。

NSLocalizedString(@"message", @"comment")

このマクロは、リソース？にあるLocalizable.stringsファイルから@"message"をキーとして翻訳済みの文字列を取得して返す。

Localizable.stringsを各言語毎に用意すればソースコードに埋め込まれたメッセージをローカライズできる寸法である。

もちろんソースコード群からLocalizable.stringsを生成コマンドも用意されており、下記コマンドで一発である。

# genstrings `find . -name '*.m'`

これで問題なければ良いのだが、、、、。

ソースコードにCJKの文字が含まれているとLocalizable.stringsを上手く生成してくれない。コメントであっても駄目(時たま、気まぐれで生成してくれる場合もあるのだが、、、)。特にソースコードがUTF-8だと駄目なのはイマイチ分からん。ShiftJISだと問題ないらしいが、、、そりゃないよAppleさん。

しかし、ソースコードに母国語のコメントを入れられないのは辛い。

幸いMacOSXにはPerl5.8が含まれており、苦無く複数のエンコードを考慮して扱えるので、genstringsと同等なスクリプトを書けば良いかも。

と、思いへこへこ書いてみたが、

genstrings で -s オプションは機能してないっぽいなぁ。
-j/-u/-noPositionalParametersオプションは未実装。使うときにでも実装するかぁ。
ふむperl 4くらいの知識ししか無いのでイマイチ定石が分からんなぁ。
perl本買ったれ。
良く分からんが書けた。。。
そのうち公開しとこぅ。

で、漸くソースコードの日本語コメント書き放題になったよ。

追記(2008/08/06)

欲しい人は多分いないと思うけど、公開しときます

genstrings2

2006年3月24日

デフォルトドキュメントを指定する方法(解決編)

先日の続き。分かれば何のことは無く、Cocoaの無償の機能の中にすでに含まれている。

2006年3月22日

デフォルトドキュメントを指定する方法は？

Xcodeを使えば、新規のプロジェクトの作成で、Cocoaのドキュメントベースの雛形は簡単できる。あとは、Documentクラスなり、NSAppにデリゲートさせてカスタムコントロールオブジェクトを作ったり、ある程度は分かる。ただし、Cocoaを使うと、無償で付いてくる機能をカスタマイズしたい場合ドキュメントを彷徨う場合が多い。まぁ、それでフレームワーク特有の定石のパターンがある程度身に付くので無駄骨には終わらない。

で、カスタマイズしたい機能で未だに分からないがある。

登録: 投稿 (Atom)

Google Code Prettify

2013年3月16日

2011年6月5日

2010年5月26日

Quartz のなんか

Emacs.appの改造

まとめ

追記 (2010/06/16)

2010年5月12日

2010年5月7日

まとめ

追加 (2010/11/03)

2010年5月1日

ソースを取ってくる

パッチをあてる

構築する

定期的追っかける

追記 (2010/05/06)

追記 (2010/05/12)

2008年3月16日

2008年3月7日

追記(2008/07/22)

2008年2月23日

追記 (2008/06/21)

2008年2月20日

2006年8月6日

2006年3月29日

追記(2008/08/06)

2006年3月24日

2006年3月22日