レイアウト マネージャーを使用しない場合 (レイアウト マネージャーを null に設定する場合) と比較して、レイアウト マネージャーとして MiGlayout で絶対配置を使用する場合、最終的なアプリケーション結果は異なるプラットフォームや解像度などで同一になりますか?
MiGlayout ソリューションとレイアウト マネージャーを使用しないソリューションの絶対配置に違いはありますか?
レイアウト マネージャーを使用しない場合 (レイアウト マネージャーを null に設定する場合) と比較して、レイアウト マネージャーとして MiGlayout で絶対配置を使用する場合、最終的なアプリケーション結果は異なるプラットフォームや解像度などで同一になりますか?
MiGlayout ソリューションとレイアウト マネージャーを使用しないソリューションの絶対配置に違いはありますか?
これについて考えます。アプリケーションに単一のフォントを提供したとしても、異なる OS では異なる方法でレンダリングされます。同じ OS でも異なる DPI では異なる方法でレンダリングされることさえあります。
レイアウト マネージャーは、これらの問題に対する保護機能です。確かに、最初に使用し始めたときは邪魔に思えますが、慣れると手放せなくなります (VB でコーディングしてみてください)。それ以外は)
レイアウト マネージャーを使用すると、フロー制御と使いやすさの複雑さに集中できます。設計しているフォントよりも 2pts 大きいフォントや、大きい/小さい画面解像度でどのように表示されるかを心配する必要はありません。
Arial フォントを使用し、コンポーネントのサイズを手動で設定することを主張した以前の開発者の仕事を元に戻すのに 2 年を費やしました。彼はフォームを適切にレイアウトできないと信じていたからです。この変更に関するユーザーからのフィードバックはすべて肯定的であり、現在、アプリケーションに動的なフォント サイズ変更を実装することを検討しています。レイアウトマネージャーなしでそれを試す方法はありません。
MigLayout を使用しない場合よりも、MigLayout を使用する可能性の方が高いと思います - IMHO
MiGlayout ソリューションとレイアウト マネージャーを使用しないソリューションの絶対配置に違いはありますか?
はい、そして最も重要なことは、AbsoluteLayout によって配置された JComponents は Container でサイズ変更できません。ComponentListener を追加し、継続的なサイズ変更のために大量のコードを作成する必要があることです。