Пакет javafx.scene.layout

Предоставляет классы для поддержки макета пользовательского интерфейса. Каждый класс области макета поддерживает различную стратегию макета для своих дочерних элементов, и приложения могут вкладывать эти области макета, чтобы добиться необходимой структуры макета в пользовательском интерфейсе. После добавления узла в одну из областей макета, область автоматически будет управлять макетом узла, поэтому приложение не должно напрямую позиционировать или изменять размер узла; см. «Изменяемость узлов» для получения более подробной информации.

Механизм макета сцены

Механизм макета сцены управляется автоматически системой после того, как приложение создает и отображает Scene. Граф сцены обнаруживает динамические изменения узлов, влияющие на макет (например, изменение размера или содержимого), и вызывает requestLayout(), что помечает этот ветвь как требующую макета, чтобы при следующем импульсе выполнить проход макета сверху вниз по этой ветви, вызвав layout() для корня этой ветви. Во время этого прохода макета, метод обратного вызова layoutChildren() будет вызван для каждого родительского элемента, чтобы выровнять его дочерние элементы. Этот механизм разработан для максимальной эффективности макета, обеспечивая объединение нескольких запросов на макет и их обработку в одном проходе, а не выполняя повторный макет при каждом незначительном изменении. Поэтому приложения не должны вызывать макет напрямую для узлов.

Изменяемость узлов

Граф сцены поддерживает как изменяемые, так и неизменяемые классы узлов. Метод isResizable() в Node возвращает, является ли данный узел изменяемым или нет. Изменяемый класс узла — это класс, который поддерживает диапазон допустимых размеров (минимальный ≤ предпочтительный ≤ максимальный), что позволяет родительскому элементу изменять его размер в этом диапазоне во время макета, учитывая политику макета родительского элемента и потребности в макете дочерних узлов. Узел поддерживает следующие методы, чтобы код макета мог определить диапазон изменяемости узла:

     public Orientation getContentBias()
     public double minWidth(double height)
     public double minHeight(double width)
     public double prefWidth(double height)
     public double prefHeight(double width)
     public double maxWidth(double height)
     public double maxHeight(double width)
 

С другой стороны, классы неизменяемых узлов не имеют согласованного API изменения размера и поэтому не изменяются размером родительскими элементами во время макета. Приложения должны установить размер неизменяемых узлов, задавая соответствующие свойства для каждого экземпляра. Эти классы возвращают свои текущие границы макета для min, pref и max, а метод resize() становится бесполезным.

Изменяемые классы: Region, Control, WebView
Неизменяемые классы: Group, Shape, Text

Например, элемент управления кнопкой (изменяемый) вычисляет свои размеры min, pref и max, которые его родительский элемент будет использовать для изменения размера во время макета, поэтому приложение только нужно настроить его содержимое и свойства:

    Button button = new Button("Apply");
 

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

    Circle circle = new Circle();
     circle.setRadius(50);
 

Диапазон изменения размера

Каждый изменяемый класс узла вычисляет соответствующий минимальный, предпочтительный и максимальный размер на основе своего собственного содержимого и настроек свойств (его «внутренний» диапазон размеров). Некоторые изменяемые классы имеют неограниченный максимальный размер (все области макета), в то время как у других максимальный размер по умолчанию ограничен их предпочтительным размером (кнопки) (см. документацию по отдельным классам для стандартного диапазона каждого класса). Хотя эти значения по умолчанию ориентированы на общее использование, приложениям часто необходимо явно изменить или установить диапазон изменения размера узла для достижения определённых макетов. Изменяемые классы предоставляют свойства для переопределения размеров min, pref и max для этой цели.

Например, для переопределения предпочтительного размера ListView:

    listview.setPrefSize(200,300);
 

Или, для изменения максимальной ширины кнопки, чтобы она увеличивалась в ширину для заполнения пространства:

    button.setMaxWidth(Double.MAX_VALUE);
 

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

    listview.setMaxSize(Region.USE_PREF_SIZE, Region.USE_PREF_SIZE);
 

И наконец, если приложение хочет восстановить значения, вычисленные изнутри:

    listview.setPrefSize(Region.USE_COMPUTED_SIZE, Region.USE_COMPUTED_SIZE);
 

Стиль CSS и размер узла

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

Границы визуального отображения против границ макета

Графический пользовательский интерфейс часто нуждается в различении границ визуального отображения узла и границ, используемых для макета. Например, узкие визуальные границы глифов символов узла Text не подойдут для макета, поскольку текст не будет выровнен, и пробелы в начале/конце будут проигнорированы. Кроме того, иногда приложения хотят применить эффекты и преобразования к узлам, не затрагивая окружающий макет (отскоки, подергивания, тени, свечения и т. д.). Для поддержки этого различия в графе сцены, Node предоставляет свойство layoutBounds для определения «логической» границы узла для макета и boundsInParent для определения визуальной границы после применения всех эффектов, обрезки и преобразований.

Эти два свойства границ часто различаются для данного узла, и layoutBounds вычисляется по-разному в зависимости от класса узла:

Таблица вычисления границ

Тип узла	Границы макета
Shape,ImageView	Включает геометрические границы (геометрия плюс обводка). НЕ включает эффект, обрезку или любые преобразования.
Text	Логические границы, основанные на высоте шрифта и ширине содержимого, включая пробелы. Может быть настроено на узкие границы вокруг глифов символов, задав boundsType. НЕ включает эффект, обрезку или любые преобразования.
Region, Control, WebView	всегда [0,0 width x height] независимо от визуальных границ, которые могут быть больше или меньше границ макета.
Group	Объединение всех визуальных границ видимых дочерних элементов (boundsInParent). НЕ включает эффект, обрезку или преобразования, установленные непосредственно на группе, однако ВКЛЮЧАЕТ эффект, обрезку, преобразования, установленные на отдельных дочерних элементах, поскольку они включены в boundsInParent дочерних элементов.

Например, если DropShadow добавлен к фигуре, эта тень не будет учитываться в макете по умолчанию. Или, если ScaleTransition используется для пульсирования размера кнопки, эта анимация пульсации не будет нарушать макет вокруг этой кнопки. Если приложение хочет, чтобы эффект, обрезка или преобразование учитывались в макете узла, оно должно обернуть этот узел в группу.