独り言日記（2006/02）

独り言日記

e-Tax（2006/02/27）

今年の確定申告はe-Taxを利用してみよう、ということで手続きを行ってみました。

http://www.e-tax.nta.go.jp

まず、「開始届出書」というのを作らないといけないのですがこれがPDF形式の入力フォームです。これの入力ですぐe-Taxを利用できるのかと思ったのですが、なにやら専用ソフトを郵送してくるみたいで、、、う〜む、時間的に間に合うのだろうか。もうちょっと早く届出しといたらよかったかなぁ。

その後、電子証明書がいるとのことで この段階でよくわからんです(^_^;;。手続きどおりやればいいみたいですが、事務作業が発生しそうなので時間はかかりそうですね。

後、証明書（支払調書、控除証明書など）は別途税務署に郵送する必要があるみたいです。どちみち郵送が発生するのなら、申告書作って証明書とともに送る従来の形がいいなぁ、と思いました。はやくもe-Tax利用を挫折です（汗）。

この手のは一部を電子化する、としてもあまりメリットを感じない、という感想を満ちました（セキュリティのための処置が必要とか、むしろ手間）。セキュリティに関しては、ネット経由になる段階で永遠の課題でしょうから、難しい問題ではありますね。

郵送で提出する証明書類も電子化すればいいのですが・・・・。これがある限りは、やはり申告自身は郵送が早いのかなと考えてしまいます（ちなみに国民年金の場合は、控除証明書が郵送されてきてますので、国関連で見た場合の手続きとしてはe-Taxの電子化とは相反するような・・・。まずはここから電子化が可能な手段をとってほしいなぁと思ったり。もちろん、誰もがネットを利用してるわけではありませんので 紙ベースのはなくせないでしょうけど）。

なお、e-Tax自身は専用ソフトウェアです。しかもWindowsのみです。Webブラウザ動作のシステムにすればよかったのに・・・・。ただ、ソフトウェア仕様は順次公開するとのことで、開発会社がタッチできるようにしていくようです。といっても、申込書を送るとCD-Rに焼いて郵送してくれる、とのことなのでなんかローテク感をかもし出してますが(^_^;;。

http://www.e-tax.nta.go.jp/shiyou/shiyou2.html

ぱっと流れを見てみた感じ（まだ届出書の送信しかしてませんが）、過去の（書類重視による）手続きから電子化の移行が、意識的にもシステム的にも難しいんでないか、という気がしました。特に国関連の大事なことですので、「重いなぁ」（＜これは意識的に）という実感です。

これに限らず、国民年金（厚生年金）とか健康保険とかの支払いをなぜ一本化しないのかとか、広義の意味でのシステムを見直してほしいなぁ、と思ったりします。＜お上

去年、さすがに月ごとの振込みが面倒になったので、引き落としにチェンジしたのですが、記帳上は年金と健康保険は別々ではありますね。

でも、せっかくの機会なので e-Taxは間に合えば利用してみようかなと思ってます。

地底神殿（2006/02/23）

新聞に記事があったのですが、日本の地下にも神殿があるようです。といっても、巨大な地下放水路ではありますが。一般の見学会も募集してますね。

http://g-cans.jp/

平日じゃなかったら行きたかったなぁ。なんか、こんな雰囲気は大好きです（笑）。リアル映画のセットじゃないすか、スケールがすごそう・・・・。３月のどっかで仕事中断していこうかな、と思ったのですがもうすでに満員・・・・、気づくのが遅かった・・・。

VC2003 vs VC2005Express（2006/02/23）

高速GIレンダラredqueen作者の大垣さんのサイトにて、VC2005 ExpressEditonでパフォーマンスダウンした、という報告が書いてありました。

http://www.teamredqueen.com/

マジで？ということで数値演算をチェック。10000 x 10000の計算を繰り返した結果をベンチしてます。Celeron 1.00GHzのWindowsXPマシンにて。単位はmsです。

ちなみに実行ごとに多少の揺れがでますので、環境には依存する結果である、ということをご了承ください。何回かチェックしてみて、よい結果が出た数値を採用しています。

浮動小数点演算とsqrt、rsqrt（1.0 / sqrt）、cos、sin、それとベクトル演算処理、ベクトル正規化でたしかに速度ダウンしてますね。というか、FPU部分で遅いところが多い？う〜ん、やはり無料ゆえの制限なんだろうか・・・＜VC2005 ExpressEdition

これだとレンダラだと致命的になりますね。そして、fmod/sqrt/rsqrtを独自処理に置き換えてみました。

これだと速くなりました。キャッシュに乗るからかな？だったらVC2003も同じか・・・製品版の「拡張された新しい最適化機能」というのが影響するのだろうか・・・。しかし、Pentium4-2.8GHzとCeleron-1.00GHzで比べると、逆数平方根の速度がANSIと自前で差が結構出ますね。OSは同じでも環境によっていろいろ差が・・・・

IntelMacでの数値演算処理（2006/02/21）

IntelMac（CoreDuo）にてベンチマークをとってみました。

数値演算処理のベンチマーク(Win/Mac/IntelMac)

得手不得手がありますが、あきらかに速度アップは期待できています。クロック数を考慮しても、今までのMacユーザは「速っ！！」って感じるかもしれませんね。ただ、計測した感じでは四則演算がちょっと重いかもしれないです。この部分でわずかに足を引っ張っている部分がありそうです。しかし、fmod（除算のあまりを求める）がやたら速い(^_^;;。ベクトル演算が速くなってますので（実質は平方根と逆数平方根計算かな）、3DCGソフトは高速化しやすいかもしれませんね。

なにげに、初めてのUniversal Binaryアプリがベンチマークになってしまった・・・。

後、Mac(Xcode)にアップしたMacのサンプルは、実行ファイルがDebugものでした（なので、ZeroLinkとなり、他環境では実行できません・・・。再ビルドすればいけますが）。また、再度アップします。

Shade8でのdialog_interfaceでSXULを使う（2006/02/21）

いろいろ試してみました。SXULでのダイアログコントロール配置を初めて使ってみましたが結構なことができそうです。

dialog_interfaceでのすべてのコントロールをSXULにてとりあえず並べてみました。OSXにて文字が一部欠けるバグがありますね。

コントロール（ウィジット）として、以下のようなものがあります。

• 水平・垂直に配置するためのレイアウト(hbox/vbox)
• カスタム描画領域（custom）
• テキスト表示（long-text）
• テキスト入力（long-text/short-string）
• コンボボックス（selection）
• プッシュボタン（push-button）
• チェックボックス（bool）
• 数値入力（float/double/int）
• スライダ（float/double）
• グループ（group）
• タブ（tab）
• プログレスバー（progress）
• リストボックス（listbox）
• 色選択（rgb）
• ベクトル入力（vec3）

ツールチップ（マウスカーソルをコントロールの上に乗せると、しばらくするとメッセージが表示される）も実装可能です。このうち、group/tabについては使い方がSDKリファレンスのほうにはありません。groupはサンプルのBasicEffectorで使ってますので、サンプルソースとSXULを見ると使い方は理解できそうです。

tabは配置方法が分からなかったのですが、これもちょっと裏技的な方法を使って調べてみましょう。Macのプラグインで「StereoRendering.shdplugin」というプラグインがあり、これはSXULを使ってタブ表示を行っています。このプラグインファイルをWindowsマシンで見ると、

[Contents]
   [MacOS]
   [Resources]
        [de.lproj]
        [en.lproj]
        [ja.proj]
            [sxuls]
              stereorendering_dialog_id.sxul
              text.sxul  
        ....
   Info.plist

のようなフォルダ構成になっているのを見ることができます（Mac上でもフォルダとしてみることは可能です）。OSXでは、ShadeのプラグインやShade自身はバンドル形式であるため、中身（リソース）を見ることができるわけです。

このうち「stereorendering_dialog_id.sxul」をテキストエディタで開くと・・・・。SXULリソースをそのまま見ることができます。タブがありますね。

SXULにて以下のように配置すると、タブが実装できました。window_interfaceでのSXULではtab内はgroupで分けるのですが、dialog_interfaceのSXULではvboxで囲ってます。

<tab>
    <vbox id="10" label="タブ1">
        <long-text id="11" label="これはタブの１つめ" default="" editable="false" short_text="true" />
        <hbox>
            <push-button id="12" label="プッシュ1" />
            <push-button id="12" label="プッシュ2" />
        </hbox>
        <bool id="13" label="チェックボックス"/>
    </vbox>
    <vbox id="20" label="タブ2">
        <push-button id="21" label="プッシュ2" />
    </vbox>
    <vbox id="30" label="タブ3">
        <push-button id="11" label="プッシュ3" />
    </vbox>
</tab>

まだすべての機能を網羅したSXUL使用プラグインは、標準プラグインでも存在していないみたいですが、「なかなかやるやん」という感想です。惜しむらくは、リストボックスが標準でチェックボックス付きでカッコワルイという点かな(^_^;;。

これらの使い方もまたTipsに書き溜めていくことにします（たぶん、SDKのリファレンスだけでは使い方を読み取れないと思いますので・・・）。

Shade8プラグインSDKでのプチ知識（2006/02/18）

ちょっとShade開発陣の方たちと話す機会がありましたので、プラグインSDKについて仕入れた情報で有益なものを書いてみます。

モーダルダイアログとフローティングウィンドウの区別

フローティングウィンドウは、window_interfaceを使ってコントロール（ウィジット）を配置するわけですが、これは独自描画になります。変わってモーダルダイアログは、dialog_interfaceを使ってappend_xxx関数にてコントロールを追加します。この場合は、OSネイティブのコントロールが使われます。ここまではShade7.xの話です。

Shade8では、dialog_interfaceにwindow_interfaceを割り当てることができるようになりました。また、「SXUL」（XML形式のリソースファイル）にてダイアログコントロールの配置を外に出せるようになりました。

ここでプチ知識。ShadeではSXULを使う形を推奨している、とのこと。dialog_interfaceの子ウィンドウとしてwindow_interfaceを割りあてるのではなく、SXULを使ったときのOSネイティブのコントロールにデザインを統一していきたい、との話でした。

整理すると、SXULでのコントロール配置を前提とする。フローティングウィンドウはwindow_interfaceを使う、モーダルダイアログはdialog_interfaceにてSXULで配置を行う。

dialog_interfaceで独自の描画領域を作る場合（プレビュー画面とか）、この描画領域としてwindow_interfaceを使うのがいいかも、ということです。

プラグインSDKのプロジェクト

SDKの「win\plugins\plugins.sln」(OSXは、「macos/plugins/xplugins.xcode」)をVisualStudioで開いて独自プロジェクトを作成する、というやり方を私はしていたのですが、「projects\BasicEffector」をコピーして改変するのが簡単、とのことです。知らなかった・・・・(^_^;;。これだと、プラグインSDKで必須のincludeファイルは分離しておき、かつプロジェクト構成でsampleファイル類とか意識しないようにすっきり管理できそうですね。OSXの場合も同じです。

SXULファイルのWin/OSXでの共有利用

私のサイトにて解説したSXULにて、Win/OSXでSXULファイルを共有できない（？）と書いたのですが、可能とのこと。これもBasicEffectorのサンプルが参考になります。すみません、私が勘違いしてました(^_^;;。

また、このへんのTipsはまとめますね。

ただ、現状はdialog_interfaceでSXULを使う場合に 使えない・実装されていないコントロールも多くあります。これは、後に追加していく予定もあるみたいです。もちろん、このサイトで無理やり実装していたOpenGL描画領域も(^_^;;。

VisualC++2005 ExpressEdition（2006/02/18）

もうご存知の方も多いと思いますが、以下のサイトにて、VC++の最新版をダウンロードできます(PlatformSDKの入れ方も記載されてます）。

http://www.microsoft.com/japan/msdn/vstudio/express/visualc/

かなり後発になりましたが試してみました。もう店頭にも製品版がありますね。

VC++.NET2003でマイナーダウンしていた「プロジェクト外のファイルが分かりにくい（アイコンが同じなので）」が直ってました。

この場合、「mwTimer.cpp」をプロジェクトからはずしているのが一目瞭然です。というか、VC++6.0まではきっちり対応していた部分なんですよ。なぜか、.NETになってからこの機能が削られてしまったんです。

後、Shadeプラグインもビルドできますね。これで、Win/Macともに無料でShadeプラグインSDKはビルドできる環境が整ったわけです。また、エラーチェックが厳しくなってますね、それほど自分のソースが安全じゃない書き方をしていた、ということか(^_^;;。Shadeプラグインをビルドした場合はwarningも出ますが、そのままビルドしても問題ありませんでした。また、フリー版のExpressEditionは最適化コンパイルにも対応しています。

ListBoxからData Browserへ（2006/02/16）

OSXでのListBoxですが、CreateDataBrowserControlで作成したコントロールに置き換えるほうが正しい使い方のようです。

以下のURLに書いていてほしかったですねぇ。こんなコントロール知らなかったですし。

http://developer.apple.com/documentation/Carbon/Reference/Control_Manager/Reference/reference.html

Data Broswerについては以下。リスト形式だけでなく、テーブル形式（グリッド形式）にもできます。

http://developer.apple.com/documentation/Carbon/Reference/databrow_reference/

ListBoxでは、文字列の挿入などがUnicodeを考えない仕様だったのですが、DataBrowserではCFStringで多言語対応して文字列を格納することになります。文字列だけでなく、アイコンやボタン、チェックボックスなどなどセルに入れることができます。

しかし・・・・・、ものすごい使いにくい・・・(^_^;;。なんでデータを追加するのにコールバックを呼ばにゃならんのだ・・・。バージョンがあがるのに使い勝手が悪くなる、というのはどうにかしてほしいところ＜Apple。

私が今までいじったウィジット（コントロール）APIで一番使いにくい仕様かもしれないです。ようやくリストボックスと同等の実装ができました（何時間費やしたことやら）。注意点としては、Data Browser内にてアイテム（カラム、セル）の挿入をしたときにカラム自身は実体を持たない、というのがあります。CFStringで文字列追加したとき、Data BrowserのControlRefを破棄するまではReleaseしてはいけません。

UTF-8でのソースの受け渡し（2006/02/15）

Windows/OSX/Linux間でソースを共有しようと奮闘していたのですが、「UTF-8でBOMなし、改行はCR/LF」とするのが一番無難な手ごたえでした。Xcode（gcc。Linuxでも同じ）では、BOMありのUTF-8だと食えませんでしたので。また、UTF-8だと改行コードは重要ですね。.NET2003ではいろいろ不都合が起こって原因をたどると改行コードでした。CR/LFで保存すると日本語コメントがまじっていてもコンパイルでとまらないようになりました。ただし、定数を文字列指定する場合は注意です（日本語文字列などは外部ファイルに出したほうがいいかも）。

後、おそらくOS Xでのバグかなというものが。「CreateNewWindow」でウィンドウやダイアログの生成をできます。このときのアトリビュートとして「kWindowCompositingAttribute」を指定することでHIViewが使えるようになります。このときは、ルートのコントロール（ControlRef）は作成する必要がありません。GetRootControlで取得できるControlRefがルートになります。HIViewの描画イベントを使う場合などはCreateNewWindowで「kWindowCompositingAttribute」が必要。

しかし、、、、このときのCreateListBoxControlによるリストボックスの挙動がかなり変になりました。描画がずれている、マウスクリックは正常に動いているようですが、再描画がX/Yの符号が反転（？）した感じの位置にて行われてしまってます。これじゃあ、せっかくの新しい機能も使い物になりません。

結局、HIViewはやめて（kWindowCompositingAttributeを指定せず）、ルートのコントロールは「CreateRootControl」で作成することにしました。ただし、描画はHIViewのを使わずに従来のkEventWindowDrawContentを。OSXではまだまだ不都合が多いですね。ほかにも変なものは発見してるのですが、別の回避策でなんとかしのいでいたりします。

後、先日、ナイスなコントロール（ControlRef）のサンプルがない、と言っていた件ですが、XCodeをインストールしたときの「/Developer/Examples/Carbon/AppearanceSample」がいわゆる「ControlRefによるウィジットを試してみました」的なサンプルで参考になりそうでした。

OS XでのHIViewとか（2006/02/14）

ちょっといじってました。今更ながらですが、コントロールのイベント処理はマウスダウンイベントで「FindControlUnderMouse」関数などでマウス位置からコントロールを取得し、自前で処理してあげるものなのでしょうか（リソース(nib)を使って、だと以前やってたのですが、すべて制御だと ちとやり方が検討つかないです(^_^;;）。

HIViewですが、サブクラス化して独自のイベント処理を行うコントロールを生成する（カスタムコントロールの生成）のは、Appleのサンプルもあるので理解できるのですが、普通のプッシュボタンとかどう実装するのだろう？「HIObjectCreate」「HIObjectRegisterSubclass」もオリジナルのコントロールのイベント処理をHIObjectで行うと おそらく一番最新の機能を使ってるんだろうなぁ、と思うのですが使い方がさっぱり。。。なんにせよ、HIObjectCreateで必要（？）な「kHIPushButtonClassID」とかがAppleのデベロッパサイトでも検索できない（ドキュメントがない、YahooやGoogleでもほとんど見つからないに等しいですねぇ）、というのはまずくないすか？もしかしたら、HIObject自身がマイナーなんだろうか、、、。

ということで、OpenGL for dialog_interface(Shade)は、ちょっと先走りすぎたということでただ今根本から修行中です。まだOS Xでは、イベント部分を把握しきれてないや、というのを理解しました（汗）。Windowsのほうですが、もうちょっとスマートにいけそうです。サブクラス化すると、キーボード／マウスフックしなくても、イベントを迂回させることができそうですね。これらはまたの機会に。

しかし、OS XでのUnicode対応は表示が安定してます。

Windowsは、フォントの都合でハングルが出なかったりWin2000と挙動が違ったりで面倒だったのですが。後、QuickDrawをやめてQuartz 2Dを使ってみました。やっぱしきれいだなぁ＜OS X。

ただ、注意点として「Quartz 2D」でのテキスト描画では英字／数字（半角のもの）以外は表示できません。この場合は、ATSUIというのを使うのだそうです。

う〜ん、OS XのAPIはあちらこちらに散らばり過ぎではなかろうか(^_^;;。コントロールの実装はControlRefのほうがわかりやすいなぁ（というか、HIObjectがよくわからん）。ちなみに、HIViewあたりを使い始めると「OSX 10.2以降」という制限がついてしまいます。10.1では動作しないです。これと入れ替わるようにQuickDraw命令は10.2以降は非推奨になってますので、早めにすべて入れ替えないといけませんね。

UTF-8のBOM（2006/02/10）

VC++でUnicode（UTF-8）でソースを扱う場合、BOMあり（シグニチャ付き）で保存しないと、コンパイルエラーが出るときがあります。なんで、すべてのUTF-8ソースにBOMをつけるわけですが、LinuxのgccではBOMをはずさないとコンパイルが通りませんね。う〜ん、なんとかUTF-8ソースを共有できないものか・・・

エラー C2001（2006/02/10）

VC++(.NET2003)にて、Unicodeをプログラムする場合に「C2001」エラーに出くわすことが多々あります。これは、「定数が2行目に続いています。」というメッセージでして、printfなどのダブルクォーテーション閉じがない場合などに出るエラーです。

こんな単純な理由だけでなく、以下の条件のときにこれが出ます。

• UTF-8でソースを保存する
• 文字セットはUnicodeを使用（プロジェクトの[全般]-[文字セット]で「Unicode文字セットを使用する」を選択）

このとき、以下のようなソースを書くとします。

#include <stdio.h>
#include <tchar.h>

int main()
{
    _tprintf(_T("テスト"));
    return 1;
}

「_T」マクロは、Unicodeで扱う場合に文字列をワイドキャラ変換するためのものです。Unicodeでプログラムを扱う場合は、最終的にWindowsに渡す文字列は 半角1文字がshortで構成される「ワイドキャラ(WCHAR)」で扱う必要があります。

上記の_tprintfは、そのマルチバイト時のprintfに相当する関数です（Unicodeの場合は「wprintf」に置きかえれる。ですが、DOS窓がワイドキャラ表記でないと どちみち表示はできないわけですが）。上記は正しいようで、実はエラーC2001が出ます。gccだと問題ないのですが・・・・

ただ、別の全角文字列を入れたり半角の時はまったく問題なかったり。これは、どうも「_T」マクロが原因な気がします。最後の全角とダブルクォーテーションの組み合わせが鬼門のようです。

これの解決策は、

 _tprintf(_T("テスト?0"));

と、文字列の最後に「?0」を入れる、これで回避できました。「?0」はマルチバイトでもワイドキャラでも終端文字ですので文字列指定には影響しません。

wxWidgetsでの「wxT」マクロも実質は「_T」ですので、同様で回避できます。

XPスタイルで行こう!!（2006/02/07）

ごくごく最近気が付いたことがあります。Windows XPでは、ウィジットが淡い水色で統一されています。対して、Windows 2000までは灰色がベースです。

＜Windows 2000以前＞

＜Windows XP＞

なにげに対応しているアプリが多い中、「これ、どうやるんだろう？」と思って調べてみました。上画像はそれを切り替えたものです。

ずばり、「XPスタイル」で検索するとその実装方法が引っかかりました。

http://www.microsoft.com/japan/msdn/windows/windowsxp/xptheming.asp

マニフェストファイル（XML）を作成し、リソースに加えるときに

CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "my.manifest"

のようにします。

そして、comctl32.libをリンクして、プログラムの初期化処理時に

#include "commctrl.h"
...
InitCommonControls();

としてビルドすると、WindowsXPではルックアンドフィールが切り替わります。2000で起動すると、普通の灰色にて表示されます。

ただ、ちょっと動作に違いがありますね。ほんのわずかにアプリケーションを豪華にしたい場合は、有効な手段かもしれません。

TurboLinux FUJI（2006/02/04）

「TurboLinux FUJI」を買ってきました。ご存知、ライブドアの子会社になってしまったターボリナックス社のLinuxディストリビューションです。

http://www.turbolinux.co.jp/

私自身は、TurboLinux8までは買っていたのですが、それ以降はノータッチでした。あの事件があってから、すぐ登録ユーザ宛にお詫びのメールが来てまして、それで「誠意があるなぁ」というのもあって、ひさびさに購入です。技術的には高いものと独自性がありますので、応援したいところです。

「David」というのが、Windowsアプリを実行できるエミュレータとしてうたってますが、これはWord/Excel/PowerPoint2000が「インストールして実行できる」だけで、エミュとしては無理っぽいですね。自分で作ったWindowsプログラムを試してみたかったのですが、起動できませんでした。LinuxでWinプログラムを動かすつもりはないので、別にいいですが(^_^;;。これを目的に購入しようと思ってる奇特な方は注意です。

ちょっとwxWidgetsをビルドしてプログラミング環境を整えようかな。LinuxのクライアントとしてはTurboLinuxは気に入ってますので、持ちこたえてほしいところ。