« 2007年2月 | トップページ | 2007年4月 »

2007.03.29

サヨナラ InputManager ?

(2007/11/03 追記:適切な権限で /Library/InputManagers にインストールすることで Leopard でも動作することが確認されています。SIMBL も 0.8.2 でインストーラが変更され、問題なく利用できています)

Cocoa Blogs 経由でInput Managers and Leopard。InputManager が Leopard では使えないかも?という話。引用されている元記事のコメント欄がなかなかのスピードで伸びてる。

ひとつめのコメントが

No more SafariStand?

なのが素敵。

引用元によれば、デフォルトでは無効になっていて、変更することもできるらしい(今のとこ)ので、全く使えなくなるかどうかは、まだわからないところのようだ。

もともと InputManager は、かな漢字変換などのテキスト入力を提供する仕組みで、そのためにすべてのアプリケーションでロードされるようになっていた。ただ、これで実装された(本当の)InputManager てのはまず見当たらなくて(NeXT 時代については知らない)、アプリケーションをハックして機能を追加したりするのに多く利用されていた。ある種のウラワザだったわけだ。アプリケーションの外側からモジュールをロードさせる手法としては、他には mach_inject を利用した mach_star や、 Unsanity の APE なんかがある。

なんでアプリケーションをハックするのかというと、SIMBL の作者が

Problem:
  Some applications do about 90% of what I want.
Solution:
  Develop my own applications.
Better Solution:
  Patch the application myself...

と言っているように、あとちょっとだけ動作を変えることができれば要求を満たすことができるのだから、イチから同じようなアプリケーションを作るなんて無駄なのだ。大変だし。

自分でもいくつか InputManager は書いているし、無くなると困るのだけれど、別の方法でロードさせることさえできれば InputManager でなくたってよいのだ。.app/Resources/Plugins/ に配置したら勝手にロードしてくれるとかだとありがたいなあ。

Objective-C のランタイムから中身見えまくりなところと、 Cocoa フレームワークの疎結合を導くデザインが、他の環境と比較して Cocoa アプリケーションがハックしやすい状況を生み出していると思う。ここの点については長期的に変わらないと考えている。アプリケーション作成する側としては、ちょっとイヤな点だとも思うけれども。

|

2007.03.17

Whi TCL? on MacPorts

Summer of Code の記事を読んでいて、MacPorts システムの中心となるプログラミング言語は Tcl にちょっと興味をもったので調べもの。

なぜ Tcl なんだろう? MacPorts/DarwinPorts は比較的最近のプロジェクトなのだから、もっと新しめの言語、たとえば perl や python(ruby は海外ではブレイク前)という選択肢もあったよね?と思って調べてみると、そのものずばりの回答が DarwinPorts の ML アーカイブに見つかった。Why TCL?

いちばんに挙げられているのが、key/valure のペアを簡単に記述できること。つまり、Portfile - DSL としての Tcl を評価したというのが理由のようだ。Portfile 書くような人は知っているとは思うけれど、MacPorts の Portfile は Tcl スクリプトそのものなんだ。例として、ruby の Portfile を見てみると、前半部分はただの設定ファイルにしか見えないよね。でも post-destroot あたりはちょっとあやしい、foreach とかあるし。そう、これはコードなんだ。前半の version や depends_lib なんかも実際には関数で、その引数として値を評価しているわけだ。クォートしなくてもリテラル文字列になる(なってしまう?)Tcl ならではだね。たいていのことは設定ファイルのように、設定項目とその値を書けばよいし、ちょっと複雑なことをしたければそのままプログラムとして表現できる。まさに言語内DSL。

そういえば、昔 Oracle や ARCServe で .tcl のついたファイルを見かけて驚いた記憶があるような気がする。海外では(日本でも?)スクリプトとして広く使われている言語なのかもしれないな。自分のまわりにないだけで。

でも、るびまの Tcl の記事 を見るとやっぱりビミョウな位置みたいにも思えるなあ。

|

MacPorts が Google Summer of Code 2007 に参戦

MacPorts が Google Summer of Code 2007 に参加とのこと。学生の申し込みは3/24まで。日本語での Google Summer of Code の案内は、 「Google Summer Code 2007 への登録が始まりました」 がでている。

今回の課題を Trac 上の Wiki から見てみよう。

  1. Task 1 依存関係: variant や バージョンによる依存関係をもっとうまく扱えるように。
  2. Task 2 Python Group: よくわからん。
  3. Task 3 仮想 "chroot": ほんとの chroot でなく、tcl スクリプト内に仮想的な chroot 環境を構築して、その中で upgrade のビルドなどを行うように。
  4. Task 4 バイナリサポート: 今はすべてローカルマシンでビルドするようになっているけれど、バイナリでの提供をサポートできるように。
  5. Task 5 GUI: port 管理(インストール、アップデート)の GUI インターフェイスを提供。
  6. Task 6 イメージ: depot にイメージにダイナミックリンクすることで active でないバージョンのライブラリも利用できるように。
  7. Task 7 root 権限: 不要なところは、通常ユーザに。
  8. Task 8 Portfiles: Portfile の機能強化。
  9. Task 9 ミラーリング: ミラーリングでの配布システムの構築。
  10. Task 10 Lint: Portfile の lint ツールの作成。
  11. Task 11 自動化されたテスト: 現在あるテストフレームワークの改善。

といったところ。けっこう楽しみ。ユーザとしては、もっとらくちんになりたいのです。

特に、ダイナミックリンクはもっとゆるいバージョンにリンクしてほしいのだよなあ。むしろバージョンなしの .dylib でもよいくらい。MacPorts ばかりに責任があるとは思わないけれど。

|

2007.03.14

MacFUSE の Objective-C ライブラリ from Google

以前にちょっと話題にした Objective-C での MacFUSE 実装用のクラス CFileSystem とは別に、Google 自身によるライブラリがあるようだ。

コアになるクラス FUSEFileSystem のヘッダだけみればおおよそ使いかたの想像はつく。CFileSystem よりも多くのことが可能で、リソースフォークも扱うことができる。

新しいファイルシステムをつくるには、FUSEFileSystem のサブクラスを作成し、いくつかのメソッドをオーバーライドすればよい。たとえば、一緒に配布されている HelloFuseFileSystem はテキストファイルひとつだけを見せる、シンプルなファイルシステム。これくらいのものならば、実装はとても簡単みたい。メソッド4つしかないし。

|

2007.03.12

NSApplication の起動プロセスについてくわしく

Everything you always wanted to know about NSApplication というエントリで、NSApplication の起動プロセスについて詳しく説明している。

  • NSApplication
  • NSAutoreleasePool
  • NSMenu
  • NSThread
  • NSWindow

といった主要なクラスをポージングで差し替えて、実際にどう動作しているかを観察したというもの。以前に似たようなものをどこかで見た記憶はあるのだけれど探し出せず。

awakeFromNib だと早すぎる/遅すぎるってときにはどこで処理すべきか?、や NSApplicationWillFinishLaunchingNotification と NSApplicationDidFinishLaunchingNotification はどのくらい違うの?、などのややマニアックな疑問への回答を与えてくれる。

|

TMPresents 0.3.4.1 (バイナリのみ) リリース

バイナリ版のパッケージミスで、RubyCocoa.framework が適切に配置されていないという問題が(いまさら)発覚。レポートをくれた Chuck さん、ありがとうございます!

直したものを 0.3.4.1 としてリリース しました。ソースは 0.3.4 のままなので、バイナリのみのリリースとなります。まあ使っている人がいるのだろうかという疑問がそもそもあるわけだが。

|

スタンドアロンな w3c (X)HTML バリデータ Validator S.A.C.

いいかげん放置しまくりなウェブサイトを再構成しようと思って CMS をみつくろっていたら、結局スクリプト群を書いてしまうだめっぷり。

で、ついでにちゃんとチェックしないとなと思って w3c のバリデータ の MacPorts を探してみたら、ないのですよ。けっこうあれ構築するのめんどうなんだよな。そもそも Web サービスである必要ないし、と思って検索。その結果、Validator S.A.C. を見つけた。

これはアプリケーション形式に w3c のバリデータをパッケージしたもので、アプリケーションを起動して、URL を入力してぽちっとすれば、検証結果が表示されるというもの。対象がローカルファイルなら、Dock 上のアプリケーションアイコンにファイルをドラッグ&ドロップすれば検証してくれるのでらくちん。

ソースコードを Help メニューから見ることができるので、ちょっと見てみよう。内部的には NSTask でバリデータを実行して、標準出力を読み込んでドキュメントウィンドウ上に表示するというシンプルな仕組み。ようするに SandTrip と同じだね。また余計なことに時間を使ってしまった。

|

2007.03.02

Appcasting はどのくらい広まっているのか?

Cocoa勉強会の発表に向けて、Sparkle の資料を作成ちゅう。説明の中で Appcasting の話もしなくちゃいけないよね、と思って調べているのだけれど、どうにも Mac 界隈が中心、というか他の環境での事例がなかなか見つからない。

技術的には Podcasting とほとんど同じで RSS ベースなので、プラットフォーム中立だ。Mac でなければならない理由はないと思うのだけど、どうなのだろう?

いろいろ探していたら itok's Lab の「アプリ更新フレームワーク:Sparkle」というエントリを見つけた。ううむ、これ以上詳しく調べないと発表の価値がなくなってしまうなあ。がんばらねば。

|

« 2007年2月 | トップページ | 2007年4月 »