@jassmith ,

Это очень хорошая идея с точки зрения стандартизации XAML, и она обеспечит мощную функциональность. Однако я бы осторожно пошел по этому пути. Это определенно будет способствовать достижению общей цели перехода Xamarin.Forms к стандарту XAML (https://github.com/Microsoft/xaml-standard). Но, наряду с VisualStates, есть большие вопросы о том, насколько это будет полезно на самом деле.

Необходимо учитывать графическое ускорение в таких областях. Отсутствие графического ускорения уже является проблемой в некоторых частях системы, таких как анимация. Я предполагаю, что если Xamarin.Forms возьмет на себя ответственность за рендеринг векторных изображений, он будет впоследствии удален с базовой платформы и перемещен из обработки графического процессора в обработку ЦП. В некоторых случаях это будет огромным ударом по производительности. Это не значит, что этого не следует делать, но следует подумать о том, можно ли оставить обработку на уровне графического процессора вместо того, чтобы переносить ее на центральный процессор. Потребители библиотеки XF должны быть осведомлены о том, что будет работать на собственной платформе и что будет отображаться библиотекой XF.

Существует также вопрос баланса между собственным рисованием и различиями в рисовании кросс-платформы. Текст — важный момент. Должен ли текст отображаться одинаково на всех платформах? Т.е. следует ли передать рендеринг шрифтов в XF, чтобы добиться единообразия на всех платформах? Возможно. Но я не думаю, что это должно быть общим проектом для XF. Люди подсознательно обнаруживают мелкие визуальные детали. Детали могут быть в анимации или так далее. Даже небольшое отклонение от нормы на данной платформе может заставить пользователя чувствовать себя некомфортно. Таким образом, это не обязательно хорошая идея, чтобы все рисунки были одинаковыми. Avalonia, безусловно, идет по этому пути, но это совершенно отдельный случай, и в этом разница между Avalonia и Xamarin Forms.

Кроме того, еще один комментарий заключается в том, что следует позаботиться о том, чтобы все примитивные типы назывались одинаково и были как можно ближе согласованы с другими платформами, такими как UWP и WPF, чтобы соответствовать стандарту XAML.

@davidortinau , у тебя есть мысли по этому поводу?

Одной из замечательных особенностей материального дизайна является Ripple. Вы рассчитываете поддержать это?
В целом я думаю, что это фантастика!

Мне очень нравится это направление. Для iOS я использовал собственные ячейки представления, используя собственные элементы (i, > options), но чем больше я применяю пользовательские темы, тем больше я просто имитирую собственные ячейки и больше стремлюсь к красиво выглядящей/работающей теме, которая беглая и согласуется с приложением, но не нативным сам по себе, за исключением деталей. Я думаю, что если используется соответствующая базовая библиотека рендеринга, GPU не будет проблемой, читайте Skia. То же самое питает Flutter.

Возможно, это отдельная проблема, но в то же время было бы неплохо сделать SVG первоклассным гражданином Forms. Например, включение изящных эффектов, таких как анимированное окрашивание кнопки изображения при нажатии.

Мое мнение таково, что в конце концов вам нужны мощные, богатые, нативные (не нативные сами по себе!) элементы управления, которые легко программировать с согласованным кросс-платформенным поведением, за странным исключением, чтобы приспособиться к нативной причуде платформы. Например, волновой эффект для Android.

@ChaseFlorell , на самом деле знаю. Идея состоит в том, что вы можете использовать x:Name в шаблоне, а затем выкапывать их с помощью FindByName. Когда у вас есть собственный элемент, вы можете применять к нему анимацию, как и к чему-либо еще, однако, вероятно, будет специальный способ получить обратный вызов анимации. Я все еще разрабатываю эти точные детали. С Skia, занимающейся рисованием, это может легко достичь 60 кадров в секунду на Android, и даже без Skia вы можете достичь 60 кадров в секунду на других платформах.

@rogihee SVG на самом деле не является форматом доставки, извините: / Я не хочу нести ответственность за попытки последовательно отображать SVG на разных платформах. Когда же они все-таки добавят хинтинг в SVG...

@jassmith , будет ли это аппаратное ускорение графики?

Исходя из QML Qt, хотелось бы увидеть это. В сочетании с несколькими очевидными встроенными элементами управления можно преобразовать много земли.

Может быть, немного преждевременно или стоит другой проблемы, но каков план доступности/тестируемости для элементов управления, построенный на этом?

@RichiCoder1 a11y - это, безусловно, то, что нужно будет правильно проработать. В идеале элемент Text должен автоматически устанавливать большинство необходимых свойств для простых элементов управления.

это функция для xf 4.0？

3.0 серия

@jassmith в дорожной карте ничего нет о рисовании и оболочке

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

будут ли все эти превью в 2018 году？@jassmith

@juepiezhongren мы не собирались делать эти предложения. Они представлены здесь для открытого обсуждения их достоинств, недостатков и т.д.

Я исхожу из вашего интереса, что эти характеристики вам интересны. Не могли бы вы поделиться некоторыми конкретными примерами того, как они помогают вам при создании приложений с помощью Xamarin.Forms? Какие проблемы вы видите в этом решении? Какие возможности, по вашему мнению, они открывают для вас?

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

Как всегда, любой желающий может написать мне по электронной почте. Дэйвид. [email protected]

Самой большой проблемой для меня является ответ «мы не можем сделать это с помощью платформы Forms», который я должен дать потенциальным клиентам и UX/UI. Это дискредитирует структуру, и у меня не так много шансов с клиентом.

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

Даст ли это предложение такие независимые от платформы примитивы композиционного пользовательского интерфейса?

@timahrentlov Нам нужно обсудить и увидеть, в чем именно заключаются эти ограничения и в чем причина этих ограничений. Но, честно говоря, я даже не осмеливаюсь думать или смотреть так далеко. Проблема, которую я вижу в Xamarin Forms, гораздо проще: она по-прежнему остается проектом с очень ограниченными ресурсами для разработки. Нереально или бесполезно обсуждать, что можно сделать, когда на самом деле нет достаточной мощности и топлива. Я не вижу смысла. Возможно, Xamarin все еще тайно надеется, что некоторые люди из сообщества OSS начнут работать и исправлять ошибки? Не поймите меня неправильно, я уважаю время и усилия, которые Xamarin вложила в Xamarin Forms.

@давидортинау
Кроссплатформенность трудно разобрать: характерный визуальный дизайн, уникальный внешний вид кнопки, уникальный эффект исчезновения заполнителя и т. д. На самом деле наши приложения не идентичны. Например, затухание уведомления Mac с небольшим взрывом очень легко произвести впечатление на его клиентов. Почему мы так любим wpf в тот день, одна из причин, по которой я упомяну, это шаблон управления, где нам так нравятся пути за нашу уникальность, такие как угловая шестиугольная кнопка. Мы хотим, чтобы xf предоставил их разработчикам кросс-платформенных клиентов.

@juepiezhongren , если вы ищете такую ​​​​настройку пользовательского интерфейса, я не думаю, что есть какая-либо кроссплатформенная структура, которая может это сделать. А насчет WPF: смешивать WPF с мобильным — плохая идея.

моя команда тоже использует React Native, где так много jsers вносят большой вклад, где через 3 месяца мы пришли к выводу, что это совсем не продуктивно. Для xf это с недостатками, с ошибками, но в основном это надежное решение, eps x.native делает все нативные API действительными. Чего не хватает, так это только внешности, недавнего безумия. К тому же с шеллом флаттер будет бесполезен, без чего-то типа флаттер.иос флаттер будет как rn с родным апи безграничным страданием.

@opcodewriter
мы используем skiasharp довольно часто, делая специальный контроль, его производительность удовлетворительна

@jassmith вы думали о том, чтобы перенести materialShell на wasm с помощью webgl, для skia, может быть, он слишком велик для загрузки

правильно, мы не хотим сильно зависеть от каких-либо сторонних библиотек для API рисования по умолчанию. \мог сделать это

с xamarin.mono и оболочкой в ​​wasm любой альфа-продукт вызовет ренессанс дотнета в китае, где преобладает ненависть к дотнету

@jassmith есть хорошие новости по этой проблеме?

какие новости вы ищете @juepiezhongren? На данный момент это Спецификация опубликована для обсуждения.

мы хотим увидеть, когда отрисовка и оболочка будут включены в дорожную карту @ChaseFlorell
универсальный рендеринг уже действителен для авалонии и флаттера

Сроки будут зависеть от моей личной скорости развития. Цель здесь не в том, чтобы отвлечь всю команду на эти усилия и избавить от этого только меня. Вы можете отслеживать ветку оболочки, если хотите посмотреть, как она собирается вместе. После Шелла придет рисование.

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

Это все очень красиво, но будет ли использоваться графическое ускорение?

@jassmith на ios, будет использоваться system.draw; на Android можно использовать skiasharp || skiasharp для всего?

@juepiezhongren он будет поддерживать несколько бэкэндов, поэтому, если вы хотите, чтобы он использовал Skia, он будет использовать Skia, если вы хотите, чтобы он использовал собственный API рисования, он будет использовать его вместо этого. По умолчанию он будет использовать собственный бэкэнд, и Skia будет включена, поэтому зависимость не будет навязываться вам.

@jassmith действительно связано с тем, что system.draw доступен для ios, а не для android.

Добавление поддержки System.Drawing @juepiezhongren не входит в мою компетенцию. Однако с этой спецификацией ничто не будет использовать System.Drawing.

в основном, отрисовка вызовет гораздо меньше рендеров

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

Я нахожусь в лагере «сделайте это как можно ближе к wpf/uwp», что, как я знаю, не всегда является самой популярной позицией здесь.

НО, это кажется отличным компромиссом между совершенно некрасивым фреймворком, выполняющим ВЕСЬ рендеринг, и текущей парадигмой XF.

Я предполагаю, что примитивы будут иметь аналоги на каждой платформе, и поэтому аппаратное ускорение не будет проблемой. Windows/iOS/Android/и т. д. по-прежнему отображают прямоугольники, круги, градиенты и т. п. и будут использовать аппаратное ускорение в той же степени, что и раньше. Это просто дало бы нам дизайнерам элементов управления возможность разрабатывать наши элементы управления с использованием примитивов, а не зацикливаться на идее Apple о кнопке против идеи Microsoft.

Я правильно резюмирую?

@pmoorelegistek в основном идея да. И мы занимаемся материалом в первую очередь потому, что в нем нет размытия как основного элемента дизайна. Это означает, что мы можем заставить его работать везде (смотря на вас, Android).

когда я закончу Shell v1, я сразу же перейду к этому

@jassmith Это золото. Используйте нативные элементы управления там, где они соответствуют дизайну UX, и легко добавляйте рисованные элементы управления, похожие на лыжи, только для (желательно нескольких) элементов дизайна, которые в этом нуждаются.

Больше никаких разговоров «не могу сделать это в Xamarin Forms» с дизайнерами и клиентами. Это устраняет ограничения дизайна, сохраняя при этом истинное естественное ощущение (в отличие от флаттера).

Я хотел бы увидеть это перед материальной оболочкой. Это решает реальное ограничение XF.
Shell — это энная функция, позволяющая легко и быстро начать работу. Начало работы слишком долго было в центре внимания, но подобные функции для дальнейшего развития _удержат_ разработчиков XF на борту.

Это должно произойти перед Material Shell, потому что от этого зависит Material Shell. Я думаю, ты хотел сказать, что предпочел бы увидеть это раньше, чем Шелл?

Shell не нацелена на то, чтобы начать работу быстрее/проще. Это предназначено для модернизации Страниц так, как мы не можем сделать, чтобы они были их собственными элементами управления. По сути, он предназначен для их полной замены, и мы будем призывать людей рассмотреть возможность переноса. Shell ориентирована на обеспечение гораздо более плавного и богатого опыта для конечных пользователей, ее анимацию можно настраивать, она может откладывать/лениво загружать вещи до/после анимации, чтобы они не вызывали сбоев. Он обеспечивает область контента с нулевой перегрузкой графического процессора в Android, сравните это с текущими страницами, где перерисовка находится только в «красной части диаграммы» повсюду.

Цель Shell не в том, чтобы заставить людей быстрее начать работу, а в том, чтобы сделать ваше приложение быстрее. С помощью Shell вы можете, например, пометить страницы/вкладки/группы как «частые», и они будут сохранены системой при условии, что пользователь посещает их постоянно. Это означает, что они не будут перезагружаться, когда вы уходите и возвращаетесь. Мы можем это сделать, потому что Shell владеет всей иерархией страниц.

У нас также есть некоторые мысли о том, как оптимизировать производительность отрисовки с помощью Shell, что, хотя мы, безусловно, никогда не будем ограничивать отрисовку с помощью Shell, потенциально сделало бы отрисовку с оболочкой намного более эффективной, поскольку мы могли бы выполнять все отрисовки за один и тот же проход. Здесь требуется крупица соли, поскольку этот шип еще не был сделан, но на бумаге он выглядит прилично.

@weitzhandler Я надеюсь перейти к этому в ближайшие 4-6 недель. Это будет намного быстрее, чтобы заставить работать эту оболочку. Ни одно из этих времен не высечено на камне.

+1

@jassmith https://github.com/nventive/Uno
это прекрасно.
уни-рендеринг отличный

Forms будет радикальным исследователем, а uno — консервативным.
мы любим обоих

+1 Отличная функция, она решит множество пользовательских проблем с пользовательским интерфейсом, мы хотим увидеть ее как можно скорее.

@jassmith кажется, что розыгрыш должен быть сделан для 3.3.0？

Есть новости по этому поводу?

Для нас это самая привлекательная функция, которую мы надеемся реализовать в Xamarin.

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

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

Shell & Material Shell — это благословение и отличные новости, пожалуйста, продвигайте это вперед! Это единственное, что будет удерживать ваших пользователей в другом месте (Uno, Flutter и другие).

печальная новость, что ничья не появится для 3.3

+1 за это, исходя из фона uwp. Я действительно хочу использовать XF, но у него есть недостатки, в настоящее время я пытаюсь флаттер, но обязательно перейду на XF, если это будет реализовано как можно скорее.

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

Какие-нибудь Новости? Планы? Дорожная карта?

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

@jassmith
Например, Line и Rectangle будут реальными просмотрами? (потому что в примере я вижу Grid с Ellipse в качестве дочернего представления). Буду
Смогу ли я добавить TapGestureRecognizer к Rectangle для обработки события касания?
Поскольку это настоящие представления, не будет ли наличие реальных представлений для рисования примитива вредным для скорости рендеринга?

@andreinitescu Я считаю, что цель состоит в том, чтобы они были реальными представлениями на стороне Xamarin Forms, но никогда не реализовывались как представления изначально:

_примитив рисования — это просто вид, у которого нет рендерера_

Таким образом, средство визуализации, расположенное выше по цепочке ( Drawing ? DrawingTemplate ?) отвечает за итерацию по потомкам, которые можно рисовать, и их отрисовку.

Я предполагаю, что это означает, что будут применяться те же ограничения, которые применяются к макетам с набором CompressedLayout.IsHeadless (без распознавателей жестов, без эффектов, без преобразований и т. д.).

@GalaxiaGuy Я думаю в том же ключе, но нахожу это немного запутанным из-за смешивания с реальными представлениями, такими как Grid. Это действительно необходимо? Вместо производных от View, почему бы не использовать их как абстрактные элементы рисования (может быть, иметь базовый абстрактный класс с именем DrawingElement с общими свойствами?)

Хорошая работа, просто правильный образец

<Button x:Class="Local.MyButton">
  <Button.Template>
    <DrawingTemplate>
      <Drawing>
        <Grid>
          <RoundedRectangle Background="{x:Bind BackgroundColor}" />
          <Ellipse x:Name="TouchFeedback" Opacity="0" />
          <Text Content="{x:Bind Text}" />
        </Grid>
      </Drawing>
    </DrawingTemplate>
  </Button.Template> --> correct this line
</Button>

Может быть, это будет в 4.0?

Drawing хорош тем, что реализует элементы управления с использованием графических примитивов, не зависящих от целевой платформы. Раньше был NControl, но у него были проблемы (со дней до netstandard2.0, до SkiaSharp), и он не обновлялся.

Спецификация 1. дублирует функциональность, уже реализованную в SkiaSharp, в гораздо более полной форме, 2. добавляет ненужные уровни сложности через XAML/Binding, которые входят в и без того непригодный для сопровождения репозиторий Xamarin.Forms.

Лучшим подходом является создание небольшой библиотеки управления на основе SkiaSharp. NControl++

@jassmith @rogihee SVG на самом деле не формат доставки, извините: / Я не хочу нести ответственность за попытки отобразить SVG последовательно на разных платформах.

SkiaSharp поддерживает SVG.

Есть новости об этом?

Есть новости об этом?

Также интересно, если это все еще может произойти. Я очень хочу создать безобразную кросс-платформенную структуру пользовательского интерфейса, и это, кажется, лучший способ добиться этого.

@legistek Вы можете использовать SkiaSharp для некрасивого кроссплатформенного рисования. Каковы, на ваш взгляд, преимущества Xamarin.Forms?

Фреймворк пользовательского интерфейса — это нечто большее, чем рисование.

Но в этой теме обсуждается структура рисования, а не структура пользовательского интерфейса...

Я думал, там обсуждается фреймворк для рисования _for Xamarin Forms_.

SkiaSharp — это среда рисования для Xamarin Forms. Тот факт, что он также работает на других платформах пользовательского интерфейса .Net, безусловно, является преимуществом, а не недостатком.

И, как было сказано в OP, SkiaSharp вполне может быть базовым механизмом рисования на отдельных платформах, но идея этого предложения состоит в том, чтобы добавить уровень абстракции и поддерживать рисование через XAML со всеми его преимуществами, наиболее заметным из которых является привязка данных. То, что вы называете ненужной сложностью, я называю элегантным.

Это все еще живо и/или будет включено в MAUI?

@legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap перечисляет фигуры, контуры и кисти, как в дорожной карте для Xamarin.Forms 4.7.0.

Прекрасные новости! Спасибо!