Win2000でPaint.NET ― 2007年09月01日 15時49分13秒
やっと見つかりましたがな
以前「Paint.NETがインストールできない」というエントリを書いたが、なんとかインストールできるものが入手できた。それまでに若干の紆余曲折があったのでメモっておこう。
2.5をインストールしてみる
会社のPCには2.5のインストーラが残っていたのでそれを持ち帰ってインストールを試みたが、いきなり「Paint.NET requires the .NET Framework 1.1.」と拒絶された。実は今回のクリーンインストールでは、.NET関連は2.0のみインストールして1.1は入れていなかったのだ。
2.5は.NET 1.1系対応の最終版で、これ以降は.NET 2.0に移行していたのは知っていたが、サイドバイサイドで動くと思ってそのまま試してみたがインストールすらできなかった。むぅ。
インターネット図書館
となると、2.5以上3.0未満のバージョンをなんとか入手したくなるわけで、まずはWeb Archiveだのみとなる。
以前のバージョンは現在の公式ページに移転する前に入手していたのでそちらの古いサイトのアーカイブを探って、いくつかページをたどってみた。
後半のほうはすでに移転先へのリダイレクトになっていたが、2006/07/15以前はかろうじて元ページが残っていたのでそこからダウンロードページへ移動、ダウンロードリンクをクリックしてみたが、リンクされているダウンロードサイトでも現在のバージョンしかダウンロードできない。むぅぅ。
ファイル名がわかれば、ひょっとして...
しかし、上記ダウンロードページにたどり着いたことで、もともとのダウンロードファイル名が判明(PaintDotNet_2_xx.exe)したので、これで検索してみることにした。
ぐーぐる先生に「PaintDotNet_2_63.exe」を尋ねて返ってきたのをいくつかたどると、なぜかゲーム系のサイトのダウンロードページへ。いってみたらダウンロードできた。いやぁ、探せばなんとかあるもんだ。
さらに日本語化
ということで、なんとか2.63をインストールでき、さらに「Paint.NET - 日本語化WEB」さんから2.5向けの非公式言語パックをダウンロード、だめ元で適用してみたらうまくいってメニュー周りも日本語化され、快適な状態で使えるようになった。まぁ、リソースファイルだけなのでランタイムバージョンには依存しないか。これでやっと、ひと段落。
ただ、アプリケーションとしての使い勝手は3.0系には及ばないんだけど、まあちょっとした画像加工とかなら間に合うからこれでいいか。
蛇足:バージョンに関する訂正
以前のエントリでは2.5系と2.8系(?たぶん3.0前の最終がこれだと思った)
とか書いていたが、2.x系の最終はどうやら2.72が最終らしく、このバージョンですでにWin2Kのサポートが切られているみたい。
まとめると、
- 2.5以前 → .NET 1.1ベース。対応OSはWin2K/WinXP(Server2003も入るかも。間違いなく動きそうだけど)
- 2.6系 → .NET2.0ベース。対応OSは変わらず。最終は2.64みたい。
- 2.7系 → .NET2.0ベース。Win2Kサポート打ち切り。最終は2.72?
- 3.x系 → .NET2.0ベース。対応はWinXP/Vista/Server2003。2007.9.1現在の最新は3.10
SpinelzのDatePickerのパフォーマンスが改善されている件 ― 2007年09月01日 17時02分49秒
ものすごい勢いでパフォーマンス改善してますが。
先日のエントリで、prototype + script.aculo.usベースのUIライブラリ「Spinelz」に対して無責任に文句たれてたら、なんと開発者ご本人よりコメントをいただいてしまった。びっくり!
詳細はコメント欄を参照していただくとして、
現在開発段階ではありますが、全体的にかなりパフォーマンス改善されております。 表示内容の変更や、複数Datepickerをバインドしてもストレスなくご利用いただけると思います。という情報をいただき、さらに正式リリース前にもかかわらず、現在の最新版のsvnリポジトリを教えていただいたので試してみた。
試してみると、年・月の切り替え時のもたつきがまったくなく、IEでも快適に使用できるように、劇的ともいえる改善がなされていた。すごい!
ざっとソースを覗いてみたら、以前はscript.aculo.usのBuilderを使ってDOM構築をしていた部分をソース文字列生成 → innerHTML書き換えに変更しているみたいなのだが、それだけ(というには修正ボリューム大きいけど)でここまで改善されるとはちょっと予想外だった。
dara-jのアプローチ
文句たれてるエントリでも書いたが、現在はとりあえず自分でスクラッチしてみている。自作するにあたり、以下のような拙い工夫をしてみている。
- テーブルそのものはnew時に生成しておき、表示更新はセルの値の書き換えのみを行う
- インスタンスが使用する要素一式のテンプレートをクラスオブジェクト(コンストラクタになるFunctionね)で1回だけ生成して、インスタンスはそれをcloneNode()したものを自己の要素とする
- 最後に選択した日付を記憶
- 選択日付と表示月の別管理、表示の記憶は表示月にする
- 日付表示として連動する要素の真下に自動的に表示
- 複数インスタンス設置時の、ポップアップの排他(DatePicker1表示中にDatePicker2を表示させたら自動的にDatePicker1が閉じる、といった具合)
テンプレートのcloneNode()が本当に有効かどうかはちと微妙なのだが、表示更新時にテーブルを再構築するのではなく表示内容のみを書き換える方法は結構自信があったのだが、どうも体感上はSpinelzの最新版のほうがパフォーマンスがいいような気がする。俺の2日間っていったい...orz
自作版については、急にSafariでNGになったりとちょっと不安定なところがありそうなので、もう少し検証してよく安定しているようであればまたSpinelzに戻すかも。ますます俺の2日間って...orz
改めて御礼
Spinelzを開発されている木下さん、無責任な悪口とも言えるエントリに貴重なコメントを寄せていただき、本当にありがとうございました。 ご教示いただいたとおりDatePickerのパフォーマンスに関して劇的ともいえる改善が見られ、今後の開発の進捗に大変期待しております。がんばってください。
おまけの愚痴: IEがむかつく
Spinelzに「IECover」というクラスがあり、DatePickerがそれを利用しているのはソースを見てしっていた。IE対策なのもコメントから伺える。さらにこれが「IEのselect要素が常に最前面に表示される」ことへの対策なんだろうってこともわかる。
が、いざ自分で作ってみると「IEのselect要素が常に最前面に表示される」ことが以下に腹立たしく、なるほどIECoverのような工夫がライブラリレベルで必要なのはそういったことかと感心させられた。IECoverが行っている、iframeを用いた回避方法なんてdara-jには自力で思いつくはずもなく、それだけでもUIライブラリに必要なスキルが多岐にわたり深いものが必要なのだなぁと思い知らされる。もっとも、IECoverなんてIE以外に必要ないんだけども。
IEのバカっぷりについては他にも
- ボックスモデルがヘン
- data:スキームに対応してない(これがあればUIライブラリに画像添付しなくてもいいのに)
- ベクターグラフィック周りが孤立無援のvml
- JScriptのString#split(RegEx, String)の結果が他の処理系と違う
- 動的に作成したiframeのバカっぷり(via: Enjoy*Study)
まぁ、根本的な部分でサードパーティのブラウザと事情が違うのはわかる(実態として、OSを構成するコンポーネント上にアプリケーションを構築しているので。mshtmlもmsxmlもWindowsスクリプティングも捨てられないのはわかる)んだけども、それが足枷になって他のモダンブラウザの足を引っ張るようでは存在意義が問われてしまうと思うのだが。
最近のコメント