Почему в Swing не рекомендуется использовать пустой макет?

Question

Недавно я начал создавать программу для компании, в которой я работаю. Так же, как справочная информация, я все еще студент и начинающий программист, поэтому мое решение, вероятно, не рекомендуется, и я не знал, как сделать это иначе, но оно работает, и я не буду судить за это, потому что это студенческая работа, совершенно не связанная с программированием.

Суть программы в том, что она будет работать на нескольких компьютерах с разными размерами экрана и разрешением (800x600 и выше). Чтобы убедиться, что он занимает как можно большую часть экрана без потери какой-либо части программы, я установил для макета значение null и жестко закодировал все, используя относительные значения.

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

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

Как вы, более опытные программисты, используете менеджеры по расположению в такой ситуации? И что вы делаете, когда хотите, чтобы кнопка была где-то определенной, а другие компоненты - где-то еще, которые не соответствуют ни одному из предопределенных макетов?

Answer 1

Если вы правильно распределите менеджеры по слоям, экран будет перетекать к разным размерам, идея состоит в том, чтобы использовать один набор менеджеров по расположению на ВСЕХ экранах.

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

Это довольно сложно сделать, но менеджеры макетов предназначены именно для этого.

Есть несколько распространенных трюков.BorderLayout - отличный макет для начала.Иногда вы можете использовать его на нескольких уровнях - часто только с 2 или 3 компонентами.Это потому, что действительно хорошо дать всем, кроме одной области, минимально необходимую площадь и отдать все остальное в ЦЕНТР.

FlowLayout может быть полезным, но сложно, если ваши компоненты имеют разные размеры.

Iне буду пытаться использовать GridBagLayout, если вы не планируете писать код для вашего менеджера компоновки (отличное решение!).

Я бы также не использовал построители графического интерфейса, они не знают, как вы хотите перекрасить макет.

Answer 2

В двух словах: потому что вся работа, которую вы объясняете выше, выполняется (или, по крайней мере, должна выполняться) менеджером по расположению.

Чаще всего при использовании нулевого макета также подразумевается, что все позиции и размеры жестко закодированы в одно значение, поэтому никакой гибкости не дается вообще. Это означает, что изменения размера окна, языка, размера шрифта, плотности отображения или любого другого связанного параметра не влияют на макет, и вы получаете обычные уродливые эффекты: пустые части окна; крошечные, неизменяемые списки; кнопки с обрезанными ярлыками; ...

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

Answer 3

ммм трюк должен заключаться в смешивании LayoutMangers и использовании чисел вложенных JPanels , каждый из которых может иметь разную компоновку или нет, на самом деле зависит от числа JComponents , который позволяет вам создавать графический интерфейс, который выглядит как наложенный, используя AbsoluteLayout , но с тем же внешним видом / выводом в графический интерфейс для каждого разрешения экрана и соотношения (4: 3, 16: 9, 16:10)

Answer 4

Вы практически используете макет - свой собственный, со всеми вашими сложными расчетами позиций.

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