BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース MonoおよびGtk#でGtk+スレッドミルを乗り切る

MonoおよびGtk#でGtk+スレッドミルを乗り切る

提案されている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

この記事に星をつける

おすすめ度
スタイル

BT