27 5月
触れてみるべきソフトウェア
Bagel2について (その2)の実質続き.ほとんどメモ.半年前の下書きからサルベージした出がらしなのでこれまたちょっと古い.
“The best way to predict the future is to invent it.”
26 5月
タイトルバーを取っ払って、タブの段と閉じるボタンの段を同じところに持っていったのはGoogle Chromeと同じ発想。ブックマークツールバーは削除、Windows 7と似たような感じでタブバーと統合する。どう統合するかは第3版で。
このレイアウトの欠点は、最大化しているときにスクロールバーをいじりたいとき、マウスを画面の端まで一気に持っていって、スクロールバー付近に気軽に合わせることができないことか。閉じるボタンが右側だったらよかったのに…。あと、タブへの視線移動量が、左に置いたときよりも大きくなりそうだ。
コマンドラインインターフェースとの相性はいいかもしれない。タブコントロール部分を出力先ととらえた時、リダイレクト記号と「出力先」のある方向が一致する。
17 5月
ここらへん読めば、Bagel2で目指しているものがおぼろげながらわかってもらえると思う。ただ、2007年くらいの自分のはてブからも拾ってきているので、情報としては古いものも混じっている。
俺がFirefoxの拡張機構に感じていた不満ってのはここにある。簡単にいえば、Piroさんがよく言っている「拡張=野良パッチ」論。Bagel2では、上でいう2の層を実装したいと思っている。正直、ここが最大の障壁。
Plan9日記は面白いから全部読むべき。Plan9の「すべてはファイル」という概念はもちろんのこと、acmeについても見ておいたほうがいい。
alohakunのエントリも面白いから全部読むべき。コメントも含めて。
より良いソリューションに対する最も危険な敵というのは、十分に良い既存のコードベースなのだ
AtomPubは最近雲行きがあやしくて鬱
WecSlicesとかアクセラレータとか、そろそろ実用段階に入ってきた感があるMicroformat。昔は読むばっかりで、はてブを活用してなかったので、もっと重要なエントリはあるはずなのに漏れがひどいなあ…
実はBagel2のモックアップをAzaに見せたことがある。
Azaの親父さんの作品。
データは常にアルゴリズムよりも正しいです。
ソフトウェアの機能や特長は、長期的に見たときに優位性にはなりません。これらは時間が経てばコピーされて陳腐化してしまう。
まだ「未来」は訪れてないんだなあ。
あんま関係ないですが、某委員会で挙げられているブラウザの中で見るべきところがあるのはfub, KIKI, Google Chromeくらいなもので、あとは全部ロートルですね。Bagel0.xもDonutのコピーにすぎないですし。今更そんなものを作ってもしょうがない。陳腐な言い回しになるのであまりこんな言い方はしたくないのだけれど、たぶん、OSとしてのWebブラウザを作りたいんだろうな…
データの取り扱い、をいかにうまく設計するか。僕は頭が悪いので、なかなか結論が出ないのでありますよ。
16 11月
どうせだから新しいことに挑戦しよう。
DWTにはDWT-WinとDWT-Linuxという二つの実装が既にあり、さらにDWT-Cocoaの開発も進行中。SWTのLinux版のBrowserウィジェットはGeckoを使っており、これも当然Dに移植されるはずである(今まさに進行中)。
「とりあえずWindowsで」とか言ったけど、やっぱりLinuxでも使いたいんだよね。
Nimbus並みにきれいならネイティブでなくてもいいのだが。
CTabFolderいいよCTabFolder
多分使わないけど。
JFaceいいよJFace
いかにもJava。setTextとか…。DWTよりDFLのほうが好ましいんだが、GTK版の開発が一向に進んでない(現時点で最新のコミットが1年前)のでパス。
あと、StyledTextが日本語を入力すると落ちる。これどうにかならんのか?
4 9月
いやもうこの話題は以前HDDがクラッシュしてBagel2の開発を決意して以来、何度となく書いているし、はてなで3回はやっている気がするが、今一度Bagel2でやりたいと思っていること、そしてその前に考えなければいけない課題を整理してみたいと思う。ここに書くのは初めてだしね。
とりあえずWindows/ReactOS。wxWidgetsがモダンな設計だったら、Linuxに広げても良かったのだけれど、どうにもこうにもwxTNGの進捗具合が思わしくないらしいので断念。Wineで動いたらめっけもの。だれかQt以外でクロスプラットフォームないいツールキットがあったら教えてほしい。OMGUIはよさげだが開発が活発じゃないし、機能も少ない。
レンダリングエンジンに何を採用するか?実用的なブラウザを作るならば、現時点ではGeckoかTridentの二択である。Geckoは言うまでもなく私の愛するレンダリングエンジンであり、2年間格闘した相手なので慣れている。またTridentは組み込みブラウザにおける実績がある。Tridentは生理的に嫌いだし、どうせWeb標準のサポートもビリだろうから、必然的にGeckoをまず選択することになる。「まず」と言ったのは、複数のレンダリングエンジンを切り替える機能に含みを持たせたいからだ。たぶん、それは実装する。
他に有力なレンダリングエンジンにはWebKitがあるが、一般に配布されているWindows版WebKitはCoreGraphics・CFNetworkなどのApple謹製ライブラリがなくては使い物にならない。これらのライブラリは再配布不可能なので、自由な活動ができない。論外である。cairo + cURLをバックエンドに利用したWebKitも作ることはできるが、今はパフォーマンスが極めて悪いし、まだ完全にはAppleのライブラリへの依存が抜けていない。パフォーマンスに目をつぶれば、今すぐに採用したい要素満載なのだが(したがって研究は継続せねばならない)、ここが致命的。
Adobe AIR版WebKitも存在するが、これはまだ調べていない。Google Talk Labs Editionで採用されているので、案外使い物になるのかもしれない。しかし、プログラミングの手間的にはCG/cairo版がいいと思う(COMなんで、C#などからも使える)。
WebKit/Gtk+をWin32でビルドすることもできるようだが、さすがに移植モノでもないのにWindowsでGtkを選択したくはない。また、QtWebKitはGPL縛りがきついので遠慮したい。Qtで開発するならQtWebKitがもっとも筋が良いはずなのだけれど。
Google Chrome版WebKitについてはまだそんなに調べていない。外部からの利用が容易なのかいささか不安。
私はかつてVB厨だった。VBとMozilla ActiveX Controlでブラウザを試しに作ったこともあったが、あまり実用的ではなかった。そんなおり、DelphiでGeckoSDKを書く猛者が現れ、RADでしかプログラミングできない厨房だった私はそれに飛びついた。そういうわけでBagel0.xではDelphiを採用した。今でもDelphiはそれなりに好きだ。だがDelphiを使い続けるのは無理だ。
Geckoの変化に対応しきれるかという問題だ。Mozilla 2ではXPCOMの互換性をぶっ壊すと思われる。Mozilla Wikiで新しい組み込みAPIの項目を見るとC++とJavaScriptのバインディングしか考えられてない。Pythonバインディングとかはやりたい奴が勝手にやれといわんばかりだ。Delphi用GeckoSDKはXPCOMとCOMが似ているから(interface型を流用できる)楽に実装できているので、ここがぶっ壊されると非常に厳しい。
ではどうするか。C++しか無いだろう。公式にはC++のAPIしか用意されないと思われる。ブラウザとSDKの保守の両方をやらされるのはたまったもんじゃない。
XULとJavaScriptで作ってもいいがまるっきりFirefoxなのでつまらない。
もっとも、GeckoSDK for Delphi、MozSwingやGeckoFXがMozilla 2でも動作する(あるいは保守している人たちがものすごくやる気があって、Moz2の変更に追従する気がある)んだったらこれほどうれしいことはない。私は本当ならDelphi, Java, C#で開発したい。特にJavaで。次期JDKにはWebKitがJWebPaneとして載るからだ。また、JavaXPCOMはIBM謹製なので、IBMの方針しだいでMoz2の変化に追随してくれる可能性がある。
一番迷っているのがここ。JavaならSwingなんだが。当初はWTLを使う気でいた。しかし最近のMSはWTLを放り出したい感じがするので、はたして使い続けてよいものなのか…。MFCは今更使いたくない(でも新しいのはリボンに対応してたりして、いったいMSはMFCをどういう扱いにしたいのかさっぱり分からん)。Gtkは見た目が×。QtはライセンスのGPL縛りが×。C#が使えるならWindowsForms・WPFも有力だが、GeckoFXがMoz2に追随する保証は無い。
SmartWin++なんてのも見つけたが日本語での情報が無い。どうしたものか。あと、Boost.GUIは頓挫したのかな?
そういうわけで何か有用な情報があったら教えて欲しい。やっぱWTLかな…。
その2に続く予定。