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

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

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

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

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

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


person Adam Smith    schedule 06.07.2011    source источник


Ответы (4)


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

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

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

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

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

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

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

person Bill K    schedule 06.07.2011
comment
Я подумал, но это конкретное приложение не может быть изменено, так что это не проблема. Что у меня было больше всего проблем, так это то, что 1. Я не нашел способ, чтобы мои кнопки располагались точно там, где я хотел, и 2. (я, вероятно, что-то здесь упустил) Я не мог, чтобы мои кнопки были правильный размер, чтобы полностью отображать весь текст при любом разрешении (longTextOnButton станет longTex ... при меньших разрешениях) - person Adam Smith; 06.07.2011
comment
У вас должна быть возможность установить минимальные размеры для своих компонентов, а точное позиционирование может быть сложным и может потребовать нескольких разных макетов по-разному. Кроме того, очень скоро вы узнаете одну вещь - когда что-то является абсолютно определенным заданным требованием (например, всегда полноэкранным), это, вероятно, изменится. Тем не менее, создавайте так, как вы чувствуете себя наиболее комфортно, и продолжайте оценивать различные подходы, извлекая уроки из своих ошибок и успехов, потому что именно так вы накапливаете полезные знания на протяжении всей своей карьеры, школа - это только начало. - person Bill K; 06.07.2011
comment
Да, я это понимаю. Я почти уверен, что в этом конкретном проекте ничего не изменится, так как это я предложил сделать, так как летом мы не очень заняты на работе, поэтому я формулирую свои собственные требования, думая о том, что было бы наиболее полезным способом его использования, но я понимаю, откуда вы пришли, я просто не думал об этом заранее. Что касается обучения на протяжении всей моей карьеры, это основная причина, по которой я нахожусь на этом сайте, поэтому я могу стать лучше, изучая то, что говорят люди, и помогая другим, которые тоже пытаются учиться. Спасибо! - person Adam Smith; 06.07.2011
comment
Внес некоторые незначительные правки в этот отличный ответ. Пожалуйста, просмотрите их. - person Andrew Thompson; 14.08.2012

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

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

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

person Joachim Sauer    schedule 06.07.2011
comment
На самом деле я не знал о других менеджерах компоновки (это немного глупо, но я никогда об этом не думал). Я знал только о тех из JDeveloper, как CardLayout, BoxLayout, GridLayout, GridBagLayout, FlowLayout и т. Д. Я посмотрю на другие, как в предложенной вами ссылке. Спасибо! Это должно упростить мне работу с другими окнами, которые я еще не создал / для будущих приложений. - person Adam Smith; 06.07.2011
comment
@Adam: да, к сожалению, встроенные менеджеры компоновки ограничены. Они либо слишком просты, чтобы быть полезными для сложных макетов (большинство из них), либо слишком сложны для использования здравомыслящим разработчиком (GridBagLayout). Я нечасто работаю с пользовательским интерфейсом, но я ненавидел делать какие-либо макеты, пока не нашел MiGLayout, который снизил задачу с ужасной до приемлемой, слегка раздражающей ;-) - person Joachim Sauer; 06.07.2011
comment
Я приму ваш совет и опробую MiGLayout! Я тоже ненавижу работу с пользовательским интерфейсом, потому что я не слишком артистичен и считаю это очень утомительным. Спасибо еще раз! - person Adam Smith; 06.07.2011

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

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

person irreputable    schedule 06.07.2011
comment
Я так не думал об этом. Я мог бы это сделать, если не перейду на макет, который мне больше нравится. Таким образом, я смогу использовать его позже в будущих проектах. - person Adam Smith; 06.07.2011
comment
Проблема может быть в том, что вы думаете об этом как о макете, вы никогда не используете только один. На разумном экране будет множество их, взаимодействующих с различными панелями и компонентами. Один размер не подходит для всех. - person Bill K; 06.07.2011

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

person mKorbel    schedule 06.07.2011