Что случилось с Null Layout в Java?

Question

Bonjour.

Проведя бесчисленные часы вокруг этого сайта, ища код для перетаскивания компонента по экрану, я заметил, что в ответах наблюдается странная тенденция.

... что все вздрагивают при звуке нулевой верстки.

Итак, я спрашиваю, в чем проблема, связанная с этим? Я занимаюсь кодированием не более трех месяцев, используя Swing не более одного, а макет - легкий ветерок, который можно использовать с бесконечной настройкой. Почему это плохая практика?

Answer 1

Основная проблема заключается в сложности, связанные в попытке сделать определение об отдельных платформах в отношении таких вещей, как шрифты и как пиксели могут быть оказаны

Даже две системы, под управлением той же ОС может генерировать различные результаты из-за разные аппаратные драйверы и конвейеры рендеринга.

Значительная часть API была абстрагирована таким образом, что вам все равно, что один компьютер использует DPI 120 и использует DirectX, а другой использует DPI 92 и использует OpenGL.

Менеджеры макетов удаляют разработчика из обязанности вычислить размер компонента (и его дочерних компонентов) в определенный момент времени, а также рассчитать взаимосвязь между этими компонентами и сделать это стандартизованным способом.

Ядро Swing API было разработано для использования этого API, поэтому, когда компонент каким-то образом изменится, что будет представлять собой изменение размера, все необходимые контейнеры будут уведомлены автоматически, а вся иерархия компонентов может быть скорректирована как обязательный.

Основная идея диспетчера компоновки - описать связь между компонентами в одном и том же контейнере, а также предоставить информацию о том, сколько может понравиться этот контейнер. Это позволяет вам сосредоточиться на пользовательских возможностях пользовательского интерфейса, а не пытаться потратить время на обновление пользовательского интерфейса, чтобы удовлетворить все возможные комбинации аппаратного и программного обеспечения.

Как бывший разработчик VB (нет, я не горжусь этим), могу вас заверить, самая неприятная часть работы с ним заключалась в разработке полезных динамических пользовательских интерфейсов, которые не выглядели дерьмо на следующий клиент машины.

Из всех аспектов свинга, то управление компоновкой является одним из наиболее приветствуется - ИМХО

Answer 2

Вы потеряете некоторые пункты графического интерфейса для его использования, потому что его трудно поддерживать, больше кода, менее гибкого, ... Добавление дополнительной кнопки приведет к большому перерасчету, который вам нужно сделать.

Как я вижу: http://leepoint.net/notes-java/GUI/layouts/nulllayout.html

Answer 3

Потому что это не макет. Все, что вы делаете, это использование графического редактора для размещения ваших компонентов в абсолютных точках. И изменение размера вашего окна или запуск вашего кода под другим разрешением монитора будет выглядеть ужасно.

Answer 4

ищет код, чтобы перетащить компонент вокруг экрана

Это другое требование. По определению при перетаскивании компонента по экрану вы не можете запрограммировать местоположение.

Сказав, что диспетчер компоновки делает больше, то просто устанавливает местоположение компонента. Отметьте Drag Layout для макета, который вы все еще можете использовать в этой ситуации.

Для других ситуаций диспетчер компоновки (или комбинация вложенных менеджеров компоновки), если это лучшее решение для разработки эффективных графических интерфейсов.