А как насчет просто .ui?

Может ли это различие быть полезным и для неостровных случаев, или оно будет более запутанным?

Или, если это в первую очередь помогает различать, например, WPF и WinUI Xaml в одном и том же решении, то как насчет соглашения, такого как .winui.xaml или .island.xaml ? Это, вероятно, облегчило бы использование существующих инструментов.

Это будет для сценариев XAML Islands или везде? Для любого другого сценария я не вижу, какова будет ценность этого, кроме создания путаницы и принуждения людей к миграции (и, вероятно, нарушения обратной совместимости для многих инструментов, таких как более старые версии VS). Соглашение вроде «whatever.winui.xaml», вероятно, было бы менее разрушительным, но я все еще вижу его полезным только в рамках острова, а не где-либо еще.

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

Я говорю, продолжайте использовать .xaml. Объем (и имя) WinUi может измениться, чтобы включить другие платформы помимо Windows (может быть, через UnoPlatform?). Что произойдет, если название проекта изменится?

Я больше склоняюсь к НЕТ. Microsoft делает слишком много переименований для продуктов и услуг, иногда в ущерб продукту/услуге или их пользователям (мнение). Это еще одно переименование.

Это будет для сценариев XAML Islands или везде? Для любого другого сценария я не вижу, какова будет ценность этого, кроме создания путаницы и принуждения людей к миграции (и, вероятно, нарушения обратной совместимости для многих инструментов, таких как более старые версии VS). Соглашение вроде «whatever.winui.xaml», вероятно, было бы менее разрушительным, но я все еще вижу его полезным только в рамках острова, а не где-либо еще.

Повсюду

Я думаю, что XAML должен оставаться .xaml , но если появится что-то новое, которое заменит или будет полезно наряду с традиционным XAML, тогда расширение .winui может быть полезным для этого. #804 :)

Этот запрос полностью сбивает меня с толку... Мне пришлось прочитать этот выпуск дважды, чтобы понять, что происходит... Это ДЕЙСТВИТЕЛЬНО фрагментирует экосистему xaml больше, чем когда-либо делали разные диалекты..

Сейчас потерял дар речи...

@liquidboy , ну, это по крайней мере один четкий отзыв в пользу того, чтобы не вносить это изменение :) Спасибо, что предоставили свой голос.

Мне нравится идея от @jesbis , возможно, мы могли бы добавить *.islands.xaml , который помогает легче различать файлы XAML, которые работают в контексте Islands, и нет.

Любопытно: будет ли лучше иметь .islands.xaml , который применяется только к файлам XAML на острове, или просто везде использовать .winui.xaml в качестве общего расширения? Я не уверен, какая из этих двух идей мне больше нравится.

Я голосую за «.islands.xaml» или аналогичный рекомендуемый (но не строго соблюдаемый) шаблон на островах, и везде файлы .xaml по-прежнему являются файлами .xaml. Таким образом, мы избегаем ненужного воздействия на людей, которые не используют острова.

Больше всего меня беспокоит инструментарий. У меня нет проблем с другим расширением, но это означает, что каждый инструмент, использующий расширение файла .xaml, необходимо обновить (я имею в виду такие вещи, как R#, XamlStyler и т. д.). Инструментальная поддержка вокруг xaml уже кажется проблемной, и похоже, что это, скорее всего, усугубит ситуацию.

Мои $0,02

Возможно, название проблемы следует изменить на что-то вроде:
Должны ли файлы XAML, включенные для Xaml Islands, иметь другое расширение файла с проектами WinUI 3?

Я решительно поддерживаю сохранение .xaml там. Может быть, вы выберете .ui.xaml или .xaml.ui, но технология сильна и обеспечивает доступность помощи. С другой стороны, к сожалению, xaml имеет некоторое клеймо после подводных камней производительности wpf, silverlight и windows phone, поэтому более чистое имя файла может помочь изменить ситуацию. Я по-прежнему люблю xaml, но нам не нужна путаница в названиях технологий, если только она не будет четко продумана.

Я думаю, что это хорошая идея, чтобы он был просто как .ui, поскольку, если winui когда-либо станет кросс-платформенным (как многие вещи для Windows), он будет более подходящим.

Это означает, что это будет доказательство будущего.

Файлы кода будут иметь расширение .ui.cs, которое говорит само за себя и легко читается.

.winui.xaml

Значит, у нас будут файлы .winui.xaml.cs? ой..

Используйте формат json. Это 2020 год.

JSON суров и не очень удобен для работы.

Используйте формат json. Это 2020 год.

Формат JSON предназначен для чтения компьютерами, а не людьми. Тяжело читать и выглядит некрасиво.

Я думаю, что .winui заставит новичка сдаться. Потому что мы будем думать, что должны выучить новый язык. И теперь у нас есть WinForms, WPF, UWP, SL, ASP и ASP.NET Core. Мы должны тратить все больше и больше времени, чтобы изучить его, но не наследовать. Я не думаю, что мы всегда должны делать новые технологии.

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

На мой взгляд, более элегантным решением вопроса «какой XAML является какой» было бы зависеть от пространства имен xmlns по умолчанию, как предлагает @grokys в этом комментарии: https://github.com/AvaloniaUI/AvaloniaVS/issues/95# комментарий к

Мы не сделали этого с UWP, но, возможно, мы сможем изменить это для WinUI.

На мой взгляд, более элегантным решением вопроса «какой XAML является какой» было бы зависеть от пространства имен xmlns по умолчанию, как предлагает @grokys в этом комментарии: AvaloniaUI/AvaloniaVS#95 (комментарий)

Мы не сделали этого с UWP, но, возможно, мы сможем изменить это для WinUI.

Вы могли бы ввести эквивалент Doctype, как в случае с HTML?

Вы могли бы ввести эквивалент Doctype, как в случае с HTML?

Возможно, но мы не должны. Пространство имен по умолчанию должно быть тем, что отличает каждую отдельную платформу (в конце концов, они делают это в отделенном коде)

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

@keboo это очень сильно ударило по мне, и это то, что я сильно подталкиваю, чтобы мы исправили и сделали правильно.
Тот факт, что мы находимся в мире, где мы не можем отличить их друг от друга (для сценария с островами), является результатом того, как инструментарий развивался на протяжении многих лет. Все совершенно отдельно, и почти невозможно рационализировать различия между разными диалектами. Я хочу изменить это и начать делать синтаксический анализ и компиляцию XAML чем-то таким, что можно было бы легко использовать во всех диалектах XAML, где в этом примере WinUI и WPF используют один и тот же фундаментальный движок. Инструментарий должен быть совместимым с подключаемым модулем, как объявлено пространством имен по умолчанию, и может быть настроен при необходимости. На мой взгляд, нам не нужно ничего большего, чтобы этот сценарий работал правильно. Хотя это огромное усилие, для меня это правильное решение для всех нас.

@stevenbrix Платформа в настоящее время понимает, когда XAML используется в ситуации с островом, но то, что я прочитал в вопросе об этой проблеме, — это способ для разработчика сказать и понять, как файл .xaml будет использоваться в WinUI 3.0. проект.

Что касается инструментария XAML в целом, он требует полной переделки времени разработки, IMO. Expression Blend был последним разом, когда дизайн и разработка XAML чувствовали себя на высшем уровне.

Из-за природы XAML это и письменная, и визуальная форма. Дизайн Visual XAML отошел на второй план, чтобы довести Intellisense до хорошего качества. Если бы существовал надежный, производительный и простой в прототипировании и доработке опыт проектирования XAML, это могло бы оживить сообщество.

Подход с использованием плагинов, который не требует большой работы от поставщиков элементов управления или инструментов, но при этом дает хорошее время для проектирования, инструментальную палитру и опыт работы со свойствами элементов, может быть очень полезным. Поскольку XAML переходит на другие нетрадиционные форм-факторы, необходимо учитывать рабочий процесс проектирования. Два представления Pane (Neo и Duo), поверхности XAML, размещенные не в окне, интеграция с оболочкой, смешанные проекты фреймворков (острова xaml, миксы GDI и WinUI), Hololens Spatial 3D, вращающиеся концентраторы поверхностей и т. д.

Но, возможно, декларативная разметка больше не является идеальным способом справиться с этим. Или, может быть, должно быть больше разделения между содержимым XAML и стилем XAML? Как с HTML и CSS?

WinUI кажется хорошей возможностью не только сохранить вещи такими, какие они есть, но и спланировать на следующие десятилетия вперед.

Нет. Не вижу смысла. Это ничего не решает.
Во всяком случае, это создает проблемы с редакторами, которые уже знают расширение xaml.
Я работаю с wpf, uwp и формами xaml каждый божий день, и меня никогда не смущало расширение.

Разве весь смысл Xaml не в том, что его проще использовать? Разве инструменты не могут понять это, не полагаясь на древнюю идею расширений файлов?

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

Если бы это был совершенно новый UI-фреймворк, то я бы не видел проблемы.

Я также не знаю, почему вы хотите различать компоненты XAML для островов с помощью предложенного islands.xaml . Будет ли это делать что-то другое в инструментах или это просто для удобства чтения в решении?

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

Если в нем есть файл с xaml, я хочу, чтобы это был файл .xaml. Раньше мне никогда не приходило в голову, что я хочу, чтобы файл UWP .xaml назывался иначе, чем файл WPF .xaml.

Следующее, что имя фреймворка в расширении файла не кажется хорошей идеей, так как имена фреймворков могут измениться, а XAML всегда есть XAML.

Итак, мое мнение: определенно оставайтесь с .xaml.

Но какие есть варианты с расширением файла .xaml?
Другое расширение файла .islands.xaml? Это означало бы, что расширение файла используется не только для описания формата, но и содержимого файла. Ммм... Но преимущество этого в том, что вы можете сделать его необязательным для разработчика. Если они хотят использовать его, они могут назвать свои файлы .islands.xaml, и инструментарий подберет это с помощью различных значков и т. д.

Другое пространство имен по умолчанию также является допустимым вариантом. Но это означало бы, что инструментарий должен просматривать каждый файл .xaml, чтобы выяснить, что это за файл. И это также означало бы, что диалекты XAML снова немного расходятся из-за другого корневого пространства имен.

Но теперь совсем другая мысль:

Если я правильно понял, все эти изменения действительно полезны только для случая XAML Island, когда вы смешиваете платформы в одном решении, верно? Потому что, если вы просто используете WinUI, вы знаете, что каждый файл XAML использует WinUI. Я не уверен, будут ли острова XAML основным сценарием для WinUI или нет. В прошлом, когда был представлен WPF, у нас также было взаимодействие WPF и WinForms, и, честно говоря, я редко видел разработчиков, использующих элементы управления WPF в своих приложениях WinForms. Вместо этого они продолжали использовать WinForms в WInForms и начинали новые проекты с WPF вместо WinForms. И, возможно, то же самое может быть верно для WinUI 3, и я думаю, что так оно и будет. XAML Islands — отличный способ модернизации, но, по моему опыту, разработчики будут делать это только в том случае, если им определенно нужен элемент управления из WinUI в их приложении WPF/WinForms. Если нет, они продолжают использовать старый стек и запускают новые приложения в новом стеке. Обратите внимание, что это не обязательно должно быть правдой, это просто мой опыт. :-)

Это означает, что мы говорим об изменении имени файла для сценария, который может не быть основным сценарием для платформы. И я думаю, именно поэтому я думаю, что это того не стоит. Что, если разработчик WPF/UWP/Silverlight/Windows Phone создаст новый проект WinUI 3? Они будут думать

Какого черта они изменили расширение файла .xaml на ...?

Пожалуйста, не удаляйте расширение файла .xaml.

Пожалуйста, не меняйте расширения!

Много лет назад мы начали использовать расширение .paml в Avalonia, но в конце концов вернулись к .xaml из-за проблем, которые оно вызывало: в IDE уже есть инструментарий для обработки XAML (независимо от того, насколько дерганый , хоть что-то!).

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

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

Затем откройте языковую службу XAML, предоставьте API для взаимодействия с дизайнером, и каждый может получить выгоду;)

Красиво пожалуйста ;)

Еще одна причина не делать этого: UWP уже борется с проблемами внедрения. Переименование продает его как еще одну технологию, а не «это более или менее то же самое, что и wpf».
Уже есть более серьезные проблемы с критическими изменениями WinUI 3.0, которые значительно навредят существующей экосистеме uwp. Не добавляйте еще одну вещь, которая отличается.
Это по-прежнему xaml, просто работающий с разными наборами API, точно так же, как c# остается c#, даже если я использую его для разных фреймворков пользовательского интерфейса. Код и API, которые я могу использовать, изменились, но это все тот же язык.

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

Еще одна причина не делать этого: UWP уже борется с проблемами внедрения. Переименование продает его как еще одну технологию, а не «это более или менее то же самое, что и wpf».
Уже есть более серьезные проблемы с критическими изменениями WinUI 3.0, которые значительно навредят существующей экосистеме uwp. Не добавляйте еще одну вещь, которая отличается.
Это по-прежнему xaml, просто работающий с разными наборами API, точно так же, как c# остается c#, даже если я использую его для разных фреймворков пользовательского интерфейса. Код и API, которые я могу использовать, изменились, но это все тот же язык.

@dotMorten Ха, у меня была такая же мысль с C#. Если мы называем файлы $ .xaml .winui , мы должны называть файлы $ .cs .wincode , чтобы сделать их согласованными. :-)

Может быть, я все еще что-то упускаю, но у меня это вызывает больше путаницы, и я не вижу в этом реальной пользы.

Мои 2 цента, придерживайтесь _.xaml_, пожалуйста.
Пожалуйста, объединяйте вещи, а не разъединяйте их.

Что делать, если вы хотите обмениваться небольшими фрагментами XAML между WPF и WinUI? Я предполагаю, что должно быть НЕКОТОРОЕ совпадение, нет? Это сделало бы совместные проекты менее полезными... или действительно есть огромная разница? Если это в основном тот же аналогичный XAML, сохраните то же расширение. Если формат ПОЧТИ отличается от переходного XAML, то может быть несколько более приемлемым изменить расширение. Тогда реальный вопрос заключается в том, насколько формат близок к оригиналу?

XAML также используется в Xamarin, предназначенном не только для Windows, но и для iOS, Android, macOS...

Замена .xaml на .winui создаст ситуацию, когда Xamarin сохранит .xaml для файлов XAML (зачем использовать .winui для iOS или Android?), а цели Windows, такие как UWP/WPF..., переместятся в .winui для файлов XAML. .

TL; DR один формат файла/соглашение два имени (.winui для Windows, .xaml для Xamarin), меня это сбивает с толку.

Расширение должно быть .xaml , так как синтаксис содержимого — это xaml, другое расширение только создаст путаницу.
Я голосую за что-то вроде .winui.xaml

оставайтесь с ".xaml", это мощный

Должен сказать, у Microsoft проблема с патологическим именованием!

И этот действительно превосходит их всех.

Нет

Если вам нужно иметь UWP XAML и WPF XAML в одном файле проекта, вместо этого используйте новый Custom Tool .

Таким образом, средство определит, использует ли файл XAML UWP XAML или WPF XAML, и отправит их правильному компилятору через цели msbuild.

Еще лучший способ — стандартизировать язык XAML, чтобы мы могли разработать общий компилятор, двоичный формат и библиотеку фреймворка.

Вот так бы я поступил!

Поскольку вы спрашиваете, нет, не делайте этого.

Если инструментарий не может прочитать файл, чтобы увидеть разницу, ХУДШИЙ СЛУЧАЙ должен быть необязательным соглашением «.winui.xaml» или подобным. Опять ключ НЕ ТРЕБУЕТСЯ. Просто файлы расширения xaml должны работать нормально, но, возможно, отсутствуют некоторые расширенные инструменты.

Хотя я понимаю идею, стоящую за этим, я думаю, что это плохое решение.
Во-первых, WinUI — это коммерческое название фреймворка, а не формат файла. Что, если кто-то решит, что версии 4 нужно изменить название на UniversalUI или что-то другое? Вы бы закончили с именем фреймворка, отличным от расширения файла, отличным от формата файла. Это может быть кошмар.

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

В-третьих, это приведет к большей фрагментации языков пользовательского интерфейса, используемых в продуктах Microsoft. Я действительно думаю, что нам нужно больше соответствовать стандарту Xaml, поэтому продукт не так важен. C# одинаков для Xamarin, Net Core, Windows 10 или WPF, почему XAML должен отличаться?

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

Используйте формат json. Это 2020 год.

@rickydatta Даже в 2020 году в Интернете для определения пользовательских интерфейсов используется HTML вместо JSON. Есть много причин, по которым языки разметки, такие как HTML и XAML, отлично подходят для определения пользовательских интерфейсов. JSON отлично подходит для нескольких вещей, но не для определения пользовательских интерфейсов. Когда вы используете JSON для пользовательского интерфейса и пытаетесь создать такие функции, как привязка данных, ссылки на статические ресурсы и т. д., вы увидите, что он становится совершенно нечитаемым. Но здесь это оффтоп, так что оставим это. Если вам нужен JSON, создайте новую задачу и посмотрим, как на нее отреагирует сообщество. :-)

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

Не делай этого.

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

Каковы потенциальные преимущества?

• Это позволит избежать возможной путаницы для людей, у которых есть некоторые файлы .xaml, которые полностью содержат элементы управления WinUI, и некоторые файлы .xaml, которые их не содержат.
• Помогите включить инструменты, чтобы определить, как работать с потенциально другим содержимым файлов .xaml.

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

Каковы потенциальные недостатки?

• Это внесло бы путаницу.
  -- "Что это за новое расширение?" «Что мне нужно, чтобы открыть его?» "Чем это отличается от ...?" "Почему они изменили его?"
  -- Какое расширение вы используете для файла, который содержит только некоторые элементы управления WinUI, при смешивании существующих элементов UWP XAML и WinUI3? Или само это предложение подразумевает, что эта возможность исчезнет? (Видите ли, просто предлагая изменить расширение файла, вы уже вносите больше путаницы и FUD. Если такие вещи, как расширения файлов, все еще могут измениться, возможно, мне следует подождать, пока я смотрю на WinUI в любом качестве, пока он не станет более стабильным. , Несколько человек посоветовали мне исследовать Flutter. Возможно, это лучшее будущее для меня.)
  -- Мое понимание одного из преимуществ Xaml Islands в существующих приложениях WPF заключалось в том, что это означало возможность повторного использования существующих навыков и знаний при работе с XAML. Это изменение предполагает, что дело не только в XAML, так что это еще одна вещь, которую необходимо изучить, и поэтому это еще одно потенциальное препятствие для принятия.)

• Это не нужно.
  -- Если люди хотят разделить файлы в решении, они уже могут сделать это несколькими способами: в разных проектах; разные справочники; префиксы или суффиксы в именах файлов; использование нескольких/подрасширений; или вложение файлов в обозревателе решений VS. Непонятно, чем новое расширение или принуждение всех к использованию нескольких/дополнительных расширений лучше, чем любой из этих вариантов.
  -- [По умолчанию] Пространства имен в файле уже сообщают инструментам, какой диалект XAML используется и что с ним должно быть возможно. (В этой области может быть какая-то недокументированная проблема, которая означает, что это невозможно, но в этом случае требуется дополнительная информация о том, почему изменение расширения файла является лучшим решением этой проблемы.)

• Он игнорирует историю.
  -- Ранее я работал с решениями, которые содержали проекты, ориентированные на WPF, Silverlight и Windows Phone. Все они использовали разные диалекты XAML, но я ни разу не запутался в том, какой из них используется или что я могу делать в файле. Я работал с решениями, содержащими XAML для UWP и Xamarin.Forms, но не сталкивался с путаницей, предсказанной в предположении, стоящем за этой проблемой. Я также разговаривал со многими другими разработчиками с похожими решениями, и я никогда не слышал, чтобы кто-то еще говорил, что им поможет использование других расширений.
  -- Из всех критических замечаний, которые я слышал о различных диалектах XAML, путаница, связанная с именами файлов, никогда не была одной из них.
  -- Разработчики обычно не любят, когда вы указываете им, как они должны называть и структурировать файлы и проекты без веской причины. Может быть гораздо лучше задокументировать руководство и рекомендуемые/предлагаемые практики для таких сценариев, как работа с проектами, содержащими файлы с похожим содержимым.
  -- Одна из важных причин того, что более широкое использование нескольких расширений в файле так и не получило широкого распространения, заключается в том, что File Explorer (или что-либо, что перечисляет содержимое файловой системы, включая предоставляемые ОС средства выбора и диалоговые окна) может внести больше путаницы, когда они ( настроены на то, что по умолчанию) скрывают известные расширения файлов. Это может привести к тому, что MyClass.winui.xaml будет выглядеть как MyClass.winui , что затем приведет к вопросам и путанице в отношении того, что это за файл, откуда он взялся, почему он отображается и т. д.
  -- Добавление нескольких/подрасширений увеличивает длину файла и, таким образом, повышает вероятность возникновения проблем, связанных с MAXPATH. Может быть, однажды это не будет проблемой, но мы еще не там. Я бы не хотел, чтобы разработчики были вынуждены давать своим файлам (и классам, поскольку они обычно синхронизируются) менее описательные имена, потому что инструментарий теперь нуждался в дополнительных шести символах для расширения (расширений).

• Это создает больше работы для разработчиков инструментов. (Как внутри Microsoft, так и за ее пределами.)
  -- Еще дело для обработки.
  -- Больше сценариев для документирования и тестирования.
  -- Меньше времени тратится на исправление ошибок и новые функции. С текущими инструментами XAML, которые считаются отстающими от других технологий и медленными для создания пользовательских инструментов, зачем делать что-то, что замедляет создание новых инструментов?

• Это может создать очень плохой прецедент.
  -- Если это произойдет, почему тогда не будет уместно заменить все текущие файлы .xaml на .wpf , .uwp , .xamarinforms и т. д.? Или .xaml2006 , .xaml20009 , .xaml-uwp5 , если ключевой проблемой является базовое пространство имен, а не то, где они используются? Потенциальная выгода будет минимальной (как в данном случае), но многие воспримут ее как то, как Microsoft предлагает именовать файлы. (Я не удивлюсь, если кто-то не сделал таких предложений, просто увидев обсуждение здесь.)
  -- Я не знаю (но рад, что меня исправили) какие-либо инструменты, предоставляемые MS, обрабатывают файлы по-разному в зависимости от подрасширений, но это, вероятно, заставит Visual Studio (и другие?, включая Windows Shell?) способен справиться с этими сценариями. Затем, как только появится возможность, я могу представить искушение ввести широкий спектр сложных, но в остальном ненужных предложений по именованию, предлагаемых и вводимых, которые будут слишком сложными для некоторых разработчиков, что приведет к путанице для остальных из нас.

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

Спасибо всем за то, что предоставили свой голос. Мы вас услышали! Мы собрали достаточно отзывов, поэтому можем с уверенностью сказать, что менять расширение .xaml — недопустимо .

Мы не собираемся фрагментировать экосистему или ломать сторонние инструменты (а их много). Мы согласны с тем, что XAML — это язык, а WinUI 3 — это платформа пользовательского интерфейса, использующая XAML. По всем этим и другим причинам имеет смысл продолжать использовать расширение xaml.

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

1. Ничего не делать. Опыт разработки XAML Islands будет таким же: файлы XAML в другом проекте (возможно, это не имеет большого значения). WInUI 3 будет использовать то же пространство имен, и это не имеет значения, поскольку это будет единственный язык XAML, используемый в проекте.

2. Используйте пространства имен, чтобы различать пользовательские интерфейсы на основе XAML. Сегодня WPF XAML и UWP XAML используют одни и те же пространства имен, возможно, WinUI 3 следует использовать другое пространство имен, как это делает Xamarin Forms («http://xamarin.com/schemas/2014/forms»), поэтому компиляторы, инструменты и дизайнеры может различать файлы. С другой стороны, это создаст диалекты, хотя это и происходит сегодня. Теоретически это облегчит разработчикам копирование и вставку примеров XAML из документов или блогов, хотя, к сожалению, есть много примеров, которые не включают пространства имен.

3. Сделайте что-нибудь, но только для островов. Нет необходимости различать все UI-фреймворки. Мы можем использовать соглашения. Например, в будущем приложение WPF с островом XAML может содержать файлы XAML в определенной папке (папке острова?). Это похоже на локализацию UWP (Strings/en-US/Resources.resw).

Еще раз спасибо за ваш отзыв . Я открою новые обсуждения, когда мы созреем больше идей.

Включение строки стиля фрагмента или типа документа для файла острова должно быть достаточным для инструментария.

Если вам нравится идея .ui.xaml , потому что это хороший компромисс. Это по-прежнему допустимое расширение XAML, а также может помочь выбрать правильный редактор и значки. Это также более эффективно, чем открывать и анализировать десятки/сотни файлов XAML только для того, чтобы найти нужный тип.

@ marb2000 WinUI 3 — это инфраструктура пользовательского интерфейса, использующая XAML.

Должно быть: WinUI 3 — это платформа пользовательского интерфейса, которая может использовать XAML. Поскольку он не требует использования XAML и не нуждается в зависимости от языка XAML.

Мы согласны с тем, что XAML — это язык

Это хорошо, и многие пространства имен, которые называются XAML, нужно переименовать в WinUI: все, что не связано с языком XAML.

Было болезненно наблюдать снижение акцента на UWP. Теперь, когда вы выполняете поиск контента UWP на канале 9, вы получаете контент Xamarin. Это такая очевидная уловка. Пожалуйста, перестаньте пытаться превратить UWP во что-то другое! Реинвестируйте, удвойте ставку и заставьте ее работать. UWP не нуждается в исправлении курса, ему нужны команды Xamarin и Office, чтобы присоединиться к нему. Внутренняя политика Microsoft убивает UWP.

@Noemata Это официальная записка?