Верстка UI - обзор подходов
От: Shmj Ниоткуда  
Дата: 29.12.24 10:06
Оценка:
Вот что интересное заметил.

Ранее старались разделить — мухи отдельно, котлеты отдельно. Т.е. желали декларативное описание UI и отдельно уже код. Вот примеры

Дедовский MFC .rc (resource script)

Канонически правильный, не мешаем котлеты с мухами:

IDD_MYDIALOG DIALOGEX 0, 0, 200, 150
STYLE WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "My Dialog"
FONT 8, "MS Sans Serif"
BEGIN
    CONTROL "OK", IDOK, "Button", WS_TABSTOP, 50, 120, 50, 14
    CONTROL "Cancel", IDCANCEL, "Button", WS_TABSTOP, 110, 120, 50, 14
END


Qt Designer UI Language (XML)

  XML 
<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
 <class>MainWindow</class>
 <widget class="QMainWindow" name="MainWindow">
  <property name="geometry">
   <rect>
    <x>0</x>
    <y>0</y>
    <width>400</width>
    <height>300</height>
   </rect>
  </property>
  <property name="windowTitle">
   <string>Пример окна</string>
  </property>
  <widget class="QWidget" name="centralWidget">
   <layout class="QVBoxLayout" name="verticalLayout">
    <item>
     <widget class="QLineEdit" name="lineEdit"/>
    </item>
    <item>
     <widget class="QPushButton" name="pushButton">
      <property name="text">
       <string>Нажми меня</string>
      </property>
     </widget>
    </item>
   </layout>
  </widget>
  <action name="actionExit">
   <property name="text">
    <string>Выход</string>
   </property>
  </action>
 </widget>
 <resources/>
 <connections/>
</ui>


QT QML (Qt Modeling Language)

  QML 
import QtQuick 2.15
import QtQuick.Controls 2.15

ApplicationWindow {
    visible: true
    width: 400
    height: 300
    title: "Пример на QML"

    Column {
        anchors.centerIn: parent
        spacing: 10

        TextField {
            id: inputField
            placeholderText: "Введите текст"
        }

        Button {
            text: "Нажми меня"
            onClicked: console.log("Текст: " + inputField.text)
        }
    }
}


— это уже переходной этап, т.к. кроме декларации — был JavaScript. Но все-же не смешивалось с основным ЯП — как то C++.

WinForms и Xaml

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

Xaml же уже полностью вернулись к концепции полного разделения — был специальный XML-файл:

  XAML 
<Window x:Class="ExampleApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Пример XAML UI" Height="300" Width="400">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*"/>
            <ColumnDefinition Width="Auto"/>
        </Grid.ColumnDefinitions>

        <!-- Метка для ввода текста -->
        <TextBlock Grid.Row="0" Grid.Column="0" Margin="10" Text="Введите текст:" VerticalAlignment="Center"/>

        <!-- Текстовое поле для ввода -->
        <TextBox x:Name="InputTextBox" Grid.Row="0" Grid.Column="1" Margin="10" Width="200"/>

        <!-- Кнопка для подтверждения -->
        <Button x:Name="SubmitButton" Grid.Row="1" Grid.ColumnSpan="2" Margin="10" Content="Отправить" Click="SubmitButton_Click"/>

        <!-- Поле для отображения результата -->
        <TextBlock x:Name="ResultTextBlock" Grid.Row="2" Grid.ColumnSpan="2" Margin="10" Text="Здесь будет результат" TextWrapping="Wrap"/>
    </Grid>
</Window>


Что с Web-технологиями

Интересно что ASP.Net WebForms — был смесью HTML и серверных тегов — все-таки позиционировался как декларативный — код на C# размещался отдельно, что поднимало на уровень выше по сравнению с тогдашним PHP:

  ASP.NET Classic WebForms 
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="ContactForm.aspx.cs" Inherits="MyApp.ContactForm" %>

<!DOCTYPE html>
<html lang="en">
<head runat="server">
    <meta charset="utf-8" />
    <title>Contact Form</title>
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@4.5.2/dist/css/bootstrap.min.css" rel="stylesheet" />
</head>
<body>
    <div class="container">
        <h2>Contact Form</h2>

        <form id="form1" runat="server">
            <div class="form-group">
                <label for="Name">Name</label>
                <asp:TextBox ID="NameTextBox" runat="server" CssClass="form-control" />
            </div>

            <div class="form-group">
                <label for="Email">Email</label>
                <asp:TextBox ID="EmailTextBox" runat="server" CssClass="form-control" />
            </div>

            <div class="form-group">
                <label for="Message">Message</label>
                <asp:TextBox ID="MessageTextBox" runat="server" TextMode="MultiLine" CssClass="form-control" />
            </div>

            <asp:Button ID="SubmitButton" runat="server" Text="Submit" CssClass="btn btn-primary" OnClick="SubmitButton_Click" />
        </form>
    </div>
</body>
</html>


Потом как-то стал популярен MVC везде, в т.ч. в том же PHP он начал активно использоваться, и уже все стало намного проще:

  ASP.NET MVC (Razor) 
@model MyApp.Models.ContactForm

@{
    ViewBag.Title = "Contact Form";
}

<h2>@ViewBag.Title</h2>

@using (Html.BeginForm("Submit", "Home", FormMethod.Post))
{
    <div class="form-group">
        @Html.LabelFor(m => m.Name)
        @Html.TextBoxFor(m => m.Name, new { @class = "form-control" })
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Email)
        @Html.TextBoxFor(m => m.Email, new { @class = "form-control" })
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Message)
        @Html.TextAreaFor(m => m.Message, new { @class = "form-control" })
    </div>

    <button type="submit" class="btn btn-primary">Submit</button>
}


  ASP.NET Blazor 
@page "/contact"
@using MyApp.Models

<h3>Contact Form</h3>

<EditForm Model="@contactForm" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <div class="form-group">
        <label for="Name">Name</label>
        <InputText id="Name" class="form-control" @bind-Value="contactForm.Name" />
    </div>

    <div class="form-group">
        <label for="Email">Email</label>
        <InputText id="Email" class="form-control" @bind-Value="contactForm.Email" />
    </div>

    <div class="form-group">
        <label for="Message">Message</label>
        <InputTextArea id="Message" class="form-control" @bind-Value="contactForm.Message" />
    </div>

    <button type="submit" class="btn btn-primary">Submit</button>
</EditForm>


Андроид

Используются XML-файлы с описанием элементов формы:

  XML-layout 
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:padding="16dp">

    <EditText
        android:id="@+id/usernameEditText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="Enter your username" />

    <Button
        android:id="@+id/submitButton"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Submit" />
</LinearLayout>


iOS

Аналогично, использовался XML для описания:

  Storyboard 
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
  <dict>
    <key>UIApplicationSceneManifest</key>
    <dict>
      <key>UIWindowScene</key>
      <dict>
        <key>UIWindowSceneRoleApplication</key>
        <dict>
          <key>UIViewController</key>
          <dict>
            <key>view</key>
            <dict>
              <key>subviews</key>
              <array>
                <dict>
                  <key>UILabel</key>
                  <dict>
                    <key>text</key>
                    <string>Hello, world!</string>
                    <key>frame</key>
                    <string>{{50, 50}, {200, 40}}</string>
                  </dict>
                </dict>
                <dict>
                  <key>UIButton</key>
                  <dict>
                    <key>title</key>
                    <string>Press me</string>
                    <key>frame</key>
                    <string>{{50, 120}, {200, 50}}</string>
                    <key>action</key>
                    <string>buttonPressed:</string>
                  </dict>
                </dict>
              </array>
            </dict>
          </dict>
        </dict>
      </dict>
    </dict>
  </dict>
</plist>


Новые нравы


А теперь смотрите к чему мы опять вернулись.

Flutter

  Flutter 
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: Text('Форма регистрации')),
        body: Padding(
          padding: const EdgeInsets.all(16.0),
          child: RegistrationForm(),
        ),
      ),
    );
  }
}

class RegistrationForm extends StatefulWidget {
  @override
  _RegistrationFormState createState() => _RegistrationFormState();
}

class _RegistrationFormState extends State<RegistrationForm> {
  final _formKey = GlobalKey<FormState>();
  final _nameController = TextEditingController();
  final _emailController = TextEditingController();
  final _passwordController = TextEditingController();

  @override
  Widget build(BuildContext context) {
    return Form(
      key: _formKey,
      child: Column(
        children: <Widget>[
          TextFormField(
            controller: _nameController,
            decoration: InputDecoration(labelText: 'Имя'),
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Пожалуйста, введите имя';
              }
              return null;
            },
          ),
          TextFormField(
            controller: _emailController,
            decoration: InputDecoration(labelText: 'Электронная почта'),
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Пожалуйста, введите email';
              } else if (!RegExp(r'\S+@\S+\.\S+').hasMatch(value)) {
                return 'Введите корректный email';
              }
              return null;
            },
          ),
          TextFormField(
            controller: _passwordController,
            decoration: InputDecoration(labelText: 'Пароль'),
            obscureText: true,
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Пожалуйста, введите пароль';
              } else if (value.length < 6) {
                return 'Пароль должен содержать хотя бы 6 символов';
              }
              return null;
            },
          ),
          SizedBox(height: 20),
          ElevatedButton(
            onPressed: () {
              if (_formKey.currentState?.validate() ?? false) {
                // Если форма валидна, отправить данные
                ScaffoldMessenger.of(context).showSnackBar(
                  SnackBar(content: Text('Форма отправлена')),
                );
              }
            },
            child: Text('Отправить'),
          ),
        ],
      ),
    );
  }
}


Kotlin Multiplatform (KMP)

Вариант Compose Multiplatform:

  Compose Multiplatform 
@Composable
fun LoginForm() {
    Column {
        TextField(value = username, onValueChange = { username = it }, label = { Text("Username") })
        TextField(value = password, onValueChange = { password = it }, label = { Text("Password") }, visualTransformation = PasswordVisualTransformation())
        Button(onClick = { /* handle login */ }) {
            Text("Login")
        }
    }
}


SwiftUI

И даже новомодный SwiftUI

  SwiftUI 
import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Hello, world!")
                .font(.title)
                .padding()
            
            Button(action: {
                print("Button pressed")
            }) {
                Text("Press me")
                    .font(.title)
                    .padding()
                    .background(Color.blue)
                    .foregroundColor(.white)
                    .cornerRadius(10)
            }
        }
        .padding()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}


— это декларативно-императивный подход какой-то, когда вроде и все в декларации, но так же можно в любом месте и функцию дернуть. Причем сразу многие популярные платформы поддались этой тенденции. Т.е. все-таки отказались от концепции полного разделения мух и котлет — немножко мух теперь поддобавить можно
=сначала спроси у GPT=
Отредактировано 29.12.2024 10:52 Shmj . Предыдущая версия .
Re: Верстка UI - обзор подходов
От: Osaka  
Дата: 29.12.24 10:52
Оценка:
S>- это декларативно-императивный подход какой-то, когда вроде и все в декларации, но так же можно в любом месте и функцию дернуть. Причем сразу многие популярные платформы поддались этой тенденции. Т.е. все-таки отказались от концепции полного разделения мух и котлет — немножко мух теперь поддобавить можно
Молодые актуальные смузихлёбы утратили древнюю технологию машинной обработки форм в дизайн-тайме?
Всякую там генерацию контролов по модели данных (не только 1разовую write-only, но и многократную синхронизацию с ручными изменениями в обе стороны).
Тогда понятно, почему машиночитаемость описаний UI им стала не нужна, ведь актуальнее педалить жабаскрипт вручную.
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Re[2]: Верстка UI - обзор подходов
От: Shmj Ниоткуда  
Дата: 29.12.24 11:32
Оценка:
Здравствуйте, Osaka, Вы писали:

O>Молодые актуальные смузихлёбы утратили древнюю технологию машинной обработки форм в дизайн-тайме?
O>Всякую там генерацию контролов по модели данных (не только 1разовую write-only, но и многократную синхронизацию с ручными изменениями в обе стороны).
O>Тогда понятно, почему машиночитаемость описаний UI им стала не нужна, ведь актуальнее педалить жабаскрипт вручную.

Вот, кстати, интересный вопрос.

Я уже третий проект делаю на Flutter — и только сейчас узнал что есть, оказывается, визуальный редактор https://www.flutterflow.io/ Но, похоже, особой популярностью не пользуется.

SwiftUI имеет встроенный в Xcode редактор Canvas — но там все-равно постоянно нужно редактировать и код — в редакторе разве что свойства подправить — перетащить элемент в нужное место и то не получится.

Kotlin Multiplatform Compose — вроде пока вообще ничего нет.

Похоже что пришли к пониманию что сложные проекты в редакторе не сделать — легче в коде. Ну или какие-то сверх продвинутые редакторы нужны, все-равно нужно будет видеть иерархию и пр.
=сначала спроси у GPT=
Re: Верстка UI - обзор подходов
От: Ilya81  
Дата: 30.12.24 10:11
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вот что интересное заметил.

S>Ранее старались разделить — мухи отдельно, котлеты отдельно. Т.е. желали декларативное описание UI и отдельно уже код. Вот примеры

S>
Дедовский MFC .rc (resource script)


S>Канонически правильный, не мешаем котлеты с мухами:

S>
S>IDD_MYDIALOG DIALOGEX 0, 0, 200, 150
S>STYLE WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
S>CAPTION "My Dialog"
S>FONT 8, "MS Sans Serif"
S>BEGIN
S>    CONTROL "OK", IDOK, "Button", WS_TABSTOP, 50, 120, 50, 14
S>    CONTROL "Cancel", IDCANCEL, "Button", WS_TABSTOP, 110, 120, 50, 14
S>END
S>


S>...

S>
iOS


S>Аналогично, использовался XML для описания:

S>
  Storyboard
S>
S><?xml version="1.0" encoding="UTF-8"?>
S><plist version="1.0">
S>  <dict>
S>    <key>UIApplicationSceneManifest</key>
S>    <dict>
S>      <key>UIWindowScene</key>
S>      <dict>
S>        <key>UIWindowSceneRoleApplication</key>
S>        <dict>
S>          <key>UIViewController</key>
S>          <dict>
S>            <key>view</key>
S>            <dict>
S>              <key>subviews</key>
S>              <array>
S>                <dict>
S>                  <key>UILabel</key>
S>                  <dict>
S>                    <key>text</key>
S>                    <string>Hello, world!</string>
S>                    <key>frame</key>
S>                    <string>{{50, 50}, {200, 40}}</string>
S>                  </dict>
S>                </dict>
S>                <dict>
S>                  <key>UIButton</key>
S>                  <dict>
S>                    <key>title</key>
S>                    <string>Press me</string>
S>                    <key>frame</key>
S>                    <string>{{50, 120}, {200, 50}}</string>
S>                    <key>action</key>
S>                    <string>buttonPressed:</string>
S>                  </dict>
S>                </dict>
S>              </array>
S>            </dict>
S>          </dict>
S>        </dict>
S>      </dict>
S>    </dict>
S>  </dict>
S></plist>
S>


scene delegate — это новшество ios 13, а swiftui появился даже чуток раньше. Сам storyboard не такой, его существеовенный недостаток — он нерасширяемй, в отличие от xaml, про идентификаторы можно лишний раз не упоминать, но кое-какие аналоги datatemplate в xaml есть, хотя полностью в xml задать нельзя. А вот аналогов control template кроме xaml я нигде больше не видел.
Re: Верстка UI - обзор подходов
От: vsb Казахстан  
Дата: 30.12.24 10:25
Оценка: 8 (1)
Лично мне никогда не нравилась декларативщина и я всегда предпочитал по возможности описывать всё программно...

У меня всегда было ощущение, что декларативщину придумали для странного workflow, когда UI рисует в редакторе форм один человек, а программирует другой. Я никогда так не работал, мне максимум — давали макеты в картинках, поэтому мне, как программисту, всегда проще всё было создавать и управлять программно.

Декларативщина хороша до какого-то момента, а потом начинает мешаться. И в итоге получается половина кода в XML, половина кода в Java, к примеру. Ну и зачем оно надо... Уже и Preview показывает не то, что реально в приложении, и редактировать форму надо с оглядкой на код, и IDE чаще всего с этим всем интегрируется далеко не идеально. А когда всё в коде, тут вопросов не возникает.

В общем декларативщина это то, что кажется супер-интуитивным, но на практике пользы немного, а неудобств хватает. Лучше инвестировать в технологии моментального обновления приложения на лету. Чтобы менял код и приложение тут же менялось без перезапуска. Вот это действительно круто и ускоряет разработку неимоверно.
Отредактировано 30.12.2024 10:27 vsb . Предыдущая версия . Еще …
Отредактировано 30.12.2024 10:26 vsb . Предыдущая версия .
Отредактировано 30.12.2024 10:26 vsb . Предыдущая версия .
Re[2]: Верстка UI - обзор подходов
От: Shmj Ниоткуда  
Дата: 30.12.24 12:47
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Лично мне никогда не нравилась декларативщина и я всегда предпочитал по возможности описывать всё программно...

По архитектурным вопросам из всех участников форума — у вас самые разумные ответы. Пора бы вам, батенька, в архитекторы.
=сначала спроси у GPT=
Re[2]: Верстка UI - обзор подходов
От: Alekzander Россия  
Дата: 30.12.24 13:08
Оценка: +1
Здравствуйте, vsb, Вы писали:

vsb>Декларативщина хороша до какого-то момента, а потом начинает мешаться. И в итоге получается половина кода в XML, половина кода в Java, к примеру. Ну и зачем оно надо... Уже и Preview показывает не то, что реально в приложении, и редактировать форму надо с оглядкой на код, и IDE чаще всего с этим всем интегрируется далеко не идеально. А когда всё в коде, тут вопросов не возникает.

vsb>В общем декларативщина это то, что кажется супер-интуитивным, но на практике пользы немного, а неудобств хватает. Лучше инвестировать в технологии моментального обновления приложения на лету. Чтобы менял код и приложение тут же менялось без перезапуска. Вот это действительно круто и ускоряет разработку неимоверно.

Как ты делаешь адаптивность? (Под разные размеры, разные dpi, разный предпочтительный размер шрифта). Элементарно, как ты хендлишь лайаутинг при изменении размеров окна? Как поддерживаешь no-mouse, слепых, слабовидящих, эпилептиков? Как что-то меняешь в чужих контролах?

От этих упражнений отношение к декларативности быстро меняется.
Re[3]: Верстка UI - обзор подходов
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.12.24 14:53
Оценка:
Здравствуйте, Alekzander, Вы писали:

A>Как ты делаешь адаптивность? (Под разные размеры, разные dpi, разный предпочтительный размер шрифта). Элементарно, как ты хендлишь лайаутинг при изменении размеров окна? Как поддерживаешь no-mouse, слепых, слабовидящих, эпилептиков? Как что-то меняешь в чужих контролах?
A>От этих упражнений отношение к декларативности быстро меняется.
Я давно отстал от современных реалий гуестроения. Но вот отдалённый пример.
Много-много лет назад один дяденька был так разочарован фундаментальной неспособностью издательских наборщиков нормально сверстать статью по рукописи, что придумал свой собственный способ управления вёрсткой.
Поскольку дяденька был программистом, то способ у него получился программистский — язык TeX. Теперь автору не нужно было отдавать своё бесценное детище на поругание посторонним — они сами могли готовить свои документы.

Способ этот был настолько хорош, что через некоторое время все научные журналы стали требовать от авторов черновики статей именно в этом формате.

Намного позже одна компания подошла к аналогичной проблеме — но там речь шла не об учёных с их заковыристыми формулами и примерами программ, где одна опечатка меняет смысл на противоположный, а обычные офисные работники. Ведь не всякий документ продиктуешь машинистке, да и вообще. Поскольку целевая аудитория у этой компании была вовсе не нердами, а вполне себе социально успешными людьми, то разработчикам и в голову не пришло сочинять какой-то там язык какого-то там программирования. WYSIWYG — наше всё.
Этот WYISWYG породил уже три поколения людей, которые выравнивание по центру выполняют пробелами, а заголовки делают ручным верчением кегля.

Более того — из опыта мы знаем, что бывает очень трудно объяснить ворду, чего от него хотят, даже если хорошо понимать его модель документа (со всеми там параграфами, управляющими символами, и стилями).
Например, его автосписки настолько ужасны, что самый популярный рецепт на их тему объясняет, как отключить их нахрен и больше никогда от них не страдать.
У TeX и его потомков таких проблем в принципе нет.
Тем не менее, в 2024 году все научные журналы принимают статьи в .docx, хотя некоторые разрешают ещё и LaTeX.

То есть декларативщина победила — несмотря на то, что в ней крайне сложно делать вещи, которые чуть менее очевидны.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Верстка UI - обзор подходов
От: vsb Казахстан  
Дата: 30.12.24 17:59
Оценка:
Здравствуйте, Alekzander, Вы писали:

vsb>>Декларативщина хороша до какого-то момента, а потом начинает мешаться. И в итоге получается половина кода в XML, половина кода в Java, к примеру. Ну и зачем оно надо... Уже и Preview показывает не то, что реально в приложении, и редактировать форму надо с оглядкой на код, и IDE чаще всего с этим всем интегрируется далеко не идеально. А когда всё в коде, тут вопросов не возникает.

vsb>>В общем декларативщина это то, что кажется супер-интуитивным, но на практике пользы немного, а неудобств хватает. Лучше инвестировать в технологии моментального обновления приложения на лету. Чтобы менял код и приложение тут же менялось без перезапуска. Вот это действительно круто и ускоряет разработку неимоверно.

A>Как ты делаешь адаптивность? (Под разные размеры, разные dpi, разный предпочтительный размер шрифта). Элементарно, как ты хендлишь лайаутинг при изменении размеров окна? Как поддерживаешь no-mouse, слепых, слабовидящих, эпилептиков? Как что-то меняешь в чужих контролах?

A>От этих упражнений отношение к декларативности быстро меняется.

Я не предлагаю высчитывать пиксели вручную в общем случае. Layout Manager-ы я не отрицаю. Их прекрасно можно создавать программно. Хорошие Layout Manager-ы решают проблему адаптивности.

Про Layout Manager-ы ещё могу добавить, что я немного работал с Parametric CAD и подозреваю, что именно подход Parameteric CAD был бы вообще идеальным для программистского Layout. Это когда программист задаёт минимальный набор фиксированных или вычисляемых параметров, а layout engine вычисляет все остальные размеры, либо говорит, что параметров задано недостаточно, избыточно или параметры противоречивы. Не уверен, что там с производительностью такого подхода, но с точки зрения удобства я бы хотел такой подход попробовать.

Про слепых ничего не могу сказать, не сталкивался с задачами адаптации UI под них. У нас таких норм вроде нет, по крайней мере пока ни разу не просили этого делать. Но полагаю, что эти задачи должен решать используемый тулкит и дополнительное ПО.
Отредактировано 30.12.2024 18:02 vsb . Предыдущая версия .
Re[4]: Верстка UI - обзор подходов
От: Ilya81  
Дата: 30.12.24 18:42
Оценка:
Здравствуйте, vsb, Вы писали:


vsb>Это когда программист задаёт минимальный набор фиксированных или вычисляемых параметров, а layout engine вычисляет все остальные размеры, либо говорит, что параметров задано недостаточно, избыточно или параметры противоречивы.

Случаем в ios не подходят ли constraints под сей критерий?

Кстати про технологии моментального обновления приложения на лету — где вообще такое бывает? В ios если даже просто запустить без пересборки, то breakpoints обычно не срабатывают, а если и срабатывают, то значения переменных не посмотреть.

Так вот получается, что без отдельного GUI tools, который всё это провери, ничего не сделать, по крайней мере, за приемлемое время.
Re[4]: Верстка UI - обзор подходов
От: Alekzander Россия  
Дата: 30.12.24 19:25
Оценка: 123 (1)
Здравствуйте, Sinclair, Вы писали:

S>То есть декларативщина победила — несмотря на то, что в ней крайне сложно делать вещи, которые чуть менее очевидны.

А можно показать пример того, как "крайне сложно делать вещи, которые чуть менее очевидны"?

А я, в свою очередь, разверну свои вопросы. Чтобы разговор стал более предметным. Вместо абстрактной декларативности я возьму лучшую на данный момент реализацию — HTML.

Элементарно, как ты хендлишь лайаутинг при изменении размеров окна?


Лэйаутинг всегда был проклятием императивных гуёв. Очень часто с ним обходились, как мой тёзка из Македонии: делаем окно no-resize на все времена (т.е. 640×480 или меньше), вот и весь сказ. Иногда контролы растягивали по ширине. Мы все помним эти простыни OnResize() { control1.Move(); control2.Move(); ... control10.Move(); }, с тоннами бойлерплейта. Когда контролов много, логика усложнялась, туда добавляли условия, иногда группировали айдишники (или хендлы, или уж сразу ссылки/указатели). Ладно, если контролам надо было просто подгонять ширину, а если что-то большее?

Допустим, нужно сделать представление с карточками контактов (как в Outlook). Там ведь и переносы на новую строку, и расстояние между карточками, и отступы. И в дело вступает, как я это называю, LISP-архитектура (от старой шутки про то, что любая сложная система без ЛИСПа содержит самодельный ЛИСП, умеющий половину от оригинала, несовместимый и глючный). То есть, люди начинают писать свой layout-менеджер. Самое смешное, что часто люди этого даже не понимают. Им так и кажется, что у них всё императивно. Они начинают... что? Правильно: искать КОМПОНЕНТ. (Кстати, это ещё один антоним декларативности — декларативность с компонентностью не совместима, точнее, в HTML (как высшей форме декларативности) есть только псевдокомпоненты, а не настоящие компоненты, об этом ниже). Компонент, который умеет отображать карточки. А декларативную схему программист закладывает в настройки этого компонента. Когда их сериализуешь — получишь декларативность, но очень хорошо замаскированную. Криптодекларативность. В HTML, для сравнения, не нужен компонент, а нужен простой div. (Или текст, или кнопка, или любой контейнер). Лэйаутинг натягивается на что угодно.

Настоящая проблема (императивщиков) в том, что декларативные средства сейчас стали очень изощрёнными. Даже простая сетка в императивном коде уже превращается в проблему. Там, где в CSS можно указать: grid-template-columns: 2fr 1fr 1fr; и получить сетку с тремя колонками, первая из которых вдвое шире остальных, императивщикам уже надо писать логику с нуля. Некоторые подключают ЧатГПТ, который, как раз, хорошо генерирует решения задач, которые миллион раз уже решали. Но CSS умеет намного больше. Допустим, надо слить в пары две первые и две последних ячейки (в индексах узлов). Или сливать помеченные ячейки. И тут разом приплыли и императивщики, и ЧатГПТ.

Как ты делаешь адаптивность? (Под разные размеры, разные dpi, разный предпочтительный размер шрифта)


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

"Предпочтительный размер шрифта" — раньше это была чисто браузерная хрень:



Но вообще, теперь она везде. В Андроиде, в 11-й винде:



Как её учитывать?

В CSS для этого есть специальные единицы — rem (доли базового размера). Что удобно, дефолтный базовый размер обычно привязывают к степени двойки (16), и это даёт нам всегда конечную десятичную дробь для условно-среднего юзера при переходе от пикселей. Было бы удобнее иметь "условный пиксель", но этого в CSS, увы, нет. Вернее, есть, но не во всех стандартах. Однако, "условный пиксель" можно получить препроцессингом, например, в LESS, если задать нужную переменную, width: 20/@rem; будет означать "ширина 20 пикселей при дефолтном размере, с пропорциональным изменением при недефолтном". А в императивщине что? Это даже сравнивать смешно.

Далее, относительность размеров в CSS иерархическая. R в rem это Root. Но на каждом уровне размеры можно привязать к контейнеру. Допустим, размер иконки 2em это два базовых размера текста для конкретно этого контейнера.

Опять же, если просто не знать про настройку базового размера текста, и игнорировать её, проблема решится сама собой. Для программиста, не для юзера.

Как поддерживаешь no-mouse


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

Я уже немножко устал писать, поэтому сразу к неочевидным вещам:

/* Special case: if any element OUTSIDE navbar is focused with keyboard, enforce hiding navbar. */
body:has(*:focus-visible) .navbar.headroom--not-top:not(:has(*:focus-visible))
{
    --navbar-action: var(--navbar-dont-mess) !important;
}

/* Special case: if any element INSIDE navbar is focused with keyboard, enforce showing navbar. */
.navbar:has(*:focus-visible)
{
    --navbar-action: var(--navbar-show) !important;
}


Что тут написано? (Это можно было бы упаковать в одно выражение, но я его слегка денормализовал для читаемости). Написано тут следующее. Если пользователь навигирует по скроллируемому контейнеру при помощи кнопок Tab / Shift + Tab (допустим, он редактирует многостраничную презентацию и выделяет объекты внутри слайдов), контейнер, конечно, прокручивается, но выбранный элемент (именно при помощи клавиатуры!) может попасть под навигационную панель. Поэтому, при наличии выделенных с клавиатуры объектов панель должна не мешать. Но если юзер донавигирует до контролов, расположенных на самой панели, она должна быть отображена.

При этом, у нас выдерживается правильный уровень абстрактности. "Не мешать" расшифровывается где-то отдельно. Это может быть простое скрытие, плавное скрытие, полупрозрачность, что угодно.

Я очень хочу посмотреть, как в одну-две строки всю эту логику упихает императивщик.

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

А ещё, декларативный подход позволяет легко и просто задавать разные стилизации фокусных рамок для обычных кнопок, прозрачных кнопок на фоне картинки (например, кнопок управления видеопотоком), светлых, тёмных, всяких разных. ОС (та же винда) в лучшем случае отобразит квадратную рамку с фиксированным офсетом. Которая на круглой кнопке Play/Pause будет смотреться как на корове седло. Для сравнения:



Это стилизация фокусной рамки для круглой прозрачной кнопки на фоне видео. Она, что естественно, такая же круглая, как и сама кнопка.

А вот это нечто похитрее:



Это таб-контрол с переопределениями. В ортодоксальном таб-контроле мы ходим по вкладкам через Tab и активируем их пробелом/Enter'ом. Тут же у нас объединённый контрол, в котором мы переключаемся между вкладками кнопками-стрелками (для удобства). Такие вещи легко переопределять при помощи tabindex: для контейнера он задаёт табабельность (возможность фокусироваться с клавиатуры), а для радиокнопок — её отменяет. При этом, за счёт :has() в селекторе стилизации можно сделать общую фокусную рамку, но оставить старую логику навигации (с переходом от вкладки ко вкладке при помощи Tab).

Как это всё описывать императивно? Со слезами на глазах.

А вот ещё:



Это фокусная рамка (и сам контрол) поменяли свой цвет. Просто потому, что попали на тёмный фон. Декларативное описание в CSS позволяет очень просто группировать цвета (как и всё остальное), делая что угодно от простого "блок на тёмном"/"блок на светлом" до полноценных скинов.

Конечно, если не делать скины, и не делать блоки разноцветными, то проблемы, опять же, не возникнет.

Как поддерживаешь ... слепых


Ну, тут всё просто. Есть декларация — отдаём её скринридеру. Нет декларации — "слепой чёрт должен сидеть дома, а не пользоваться нашими UI'ем!" (ц).

На самом деле, конечно же, дай дураку декларативный HTML/CSS, он и из него сделает императивное говно, и скринридер не сможет ничего озвучить. У декларативности есть свои градации. В HTML истинно декларативный интерфейс называется "семантическая разметка".

Вообще, accessibility это такой тест на вшивость. Если делаешь хорошо (описывая кнопки как кнопки и т.д.), она будет сама собой. Если делаешь плохо, то не будет. Всякие технологии типа WAI ARIA содержат дохрениллион атрибутов, которыми можно управлять accessibility (метка, роль компонента, описание — всё это для скринридера), но искусство программиста в том, чтобы добиваться результата без их использования. Это официальный дзен accessibility, про который можно прочитать на MDN, например.

Конечно, если не поддерживать слепых... Ну, тенденция уже понятна, да?

Как поддерживаешь ... слабовидящих, эпилептиков


"Буду краток". Условные декларативные стилизации, собранные в одном месте, позволяют добиться результата намного проще, чем куча if'ов, разбросанных по всему коду.

Как что-то меняешь в чужих контролах?


Был такой случай. Чел спросил: я, мол, пользуюсь слайдером Owl carousel (известный слайдер) и хочу задать промежуток адаптивно (т.е. не 10px, а 0.625rem, чтобы при изменении базового размера промежуток пропорционально менялся). А компонент принимает строго число, трактуя его как пиксели. Как быть?

Императивно-компонентный подход настолько въелся в этих людей, что они не видят совершенно очевидного. Тут нет компонентов. А эти псевдокомпоненты (я обещал, что ниже объясню) — всего лишь декларативная разметка, декларативная стилизация и немножко обработчиков.

Ему ответили совершенно правильно: посмотри, какую разметку генерирует "компонент", и перестилизуй её как хочешь. Грубо говоря, напиши:

.owl-slide
{
    margin: 0.625rem !important;
}


Что делают при отсутствии декларативности? Покупают исходный код компонента, меняют, пересобирают. Иногда декомпилируют. При каждом обновлении версии — смыть, повторить.

А ведь в чужих компонентах бывают ошибки и похлеще.

Поисправляешь их недельку-другую, и быстро начнёшь ценить декларативность.

И чем больше у тебя юзеров, тем больше среди них слепых, одноруких, эпилептиков, тех, кто поставил размер базового шрифта ровно 21, юзает вертикальный экран с HiDPI и коэффициентом масштабирования 125%, и ещё выводит результат на печать. И приходится всё делать правильно, потому что каждая группа это, например, тысяча лицензий.
Отредактировано 30.12.2024 19:41 Alekzander . Предыдущая версия . Еще …
Отредактировано 30.12.2024 19:28 Alekzander . Предыдущая версия .
Re[5]: Верстка UI - обзор подходов
От: vsb Казахстан  
Дата: 30.12.24 19:32
Оценка:
Здравствуйте, Ilya81, Вы писали:

I>Случаем в ios не подходят ли constraints под сей критерий?

Что-то близкое, но не совсем. В Parametric CAD я могу задавать вообще любые расстояния. А также могу задавать произвольные ограничения. К примеру что ширина этой кнопки должна быть ровно в 2 раза больше ширины этой кнопки. А он уже по этим вводным какой-то хитрой математикой высчитывает что надо.

I>Кстати про технологии моментального обновления приложения на лету — где вообще такое бывает? В ios если даже просто запустить без пересборки, то breakpoints обычно не срабатывают, а если и срабатывают, то значения переменных не посмотреть.

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

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

На iOS не знаю, когда я для него разрабатывал, не видел там такого функционала.

Но вообще все эти решения — они как бы сверху прилеплены, не продуманы фундаментально. Ведь проблема замены кода на лету — она совсем не тривиальная в общем случае. Есть определённое состояние, если я меняю структуры данных в приложении, то они будут не совместимы со старым состоянием. Возможно если этот механизм продумать прям на уровне дизайна языка, виртуальной машины и архитектуры, получится что-то интересное... Не знаю. А сейчас пытаются патчить, если не получается — выдают ошибку, перезапускай. На практике это покрывает 80% случаев, так что может и не нужно ничего лучше.
Отредактировано 30.12.2024 19:33 vsb . Предыдущая версия .
Re: Верстка UI - обзор подходов
От: SergeyIT Россия  
Дата: 30.12.24 21:50
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Вот что интересное заметил.

А чего Делфи не вспомнил.
До сих пор, если надо написать что-то быстро, использую Lazarus. UI делаю мышкой, устраивает полностью
Извините, я все еще учусь
Re[6]: Верстка UI - обзор подходов
От: Ilya81  
Дата: 04.01.25 17:07
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>К примеру что ширина этой кнопки должна быть ровно в 2 раза больше ширины этой кнопки.

Элементарная вещь в iOS, кроме этого есть приоритеты на сжатие и растяжение, т. е. чей intrinsic size главнее.

vsb>Также в андроиде это работает, но там гораздо дольше цикл сборки, несколько секунд нужно, чтобы собрать приложение и пропатчить его на устройстве. С дебаггером проблем вроде нет.

vsb>На iOS не знаю, когда я для него разрабатывал, не видел там такого функционала.

А вот как раз с циклом сборки в iOS плохо, в swift зачем-то наворотили какой-то мудрёный синтаксис, и теперь не могут для него как следует сделать compiler.
Re[7]: Верстка UI - обзор подходов
От: vsb Казахстан  
Дата: 06.01.25 14:27
Оценка:
Здравствуйте, Ilya81, Вы писали:

vsb>>Также в андроиде это работает, но там гораздо дольше цикл сборки, несколько секунд нужно, чтобы собрать приложение и пропатчить его на устройстве. С дебаггером проблем вроде нет.

vsb>>На iOS не знаю, когда я для него разрабатывал, не видел там такого функционала.

I>А вот как раз с циклом сборки в iOS плохо, в swift зачем-то наворотили какой-то мудрёный синтаксис, и теперь не могут для него как следует сделать compiler.

Просто не надо писать на Swift. Убогий язык. Objective C намного удобней.
Re[8]: Верстка UI - обзор подходов
От: Ilya81  
Дата: 07.01.25 21:34
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Ilya81, Вы писали:

vsb>>>Также в андроиде это работает, но там гораздо дольше цикл сборки, несколько секунд нужно, чтобы собрать приложение и пропатчить его на устройстве. С дебаггером проблем вроде нет.

vsb>>>На iOS не знаю, когда я для него разрабатывал, не видел там такого функционала.

I>>А вот как раз с циклом сборки в iOS плохо, в swift зачем-то наворотили какой-то мудрёный синтаксис, и теперь не могут для него как следует сделать compiler.

vsb>Просто не надо писать на Swift. Убогий язык. Objective C намного удобней.

Как сказать... В Objective C не назначить generic отдельному методу, closure громоздкие, нет того, что именуют pattern matching, ещё пустые указатели сложнее отслеживать. Впрочем, как раз с closure в swift хзуже всего compiler справляется.
Re[9]: Верстка UI - обзор подходов
От: vsb Казахстан  
Дата: 08.01.25 09:05
Оценка:
Здравствуйте, Ilya81, Вы писали:

vsb>>Просто не надо писать на Swift. Убогий язык. Objective C намного удобней.

I>Как сказать... В Objective C не назначить generic отдельному методу, closure громоздкие, нет того, что именуют pattern matching, ещё пустые указатели сложнее отслеживать. Впрочем, как раз с closure в swift хзуже всего compiler справляется.

Под убогостью я понимаю реализацию. Xcode как падала с первой версии Swift, так и до сих пор падает, пусть и пореже. Компилятор как кидал какие-то internal error-ы, так и кидает. Про время компиляции они вообще не думают при дизайне языка, я видел выражения, которые роняют компилятор по какому-то таймауту, мол слишком долго компилировать, при том, что там выражение простейшее, это не специально подобранный код, а код, который вполне можно написать самому.

Так-то в теории оно, конечно, красивое и современное, без вопросов. Но пользоваться этим неприятно. А Objective C — ну старенький, дубовый, но задачи решает, а инструментарий прекрасно работал ещё 20 лет назад.
Отредактировано 08.01.2025 9:06 vsb . Предыдущая версия .
Re[10]: Верстка UI - обзор подходов
От: Ilya81  
Дата: 08.01.25 11:24
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Ilya81, Вы писали:

vsb>>>Просто не надо писать на Swift. Убогий язык. Objective C намного удобней.

I>>Как сказать... В Objective C не назначить generic отдельному методу, closure громоздкие, нет того, что именуют pattern matching, ещё пустые указатели сложнее отслеживать. Впрочем, как раз с closure в swift хзуже всего compiler справляется.

vsb>Под убогостью я понимаю реализацию. Xcode как падала с первой версии Swift, так и до сих пор падает, пусть и пореже. Компилятор как кидал какие-то internal error-ы, так и кидает. Про время компиляции они вообще не думают при дизайне языка, я видел выражения, которые роняют компилятор по какому-то таймауту, мол слишком долго компилировать, при том, что там выражение простейшее, это не специально подобранный код, а код, который вполне можно написать самому.

Есть такое. Кому пришло в альтернативный орган мышления сделать такой синтаксис — не знаю, но полноценный compiler теперь в итоге сделать не могут. Ещё и сообщения об ошибке в 90% случаев бесполезные. Помню, разок собрался уже писать заново немаленький кусок, поскольку никак не мог понять, где ошибка, как вдруг заметил, что вместо return написал retrun. Аналогичное бывало, когда перед flatMap пропускал знак вопроса, не заметив, что исходный тип optional.
Re: Верстка UI - обзор подходов
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 05.02.25 15:11
Оценка:
Здравствуйте, Shmj, Вы писали:

S>
Дедовский MFC .rc (resource script)
Это не MFC, а стандартный формат описания ресурсов в инструментах от MS.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.