Комментарии 34
Я выиграл в игре "Угадай технологию по UI"
А что тут угадывать то, если ответ в заголовке?
А мне вот очень понравился калькулятор с тёмно-розовыми кнопками. Справедливости ради стоит заметить, что в Avalonia 0.10.0, который уже вот-вот зарелизят, сделали тему, основанную на Microsoft Fluent Design. А ещё есть набор стилей Citrus.Avalonia. С релизом 0.10 будет сложнее угадать эту технологию по UI!
var styles = new Styles() {
new Style(s=>s.OfType<Button>().Class("primary").Class(":focus")) {
Setters = {
new Setter(Button.BorderProperty, ...)
}
}
}
против XML
<Styles>
<Style Selector="Button.primary:focus">
<Setter Property="Button.Border" Value="#ff0000"/>
</Style>
</Styles>
В этом аспекте мне очень сильно нравится Jetpack Compose на котлине и Fabulous на F#.
Avalonia FuncUI — имхо не очень удобна, тк значения свойств записываются через список, а не через объект.
Условно:
let textBox= TextBox.create [TextBox.text "Hello world"; TextBox.width 100]
против
let textBox = TextBox(text = "Hello world", width = 100)
Кстати, я планировал в январе написать статью о разработке UI на F#, следите за обновлениями :)
let view (state: CounterState) (dispatch): IView =
DockPanel.create [
DockPanel.children [
Button.create [
Button.onClick (fun _ -> dispatch Increment)
Button.content "click to increment"
]
Button.create [
Button.onClick (fun _ -> dispatch Decrement)
Button.content "click to decrement"
]
TextBlock.create [
TextBlock.dock Dock.Top
TextBlock.text (sprintf "the count is %i" state.count)
]
]
]
И мне в нём не нравится, что свойства пишутся в списке, а не в объекте/параметрах — не удобно исследовать API через автокомплит.
Нужно ли при этом весь остальной проект писать на F#? Если да, то не везде его использование оправдано — лучше использовать что-то отдельное, независимое от основного языка разработки.
На альтернативный DSL заведена issue: Alternative markup syntax proposal.
Тогда стоит попробовать Flutter. Код на нем выглядит почти так вы описали.
Вот так, например:
Card(
child: Container(
padding: EdgeInsets.all(10),
child: TextFormField(
textInputAction: TextInputAction.search,
onFieldSubmitted: (_) => _onSearch(),
autofocus: true,
controller: queryController,
decoration: InputDecoration(labelText: 'Ключевые слова'),
),
)
)
Кстати, в авалонии есть прикольная штука для гридов, можно писать вот так
<Grid RowDefinitions="*,*,*,"/>
вместо вот этого
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="*"></RowDefinition>
<RowDefinition Height="*"></RowDefinition>
<RowDefinition Height="*"></RowDefinition>
</Grid.RowDefinitions>
</Grid>
Ну там про значимые различия, про сахар, с которым вкуснее, про перспективы, особенно в мобилки, как компилить под разные оси (что для этого надо), что там с производительностью и ограничениям.
А то получилось что-то больше похожее на Ctrl+H из 2006 года.
ViewLocator нам в этот раз не пригодится, так как он используется для создания кастомных контролов.
Правильнее, наверное, сказать «пользовательских контролов», а не «кастомных». По крайней мере, если использовать терминологию WPF.
И ещё… В Avalonia строки и столбцы сетки можно указывать куда проще:
Например,
<Grid RowDefinitions="auto * *" />
Если следите за комментариями, скажите для ясности (я не уверен): разве можно Avalonia, который фреймворк для юи на решетках, сравнивать с Electron, который веб?
Не туда вопрос, простите. Дочитался до сути, и понял что не то спросил. Сравнение в контексте потребления памяти.
А с выходом .NET MAUI многие кроссплатформенные разработчики так и пишут, прощай Xamarin Forms (И уж тем более Авалон). Ибо подобные фреймворки теряют свою актуальность и оказываются на свалке технологий, там же где и Borland Delphi, Visual Basic 6 и список можно продолжать еще долго…
На самом деле всё не совсем так, как вы пишете. Да, действительно, с выходом .NET MAUI Xamarin.Forms отправится на свалку, потому что .NET MAUI и есть, по сути своей, эволюция Xamarin.Forms с новыми API. При этом, в Microsoft собираются сделать API .NET MAUI совместимым с API Xamarin.Forms. Подробнее о планах команды можно посмотреть в видео с виртуальной конференции ReactiveUI под названием Dualscreen, .NET MAUI and ReactiveUI. Там разработчик нового MAUI и старого Xamarin.Forms делится инсайдами о новом API.
Далее, на странице репозитория dotnet/maui мы видим сводку о поддерживаемых платформах, согласно которой Linux всё так же остаётся community-maintained. Это значит, что, ну, Microsoft Linux поддерживать не будет, а Avalonia уже поддерживает. Не исключено, что может появиться бакенд MAUI, основанный на Avalonia, с помощью которого можно будет обеспечить поддержку Linux — будем посмотреть.
Далее, ниши у Xamarin.Forms (или MAUI) и AvaloniaUI (или WPF) принципиально разные. Про производительность Avalonia в сравнении с WPF можно посмотреть в Core2D rendering performance WPF vs Avalonia+Direct2D,SkiaSharp,Cairo vs WPF+SkiaSharp. На Avalonia уже пишут сложные кроссплатформенные редакторы наподобие таких:
Было бы любопытно посмотреть на что-то подобное, написанное на Xamarin.Forms и работающее на десктопах. Потому что есть мнение, что основной нишей Xamarin.Forms (и MAUI) останутся приложения попроще, больше ориентированные на мобильный сегмент, а не на высокопроизводительный десктоп.
А Uno пока, как говорят, needs more love. Но я слабо знаком с этим фреймворком — про производительность или сегмент, который оно покрывает, ничего не могу сказать. Надо пробовать.
Когда нам в далёком 2013 потребовалось сделать хороший UI для игр и захотелось использовать опыт WPF/XAML, выбор пал на NoesisGUI — проприетарная кроссплатформенная библиотека, имплементирующая WPF API с полной поддержкой всех фич XAML (и даже сверх того за счёт отдельных расширения для 3D эффектов, text stroke и т. п.), с оптимизацией под видеоигры. Спустя много лет и багрепортов (включая сотни моих) проект дорос до достойного уровня и теперь это уже полноценный middleware используемый даже в таких ААА проектах, как Baldur's Gate 3. Ну и наши две инди-игры его успешно используют. Например, (немного устаревшие) скриншоты UI из последней игры twitter.com/noesisengine/status/978583221398114304 при этом исходные коды игры (кроме нашего движка) доступны публично github.com/AtomicTorchStudio/CryoFall Можно посмотреть, как многое устроено (сотни XAML файлов) или даже поиграться в live editing (исходники идут в открытом виде с игрой, во многом благодаря Roslyn это удалось осуществить).
Авалония для самых маленьких