macの最近のブログ記事

まだ生きてるよ!(挨拶)

ご他聞に漏れずうちもSnow Leopard入れましたが、Growlが現時点(1.1.6)でどうやらまだ対応してない(公式曰く1.2まで待ってけろとな)、というかx86_64用バイナリを持ってないようですね。

IntermezzoがGrowlを使用しているので、本体のx86_64対応を進めとこうと思ってもビルド時にリンクさせておくと当然エラーが出て怒られる。Growlが動かなくてもかまわないからとりあえずx86_64動作時にもGrowlの如何に関わらず動かしたいと思ったので、実行時の動的ロードに切り替えよっかってしてみたんだけどなかなか動かないからアレッと思ってギアいじったっけロー入っちゃってもうウィリーさ(何)

http://growl.info/documentation/developer/implementing-growl.php?lang=cocoa
Implementing Growl support in your Cocoa Application

ここに書いてあったのにね。

この"Using Cocoa, you can use the following code snipped..."を参考に少し修正したのが下です。

    Class bridgeClass = nil;

    NSString* growlPath = [[[NSBundle mainBundle] privateFrameworksPath] stringByAppendingPathComponent:@"Growl.framework"];
    NSBundle* growlBundle = [NSBundle bundleWithPath:growlPath];
    if (growlBundle && [growlBundle load]) {
        // bridgeClass = [growlBundle principalClass];
        bridgeClass = [growlBundle classNamed:@"GrowlApplicationBridge"];
        
        if ([bridgeClass isGrowlInstalled] == NO || [bridgeClass isGrowlRunning] == NO) {
            // Growl本体がインストールされてないか、動いてないよ
            return;
        }
        
        [bridgeClass setGrowlDelegate:self];
    } else {
        // Growlフレームワークがない、またはロードできないよ
        // x86_64の場合はここに来るよ
        return;
    }

    // ok

GrowlApplicationBridgeクラスがビルド時のリンクで解決できないので、classNamed:メソッドを使いバンドル(フレームワーク)から読み込んでリンクする方向に倒して、ようやく動くようになったとです。Growl.frameworkのInfo.plist読む限りでは、Principal ClassはGrowlApplicationBridgeクラスなので、classNamed:の代わりにprincipalClassメソッドでも行けるはずだけど、将来に渡ってどうかは分かんないのでとりあえずclassNamed:で名指しにしてます。まあそんときゃGrowlApplicationBridgeクラスだってdeprecatedになってるかもしんないけどねー。

まあ、Growl 1.2が出れば多分それで無問題なんだろうけどねー。

(*´・ω・)(・ω・`*)ネー

Intermezzo 0.9.0リリース

| コメント(0) | トラックバック(0)

ひさびさのIntermezzoのバージョンアップです。

  • キーワード機能を実装しました。
    "Preferences"パネルで"Keyword"タブを追加しました。ここでリストに追加すると、強調表示およびキーワード出現時にGrowlによって表示されます。
  • Growl機能復活しました。

こんなところで。次いくとしたら0.9.x->0.10.0かなあ。1.0に持っていくまでにもう少しかかるかもです。

Intermezzo 0.7.0 リリース

| コメント(0) | トラックバック(0)

Intermezzo 0.7.0リリースしました。...といってもやっとbetaなので、取り扱いにご注意ください(何)

http://trac.foursics.jp/intermezzo/
Intermezzo trac

  • 今のところ10.5(Leopard)専用ですが、10.4以前への対応は検討中です。
  • ドキュメントは今作ってます。
  • メニューに余計なのとか入ってるっていうか残ってますけど、気にしないでください。
  • バグレポートや機能要望などはtracのチケットで受けられるようにしますのでそちらにどうぞ(ここでもいいけど^^;;)

MacOSX上でネットワークを扱うプログラムを書く場合、やり方はいくつかある。

  • ソケット
  • NSStream
  • NSURLConnection
  • 分散オブジェクト環境

あと、CarbonベースでもよC言語向けのが欲しければCFNetwork、あとBSDソケットとほぼ同等だけどCFSocketという手もある。まだ他にもあるかななな。

http://www.geekpage.jp/programming/macosX-network/
Geekなぺーじ : Mac OS Xネットワークプログラミング

まあ、NSURLConnectionなんかはURLベースなので「ネットワーク」というには大分限定的・局所的だし、分散オブジェクト環境に至ってはCocoaアプリケーション同士でないとほとんど使いこなせない。汎用性ではソケットに勝るものは無いでしょう。ただ、状況に応じていろんな選択肢があること、これを常に心に留めておくことはとっても重要。

あと、Cocoaではソケット・ファイルディスクリプタをwrapすることのできるNSFileHandleもあるので、ぜひこれらをフル活用していきたい。通知(NSNotification)やデリゲートの仕組みを元に、メインループからの非同期的読み込みの機構も実装されているので、これを使った方がCocoa GUIアプリケーションとしてより自然な挙動を実現することができる。

確かにソケットでよく使うFIONBIOやselect()/poll()などはそのまま適用可能だけど、UNIX系由来のコードを出来るだけそのまま動かすといった明確な意図に基づいて扱う場合以外は、それが有効に効力を発揮する局面はあんまり無いように思う。(≒GUIを持たない、純粋にC言語でmain()からがりがり書くようなケースも含む。ただそれでも、結果的にCocoa/Carbonに乗っておいた方が楽になれることも結構ある)

まあ、NSStreamとNSFileHandleさえあればわりとごはん3杯くらいいけます。はい。

http://developer.apple.com/documentation/Cocoa/Conceptual/Streams/Streams.html
Stream Programming Guide for Cocoa: Introduction to Stream Programming Guide for Cocoa

http://developer.apple.com/documentation/Cocoa/Conceptual/LowLevelFileMgmt/LowLevelFileMgmt.html
Low-Level File Management Programming Topics: Introduction to Low-Level File Management Programming Topics

今週のObjective-C重箱の隅

| コメント(0) | トラックバック(0)

http://www.atmarkit.co.jp/fcoding/articles/objc/02/objc02a.html
一番初めのObjective-Cプログラム - @IT

ものすごぅく細かいことだけど、ブコメにも出ているのに割とスルー気味なのが気になったので書いちゃう。

  • alloc/retainとreleaseの対応付け

    他の点は見解の違いや記述意図次第で変わる話なので、ぶっちゃけどうでもいいと思うけど、これに関しては最低限きちんとやった方がいい。

    Cがmalloc()に始まりfree()に終わる言語であるように、Objective-Cもメモリ確保が非常に大きな意味を持つ。私がこの言語に触れたときはその最初の一歩(から少し踏み出したくらいだったかもしれないが)で、alloc、retain、releaseの組み合わせについて散々言及された文献にぶち当たらされたものだった。

    最初の一歩なので、それぞれの意味や規則についていろいろと説明するのは後回しでかまわないのだから、せめてサンプル内でもreleaseするくらいはして欲しかった。訳分からないうちから癖づけるくらいしないと、retain/releaseが幾重にも折り重なる現実のObjective-Cのコードとやっていくのはちょっと、いやかなり難しい。まあ、最近はGarbage Collectionも入ってきてはいるけど、それが全面的に受け入れられるほどまだObjective-Cの世界はシフトしていってないし。

  • クラス個別のヘッダファイルのインポート

    これはどうなんだかな。最初なんで、使用するクラスを名指しでインポートして見せたいっていう意図なんだろうけど、通常は#import <Foundation/Foundation.h>とか#import <Cocoa/Cocoa.h>とか、フレームワーク単位で用意されたヘッダファイルがあってそっちを使うことが多いと思うなあ。でそいつをプリコンパイルヘッダに持ってくとかね。あんまり個別にインポートしてばかりいるとそれだけで1画面分とかなってしまうので、一般的にはちょっとおすすめできない。まあ、考え方次第だと思うけど。

  • ヘッダファイルさらに

    Objective-Cは良くも悪くも根っこがCなので、ヘッダファイルをどのようにインポート(Cではインクルード)するかを一応ちゃんと考えとかないといけない、と思う。まあ、Cではかつて同一のヘッダファイルに対する多重インクルードを防ぐ仕組みが言語仕様上無かった頃の名残であって、#importでそこを解決してるんだからいいじゃない、という考え方もあるにはあるけど、しなくてもいいインポート/インクルードを防ぐことでコンパイル時間をコンパクトに保ちましょう、という主張は(この程度の極小規模のコードではあるが)まだ説得力があるはずだ。

    従って今回のケース、stdio.hのインポート位置は明らかにSinger.mの方だと思うし、Song.hについても同じくずらすことはできる。まあ、Song.hについては@class使ったりする必要があってさらに説明が増えることになるから、やんない方がいいか。まあ、そこをid型使ってごにょごにょ、っていうこともできるけどね。

  • @implementationの後ろは

    クラス名だけでok。": 親クラス名"は要らんすよ。

これの続報。

http://theocacao.com/document.page/18
Theocacao: Bindings and File's Owner

Cocoa BindingsをInterface Builderで設定してしまうと発生するretainを回避するには、代わりにawakeFromNibでsetContent:してやればよいということのようだ。実際それでうまく回避できましたよ。

ひさびさにCocoaネタ。

releaseしたはずのインスタンスがどうしてもdeallocされなくて不審に思っていたら、そいつがOwnerとしてNIB内でCocoa BindingされていたためにretainCountが+1されてしまい、どうしてもカウントが0にできなかったというオチ。よくよく考えれば当たり前なんだけど盲点だったなあ。

NIBから見ればOwnerの領域はNIBの外部なわけで、そいつがNIB(上のインスタンス)からretainなんかされたら循環参照まっしぐらですわな。ありがちな教訓にはたとする師走の暮れでありましたとさ。ちゃんちゃん。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちmacカテゴリに属しているものが含まれています。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

ウェブページ

OpenID対応しています OpenIDについて
Powered by Movable Type 5.04