Flutter: ☂ Добавить поддержку UWP

Возможно, пока нет, см. #10881.

Я хотел бы включить себя в этот запрос функции, было бы здорово, если бы Flutter поддерживал Windows 10 UWP.

Это также должно охватывать Xbox One, на который вы можете ориентироваться в Xamarin/UWP.

Да, пожалуйста. Поддержка Windows определенно изменит правила игры.

это не официально, но вы можете проверить этот проект. https://github.com/google/flutter-desktop-embedding Я думаю, что glfw также доступен в Windows, так что вы можете попробовать :wink:

Чувак... я хочу настоящий xplat :)

Я просто набирал тот же запрос функции 😉 ... Надеюсь, это наберет обороты!

Как пользователь с несколькими устройствами Windows, MacOS и Chrome OS в моем доме ... последняя модель Surface Pro неизменно становится моим ежедневным водителем каждый год; с момента выпуска SP4. Кажется, сейчас он чрезвычайно популярен в кампусе и на работе. Тем не менее, скудный выбор качественных приложений UWP продолжает оставаться для меня самым большим больным местом.

Я считаю, что элегантность и простота Flutter потенциально могут обеспечить стимулы, необходимые разработчикам/корпорациям, чтобы включить Win10 в свою мультиплатформенную стратегию... и в процессе, надеюсь, продвигать Flutter до такого же статуса/популярности, как Java; для рассмотрения ИТ-руководителями при выборе инструментов и платформ для разработки продуктов.

Xamarin, Ionic и т. д. включают UWP, так почему Flutter?

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

Удаление из проекта Window MVP. Мы все еще оцениваем UWP в качестве цели и, вероятно, в конечном итоге поддержим ее, но первоначальный акцент делается на том, чтобы позволить Win32 ограничить область применения.

Я думаю, это ошибка. Все платформы, которые не поддерживают uwp, не поддерживаются с 20 января 2020 года. То есть к тому времени, когда это будет готово.

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

Единственным фокусом должен быть uwp, а wpf следует игнорировать.

Все платформы, не поддерживающие uwp, не поддерживаются с 20 января 2020 года.

Решение сосредоточиться в первую очередь на Win32 API носит технический характер, а не основано на целевых платформах.

wpf следует игнорировать

В настоящее время нет планов использовать WPF.

Извините, win32 следует игнорировать.

Почему?

Потому что win32 ограничивает флаттер на платформах Windows. Uwp нет, потому что к тому времени, когда вы это сделаете, не будет поддерживаемых платформ Windows, которые не поддерживают uwp, но есть платформы на Windows, которые не поддерживают win32 (arm64, для которого потребуется полная перестройка)

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

тем не менее, есть платформы на Windows, которые не поддерживают win32 (arm64, для которого потребуется полная перестройка)

Windows 10 на ARM поддерживает Win32, нужно только скомпилировать приложение под ARM64, как в случае с UWP.

Все платформы, которые не поддерживают uwp, не поддерживаются с 20 января 2020 года. То есть к тому времени, когда это будет готово.

Поддержка Windows 8.1 заканчивается в 2023 году. Она не поддерживает UWP.

@stuartmorgan Привет, мне интересно работать над поддержкой UWP.

Вы упомянули выше: «Мы все еще оцениваем UWP как цель» — я хотел бы знать, что вы обнаружили.

Спасибо,
-Джейк

@ Kapranov98 Я только что закончил экспериментировать с переносом флаттера на Windows 10 ARM. Win32/UWP — наименьшая из проблем. Сам Dart требует существенных изменений для работы на WinARM. Специфический код ARM в dart никогда не предназначался для работы в каких-либо системах, кроме posix'ish (ios, android, linux и т. д.). Не говоря уже о том, что WinARM поддерживает только набор инструкций Thumb-2, и, насколько я понимаю, dart jit использует набор инструкций ARM (хотя мне нужно получить официальное подтверждение этого). Заставить порт работать будет довольно значительным усилием.

@Jakesays , вы пытались включить /appcontainer в рамках своих экспериментов?

Вы упомянули выше: «Мы все еще оцениваем UWP как цель» — я хотел бы знать, что вы обнаружили.

Я скоро начну первоначальный документ для сбора информации и свяжу его отсюда. Однако на данный момент не так много деталей (и как только первоначальный документ будет готов, такие вещи, как результаты вашего расследования ARM, будут очень кстати в качестве дополнений). Когда я говорю «все еще оцениваю», я имею в виду, что мы все еще планируем поддерживать его в будущем, и в рамках этого будем оценивать все, что необходимо сделать. Поскольку это не наша цель для первоначального MVP, в настоящее время не так много активных расследований.

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

Изменится ли этот разговор теперь, когда Windows 10 X станет чем-то особенным? Win32 сможет работать в Windows 10 X, но я думаю, что UWP подойдет гораздо лучше. Планирует ли Flutter вообще поддерживать устройства с двумя экранами? Surface Duo и Surface Neo?

@nerocui Насколько я понимаю, Duo — это устройство Android, поэтому я думаю, что Flutter будет работать нормально (по крайней мере, на одном экране). Я не уверен, на каком процессоре работает Neo, но если это ARM, то Flutter в значительной степени мертв в воде. Dart в настоящее время не генерирует совместимый ассемблерный код для winarm (winarm использует исключительно инструкции thumb-2, а IIRC Dart использует как thumb-2, так и инструкции arm). Было бы нетривиальной задачей заставить его работать.

@JakeSays Neo использует Intel Lakefield, так что это x86. Меня больше беспокоит часть истории UWP. На мобильном устройстве, таком как Neo, пригодится управляемый жизненный цикл из модели приложения UWP. Win32 не идеален для времени автономной работы. Кроме того, приложения Win32 на Neo будут работать в контейнере, что плохо скажется на производительности. Ориентация на UWP на самом деле является действительно разумным шагом. И Android, и iOS используют модель управляемых приложений, UWP должен обеспечить большую согласованность. Windows 8 можно в значительной степени игнорировать, ни одна из статистических данных не показывает какой-либо значимой доли рынка.

@nerocui Хорошо, тогда должно быть возможно получить флаттер для целевой UWP. Самая большая проблема — отсутствие поддержки OpenGL в UWP, но ее можно решить, используя ANGLE под флаттером.

Я искал UWP, но моей целью был ARM/WinIOT.

@JakeSays UWP должен подойти для большинства устройств, но для Windows на ARM это головная боль. Как это ни парадоксально, флаттер UWP (если он когда-либо появится) должен оставаться эмулированным на устройствах Windows на базе ARM. Какого уровня завершения вы достигли для порта flutter/uwp?

@nerocui Я перестал работать над этим, как только обнаружил проблему с Dart.

Хотя UWP определенно желательна, Win32 определенно никуда не денется. Недавно Microsoft объявила о добавлении поддержки Win32 в Магазин Windows. Также многие игры продолжают разрабатываться под платформу Win32.

Да, Microsoft принимает приложение Win32 в магазине, и оно широко используется в мире, чем UWP. Приложение Win32 имеет лучшую производительность, но имеет ограничение на потребление батареи. Win32 имеет только 2 состояния «Работает» или «Не отвечает» (зависание), но у UWP больше состояний (более дружественных к мобильным устройствам), таких как «Работает в фоновом режиме» и «Приостановлено».

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle

Аккумулятор важен для мобильного устройства, такого как ноутбук или устройство с Windows 10x.

Это должен быть простой разговор:

По состоянию на 14 января существует 0 поддерживаемых версий Windows, которые не поддерживают UWP.

Существуют основные версии Windows, которые не поддерживают развертывание приложений Win32 в магазине или иным образом.

Win32 — это устаревшая платформа. Если вы поддерживали более старую систему, конечно, это win32. Но флаттер — это совершенно новый код. Нет причин писать его для устаревшего API, который не поддерживается на руке, когда его можно написать для UWP и поддерживать везде, где поддерживается Windows.

Но флаттер — это совершенно новый код.

На самом деле это не так; Я разговаривал с людьми, заинтересованными в сценариях добавления в приложение, позволяющих использовать Flutter в существующих приложениях Win32.

Нет причин писать его для устаревшего API, который не поддерживается на руке, когда его можно написать для UWP и поддерживать везде, где поддерживается Windows.

В комментариях выше уже объяснялось, что поддержка этих устройств — это не просто вопрос Win32 и UWP. Точно так же ограничения песочницы, которые необходимы для некоторых развертываний или моделей распространения, будут применяться к движку, который представляет собой большую существующую кодовую базу, а не разработку с нуля, поэтому здесь тоже есть сложности.

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

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

@stuartmorgan знаете ли вы о каких-либо дискуссиях о решении проблемы ограничений winarm только для большого пальца 2?

@stuartmorgan UWP можно использовать в приложениях win32/Winforms/WPF. XAML Islands просты и хорошо поддерживаются. Win32 не работает на winarm, как указано @JakeSays. Таким образом, ваш аргумент не имеет смысла и не является оправданием для флаттера, нацеленного на устаревший API в случае встраивания флаттера в устаревшие приложения.

Далее для всех НОВЫХ разработок:

База установки Windows 7 падает как камень. В следующем году WinARM собирается резко взлететь вверх. Windows 7 будет занимать <5% рынка Windows (менее 50 миллионов устройств и ни одно из тех, кто платит за программное обеспечение) к июлю по текущим ставкам) и тут же опустится на дно вместе с Windows XP и Vista (почти исключительно из-за встроенных систем, в которых они никогда не развернули бы новое приложение на основе Flutter, не заменив им ОС из-за отсутствия поддержки.

Ваши утверждения и весь этот подход Win32 демонстрируют непонимание того, как версии Windows расширяются, а затем удаляются (до бесконечных версий Windows 10, каждая из которых имеет UWP, поэтому этот поток не имеет значения):

1. Выпущена новая версия, очень медленное внедрение только на новых устройствах и только в потребительском пространстве.
2. (Win 7 => 10) Потребительские устройства обновляются быстрее, и их доля на рынке растет.
3. Рост ограничен техническими фанатами, которые не любят изменений, утверждая, что новая версия хуже старой, хотя это не так.
4. Предприятия продолжают оставаться в стороне, поскольку новая версия завоевывает большую часть потребительского рынка.
5. Microsoft объявляет о прекращении поддержки и исправлений для старой версии Windows, поскольку потребители начинают игнорировать технических специалистов и понимают, что новая версия намного лучше старой. Принятие достигает около 50%.
6. Бизнес из-за давления со стороны пользователей, которым новая версия нравится больше; программное обеспечение, которое лучше работает на новой версии; и надвигающийся крайний срок для устаревания начала развертывания новой версии на замещающем оборудовании. Принятие достигает около 60-65%
7. Дальновидные ИТ-менеджеры начинают контролируемое развертывание новой версии для каждой группы.
8. Крайний срок вырисовывается через несколько месяцев, а остальные ИТ-менеджеры просто забивают его, сетуя на проблемы, потому что они не спланировали это должным образом, и ругают Windows (это технари сверху) за их проблемы. Доля рынка вырастет с 65% до 90% за 6-8 месяцев, когда закончится гонка за крайним сроком поддержки.
9. Остались только встроенные системы, которые доплачивают за исправления безопасности из-за высокой стоимости замены этих систем, аппаратное обеспечение которых было разработано для предыдущей ОС и обычно требует замены аппаратного обеспечения.
10. Встроенные системы начинают взламывать, поэтому предприятия получают выгоду и начинают заменять оборудование.
11. Только люди, которые используют ОС, — это страны третьего мира, которые не могут использовать что-либо еще, и взломать их не проблема.

Мы сейчас на #8. Если разработчики нацеливаются на Windows 7 для нового программного обеспечения, они не знают истории. Развертывание Windows 10 точно следует выпуску Windows 7 до него. Нет никаких причин выбирать #9, потому что они не выпускают основные обновления программного обеспечения даже с добавочными колебаниями в приложениях win32 между выпусками аппаратного обеспечения.

Таким образом:

1. Острова XAML обращаются к вашим добавочным приложениям win32 с аргументом флаттера внутри них. И практически 0% людей, которые на самом деле покупают (а не крадут) программное обеспечение, будут использовать платформу, которая не сможет использовать XAML-остров к сентябрю этого года, как раз к тому времени, когда рабочий стол flutter станет достаточно стабильным для производства.
2. Не существует логического рынка для ориентирования нового приложения на Windows 7. Абсолютно никто, хоть как-то разбирающийся в истории и в том, как работает рынок настольных компьютеров между потребителем и бизнесом, не стал бы писать новое приложение на win32, если бы не было абсолютного блокировщика API (что весьма сомнительно, поскольку сейчас API в значительной степени дублируются). И даже если бы они это сделали, он бы работал в Windows 10, и поэтому нет причин, по которым они не могли бы использовать острова XAML для флаттера в этом приложении win32.

Таким образом, решение флаттера использовать win32 нелепо и показывает полное непонимание рынка Windows. (что неудивительно, к сожалению, выходит из Google)

@JohnGalt1717 JohnGalt1717 Я могу ошибаться, но моя проблема с winarm не имеет ничего общего с win32. Кроме того, и это всего лишь предложение, но вы можете немного отказаться от риторики. Использование таких терминов, как «неосведомленность», и широкомасштабные, необоснованные заявления действительно мешают донести вашу точку зрения.

Заставить Flutter работать на winarm — непростая задача, как неоднократно отмечалось в этой ветке. Заставить Flutter работать на win32 — довольно тривиальная задача, так как для самого флаттера требуются небольшие изменения. Имеет смысл начать с низко висящих фруктов (win32), особенно с учетом того, что наибольший интерес, который я наблюдал в отношении Flutter и Windows, был связан с рабочим столом. Это имеет мало общего с win32 и uwp и больше связано с тем фактом, что реальность такова, что СЕЙЧАС существует МНОГО систем win32.

@JakeSays WinArm не позволяет публиковать приложения win32 в магазине на Arm. (кроме Office) Помимо проблем с компиляцией.

Какая часть моих утверждений не обоснована? Данные на 100% подтверждают мою позицию. К тому времени, когда Flutter для настольных компьютеров будет готов к выпуску в Windows, будет 5% или менее машин Windows, на которых не может работать UWP, и тонна, на которой вы не сможете развернуть приложение win32. (т.е. все устройства ARM, включая Duo или Neo или что-то еще, работающее под управлением Windows, и все версии сторонних производителей, которые расширяются.)

Заставить флаттер работать под UWP, который работает на WinArm, WinX64 и WinX86, не должно быть сложнее, чем на win32. Он также обеспечивает проверку орфографии в текстовых полях и т. Д., Правильное масштабирование на основе DPI без героических действий и улучшенную поддержку культуры из коробки. (не говоря уже о том, что воспроизведение мультимедиа намного лучше и проще, чем в win32. Т.е. я могу тривиально воспроизводить видео в формате widevine, playready, AES, зашифрованное с помощью 3 строк кода в UWP. Сделать то же самое в win32 — это огромное усилие. Не говоря уже о субтитрах). .

В Win32 и UWP нет «низко висящих фруктов». UWP — это рабочий стол. Все остальное — устаревший рабочий стол. (кроме Silverlight, очевидно). Они снова портируют UWP и его API для устаревших платформ, чтобы помочь компаниям не переписывать свои приложения. Они добавили острова XAML именно для описанного варианта использования добавления Flutter к существующим приложениям (и ко всему прочему UWP).

«СЕЙЧАС существует МНОГО систем win32».

Вот как выглядит диаграмма в сентябре: 5% людей, использующих Windows, будут заблокированы к сентябрю. Из этих 5% практически никто из них не покупает программное обеспечение на основе исторических данных. К октябрю 5% пользователей Windows будут использовать его на какой-либо ARM и будут заблокированы от Win32.

Так что выбирай свой яд.

Однако при этом обратите внимание, что количество людей, заблокированных в UWP, будет постоянно уменьшаться, а количество людей, заблокированных в Win32, будет постоянно увеличиваться. Таким образом, вы фактически гарантируете переписывание через 12-24 месяца, если выберете win32 вместо UWP для умирающего рынка, который вы все равно не можете эффективно поддерживать, потому что Microsoft не собирается исправлять ошибки в Windows 7, только безопасность обновления для тех, кто платит за них. (которое все равно не будет использовать приложение с флаттером)

Это также гарантирует, что версия видеоплеера для Windows всегда будет сильно ограничена из-за огромного подъема, необходимого для работы DRM на Win32, не будет встроенной проверки орфографии или автокоррекции для тех, кто использует программную сенсорную клавиатуру. , и культурные вещи будет намного сложнее сделать правильно.

Это называется обратным мышлением.

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

Подскажите, где я на самом деле не прав. И даже если мои предположения и прогнозы немного неверны, скажите мне, почему мое утверждение со временем неверно и менее вредно и требует меньше работы, чем альтернатива, в которой гораздо больше работы, гораздо больше ошибок и гораздо труднее достичь паритета с другие платформы с течением времени для таких вещей, как видео, проверка орфографии и т. д. Неважно, как вы это срежете, к этому времени в следующем году практически никто не будет использовать Windows 7. А это означает, что Flutter будет на 100% доступен практически для всех в любой ситуация, если это делается в UWP, а не в win32. По сравнению с win32, который обслуживает мертвую ОС и блокирует разработчиков флаттера от нового и растущего рынка WinARM.

Например, я могу прямо сейчас в UWP создать видеоплеер со всеми функциями текущего видеоплеера, а также субтитры и DRM в UWP за несколько минут с отличной документацией, которую Flutter может использовать как часть флаттер видеотека. Я точно знаю, что прямо сейчас они работают над субтитрами и DRM для флаттер-видеоплеера. И мне не нужно ничего знать, кроме звонков UWP. Это означает, что обеспечить полную функциональность видео во Flutter с UWP тривиально, и это может сделать почти любой C#, который представляет собой огромную группу людей по сравнению с теми, кто знает, как использовать C++, создавать поверхности DirectX и создавать кодировщики/декодеры/транскодеры мультимедиа и подключи все это. (да, в win32 невозможно воспроизвести множество форматов без пользовательских библиотек, которые поддерживаются в UWP «из коробки»). количество времени.

То же самое верно для последовательной связи, Bluetooth, отслеживания местоположения и т. д. и т. д. и т. д. (и API-интерфейсы отслеживания местоположения и датчиков только сейчас, в Windows 10 2020/H1, подходят к win32 и не будут работать в предыдущих версиях Windows). 10, поэтому вы полагаетесь на то, что каждый, кто использует самую последнюю версию Windows 10, даже получит доступ к этой функции, в отличие от 100% пользователей в Windows 10, имеющих доступ к функциям UWP для этих API.) Назовите свои функции, которые вы считаете само собой разумеющимся. с плагинами для флаттера для Android/iOS, и вы увидите то же самое: их реализация тривиальна в UWP по сравнению с win32, и поэтому у вас гораздо больше шансов реализовать их в UWP, чем если бы вы написали флаттер для рабочего стола в win32, кроме все остальные вопросы.

@JakeSays Все еще жду, когда ты продемонстрируешь что-нибудь неуважительное (или неправильное) из того, что я сказал. Из того, что я могу сказать, вам просто не нравится слово, которое я употребил правильно. И, самое главное, я использовал его абстрактно, а не против вас или кого-то еще лично. Это не была атака с использованием омонимов.

@stuartmorgan знаете ли вы о каких-либо дискуссиях о решении проблемы ограничений winarm только для большого пальца 2?

@JakeSays Я не следил за обсуждениями на уровне компилятора Dart; Я не в курсе дискуссий о поддержке ARM, но это не значит, что их нет. Вам обязательно следует подать запрос на функцию Dart, если вы еще этого не сделали.

Самая большая проблема — отсутствие поддержки OpenGL в UWP, но ее можно решить, используя ANGLE под флаттером.

Текущее встраивание Windows уже использует ANGLE, и Джеймс экспериментировал с поддержкой UWP с первых дней своей работы над этим встраиванием, так что это уже идет полным ходом.

@stuartmorgan Я сделаю это.
И да, я забыл, что программа для встраивания Windows использует ANGLE.

@JohnGalt1717 , пожалуйста, ознакомьтесь с нашим Кодексом поведения . Стандарты сообщества Flutter требуют профессионального и уважительного общения и активных действий, чтобы люди чувствовали себя желанными.

Есть много увлеченных и талантливых людей, работающих над Flutter, и много веских причин, чтобы продолжать или не заниматься определенной линией развития. Я могу сказать, что вы увлечены работой Flutter над UWP. Как и другие. Некоторые также увлечены тем, чтобы заставить его работать на win32. Это проект с открытым исходным кодом, все, что нужно для его реализации, — это взносы. В то же время, пожалуйста, не предполагайте, что участники, работающие над альтернативными путями, невежественны, тратят время впустую или думают отсталыми.

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

/cc @timsneath @Hixie

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

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

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

Если вы чувствуете себя оскорбленными заявлениями, сделанными не о вас, мне жаль, что вы так себя чувствуете. Возможно, решение состоит в том, чтобы серьезно отнестись к моей позиции, подумать над ней логически и продемонстрировать, что вы действительно приняли во внимание эти факты и не игнорируете их, и у вас есть какой-то долгосрочный план того, как win32 будет работать на окнах, требующих store, и этот магазин не позволяет публиковать приложения win32 arm. И что накладные расходы на использование win32 гарантируют, что Windows всегда будет отставать от других платформ, поскольку вы сокращаете количество возможных участников на 90+% с этим выбором. Тогда было бы ясно, что вы не невежественны и не мыслите отстало, и поэтому то, что я сказал, не должно вас оскорблять.

Вместо этого я получаю «Я обижен (на что-то, не направленное на меня), поэтому вы не правы». Что не является аргументом в любом споре.

Учитывая, что ни одна из моих позиций не была рассмотрена, независимо от того, как она была сформулирована, ясно, что флаттер вряд ли когда-либо станет жизнеспособным решением для Windows и позволит паритет приложения, написанного для iOS, Android и Windows. Это гарантирует, что моя команда не будет использовать флаттер, как планировалось, в нашем следующем проекте, поскольку вы вынуждаете нас использовать как минимум 2 фреймворка (и, следовательно, как минимум 2 языка программирования) в результате этого решения, поэтому я мог бы также выбрать путь к совершенству вместо компромисса, даже если есть больше накладных расходов.

Джеймс экспериментировал с поддержкой UWP с первых дней своей работы над этим внедрением, так что это уже идет полным ходом.

@stuartmorgan @clarkezone Есть ли общедоступный пример запуска Flutter на UWP? Я хотел бы попробовать это, даже если это на очень ранних стадиях.

В настоящее время я работаю над прототипом поддержки UWP. Это еще очень рано (например, я еще не видел пикселей), но у меня есть план, как это сделать. Это будет зависеть от незначительной поправки к предыдущему изменению Angle, которое я сделал. Я закодировал это, но еще не отправил Angle. Отказ от ответственности: это не является обязательством выпустить что-то, это все еще исследование того, что возможно. Я сообщу здесь, когда добьюсь более интересного прогресса (например, пикселей).

Спасибо за оперативный ответ @clarkezone

Я нашел в вашем форке FDE ветку под названием uwptest . Это тот, над которым вы экспериментируете? Я хотел бы следить за вашими обновлениями на этом маршруте.

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

Привет, @clarkezone! Могу я спросить, ваша работа поддерживается Microsoft? Можем ли мы ожидать, что Microsoft поддержит Flutter для создания приложений для Windows? Если да, есть ли планы сделать UI Fabric доступной для Flutter?

Я думаю, что в последнее время все больше и больше интереса к созданию красивого корпоративного программного обеспечения для повышения вовлеченности/удовлетворенности сотрудников. Сейчас я работаю над рядом таких проектов. Совсем недавно мы выпустили Android-приложение на базе Flutter для одной из финансовых компаний Большой четверки. Хотя эти предприятия, как правило, используют C# и Xamarin для своего внутреннего программного обеспечения, они ожидают более высокого качества пользовательского интерфейса для своих мобильных приложений на рабочем месте — и в этом случае Flutter оказывается лучшим вариантом. В то же время Microsoft производит отличные устройства, используемые в корпоративной среде, на которых можно запускать приложения Flutter, поэтому было бы здорово получить дополнительную поддержку от Microsoft и/или Google, чтобы это произошло.

Привет Лукаш. Моя работа не поддерживается MS, она выполняется на личной основе в свободное время. Согласен по остальным пунктам точно. FWIW Я добился довольно хорошего прогресса, у меня есть прототип Flutter runner, работающий от начала до конца для вывода / рендеринга (пока нет ввода), большая / следующая задача, над которой я сейчас работаю, - это правильно связать все, не вытягивая в user32/gdi32 и т. д. этот шаг необходим, чтобы иметь возможность успешно увидеть запуск прототипа на устройствах, отличных от настольных, таких как XBOX, эмулятор Windows 10x, и оказывается (еще одним) бритьем яка :-)

Пожалуйста, добавьте Магазин Windows !!!!

@ daniele777 это то, над чем я работал ;-) Обновление статуса: с 84 ошибок компоновщика до 10

Могу ли я помочь ?? улучшить проект ?? можешь сделать мне задание?

@ daniele777 daniele777 сейчас нет, базовый PoC все еще работает. Ошибки компоновщика устранены, но есть проблема сборки при вызове Dart, попадающем в бесконечный цикл в конвейере сборки. Есть и другие проблемы. Я собираюсь в отпуск на пару недель, поэтому какое-то время не будет никакого прогресса, но как только я вернусь, и мы пройдем фазу PoC, могут быть параллелизуемые элементы, о которых я сообщу здесь в этом случае.

ладно всего хорошего!

Не могу дождаться, когда это прибудет сюда раньше. Я попробовал текущий флаттер на основе win32 в Windows. OMG, рендер настолько пикселизирован, что выглядит как современный дизайн, но реализован с использованием фреймворка 10-летней давности. Это не то, что можно было бы ожидать увидеть на экране 4k. Привыкнув к плавным краям текста в приложениях UWP и современных веб-приложениях, рендеринг win32 выглядит крайне устаревшим.

@nerocui - если вы видите пиксельный рендеринг в Windows, это, скорее всего, другая ошибка, которую нельзя исправить простым переходом на UWP. Не могли бы вы создать новую проблему с инструкциями по воспроизведению (и, возможно, снимком экрана с пикселизацией)?

@dnfield Это не похоже на пикселизацию изображений. Просто текст и форма рендерятся (похоже) без аппаратного ускорения, поэтому края не выглядят гладкими. Это происходит со многими программами win32, которые я вижу. Шагов воспроизведения нет, так как это просто текст и кнопка на странице шаблона по умолчанию.

@nerocui Это потому, что приложения win32 не имеют надлежащего масштабирования DPI по сравнению с UWP. ВОЗМОЖНО, проделав ТОННУ работы, заставить рендеринг текста win32 работать правильно, но это ОЧЕНЬ сложно.

@ JohnGalt1717 Спасибо, это именно моя точка зрения. Flutter должен создавать красивые кроссплатформенные приложения, но win32 — это единственная вещь, которая делает приложения уродливыми. Из-за этого реализация флаттера в Windows выглядит хуже, чем на других платформах.

win32 — единственная вещь, которая делает приложения уродливыми.

Как сказал @dnfield , это крайне маловероятно. Рендеринг текста Flutter полностью выполняется Skia в (правильно масштабированном для DPI) контексте GL. Создание контекста GL с помощью API-интерфейсов UWP не изменит отрисовку.

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

Это может быть так же просто, как встраивание где-то, например, игнорирование флага сглаживания. Но без шагов для воспроизведения мы не можем сказать.

https://github.com/flutter/flutter/issues/53308
Поданная проблема. Пожалуйста, посмотрите, является ли это точной/достаточной информацией.

Я предполагаю, что если вы установите DPI на 150% или хуже 175% и загрузите текст, вы его увидите.

Пожалуйста, прекратите публиковать здесь подробности рендеринга; согласно моему объяснению выше, это не связано с этой проблемой и, следовательно, не по теме.

готовы к публикации в магазине Windows? какие-нибудь Новости?

Нет, не готов к публикации в магазине. Пиксели и ввод работают на XBOX и Windows 10x. Все еще итерации по API. Еще много работы осталось.

Я думал о несколько другом подходе — я еще не пробовал, но могу попробовать, если найду свободное время — как насчет использования Flutter для Интернета с Skia WASM на рабочем столе (который может поддерживаться Blazor)? Я могу считать ограниченный доступ к вводу-выводу одним недостатком, но фактический рендеринг пользовательского интерфейса и обработка событий должны работать так, как ожидалось. Похоже, что Windows хорошо поддерживает PWA (как и Chrome OS), и этот подход может быть легче реализовать, но при этом он обеспечивает хорошую производительность.

@lukaszciastko нет, это будет еще один Электрон. Flutter должен отображаться в собственном окне Windows (HWND), которое, в свою очередь, может быть встроено в любое родное приложение Windows (win32, Winforms, wpf).
ИМХО uwp не следует рассматривать как основное приложение для Windows. Даже MS этого не сделал.

@clarkezone Мне не терпится увидеть, как ваша работа будет включена в проект, чтобы мы могли запускать приложения для Windows.

так что мы можем приложения, которые работают в Windows

Уже некоторое время можно запускать приложения Flutter в Windows . Эта проблема теперь касается конкретно UWP.

Я обновлю заголовок, чтобы было понятнее.

так что мы можем приложения, которые работают в Windows

Уже некоторое время можно запускать приложения Flutter в Windows. Эта проблема теперь касается конкретно UWP.

Я обновлю заголовок, чтобы было понятнее.

Стюарт, я нигде не видел документации о том, как создавать и запускать приложения Flutter в Windows. Подскажите, пожалуйста, где я могу найти эту информацию?

@steskalja У вас есть документ здесь https://github.com/flutter/flutter/wiki/Desktop-shells#create
В резюме вы должны быть в ветке master и запустить:
flutter config --enable-windows-desktop

В проекте, который вы хотите попробовать:
flutter create . // Добавим папку windows, будьте осторожны с изменениями в папках android и ios,
flutter run -d windows

Точнее, мои мысли об этом разработчике. Остается надеяться, что есть какая-то связь с Project Union. Я люблю флаттер и так счастлив, что этот SDK стал вещью. Меня беспокоит будущее приложений Win32 в ОС Windows.

Какая база знаний у команды флаттера?

Когда вы закончите с этим, означает ли это, что мы можем реализовать плагины Flutter на C# и использовать из плагинов любые API, SDK и пакеты NuGet, доступные для приложений UWP?

@kinex Мне любопытно узнать, почему вы думаете, что это связано. Добавление поддержки .net для подключаемых модулей было бы относительно простым и не требовало бы UWP. Хотя это как-то выходит за рамки флаттера.

@JakeSays Насколько я понимаю, среда выполнения (в данном случае UWP) определяет, как создаются плагины и что доступно для плагинов. Так что, возможно, ответ на мой вопрос «конечно», но я не совсем уверен.

В плагинах для Android вы можете использовать Kotlin (или Java) и любые Android API, SDK и пакеты. В плагинах iOS вы можете использовать Swift (или Objective-C) и любые iOS API, SDK и Pods. Я ожидаю того же от UWP, и это сделает его действительно потрясающим.

Мы намерены упростить использование C# в подключаемых модулях, но это ортогонально поддержке UWP.

Запуск UWP означает возможность использовать специфичные для UWP API-интерфейсы в подключаемых модулях, но, насколько я понимаю, очень немногие API-интерфейсы на самом деле специфичны для UWP (например, согласно этой документации «Общее правило заключается в том, что настольное приложение может вызывать универсальную платформу Windows). (UWP) API."

@stuartmorgan На самом деле это неправда. В конце концов, с воссоединением проекта, это БУДЕТ правдой, но сейчас это не так, и даже тогда это касается устаревшего программного обеспечения, а не новых приложений, как в случае с флаттером. Существует огромное количество вещей, которые вы не можете сделать без UWP (например, доступ к плагинам для различных видеокодеков, видеоплееру DRM и т. д.), поэтому у меня всегда были проблемы с подходом, который использует команда флаттера. . Существует 0 операционных систем, поддерживаемых Microsoft (и, следовательно, безопасных), которые не могут запускать UWP на рынке (т.е. нацеливание на Windows 7 нелепо и не должно быть целью Flutter, целью должна быть только Windows 10). Таким образом, есть 0 причин, по которым это не должно быть нативным UWP с первого дня.

Хуже того, все Windows 10 S и варианты НЕ МОГУТ запускать приложения win32, поэтому флаттер будет заблокирован от них. Они также будут заблокированы на устройствах ARM/ARM64, если только они не работают в UWP, а Windows X, которая запускает приложения win32 в контейнере докера с использованием удаленного рабочего стола, в результате будет иметь значительно худший опыт, чем собственные приложения UWP, особенно когда речь идет о производительность графики.

Таким образом, если бы google/flutter думали о будущем с поддержкой Windows, это был бы полностью UWP с первого дня, который позволяет C++ и .NET (подавляющее большинство разработчиков Windows используют .net, а не C++) И поддерживает все текущие И будущие устройства Windows с лучшими возможная интерактивность. Нынешний подход win32 является недальновидным и плохо изученным (что указывает на действительно огромное слепое пятно в Google, что вызывает обеспокоенность, учитывая более миллиарда устройств, работающих под управлением Windows).

Учитывая, что Skia уже работает на UWP, очень мало причин, по которым это не было бы средой де-факто и центром 100% усилий Google в Windows. (и действительно, работа с Microsoft, чтобы получить все удаленные симуляторы Xamarin и прямое развертывание на устройствах iOS в Windows)

@ JohnGalt1717 Вы уже несколько раз приводили этот аргумент в этом выпуске; повторять это неконструктивно. Если вы хотите ускорить разработку поддержки UWP, вы можете внести в нее свой вклад.

@stuartmorgan Мне было бы любопытно узнать, что вы думаете об использовании С#. У меня есть несколько идей, как заставить это работать.

@kinex на самом деле плагины флаттера — это, по сути, просто код C, который взаимодействует с флаттером через простой API. Чтобы написать их на C #, в основном потребуется «плагин .net», написанный на C, который будет размещать CLR и соединять мир флаттера и С#. Теоретически было бы возможно написать плагины флаттера на java для Windows или на любом языке, если языковая среда может работать в целевой операционной системе.

@JakeSays Я подал https://github.com/flutter/flutter/issues/64958 с моими текущими мыслями о C#, поскольку я, по-видимому, никогда не регистрировал их здесь. Любой, кто интересуется конкретно C#, должен следить за этой проблемой.

@JakeSays Хорошо, спасибо за разъяснение. Без дополнительных знаний я предположил что-то вроде этого: плагины C# (возможно, реализованные как библиотеки .NET?) будут загружаться исполнителем UWP, и код Dart может вызывать их через процесс запуска UWP. В этой воображаемой архитектуре эти подключаемые модули C# могут получать доступ к тем же API, SDK и пакетам NuGet, что и любая библиотека .NET, размещенная в приложении UWP.

В любом случае, приятно знать, что есть планы относительно поддержки C#. Я считаю, что будет больше авторов плагинов (=больше плагинов быстрее) и более стабильные плагины, если можно будет использовать C# вместо C++.

@kinex , вы правы в том, что плагины С# будут иметь доступ к полному набору библиотек .net, а также к пакетам nuget. Когда код С# выполняется, он работает в полной среде .net (или в ядре .net, в зависимости от обстоятельств).

FFI — гораздо более легкое решение для плагинов. См., например, https://pub.dev/packages/win32 . Но это далеко не тема для вопроса, который якобы касается создания бегуна на основе UWP.

@timsneath Я думаю, что ffi и плагины решают две разные проблемы. iirc есть много ограничений на то, что вы можете делать с ffi (например, это синхронно).

Опять же, я зарегистрировал # 64958 для плагинов C #; пожалуйста, продолжайте любое обсуждение, касающееся C#, но не UWP.

приятные вещи происходят
кто-то должен попросить Microsoft внести свой вклад и здесь

@ airbus5717 что ты имеешь в виду? Microsoft постоянно участвует в обсуждениях.

Я подумал, что стоит поделиться сентябрьским обновлением 2020 года о состоянии эксперимента Flutter UWP, над которым я работаю. Прогресс был медленнее, чем мне хотелось бы, так как это проект в свободное время / с максимальными усилиями, над которым я работал только по вечерам и в выходные дни. Тем не менее, я смог добиться приличного прогресса за последние шесть месяцев или около того и заставить работать некоторые сценарии, а именно:

• экспериментальный модуль WinRT Flutter для внедрения с использованием CoreWindow в сочетании с входными API WinRT, работающими в изолированной программной среде AppContainer: https://github.com/clarkezone/engine
• соответствующий тестовый запуск Flutter UWP (всего 115 строк C++!) с демо-версией Flutter с использованием Flutter Gallery : https://github.com/clarkezone/fluttergalleryuwp
• с их помощью я смог успешно опубликовать пакетную версию MSIX Flutter Gallery в Microsoft Store, пройдя проверки WAC API для сертификации магазина (наконец-то :-))

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

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

В приведенном ниже примере я смог взять исходный код часов Flutter Particle с https://github.com/miickel/flutter_particle_clock , построить его в режиме выпуска для Windows, взять полученный двоичный файл app.so , упаковать его для UWP, использующий тот же Flutter Runner, который использовался выше для Flutter Gallery, опубликуйте в Microsoft Store и установите на свой XBOX: