Javaプログラムを「ネイティブに表示」するのが難しいのはなぜですか？

ほとんどのJavaアプリケーションは、C / C ++アプリケーションと同じようには見えません。Swingは、見た目が明確になるように意図的に設計されたかもしれませんが、私が読んだ内容に基づいて、たとえばSWTは「ネイティブに見える」ことを試みましたが、完全に成功しません。

私の質問は：

Java言語の開発者がネイティブGUIの外観を正確にコピーするGUIシステムを設計するのが難しいのはなぜですか？ネイティブGUIの違いは何ですか？「ネイティブ」ボタンのように見えるボタンを設計するだけの問題ではありませんか？それともそれよりも深くなりますか？

「ネイティブ」ボタンのように見えるボタンを設計するだけの問題ではありませんか？

まあ-ちょっと、ボタン用。しかし、これは想像以上に難しいかもしれません。最近では、GUIコンポーネントを表すために使用されるグラフィックは、ストレッチされたランダムなビットマップほど単純ではありません（これらはまったくうまくスケーリングされないため）-多くの場合、多くのコーナーケースがプログラムされたベクターベースのグラフィックです（そのため、ボタンが画面の端に達すると、たとえばわずかに異なって見える場合があります。）そしてもちろん、ボタンをクリックしたときに異なるグラフィックが必要になります。著作権上の理由で、開発者はこれらの既存のグラフィックスをそのまま使用することはできないことが多いので、再作成する必要があります-そして、ほとんどの部分で良い仕事をしている間、必然的にそこにある膨大なグラフィックコンポーネントを考えると見逃されることがあります。

もちろん、上記のすべてはSwingに基づいていますが、これはもちろん軽量で非ネイティブのGUIツールキットです。SWTはネイティブではないので、具体的にはSWTがネイティブに見えないと言いますが、これは少し奇妙です。これは、下にあるJNIを使​​用してネイティブコンポーネントを呼び出すツールキットです。そのため、何かが正しく表示されない場合は、ルックアンドフィールのせいではありません。

一部のシステムでは「ネイティブ」と見なすことができるツールキットが文字通り半ダースあります。これらのいくつかはかなりユニークな概念または機能を備えており、クロスプラットフォームツールキットでそれらを複製するのは退屈です。アプリケーションのルックアンドフィールは、「スキン」によって決まるだけでなく、レイアウトとその動作によっても決まります。考慮事項：

• ダイアログでは、「OK」ボタンはどちら側に属しますか（左側または右側）。さて、システムごとに個別のダイアログを作成しましょう。
• 画面上のデフォルトのボタンをどのようにマークしますか？ボタンを拡大する色合い、太字フォント？結構です、それをスタイルシートに入れましょう。
• Windowsでは、「リボン」の概念はかなりネイティブです。これは、リボンが一般的ではないMacにどのように変換されますか？結構、ピクセルの正確なレイアウトを忘れて、システムごとに異なるツールバー実装を提供しましょう。
• メニューバーはウィンドウの一部ですか（Windows、オプションでKDE）、または画面の上部にありますか（Mac、Unity）？十分正確に、ピクセルごとの正確なレイアウトは既に捨てているため、システムごとに異なる実装を作成しましょう。
• フォントはどのようにレンダリングされますか？可能な限り鮮明、または滑らかでアンチエイリアス処理されていますか？そして、どのフォントを使用する必要がありますか？フォントごとにメトリックが異なるため、同じ幅にレンダリングされた同じ段落には、フォントに応じて行数が異なる場合があることに注意してください。
• ウィンドウの背景は単色、画像、またはグラデーションですか？それもスタイルシートに入れましょう。
• スクロールバーはどのように見えますか？ボタンはどこにありますか（ある場合）。それらはどのくらいの幅ですか、またはポインターが特定の領域に移動したときにのみ表示されますか？
• 他の配色をどのように組み込むのですか？
• ドラッグ可能なものは何ですか？コンテキストメニューはどこにありますか？

これらの問題は、アプリケーションの動作や一般的なレイアウトに触れる場合、単純なスタイルシートでは解決できません。唯一の実際のソリューションは、各システムのアプリケーションを書き直すことです（したがって、Javaのクロスプラットフォームの利点を無視します）。唯一の現実的な解決策は、ピクセルの正確なレイアウトを忘れ、システム固有のツールキットを抽象化する共通のインターフェースに書き込むことです。Swingがとる解決策は、さまざまなシステムをエミュレートすることです。

そして、クロスプラットフォームの一貫性があります。これは、アプリがすべてのシステムでまったく同じに見えるという考え方です（多くの場合、ゲームで選択され、没入感が増します）。デスクトップアプリケーションでは、これは単に迷惑であり、ユーザーの期待を覆します。

はい、より深くなります。

このボタンのみを作成する場合、WindowsまたはOS Xボタンのように見えるボタンを作成するのは簡単です。しかし、ボタンは元のボタンと同じように「振る舞う」必要があり、簡単ではないかもしれません。あるバージョンではより多くのスペースがあり、別のバージョンではない場合があります。

これは、GUI全体を使用している場合は大げさです。OSXプログラムは、Windowsプログラムとは異なるコンテンツを表示します。これは1つのGUIでキャプチャすることはほとんど不可能です。2つのGUIが必要になりますが、それほど多くのアプリケーションはそれほど騒ぎません。代わりに、彼らは「ほとんどのシステムで大丈夫に見える」ことを目指しています-これはまだいくらか異質に見えますが、使いやすく、開発がずっと簡単です。

OSXボタン、Windowsボタン、または他のツールキットのボタンのように見えるボタンを作成するのは難しくありません。ただし、ほとんどの環境のUIガイドラインは、「これがボタンの外観です」という基本ほど単純ではありません。UI要素間の間隔から、特定の既知のアクションがリストに表示される順序、メニューシステムの[設定/オプション]ダイアログの正確な位置まで、多くの微妙な違いがあります。非常にシンプルなユーザーインターフェイスの最も一般的なケースを自動化できますが、ほとんどのUIタスクではないにしても、多くの場合、より細かいタッチが必要です。

SWTはこれをある程度自動化しようとしましたが、単純なUIタスクに適しています。しかし、万能ソリューションはありません。そのため、UIがより複雑になると、使用する基本的な方法が崩れ始めます。一般に、骨の折れる手作業によるUI作業に戻すことは可能ですが、これはほとんどのプログラマーがすべてのプラットフォームで実行できる、または実行しようとするものではありません。

これに対するSwingのアプローチは、可能な限りネイティブツールキットを避けることでした。それはネイティブではなく、そうしようとはしていません。代わりに、どこで実行されても（ほとんど）同じように見えるものを作成しようとします。みんなを喜ばせる（無駄に）のではなく、自分自身を喜ばせようとしましたが、それが成功するまでは成功しましたが、その結果がユーザーコミュニティ全体にどれほど効果的であるかを疑問視できます。

アプリケーションがすべてのシステムでできる限り自然に見えることと、アプリケーションが各システムで同じように動作することを期待することとの間にはトレードオフがあります。「正しい」選択はありません。

さらに、「自然な」側面を選択した場合でも、グラフィックツールキットのユーザーを、アプリケーションの予期せぬ破損を引き起こす可能性のあるネイティブコンポーネントおよびAPIの「改善」から保護することができます。

これが、一部のGUIツールキット開発者が、ネイティブコンポーネントを模倣する独自のコンポーネントを提供することを好みますが、独自の実装を提供するためです。一方、機能的に完全なGUIツールキットを開発することは多大な労力であり、経済的な考慮事項がいくつかの端を切ることにつながる可能性があります。

この問題はJava固有のものではありませんが、プラットフォームに依存しないツールキットを作成するすべての企業が直面していることに注意してください。

それはすべて歴史によるものです。

Sunは、すべてのJavaソフトウェアがすべてのマシンで同じように動作することを望んでいました。

ソフトウェアが「ネイティブに表示される」ためには、特定のOS上で他のソフトウェアと同じように動作する必要があります。

Sunは、OSとの統合によりソフトウェアが各OSで異なる動作をするため、OSと統合されたJavaソフトウェアの作成を困難にするために、あらゆる力を尽くしました。

最近では、Webサーバーベースのソフトウェア以外を気にするJavaプログラマーはほとんどいません。

Sunは、Microsoft Javaベースのシステムを使用したすべてのプログラマーを駆り立てて、デスクトップ上のJavaを殺しました。そのため、初期にJavaを選択したプログラマーは見苦しくなりました。

「ネイティブに見える」ことを重視するデスクトップソフトウェアを作成する人は、Javaを使用しないことをずっと前に学んでおり、Oracleソフトウェアを使用するたびにビューが強化されています。

そのため、最近では、Javaプログラマーからデスクトップソフトウェアに「ネイティブに表示」する必要はありません。

nativeSWTなどのツールキットは、そのOSのUIに対して公開されている標準に従っているのに対し、実際には独自の処理を行うネイティブアプリです。問題は、これらの標準に準拠したアプリを誰も作成しないため、Javaアプリを起動するときです。ネイティブではないようです。例として、Microsoftのプロジェクト（Office、Outlookなど）のほとんどすべては、Windows標準コントロールを使用して視覚的に再現することはできません。

MicrosoftとAppleの両方がOSプラットフォームに動的UI機能を追加すると、さらに悪化します。WebデザインがWebサイトのスタイルを作成するのとほぼ同じ方法で、開発者がアプリのスキン/スタイルを設定できるようにします。

Androidプラットフォーム上のJavaは、このパスをたどっています。スキナブルスタイルを使用してXMLで定義されたAndroidのUI要素を作成します。

Javaは、デスクトッププラットフォームとして非常に人気があったことはありません。その結果、これらの業界の変化はデスクトップランタイムにまで伝播していません。問題を修正するために時間を費やすことをいとわない開発者が不足しています。

どのオペレーティングシステムを「ネイティブ」に見せたいですか？

あなたはそれらのすべてに100％の時間をネイティブにすることはできません。

SWTなどは、何らかの妥協が必要な場合に、それらすべてにネイティブに見えるようにするためのベストエフォートアプローチです。

そして実際、この妥協点はますます到達しにくくなっています。オペレーティングシステムのせいではなく、入力デバイスのせいです。タッチスクリーンの場合、実際にはマウスの右ボタンがないため、デザインを変える必要があります。したがって、それ以外の場合は同じ機能に対応する必要があります。

そこなし、guesturesに、マウスの右ボタンから「直感的」な機能を動かす魔法のボタンになることはありませんあなたは（その時点で、あなたはあなたが考えられているすべてのプラットフォームに固有のすべての単一の入力デバイスごとに詳細な態様をspecifiyingが、それにもかかわらず、非-あなたが考慮していないものにネイティブ）。

本当に良い質問です。過去数年間、私はいつも自分でそれについて疑問に思っていました。この背後には正当な理由があると思っていましたが、実際はそうではありません。

答えはかなり単純で、多くの答えが実際に問題を掘り下げているわけではないと思います。

あなたの言語が画面上にピクセルを描画することを許可している場合、それに基づいてWindowsフォームコントロールのルックアンドフィールを正確に模倣するGUIフレームワークを100％作成することができます。

Javaはクロスプラットフォームであるため、実際の実行システムタイプ（Mac / Windows）に基づいて、UIが両方のプラットフォームで異なるように選択され、ランタイムプラットフォームスタイルに一致することを確認できます。

たとえば、XAMLでわかるように、UIは非常に構造化された形式と言語で簡単に表示できます。時間がかかる場合は、「ネイティブ」動作を選択することもできます。

したがって、Java開発者がMacおよびWindowsでネイティブに見えるアプリケーションを取得できるようにするGUIフレームワークを作成することが可能です。

そこで、Swingに行きます。これは、Java用に作成できるGUIフレームワークの無限の可能性のうち、たった1つのGUIフレームワークです。それはプログラムされた方法で動作しますが、上記のプロセスに従わず、両方のシステムで奇妙に見えるアプリを取得します。これがSwing開発者の選択であり、誰も彼らにこれを強制し、そのように振る舞わせたわけではありません。