Pull to refresh

Comments 34

Я выиграл в игре "Угадай технологию по UI"

А что тут угадывать то, если ответ в заголовке?

А мне вот очень понравился калькулятор с тёмно-розовыми кнопками. Справедливости ради стоит заметить, что в Avalonia 0.10.0, который уже вот-вот зарелизят, сделали тему, основанную на Microsoft Fluent Design. А ещё есть набор стилей Citrus.Avalonia. С релизом 0.10 будет сложнее угадать эту технологию по UI!


Мне UI тоже нравится, и очень-очень.
И особенно это цвет фиолетовый (или сиреневый, или темно-розовый) — фирменный цвет дот-нета, очень даже хорош.


То что на скрине у вас — тоже, кстати очень приятно выглядит.

Хорошо, что avalonia есть, но лично мне очень не хватает какого-нибудь компактного и удобного DSL, чтобы не верстать и не стилизовывать в xml (сейчас из кода можно верстать, но назвать это компактным и удобным язык не поворачивается).
Примерно так сейчас пишутся стили
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 в таком стиле порой ощущается перегруженным.
Кстати, я планировал в январе написать статью о разработке UI на F#, следите за обновлениями :)
В данном замечании нельзя не отметить наличие у Авалонии поддержки F# с mvu синтаксисом, который действительно походит на dsl и kotlin compouse
 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#? Если да, то не везде его использование оправдано — лучше использовать что-то отдельное, независимое от основного языка разработки.

Можно писать либы на F# или наоборот, основной проект на C# а либы со стилями или котролами на F#

Ну, на уровне сборок разруливается. Т.е. в одной сборке можно использовать или F#, или C#. Но вообще, я бы вот F# как раз для логики использовал, а вот для разметки xaml — самое оно

Тогда стоит попробовать 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>
Класс, спасибо за подсказку!

А мне привычнее писать


Rows.Add(rows);

Авалония на самом деле приятная, как посмотрел.

Краткий пересказ статьи для экономии Вашего времени: все тоже самое, что и в WPF
Многое очень похоже, да. Кстати, привыкшим к WPF разработчикам будет интересна вот эта страничка документации — тут рассказывается об основных различиях.
Честно говоря, именно это искал в статьею Спасибо.
Собственно в этом и вся магия. Берешь привычный подход к wpf и используешь. Но Авалония зашла дальше и расширила его, как платформенно (Добавились Linux, MacOs, уже виден горизонт в поддержке IOS и есть определенные работы под Android), так и в рамках синтаксиса (появилась более удобная стилизация, новые возможности в биндигах, новые уникальные контролы).
Так может и статейку по этому поводу?
Ну там про значимые различия, про сахар, с которым вкуснее, про перспективы, особенно в мобилки, как компилить под разные оси (что для этого надо), что там с производительностью и ограничениям.
А то получилось что-то больше похожее на Ctrl+H из 2006 года.
Может быть, спасибо за хорошую идею. Заголовок статьи достаточно полно отражает ее содержание и скорее призывает поверхностно знакомых разработчиков с платформой .net обратить внимание на Avalonia UI.
ViewLocator нам в этот раз не пригодится, так как он используется для создания кастомных контролов.

Правильнее, наверное, сказать «пользовательских контролов», а не «кастомных». По крайней мере, если использовать терминологию WPF.
И ещё… В Avalonia строки и столбцы сетки можно указывать куда проще:
Например,
<Grid RowDefinitions="auto * *" />

А как у данного GUI-фрейворка обстоят дела с потреблением памяти (по сравнению, например с Electron)
Если упрощать — в среднем лучше, чем Electron, но куда хуже, чем что-то плюсовое. По сравнению с WPF… зависит. Фреймворковская версия поэкономнее будет (многое прекомпилировано и лежит в GAC), неткоровский сопоставимо жрет.

Если следите за комментариями, скажите для ясности (я не уверен): разве можно Avalonia, который фреймворк для юи на решетках, сравнивать с Electron, который веб?

Electron не совсем веб. Оба фреймворка (и Авалония, и Электрон) нужны для создания кроссплатформенных приложений на десктоп. Разница здесь в способе создания этого приложения, но пользователь все еще получает кроссплатформенное десктопное приложение.
Electron не совсем веб.

Почему я Электрон вебом обозвал — так у него веб (клиент-серверное взаимодействие) в крови, а у второго, (наверное), — нет.

Не туда вопрос, простите. Дочитался до сути, и понял что не то спросил. Сравнение в контексте потребления памяти.

У меня вот только 1 вопрос — почему не Xamarin? Он еще и на мобильных платформах работает, и есть крутейший fabulous.
Утверждение, что Авалония самый крупный .NET фреймворк для кроссплатформенной разработки — явно ложный. Есть более крупные и известные Xamarin Forms, Uno Platform. Которые поддерживают (и в более лучшем виде чем это ваша Авалония) и iOS, Android, Windows, Mac, Linux.
А с выходом .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 уже пишут сложные кроссплатформенные редакторы наподобие таких:


image


Было бы любопытно посмотреть на что-то подобное, написанное на Xamarin.Forms и работающее на десктопах. Потому что есть мнение, что основной нишей Xamarin.Forms (и MAUI) останутся приложения попроще, больше ориентированные на мобильный сегмент, а не на высокопроизводительный десктоп.


А Uno пока, как говорят, needs more love. Но я слабо знаком с этим фреймворком — про производительность или сегмент, который оно покрывает, ничего не могу сказать. Надо пробовать.


image

Avalonia стремительно развивается и это не может не радовать! Выбор технологий для разработки кроссплатформенного UI с помощью XAML стал очень широк.

Когда нам в далёком 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 это удалось осуществить).
Sign up to leave a comment.