アカウント名:
パスワード:
XPCOMはAPIの古さから、そろそろ捨ててほしいです。逆にXULは、Windowsのピクセル依存UIやHTML/CSSの制限を無視して作られたため、当時のUI言語としてはピカイチでした。HTMLのサブセットという扱いでも良いので、XULを生かす方法は無いのでしょうか…
http://www.ibm.com/developerworks/jp/webservices/library/co-xpcom.html [ibm.com]>XPCOMは、確かにスレッドをサポートしています。ただし、スレッド・セーフなコンポーネントは標準的なものではなく、むしろ例外的です。>ほとんどのコンポーネントは、メイン・アプリケーションと同じスレッド内に共存するように記述されるからです。
古いって捨てる理由になるの？
既にjs-ctypesというものがあるので、XPCOMは要らない気がします。安定したAPIなんて幻想。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
捨てるべきはXPCOMであって、XULではないのに… (スコア:3, 興味深い)
XPCOMはAPIの古さから、そろそろ捨ててほしいです。逆にXULは、Windowsのピクセル依存UIやHTML/CSSの制限を無視して作られたため、当時のUI言語としてはピカイチでした。
HTMLのサブセットという扱いでも良いので、XULを生かす方法は無いのでしょうか…
http://www.ibm.com/developerworks/jp/webservices/library/co-xpcom.html [ibm.com]
>XPCOMは、確かにスレッドをサポートしています。ただし、スレッド・セーフなコンポーネントは標準的なものではなく、むしろ例外的です。
>ほとんどのコンポーネントは、メイン・アプリケーションと同じスレッド内に共存するように記述されるからです。
Re: (スコア:0)
古いって捨てる理由になるの？
Re:捨てるべきはXPCOMであって、XULではないのに… (スコア:0)
既にjs-ctypesというものがあるので、XPCOMは要らない気がします。
安定したAPIなんて幻想。