Javaプログラムを「ネイティブに見える」ようにすることはなぜ難しいのですか？
ほとんどのJavaアプリケーションは、C/C++アプリケーションと同じように見えません。Swingは、見た目が異なるように意図的に設計されている可能性がありますが、私が読んだ内容に基づいて、たとえばSWTが試しました「ネイティブに見える」ために、完全に成功しません。
私の質問は：
Java言語の開発者が正確にのようにネイティブGUIの外観をコピーするGUIシステムを設計することが難しいのはなぜですか？ネイティブGUIの違いは何ですか？それは「ネイティブ」ボタンのように見えるボタンを設計することだけの問題ですか？それともそれより深くなりますか？
「ネイティブ」ボタンのように見えるボタンをデザインするだけの問題ではないですか？
まあ-ボタンのようなものです。しかし、これは想像以上に難しいかもしれません。最近、GUIコンポーネントを表すために使用されるグラフィックは、引き伸ばされたランダムなビットマップほど単純ではありません（これらは非常に適切にスケーリングされないため）-多くの場合、多くのコーナーケースがプログラムされたベクトルベースのグラフィックです（そのため、ボタンが画面の端に到達すると、たとえば少し異なるように見える場合があります。）もちろん、ボタンをクリックしたときに異なるグラフィックが必要になります。著作権の理由から、開発者はこれらの既存のグラフィックをそのまま使用できないことが多いため、再作成する必要があります。大部分のグラフィックコンポーネントは正常に機能しますが、膨大な数のグラフィックコンポーネントがあるため、必然的に見逃されるものもあります。これは以前ほど深刻ではありません。最近、Swingでデフォルトのプラットフォームのルックアンドフィールを設定した場合、奇妙に見えるのはごくわずかです。
上記はすべて、Swingに基づいていると言っています。Swingはもちろん、軽量の非ネイティブGUIツールキットです。 SWT （nativeです）の下でJNIを使用してネイティブコンポーネントを呼び出すツールキットであるため、SWTがネイティブに見えないことを具体的に言及している-したがって、何かが正しく表示されない場合は、ルックアンドフィールが原因です。
一部のシステムでは「ネイティブ」と見なすことができるツールキットが文字通り6ダースあります。これらのいくつかにはかなりユニークな概念や機能があり、クロスプラットフォームツールキットでそれらを複製するのは面倒です。アプリケーションのルックアンドフィールは、「スキン」によって決まるだけでなく、レイアウトとその動作によっても決まります。いくつかの考慮事項：
- ダイアログで、[OK]ボタンはどちらの側にありますか（左側または右側）。公正に、システムごとに個別のダイアログを作成しましょう。
- 画面上のデフォルトボタンをどのようにマークしますか？色の濃淡、太字のフォント、ボタンの拡大？十分に公平です。スタイルシートに入れましょう。
- Windowsでは、「リボン」の概念はかなりネイティブです。これは、リボンが一般的でないMacにどのように変換されますか？十分に公平です。ピクセル単位のレイアウトを忘れて、システムごとに異なるツールバーの実装を提供しましょう。
- メニューバーはウィンドウの一部ですか（Windows、オプションでKDE）、それとも画面の上部にありますか（Mac、Unity）？十分に公平です。ピクセル単位のレイアウトをすでに破棄しているため、システムごとに異なる実装を作成しましょう
- フォントはどのようにレンダリングされますか？可能な限り鮮明ですか、それともスムーズでアンチエイリアス処理されていますか？そして、どのフォントを使用すべきですか？フォントが異なればメトリックも異なるため、同じ幅にレンダリングされた同じ段落は、フォントによっては行数が異なる場合があることに注意してください。
- ウィンドウの背景は単一の色、画像、またはグラデーションですか？それをスタイルシートにも入れましょう。
- スクロールバーはどのように見えますか？ボタンはどこにありますか？それらの幅はどれくらいですか、またはポインタが特定の領域に移動したときにのみ表示されますか？
- 他の配色をどのように組み込むのですか？
- ドラッグできるものは何ですか？コンテキストメニューはどこにありますか？
これらの問題は、アプリケーションの動作や一般的なレイアウトに触れたときの単純なスタイルシートでは解決できません。実際の唯一の解決策は、各システムのアプリケーションを書き直すことです（したがって、Javaのクロスプラットフォームの利点は無視されます）。唯一の現実的な解決策は、ピクセル単位の正確なレイアウトを忘れ、システム固有のツールキットを抽象化する共通のインターフェースに書き込むことです。 Swingがとった解決策は、さまざまなシステムをエミュレートすることです。
そして、クロスプラットフォームの一貫性があり、アプリはすべてのシステムでまったく同じに見えるという考えがあります（多くの場合、ゲームによって選択され、これにより没入感が向上します）。デスクトップアプリケーションでは、これは単に迷惑であり、ユーザーの期待に反します。
はい、さらに深くなります。
このボタンのみを作成する場合、WindowsまたはOS Xボタンのように見えるボタンを作成するのは簡単です。ただし、ボタンは元のボタンと同じように「動作」する必要があります。これは簡単ではない可能性があります。おそらく、1つのバージョンではより多くのスペースが利用可能ですが、他のバージョンでは利用できません。おそらく、Windowsバージョンでのデザインの色のほうが適しています。
これは、GUI全体を使用している場合はさらに厳しくなります。OSXプログラムは、Windowsプログラムとは内容が異なります。これを1つのGUIでキャプチャするのはほとんど不可能です。2つのGUIが必要になりますが、多くのアプリケーションがそれほど面倒ではありません。代わりに、「ほとんどのシステムで問題ないように見える」ことを目指しています。これはまだ多少異質に見えますが、使いやすく、開発がはるかに簡単です。
OSXボタン、Windowsボタン、またはその他のツールキットのようなボタンを作成することは難しくありません。ただし、ほとんどの環境のUIガイドラインは、「これはボタンの外観」の基本事項ほど単純ではありません。 UI要素の間隔から、特定の既知のアクションがリストに表示される順序、メニューシステムの[設定]/[オプション]ダイアログの正確な位置まで、微妙な違いがたくさんあります。非常にシンプルなユーザーインターフェースの最も一般的なケースを自動化できますが、ほとんどではないにしても多くのUIタスクは、はるかに細かいタッチが必要です。
SWTはこれをある程度自動化しようとしましたが、これもまた、単純なUIタスクに適しています。しかし、万能のソリューションはありません。そのため、UIがより複雑になると、UIが使用する基本的な方法が崩れ始めます。一般に、手間のかかるUI作業に合わせることができますが、これは、ほとんどのプログラマーがすべてのプラットフォームで実行できる、または実行しようとするものではありません。
Swingのこれに対するアプローチは、可能な限りネイティブツールキットを避けることでした。それはネイティブではなく、そうしようとはしません。代わりに、どこで実行されても（ほとんど）同じに見えるものを作成しようとします。すべての人を喜ばせるために（無駄に）試みるのではなく、それ自体を喜ばせるように試みました。
アプリケーションがすべてのシステムで可能な限り自然に見えることを期待することと、アプリケーションが各システムで同じように動作することを期待することの間にはトレードオフがあります。 「正しい」選択はありません。
さらに、「自然に見える」側を選択したとしても、アプリケーションを予期せず破壊する可能性のある、基盤となるネイティブコンポーネントとAPIの「改善」からグラフィックツールキットのユーザーを保護したい場合があります。
これが、一部のGUIツールキット開発者がネイティブコンポーネントを模倣する独自のコンポーネントを提供することを好むが、独自の実装を提供する理由です。一方、機能的に完全なGUIツールキットを開発することは大きな努力であり、経済的な考慮事項により、いくつかの最先端を切り取ることになるかもしれません。
この問題はJava=固有のものではありませんが、プラットフォームに依存しないツールキットを製造するすべての企業が直面しています。
nativeは、SWTなどのツールキットがそのOSのUIの公開された標準に準拠しているのに対して、実際にネイティブアプリが独自に機能していると思います。問題は、これらの標準に従ってアプリをビルドする人がいないため、Javaアプリを起動したときです。これはネイティブではないようです。例として、ほとんどすべてのMicrosoftのプロジェクト（Office、Outlook、など）Windows標準のコントロールを使用して視覚的に再現することはできません。
MicrosoftとAppleが動的なUI機能をOSプラットフォームに追加するため、開発者は、WebデザインがWebサイトのスタイルを作成するのと同じように、アプリのスキン/スタイルを設定できるようになるため、さらに悪化します。
Androidプラットフォーム上のJavaはこのパスをたどっています。AndroidのUI要素をスキン可能なスタイルのXMLで定義しています。
Javaはデスクトッププラットフォームとして非常に人気がありませんでした。その結果、業界におけるこれらの変化は、デスクトップランタイムにまで伝わっていません。問題を修正するために時間を費やす気がある開発者が十分ではありません。