15

Java や Qt を C++ で使用する場合と、gui-designer ツールを使用する場合のように、GUI を手作業でコーディングすることについて、いくつかの意見を聞きたいですか? GUI デザイナー ツールの例としては、MFC GUI デザイナー、Qt デザイナー、Interface Builder (Apple) などがあります。

以前はハンド コーディングのファンでしたが、最近の経験から切り替えました。私がハンド コーディングで見た問題は、GUI を作成するのはかなり迅速かつ柔軟ですが、かなり前に作成された GUI に変更を加える必要があると、非常に困難になる可能性があることです。大きなパネルで適切な要素を見つけるのは難しい場合があります。

2 つ目の問題は、GUI の作成とレイアウトのコードに多くのロジックを簡単に追加できることです。私は頻繁に GUI コードのメンテナンスを引き継がなければなりませんでしたが、これは再利用が非常に困難でした。なぜなら、その動作は外観と混ざり合っており、レイアウトと動作が混ざり合ってクラスが非常に大きくなり、理解が困難になることがよくあるからです。

GUI デザイナー ツールを使用すると、ビュー内の外観とロジックをより明確に分離できます。

4

11 に答える 11

16

標準 (またはデファクトスタンダード) の GUI マークアップ言語がない場合は、常に GUI 設計を手作業でコーディングします( の場合と同様)。その理由は、GUI ビルダー設計ツールを使用すると、特定の IDE の使用に縛られることがわかったからです。時間の経過とともに、GUI の設計やコードの記述に最適な IDE は変化し、各開発者は、最も快適に感じる IDE を自由に選択する必要があります。Java

現在私が働いている場所には、Netbeans Matisse GUI ビルダーを使用して作成された多くのレガシー GUI があります (当時の私のアドバイスに反して :-)。すべての開発者がIntelliJ IDEAまたはEclipseのいずれかを IDE として好むため、これらは現在ほとんど保守できません。開発者が GUI レイアウトを変更するためだけに Netbeans を起動するのは現実的でも実行可能でもありません (人々は Netbeans プロジェクトの定義を同期させません)。

もう 1 つのポイントは、GUI レイアウト コードを作成する合計時間は、特定のプロジェクトの開発作業全体の 5% に過ぎないということです。自分でコードを書くのに 2 倍の時間がかかったとしても、大局的に見ればオーバーヘッドはそれほど大きくありません。また、長期的な保守性を確保するために支払う代償もわずかです。

GUI レイアウト ロジックをビジネス ロジックから分離することについて明確に理解している限り、その結果として問題が生じることはないと思います。ここではもう誰も GUI ビルダーを使用していません!

于 2009-03-08T15:18:13.243 に答える
7

私は手作業で行います。物事をシャッフルして、アプリケーション内でパネルを再利用する方がはるかに簡単です (一部のパネルは複数の場所に表示される場合があります)。

デザイナーの使用は、アーティストが GUI を行うことになっているチームにいる場合に機能します。

大きなパネルで適切な要素を見つけるのは難しい場合があります。

?? 私はそれを見たことがない。

于 2009-03-08T15:26:28.980 に答える
4

面白いことに、私にとっては逆になっています。Winforms の観点から言えば、デザイナーによって生成されたコードは非常にノイズが多く、おそらくすべてのプロパティ設定の 4 分の 1 または 2 分の 1 が実際に必要です。デザイナーと一緒に作業する場合、かなり大きなコントロールを作成することも魅力的です。Winforms デザイナーでコントロールの階層を変更することは、私の目には悪夢のようなものです。

私の最後のプロジェクトでは、フォーム、ドックマネージャー、メニュー、ツールバーなどにスプリッターを宣言的に設定するための追加の API を作成しました。これらは、関心の分離をさらに強化するようなものです。

また、WPF の方がはるかに優れていることは確かですが、Windows フォームでもある程度機能する自動レイアウト機能にもっと依存しようとしています。

于 2009-03-08T15:05:35.910 に答える
4

GUI を手作業でコーディングするのではなく、インターフェイス ビルダーを使用する必要があると強く感じています。質問で述べたように、それははるかに明確な分離であり、何かを編集する必要があると、はるかに簡単になります。

Qt Designer には、.uiファイルからクラスを作成するためのこの機能があります1)が、この機能を使用しないことが最善の方法だと思います。ファイルからウィンドウを作成する速度の問題は、ウィンドウを.ui一度だけロードする必要があるため、無視できます。

これは PyQt ですが、C++ でも同様のことが可能です。

class SelectDateDialog(QDialog):
    def __init__(self):
        QDialog.__init__(self)
        uic.loadUi("resources/SelectDate.ui", self)

基本的に、これはすべての UI コードをメソッドに含めるのと同じ効果があります__init__()が、UI はコードからほぼ完全に分離されています。

1).uiファイルは、ユーザー インターフェイスを記述する XML ファイルです。

于 2009-03-08T16:11:24.160 に答える
3

多くの入力フォームと表形式のデータを含むビジネス アプリケーションを設計している場合、UI デザイナーを使用するよりも、UI のコードを作成する方が高速であり、保守も容易です。この種のアプリケーションでは、1 つの要素を画面上の事前定義された場所に正確に配置する必要はほとんどありませんが、一方で、単純に個別のメソッドに抽出できる繰り返しや設計規則が多数あります。

たとえば、Eclipse または OpenOffice の設定ダイアログを考えてみましょう。たくさんのカテゴリと、それぞれに設定するさまざまなオプションがあります。そのサイズのものを作成する必要がある場合、各画面を手作業で設計することは平凡な作業です。はるかに優れたアプローチは、提供されたドメイン データから、いくつかの規則とデフォルトに従って、オンザフライで UI 要素を生成するコードを記述することです。

デザイナーを使用することで分離が容易になることも、ビジネス ロジックを UI から除外していることを考えると、その認識された分離がどのように役立つかはわかりません。

最後に、Java を使用している場合は、必ずMigLayoutを確認してください。Swing と SWT で動作し、その構文は非常に簡潔で明確であり、信じられないほど便利なデバッグ モードがあります。

于 2009-03-08T17:28:07.767 に答える
3

OS X で Interface Builder を使用することを強くお勧めします。学習したい場合は、手動で行うこともできますが、実際のプロジェクトで使用することで、多くの頭痛の種から解放されます。それは本当にかなり強力です。

Java と C++ に関しては、何を行っているか、どのプラットフォームに依存するかによって異なります。単純なアプリケーションの場合、UI コードをまったく見なくても問題ありません。ただし、複雑なアプリケーションやリッチ クライアントの場合は、通常、一部のコードを手動で実行する必要があります。

于 2009-03-08T15:07:44.517 に答える
2

状況次第ですよ、本当に。どちらにもそれぞれの役割があると思います。私は通常、ハイブリッド アプローチを使用します。

GUI ビルダーが実行できないことが常にいくつかあります (たとえば、Interface Builder で色を UIColor 定数に設定するなど)。一方、ほとんどの UI 作業は非常にありふれたものです (たとえば、静的ラベルの追加など)。

私は平凡なことを GUI ビルダーで行い、より興味深いことをコードで行うことを好みます。

また、GUI ビルダー (私の場合は Interface Builder とグレード) によって生成された XML を手作業で編集していることに気がつくこともあります。

于 2009-03-08T15:03:37.600 に答える
1

正しい答えは、ターゲット プラットフォームの文化に依存すると考えがちです。OS X では、Interface Builder はツール チェーンの不可欠な部分であるため、避けるのは困難です。

Java (awt または swing) では、逆のことが実際に当てはまります。これに対するツールチェーンのサポートはありません。

実際には、ツールが出力を生成する方法を知ることができます。Interface Builder は、Cocoa が画面にコントロールを配置する方法に固有の .nib 形式のファイルを生成します。本質的にインターフェイス マークアップ形式とは何かを理解します。Java にはそのような類似の概念はありません。すべてがコンパイルされたクラスであるため、便利な結果を得るのははるかに困難です。

GTK+ は、glade と組み合わせると、両者のバランスが取れているように見えます。

于 2009-03-08T15:49:29.250 に答える
1

2 つのアプローチを混在させることを妨げるものは何もありません。私はよく、GUI デザイナーでフォームのメイン レイアウトを作成し (すばやく、何をしているかを確認できるため)、そこに 1 つまたは複数のパネルを配置して、コードを入力します。これは、GUI を特定の状況に適応させる必要がある場合に特に便利です。たとえば、接続されているハードウェアに応じて GUI を変更する必要がある場合などです。

いずれにせよ、最も重要なことは、GUI とアプリケーション ロジックを分離しておくことです。

于 2009-03-08T15:50:36.130 に答える
0

UI に非標準の機能を含めたい場合は、ハンド コーディングが適しています。柔軟性は向上しますが、Java/C++ は UI 設計を対象とする言語ではないため、優れたインターフェイスを作成するためにより多くの時間を費やす必要があります。

加えて、リビジョン管理があれば、バイナリ形式や RCS フレンドリーではない xml 形式を使用する設計ではできない変更の履歴を見ることができます。

現在、UI を視覚的にデザインするために利用できるツールのほとんどには、いくつかの機能が欠けています。それらは十分に柔軟ではなく、一部の機能はそれらをコーディングすることによってのみ達成できます。また、場合によっては、生成されたコードが実際には人間に優しくなく、手動で変更すると、デザイナーを使い続けることができなくなる可能性があります。

しかし、デザインがシンプルであれば、デザインは本当に時間の節約になる可能性があり、デザイナーが将来改善されることを期待できますが、私は広範にとどまりません.

私の結論は、今日柔軟性が必要な場合は、インターフェイスを手作業でコーディングする必要があります。シンプルで高速なものが必要な場合は、デザイナーが最適な選択です。

おそらく将来、デザイナーはより強力になるか、XUL や XAML のような C++/Java での使用により適した UI デザインに特化した新しい言語が登場するでしょう。

于 2009-03-08T17:24:49.430 に答える
0

これに関する私の見解: 1. 手作業でコーディングされた GUI コードは、はるかに再利用可能です。 2. レイアウトの問題は、デザイナーにとってより単純です。

于 2009-03-08T15:07:32.580 に答える