neko

IRcat 20060407

06/04/07

「新しいUI」として導入したツールバーの挙動を安定化させたバージョンを公開します. ところで, β版扱いで公開してますが, Intel Macではちゃんと動いてるんでしょうか? ^^;; 何もコメントがないという事は動いてると思ってますけどね.

ちなみにこのUIのせいで, 今のIRcatはTigerでしか動きません. (そもそも10.3以前で動くUniversal binaryってちょっと面倒なんですが). 基本的にCocoa版のIRcatは下位互換をまったく無視して, 便利そうな機能はがんがん使う方向で実装しています. そっちの方が作ってて楽しいですからねぇ. コトノコは下位互換を気にしたコーディングにしていますが.

なんでそんな話になったかというと, サーバのディスク領域が少なくなってきたので, 2004年に公開したIRcatのソース/バイナリをサーバから削除しました. 困る人がいるとは思えませんが一応告知しておきます.

ircat-20060407.tar.gz (source のみ)
ircat-20060407.dmg.gz (バイナリ)

主な変更点は以下の通り

  • 環境設定ダイアログのアイコンをブラッシュアップ
  • ツールバーのカスタマイズを繰り返すと発生していた不都合の修正
  • 「Text only」の場合に, チャンネルメニューのチェックがずれていた不都合の修正
Comments & Trackbacks
Trackback URL for this entry : http://afternooncafe.jp/cgi-bin/mt/tb.cgi/371

Intel CPUのMac miniで使っていますが、問題なく動いています。ありがたく使わせていただきます

報告ありがとうございます

メッセージをタイプするエリア以外をクリックした後は、明示的にタイプエリアを再度クリックしてキーボードフォーカスをそこに戻さないとメッセージをタイプできません。
この問題の改善は難しいでしょうか?
個人的には、この問題があるので、いまだにIRCat 0.9.7のほうを愛用しています。

http://www.afternooncafe.jp/archives/04_03_22_neko.html

この頃から問題にはしていますが, 解決できないのが現状です

MacBook Proで使用させて頂いています。快適で、問題もありません。いつもありがとうございます。感謝です。

便利に使わせていただいております。
ところで、以下の様なトピックを設定するとトピックが正しく表示されないばかりかメンバーリストも出なくなります。
短くしたりすると表示できるので文字数等が関係しているようです。
一度お調べください。
topic 12345678901234567あいう12あ(あ)abcdefghあabあいうえ

やってみましたが, こちらでは正常に表示されます

…さて, どうしましょうかねぇ…

色々試した結果、IRcatの問題では無く、MacOSの日本語入力の問題らしいです。
74桁目に漢字を1文字入れる(73文字はASCII)となぜか最後に?(がついていました。
#ircle,Boomerang IntelMacどれでも同じ結果
ただし、この不正シーケンスで表示がおかしくなるのはIRcatだけでした。

β版公開日から毎日常用していますが、今の所目立った問題はありません。
ログイン時のパス付き部屋への自動入室は、部屋の名前のあとに半角スペースとパスを入れて登録しておけば出来るんですね・・・今まで気がつきませんでした。
ログの保存機能もあるし、今の所は要望の様なものも浮かんできませんね・・あ、キーワード別で効果音が設定出来たら良いなとは思いました。
あとは不満もなく使わせていただいています♪

Growlに対応する予定はありますでしょうかー?

http://growl.info/

キーワード別効果音あたりは実装したいとは思っていますが, 時間がとれませんねぇ^^;;

Growl対応の予定はないです. 私が使っていないので.

Intel MacMiniで有り難く使わせていただいております。

一つ問題点がありまして、ログファイルが読めないのです。出来たログファイルを見ると、BOM付きのUTF-16LEになっているようなのですが、その先頭にUTF-16BEのBOMが付いています。従って、バイナリエディタで見ると↓のようになっています。

FE FF FF FE 23 00 ...

ChannelModal.mの551行目あたりを修正すれば良いと思うのですが…

バージョンアップの機会がありましたら、検討して頂けると幸いです。

なお、Rosettaを使えば上記の問題も起きませんので、とりあえず不都合はありません。快適に使わせて頂いております。

ログの件の続きですが、ChannelModal.mの615行目を↓のようにすると、問題が起きなくなるようです。

[mLogFile writeData:[NSData dataWithBytes:L"\xfeff" length:2]];
(バックスラッシュが文字化けするので、全角にしてあります)

私はPPC Macを持っていないので、PPC環境で正常動作するか判りませんが…

ご参考になれば幸いです。

わざわざありがとうございます.

ただ, こうするのが正しいのかなぁと思っていますが, Intel Macでこれが動くか確認お願いできませんか?

unichar bom = 0xfeff;
[mLogFile writeData:[NSData dataWithBytes:(char*)(&bom) length:2]];

私も書いた後でそう思いました。私、2週間前までwchar_tが常に16ビットの世界にいたんで…(笑)

ご指摘の通りに変更してコンパイルして、動作確認しました。ご対応ありがとうございます。

561行目も↓のようにしないと、ログの中に謎コードが残ってしまいますね…
if(*(unichar *)bom == 0xfeff){

こちらはテキストエディタでは問題ないですが、Perlあたりに食わせると文句を言われそうです…

修正はすぐできたのですが, 週末ちょっと忙しくてuploadできませんでした^^;;

Perlだけでなくて, miでも途中にBOMがあると, うまくencodeを認識してくれませんね.
そこらへんも修正して, 20060718版としてあげておきます.

Comments
そらぴ~ at 04/12 19:58
atsushi at 04/18 10:28
mrmt at 05/02 02:06
atsushi at 05/02 10:57
rucifer at 06/01 12:59
すぎさわ at 06/13 11:09
atsushi at 06/18 21:20
すぎさわ at 06/20 15:12
くまん at 06/25 16:39
hirose31 at 06/28 01:56
atsushi at 06/28 07:03
Takashi Ito at 07/14 22:22
Takashi Ito at 07/14 23:52
atsushi at 07/18 09:23
Takashi Ito at 07/18 20:23
atsushi at 07/18 22:23
(16 comments)
Powered by Movable Type 4.27-ja