Почему в Swing не рекомендуется использовать пустой макет?
Недавно я начал создавать программу для компании, в которой я работаю. Так же, как справочная информация, я все еще студент и начинающий программист, поэтому мое решение, вероятно, не рекомендуется, и я не знал, как сделать это иначе, но это работает, и я не буду судить за это, потому что Это студенческая работа, совершенно не связанная с программированием.
Суть программы в том, что она будет работать на разных компьютерах с разными размерами экрана и разрешением (800x600 и выше). Чтобы убедиться, что он занимает как можно большую часть экрана без потери какой-либо части программы, я установил макет на ноль и жестко запрограммировал все, используя относительные значения.
Программа в стиле киоска, и я сначала получаю значения размера экрана и оттуда иду (например, от макушки головы, левое меню занимает восьмую часть экрана, верхняя полоса 2% и т. Д.), Я также использую метрики шрифта, чтобы убедиться, что компоненты имеют правильный размер и что все отображается правильно.
Мой вопрос: почему так неодобрительно делать макет пустым вместо использования менеджеров макетов? (На некоторых форумах мне говорили, что это ужасный способ работы). Я знаю, как работает менеджер макетов, и знаю, как использовать различные макеты, но для требований этой программы (несколько разных разрешений, пользовательских форм кнопок и мест размещения изменение текста на компонентах при смене языка и т. д.), я не мог видеть себя с помощью менеджеров компоновки, чтобы сделать все это.
Как вы, более опытные программисты, используете менеджеры по расположению в такой ситуации? И что вы делаете, когда хотите, чтобы кнопка была где-то определенной, а другие компоненты - где-то еще, которые не соответствуют ни одному из предопределенных макетов?
4 ответа
Если вы правильно наложите слои на менеджеры раскладки, экран будет перетекать для вас в разные размеры, идея состоит в том, чтобы использовать единый набор менеджеров раскладки на ВСЕХ размерах экрана.
Если вы используете нуль, вам придется делать каждый размер экрана самостоятельно. Не только это, но если приложение может быть оконным, вы должны поддерживать все возможные размеры, до которых они могут прокручиваться.
Это довольно сложно сделать, но менеджеры макетов предназначены именно для этого.
Есть несколько распространенных трюков. BorderLayout - отличный макет для начала. Иногда вы можете использовать его на нескольких уровнях - часто только с 2 или 3 компонентами. Это потому, что это действительно хорошо - дать всем, кроме одной области, минимально необходимую площадь и отдать все остальное ЦЕНТРУ.
FlowLayout может быть полезен, но сложно, если ваши компоненты имеют разные размеры.
Я бы не стал использовать GridBagLayout, если вы не планируете писать код для вашего менеджера компоновки (отличное решение!).
Я также не стал бы использовать GUI-компоновщики, они не знают, каким образом вы хотите переформатировать макет.
В двух словах: потому что вся работа, которую вы объясняете выше, выполняется (или, по крайней мере, должна выполняться) менеджером по расположению.
Чаще всего при использовании нулевого макета это также означает, что все позиции и размеры жестко закодированы в одно значение, поэтому никакой гибкости не предоставляется. Это означает, что изменения в размере окна, языке, размере шрифта, плотности отображения или любых других связанных параметрах не влияют на макет, и вы получаете обычные уродливые эффекты: пустые части окна; крошечные, неизменяемые списки; кнопки с обрезанными ярлыками; ...
Похоже, что работа, которую вы делаете, должна действительно выполняться менеджером макетов. Либо найдите тот, который делает это (мое личное предложение будет MiGLayout, который делает много и прост в использовании), либо напишите свой собственный.
Вы практически используете макет - свой собственный, со всеми вашими сложными расчетами позиций.
Вы можете переместить эту логику в пользовательский класс менеджера компоновки, чтобы успокоить критиков.
Хм, трюк должен заключаться в смешивании LayoutMangers и использовании числа вложенных JPanels, каждый из которых может иметь разный Layout или нет, на самом деле зависит от количества JComponents, что позволяет вам создавать GUI, который выглядит как выложенный с помощью AbsoluteLayout, но с тем же внешним видом / вывод в графический интерфейс для каждого разрешения экрана и соотношения (4:3, 16:9, 16:10)