"YUKATA"から始まるコミュニケーション（Agile2008 ライトニングトークより）
私は「浴衣」を着てパーティーに参加したことで、たくさん声を掛けていただけました。 そこで感じたことは、このカンファレンスが人との繋がりを生み出し、また言葉の壁を越えて積極的に交流する場所であることです。民族衣装はそれらを助けてくれるものでした。きっとこの交流が、新たなムーブメントをアジア圏の仲間たちにも与えてくれると確信しています。
News
MonoおよびGtk#でGtk+スレッドミルを乗り切る
作者 Jonathan Allen, 翻訳者 編集部 投稿日 2008年7月22日 午前6時18分
提案されているGtk+ 3.0の変更は、相当な物議を醸した。多くの人が、「コードの品質」問題でおこなわれており、直接新機能には結びつかない大量の変更について不平をまくし たてている。最も激しく批判をする人びとは、またGtk+の最も重要な対象者であり、フレームワークに依存しているアプリケーションデベロッパである。
Havoc Pennington氏(リンク)は、そうした変更の利便性を疑っている。
「コードのクリーンアップ」や「非推奨のものの除去」がひとりでに終了するという主張に他の人同様、わたしも疑問に思っています。コードのクリーンアップ が重要なときもあります。というのは、コードがまだアクティブに使用されていて、それを正しくするのが不可能であったり、それ以上理解することができない からです。しかし、非推奨GTK+ウィジェットはそうではありません。ただそこに触れられずに置かれており、最悪のケースでは表面上の問題です。それらを 使用していない人には、大きな影響はないです。
一方、Morten Welinder氏(リンク)は既存のアプリケーションを可視の状態に維持することを危惧している。
大規模なアプリケーションの生産には、さまざまな作業を要すので、(うまくいけば)よく設計されたコードを記述したときは、記述されたままにしておきたい です。来週のGTK+の 廃止予定が実施されないといいと思います。事実上わたしのコードがbitrotになってしまいます。(1つのジョブに2種類のコード(「古い」GTK+) と「新たな」GTK+)を記述することはしたくありません)。
バージョン3以降が、こうした心配の対象である。Kristian Rietveldは、3、4年ごとに変更を導入する意向を示した(PDF)。
しかし、痛みを伴ってこそ、チャンスは訪れる。プロジェクトが完了するとすぐに、Gtk+ APIは変化する一方、Gtk# APIはそうした意図はない。Jeffrey Stedfast氏(リンク)が指摘しているように、Monoデベロッパはここから孤立しており、Gtk# 2アプリケーションは変更なくGtk# 3で実行すべきである。
原文はこちらです：http://www.infoq.com/news/2008/07/Gtk-Compatibility
No comments
返信