3

約 6 か月前に GTKMM アプリケーションを開始しましたが、すべてが機能するようになり、実際に毎日使用しています。これは基本的に、別のアプリケーションからデータ ファイルを読み込み、グラフを生成し、データを簡単に並べ替えて表示できるようにするデータベース アプリケーションです。それはいいですね。

しかし、私のコードはごちゃごちゃしていて、今日別の機能を実装しようとしたときに、おそらくどこかで間違った方向に進んでいることに気付きました。

私のメイン ウィンドウ GUI はグレード ファイルで定義され、すべての GUI (Gtk::DrawingArea に基づくカスタム ウィジェットであるプロット ウィジェットを除く) は単一のファイルにあります。ウィジェットとツリーストアへのポインタがいっぱいで、すべてコンストラクタで設定され、デストラクタで削除されます。

GUI 全体が複数のペインに分割されたメイン ウィンドウであるため、すべてを 1 つのファイルにまとめることは理にかなっています。また、異なるペインは他のペインと「通信」する必要があります。

保守しやすいようにコードを整理するにはどうすればよいですか? 基本的にウィジェットのコレクションである新しいクラスを作成し、その「スーパー ウィジェット」をメイン ウィンドウに配置しますか (各ペインはスーパー ウィジェットとします)。

GTKMM のチュートリアルは一般的に非常に最小限に抑えられているため、そこから多くの洞察を得ることができませんでした。

4

2 に答える 2

3

私が最終的に行った解決策は、ウィジェットの各論理コレクションを独自のクラスに分離することでした。次に、マスター GUI クラスでキャッチされ、そこで処理されるシグナルを作成します。受け渡さなければならないことはすべて、マスター GUI クラス コードで行われますが、今では理にかなっています。たとえば、フィルター フレームで変更された特定のコンボボックスの値は気にしません。代わりに、フィルターが変更された時期に興味があります。したがって、フィルター クラス (すべてのフィルター ウィジェットを含む) はカスタム changed() シグナルをスローし、そのフィルター内の変数のセッターとゲッターを使用して、ウィジェットを適切に更新します。

この方法は非常にクリーンで、シングルトンを回避し、UI を区分化し、全体的に操作しやすくしていると思います。

于 2011-02-02T19:13:38.553 に答える
3

私は現在、大規模な GTKMM アプリケーションに取り組んでいます。コードベース全体で従う一般的なルールは、各フレーム (ウィジェットのコレクションを含む) が独自の cpp ファイル内の独自のクラスであるということです。これらのクラスは、それぞれが getFrame メソッドを公開するシングルトン クラスとしてメイン関数でインスタンス化されます。

// Single instance of this class.
SomeGUIComponent* SomeGUIComponent::m_instance = NULL;

SomeGUIComponent& SomeGUIComponent::getInstance()
{
  if (m_instance == NULL)
  {
    m_instance = new SomeGUIComponent();
  }
  return *m_instance;
}

Gtk::Frame& SomeGUIComponent::getFrame()
{
  return m_myMasterFrame;
}

したがって、これは次のようにしてより大きなアプリケーションに追加できます。

SomeGUIComponent::getInstance().getFrame()
于 2011-02-01T14:46:30.187 に答える