Как стать автором
Обновить

Комментарии 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.
Вот старое выступление товарища kekekeks. По его словам, Xamarin тогда (и сейчас?) не очень хорошо подходил для десктопов
Утверждение, что Авалония самый крупный .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 это удалось осуществить).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий