Flutter: ☂ UWP 지원 추가

아마도 지금은 아닐 것입니다. #10881을 참조하십시오.

이 기능 요청에 저를 포함시키고 싶습니다. Flutter가 Windows 10 UWP를 지원했다면 정말 좋았을 것입니다.

여기에는 Xamarin/UWP에서 대상으로 지정할 수 있는 Xbox One도 포함되어야 합니다.

예, 부탁합니다. Windows 지원은 확실히 게임 체인저가 될 것입니다.

이것은 공식적인 것은 아니지만 이 프로젝트를 확인할 수 있습니다. https://github.com/google/flutter-desktop-embedding glfw Windows에서도 사용할 수 있으므로 시도해 볼 수 있다고 생각합니다.wink:

이봐... 난 진짜 xplat을 원해 :)

방금 동일한 기능 요청을 입력하고 있었습니다 😉... 이것이 관심을 끌기를 바랍니다!

집에 여러 Windows, MacOS 및 Chrome OS 장치를 사용하는 사용자로서... 최신 모델인 Surface Pro는 결국 매년 제 데일리 드라이버가 됩니다. SP4가 출시된 이후로. 현재 캠퍼스와 직장에서도 매우 인기가 있는 것 같습니다. 그러나 고품질 UWP 앱의 부족 선택은 계속해서 나에게 가장 큰 골칫거리입니다.

저는 Flutter의 우아함과 용이함이 다중 플랫폼 전략에 Win10을 포함하기 위해 개발자/군단이 필요로 하는 인센티브를 잠재적으로 제공할 수 있다고 믿습니다... 그리고 그 과정에서 Flutter를 Java와 유사한 상태/인기까지 홍보할 수 있기를 바랍니다. 제품 개발을 위한 도구 및 플랫폼을 선택할 때 IT 임원을 고려합니다.

Xamarin, Ionic 등에는 UWP가 포함되어 있는데 왜 Flutter인가요?

이것은 매우 포괄적인 버그이기 때문에 할당을 제거합니다. 특정 하위 작업은 개별 버그에서 추적되며 평소와 같이 특정 담당자와 이정표가 표시됩니다.

Window MVP 프로젝트에서 제거. 우리는 여전히 UWP를 대상으로 평가하고 있으며 결국 지원할 예정이지만 초기 초점은 Win32가 범위를 제한할 수 있도록 하는 것입니다.

나는 이것이 실수라고 생각한다. uwp를 지원하지 않는 모든 플랫폼은 2020년 1월 20일 현재 지원되지 않습니다.

현재 대규모 마이그레이션이 공격적으로 진행되고 있기 때문에 필요하지 않은 경우 레거시 플랫폼을 지원하는 것은 무의미합니다.

유일한 초점은 uwp여야 하고 wpf는 무시되어야 합니다.

uwp를 지원하지 않는 모든 플랫폼은 2020년 1월 20일부터 지원되지 않습니다.

먼저 Win32 API에 집중하기로 한 결정은 대상 플랫폼을 기반으로 하는 것이 아니라 기술적인 것입니다.

wpf는 무시해야 합니다

현재 WPF를 사용할 계획은 없습니다.

죄송합니다. win32는 무시해야 합니다.

왜요?

win32는 Windows 플랫폼에서 플러터를 제한하기 때문입니다. Uwp는 uwp를 지원하지 않는 지원되는 Windows 플랫폼이 없을 것이기 때문에 Uwp는 그렇지 않습니다. 그러나 Windows에는 win32(완전히 재구축이 필요한 arm64)를 지원하지 않는 플랫폼이 있습니다.

분명히, UWP 지원을 위한 노력에 관심이 있는 사람이라면 누구나 환영하며 그렇게 하는 것이 좋습니다.

그러나 win32를 지원하지 않는 Windows 플랫폼이 있습니다(완전히 다시 빌드해야 하는 arm64).

ARM의 Windows 10은 Win32를 지원하므로 UWP의 경우와 마찬가지로 ARM64에서 애플리케이션을 컴파일하기만 하면 됩니다.

uwp를 지원하지 않는 모든 플랫폼은 2020년 1월 20일 현재 지원되지 않습니다.

Windows 8.1 지원은 2023년에 종료됩니다. UWP는 지원하지 않습니다.

@stuartmorgan 안녕하세요 UWP 지원 작업에 관심이 있습니다.

위에서 "UWP를 여전히 대상으로 평가하고 있습니다"라고 언급하셨습니다. 무엇을 발견했는지 알고 싶습니다.

감사 해요,
-제이크

@Kapranov98 방금 Windows 10 ARM에 플러터를 이식하는 실험을 마쳤습니다. Win32/UWP는 가장 적은 문제입니다. Dart 자체를 WinARM에서 실행하려면 상당한 변경이 필요합니다. dart의 ARM 특정 코드는 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는 듀얼 스크린 장치를 전혀 지원할 계획입니까? 서피스 듀오와 서피스 네오?

@nerocui 내가 알기로는 Duo는 안드로이드 장치이므로 Flutter가 (적어도 한 화면에서) 잘 작동할 것이라고 상상합니다. Neo가 실행 중인 CPU는 확실하지 않지만 ARM이라면 Flutter는 거의 죽었습니다. Dart는 현재 winarm에 대해 호환되는 어셈블리 코드를 생성하지 않습니다(winarm은 thumb-2 명령어만 사용하고 IIRC Dart는 thumb-2 및 arm 명령어 모두 사용). 그것을 작동시키는 것은 사소한 일이 아닐 것입니다.

@JakeSays Neo는 Intel Lakefield를 사용하므로 x86입니다. 나는 이야기의 UWP 부분에 대해 더 걱정하고 있습니다. Neo와 같은 모바일 장치에서는 UWP 앱 모델의 관리되는 수명 주기가 유용합니다. Win32는 배터리 수명에 적합하지 않습니다. 또한 Neo의 win32 앱은 컨테이너에서 실행되므로 성능이 저하됩니다. UWP를 대상으로 하는 것은 실제로 매우 현명한 조치입니다. Android와 iOS 모두 관리되는 앱 모델을 실행하므로 UWP는 더 많은 일관성을 제공해야 합니다. Windows 8은 거의 무시할 수 있으며 어떤 통계도 의미 있는 시장 점유율을 보여주지 않습니다.

@nerocui Ok 그러면 대상 UWP로 플러터를 얻을 수 있어야 합니다. 가장 큰 문제는 UWP에서 OpenGL 지원이 부족하지만 Flutter 아래에서 ANGLE을 사용하여 해결할 수 있어야 합니다.

UWP를 찾고 있었지만 타겟은 ARM/WinIOT였습니다.

@JakeSays UWP는 대부분의 장치에 적합해야 하지만 Windows on ARM에서는 골치거리입니다. 아이러니하게도 UWP(만약 출시된다면) 플러터는 ARM 기반 Windows 장치에서 계속 에뮬레이트되어야 합니다. flutter/uwp 포트의 완성도는 어느 정도입니까?

@nerocui Dart 문제를 발견한 후 작업을 중단했습니다.

UWP가 확실히 필요하지만 Win32는 확실히 아무데도 가지 않습니다. Microsoft는 최근 Windows Store에 Win32 지원을 추가한다고 발표했습니다. 또한 많은 게임이 Win32 플랫폼에서 계속 개발되고 있습니다.

예, Microsoft는 Store에서 Win32 앱을 허용하며 UWP보다 전 세계적으로 널리 사용됩니다. Win32 앱은 최고의 성능을 가지고 있지만 배터리 소모에 제한이 있습니다. Win32에는 실행 중 또는 응답하지 않음(정지) 상태가 2개뿐이지만 UWP에는 백그라운드에서 실행, 일시 중단과 같은 더 많은 상태(모바일 장치에 더 친숙함)가 있습니다.

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

배터리는 노트북이나 Windows 10x 장치와 같은 모바일 장치에 중요합니다.

이것은 간단한 대화여야 합니다.

1월 14일 현재 UWP를 지원하지 않는 지원되는 Windows 버전은 0개입니다.

상점이나 다른 곳에서 배포되는 win32 앱을 지원하지 않는 Windows의 주요 버전이 있습니다.

Win32는 레거시 플랫폼입니다. 이전 시스템을 유지 관리했다면 확실히 win32입니다. 그러나 flutter는 완전히 새로운 코드입니다. UWP용으로 작성될 수 있고 Windows가 지원되는 모든 곳에서 지원되는 경우 arm에서 지원되지 않는 레거시 API용으로 작성할 이유가 없습니다.

그러나 flutter는 완전히 새로운 코드입니다.

이것은 실제로 그렇지 않습니다. 기존 Win32 애플리케이션에서 Flutter를 채택할 수 있도록 하는 앱 추가 시나리오에 관심이 있는 사람들과 이야기를 나눴습니다.

UWP용으로 작성될 수 있고 Windows가 지원되는 모든 곳에서 지원되는 경우 arm에서 지원되지 않는 레거시 API용으로 작성할 이유가 없습니다.

위의 설명은 이미 이러한 장치를 지원하는 것이 Win32 대 UWP의 간단한 문제가 아니라고 설명했습니다. 마찬가지로 일부 배포 또는 배포 모델에 필요한 샌드박싱 제한 사항은 미개발 개발이 아닌 기존의 대규모 코드베이스인 엔진에 적용되므로 복잡성도 있습니다.

이 인수는 또한 지원되는 버전이 아닌 설치 기반에 신경을 쓰는 새 코드를 개발하는 많은 사람들이 있다는 사실을 무시합니다. 현실은 Windows 7이 여전히 설치 기반의 매우 중요한 부분이며 가까운 장래에 크게 바뀌지 않을 것이라는 점입니다.

UWP를 지원해야 하는 충분한 이유가 있으며, 여러 번 말씀드린 것처럼 앞으로도 지원할 계획입니다. 그러나 결정이 간단하다고 주장하기 위해 관련된 절충안을 지나치게 단순화한다고 해서 그 과정이 가속화되지는 않을 것입니다. 다시 말하지만, UWP 지원에 대해 강하게 느끼는 사람이라면 누구나 UWP 포함 개발에 기여하는 것을 환영합니다.

@stuartmorgan winarm 의 thumb 2 전용 제한 사항에 대한 솔루션에 대한 논의를 알고 있습니까?

@stuartmorgan UWP는 win32/Winforms/WPF 응용 프로그램에서 사용할 수 있습니다. XAML 아일랜드는 간단하고 잘 지원됩니다. Win32는 @JakeSays가 설명한 대로 winarm에서 작동하지 않습니다. 따라서 귀하의 주장은 의미가 없으며 레거시 앱에 플러터를 포함하는 경우 레거시 API를 대상으로 하는 플러터가 정당화되지 않습니다.

모든 새로운 개발을 위한 추가 사항:

Windows 7 설치 기반이 돌처럼 떨어지고 있습니다. WinARM은 내년에 대대적으로 상승할 예정입니다. Windows 7은 현재 요율로 7월까지 Windows 시장의 5% 미만(장치 5천만 대 미만, 소프트웨어 비용을 지불하는 장치 없음)이 될 것이며 Windows XP 및 Vista와 함께 바닥에서 반등할 것입니다(거의 전적으로 다음과 같은 임베디드 시스템 때문입니다). 그들은 지원 부족으로 인해 OS를 교체하지 않고 새로운 Flutter 기반 응용 프로그램을 출시하지 않을 것입니다.

귀하의 진술과 Win32에 대한 이 전체 접근 방식은 Windows 버전이 확장된 후 삭제되는 방식을 이해하지 못하는 것을 보여줍니다(Windows 10의 끝없는 수정 이전에는 모두 UWP가 있으므로 이 흐름은 관련이 없음).

1. 새 버전이 출시되었으며 새로운 장치에서만 매우 느리게 채택되고 소비자 공간에서만 적용됩니다.
2. (Win 7 => 10) 소비자 장치는 더 빨리 업데이트되고 시장 점유율이 증가합니다.
3. 변화를 좋아하지 않는 기술 괴짜들은 새 버전이 이전 버전보다 나쁘다고 주장하면서 성장을 제한합니다.
4. 새 버전이 소비자 공간에서 대부분의 시장 점유율을 확보함에 따라 기업은 계속 방관하고 있습니다.
5. 소비자가 기술 괴짜를 무시하기 시작하고 새 버전이 이전 버전보다 훨씬 낫다는 것을 깨닫기 시작하면서 Microsoft는 이전 버전의 Windows에 대한 지원 및 패치의 만료 날짜를 발표합니다. 채택률은 약 50%에 이릅니다.
6. 새 버전을 더 좋아하는 사용자의 압력을 통해 비즈니스; 새 버전에서 더 잘 작동하는 소프트웨어 그리고 교체 하드웨어에 새 버전을 배포하기 시작하는 데드라인이 다가오고 있습니다. 채택률은 약 60-65%에 이릅니다.
7. 미래 지향적인 IT 관리자는 그룹별로 새 버전의 제어된 롤아웃을 시작합니다.
8. 기한이 몇 달 앞으로 다가왔고 나머지 IT 관리자들은 계획을 제대로 세우지 않았기 때문에 문제에 대해 읊조리며 문제에 대해 Windows(위에서 온 기술 괴짜들)에게 덤벼들었습니다. 시장 점유율은 6-8개월 만에 65%에서 90%로 올라갑니다. 지원 마감 기한이 다가오면 완료됩니다.
9. 이전 OS용으로 설계된 하드웨어이며 일반적으로 하드웨어 교체가 필요한 이러한 시스템을 교체하는 높은 비용 때문에 보안 패치에 대해 추가 비용을 지불하는 임베디드 시스템만 남아 있습니다.
10. 임베디드 시스템은 해킹을 당하기 시작하므로 기업은 비용을 절감하고 하드웨어를 교체하기 시작합니다.
11. OS 쓰던 사람만 남게 된 제3세계는 아무 것도 쓸 수 없고 해킹당해도 문제가 되지 않는다.

우리는 지금 #8에 있습니다. 개발자가 새로운 소프트웨어를 위해 Windows 7을 목표로 하고 있다면 그들은 역사에 대해 무지합니다. Windows 10 롤아웃은 정확히 그 이전의 Windows 7 롤아웃을 따릅니다. 하드웨어 릴리스 사이에 win32 앱의 증분 플러터에도 불구하고 주요 소프트웨어 업데이트를 롤아웃하지 않기 때문에 #9를 대상으로 하는 이유는 없습니다.

따라서:

1. XAML 섬은 인수 내부에 플러터를 사용하여 증분 win32 앱을 처리합니다. 그리고 실제로 소프트웨어를 구매하고 훔치지 않는 사람의 거의 0%는 플러터 데스크톱이 프로덕션에 적합할 정도로 안정될 즈음에 올해 9월까지 XAML 아일랜드를 사용할 수 없는 플랫폼을 사용할 것입니다.
2. 새로운 애플리케이션을 위해 Windows 7을 목표로 삼는 논리적 시장은 없습니다. API에 대한 절대적인 차단기가 없는 한(지금 API가 대부분 미러링되는지 의심스러운) 역사와 데스크톱 시장이 소비자와 기업 간에 어떻게 작동하는지 이해하는 사람은 아무도 없습니다. 그리고 그렇게 하는 경우에도 Windows 10에서 실행되므로 해당 win32 앱에서 플러터에 XAML 아일랜드를 사용할 수 없는 이유가 없습니다.

따라서 win32를 사용하기로 한 펄쩍 뛰는 결정은 우스꽝스럽고 Windows 시장을 이해하지 못하는 완전한 실패를 보여줍니다. (슬프게도 Google에서 나오는 것은 놀라운 일이 아닙니다)

@ JohnGalt1717 내가 실수했을 수도 있지만 winarm에 대한 내 문제는 win32와 아무 관련이 없습니다. 또한 이것은 단지 제안일 뿐이지만 수사학을 약간 줄이고 싶을 수도 있습니다. 무지와 같은 용어를 사용하고 광범위하고 근거 없는 주장을 하는 것은 요점을 전달하는 데 방해가 됩니다.

이 스레드에서 여러 번 지적했듯이 Winarm에서 Flutter를 실행하는 것은 쉬운 일이 아닙니다. win32에서 Flutter를 실행하는 것은 Flutter 자체에 약간의 변경이 필요하기 때문에 상당히 간단한 작업입니다. Flutter 및 Windows에 관해 내가 본 대부분의 관심이 데스크탑에 관한 것이라는 점을 감안할 때 낮은 매달린 과일(win32)로 시작하는 것이 합리적입니다. 이것은 win32 대 uwp와 거의 관련이 없으며 현재 많은 win32 시스템이 있다는 사실과 더 관련이 있습니다.

@JakeSays WinArm은 win32 앱이 Arm의 스토어에 게시되는 것을 허용하지 않습니다. (Office 이외) 컴파일 문제를 제외하고.

내 주장의 어떤 부분이 입증되지 않습니까? 데이터는 100% 내 입장을 지지합니다. 데스크톱용 Flutter가 Windows에서 출시될 준비가 되면 UWP를 실행할 수 없는 Windows 시스템의 5% 이하와 win32 앱을 배포할 수 없는 수많은 시스템이 있을 것입니다. (즉, Duo 또는 Neo를 포함한 모든 ARM 장치 또는 Windows를 실행하는 모든 장치와 증가 중인 모든 타사 버전)

WinArm, WinX64 및 WinX86에서 작동하는 UWP에서 플러터를 실행하는 것은 win32보다 어렵지 않아야 합니다. 또한 텍스트 상자 등의 맞춤법 검사, 영웅 없는 DPI를 기반으로 한 적절한 크기 조정 및 기본적으로 더 나은 문화 지원을 제공합니다. (미디어 재생은 win32보다 훨씬 뛰어나고 쉽습니다. 즉, UWP에서 3줄의 코드로 widevine, playready, AES 암호화된 비디오를 간단하게 재생할 수 있습니다. win32에서 동일한 작업을 수행하는 것은 엄청난 노력입니다. 캡션에 대해서는 말할 것도 없습니다. .

UWP와 비교하여 win32에는 "낮은 매달린 과일"이 없습니다. UWP는 데스크톱입니다. 다른 모든 것은 레거시 데스크탑입니다. (Silverlight는 제외) UWP를 다시 포팅하고 있으며 회사에서 앱을 다시 작성하지 않도록 지원하는 레거시 플랫폼용 API입니다. 기존 애플리케이션(및 기타 UWP)에 Flutter를 추가하는 것에 대해 간략하게 설명된 사용 사례를 위해 XAML 아일랜드를 추가했습니다.

"현재 많은 win32 시스템이 있습니다."

9월의 다이어그램은 다음과 같습니다. 9월까지 창을 실행하는 사람의 5%가 잠깁니다. 그 5% 중 사실상 그들 중 누구도 과거 데이터를 기반으로 소프트웨어를 구매하지 않습니다. 10월까지 Windows 사용자의 5%가 일종의 ARM에서 이를 사용하고 Win32에서 사용할 수 없게 됩니다.

그러니 독을 고르세요.

그러나 그렇게 할 때 UWP에서 잠긴 사람들의 수는 계속 줄어들고 Win32에서 잠긴 사람들의 수는 계속해서 많아집니다. 따라서 Microsoft는 Windows 7에서 버그를 수정하지 않고 보안만 유지하기 때문에 어떻게든 효과적으로 지원할 수 없는 죽어가는 시장에 대해 UWP 대신 win32를 사용하는 경우 12-24개월 내에 재작성을 효과적으로 보장합니다. 비용을 지불하는 사람들을 위한 업데이트. (어쨌든 Flutter와 함께 앱을 사용하지 않을 것입니다)

또한 Windows 버전의 비디오 플레이어는 Win32에서 DRM이 작동하도록 하는 데 필요한 엄청난 리프트 때문에 항상 크게 제한됩니다. 소프트웨어 터치 키보드를 사용하는 사람들을 위한 인라인 맞춤법 검사기 또는 자동 수정이 없습니다 , 그리고 문화적인 것들은 제대로 하기가 훨씬 더 어려울 것입니다.

이것을 거꾸로 생각이라고 합니다.

당신이 무지라는 단어를 좋아하지 않는다면, 그것은 내 문제가 아닙니다. 사실과 역사를 모르면 정의상 무지합니다. 이 경우 해롭습니다. 금지되지 않은 사회적으로 올바른 단어를 사용하고 싶다면 사용하고 싶은 단어를 알려주세요. 찾아서 교체하겠습니다.

내가 실제로 어디가 틀렸는지 말해주세요. 그리고 내 가정과 예상이 약간 빗나가더라도 시간이 지남에 따라 내 주장이 옳지 않고 덜 해롭고 덜 일하며 훨씬 더 많은 작업, 훨씬 더 많은 버그 및 훨씬 더 어려운 시간을 가진 대안보다 비디오, 맞춤법 검사 등을 위해 시간이 지남에 따라 다른 플랫폼을 사용할 수 있습니다. 어떻게 나누든 상관없이 내년 이맘때쯤이면 Windows 7을 사용하는 사람은 거의 없을 것입니다. 즉, Flutter는 모든 분야에서 거의 모든 사람이 100% 사용할 수 있게 될 것입니다. UWP에서 수행되고 win32가 아닌 경우 상황입니다. 죽은 OS를 수용하고 WinARM의 새롭고 성장하는 시장에서 플러터 개발자를 잠그는 win32와 비교합니다.

예를 들어, 지금 UWP에서 현재 비디오 플레이어의 모든 기능과 함께 Flutter에서 사용할 수 있는 우수한 문서와 함께 몇 분 만에 UWP에서 캡션과 DRM을 갖춘 비디오 플레이어를 만들 수 있습니다. 플러터 비디오 라이브러리. 그들이 지금 플러터 비디오 플레이어의 캡션과 DRM을 작업하고 있다는 사실을 알고 있습니다. 그리고 UWP 호출 외에는 아무것도 알 필요가 없습니다. 즉, Flutter에서 UWP를 사용하여 전체 비디오 기능을 제공하는 것이 간단하고 거의 모든 C#에서 이를 수행할 수 있습니다. C++ 사용, DirectX 표면 생성, 미디어 인코더/디코더/트랜스코더 생성 및 모든 것을 연결하십시오. (예, win32에서는 UWP에서 기본적으로 지원되는 사용자 지정 라이브러리 없이 많은 형식을 재생할 수 없습니다.) UWP(C++로 작성되더라도) 대 win32 간에 동일한 제품을 만들려는 노력은 약 1/100입니다. 시간의 양.

직렬 통신, 블루투스, 위치 추적 등에 대해서도 마찬가지입니다. (위치 추적 및 센서 API는 현재 Windows 10 2020/H1에서 win32로 제공되며 이전 버전의 Windows에서는 작동하지 않습니다. 따라서 Windows 10 사용자 중 100%가 이러한 API에 대한 UWP 기능에 액세스할 수 있는 것과 달리 최신 버전의 Windows 10을 사용하는 모든 사람에게 이 기능에 대한 액세스 권한을 부여하게 됩니다.) 당연하게 여기는 기능의 이름을 지정하십시오. Android/iOS용 flutter용 플러그인을 사용하면 동일한 결과를 볼 수 있습니다. UWP에서 구현하는 것은 win32에 비해 간단하므로 win32에서 데스크톱용 flutter를 작성하는 것보다 UWP에서 구현될 가능성이 훨씬 더 높습니다. 다른 모든 문제.

@JakeSays 여전히 내가 말한 것에 대해 무례한(또는 잘못된) 것을 보여주기를 기다리고 있습니다. 내가 말할 수 있는 한, 당신은 내가 올바르게 사용한 단어를 좋아하지 않습니다. 그리고 가장 중요한 것은, 나는 그것을 추상적으로 사용했고, 당신이나 다른 사람을 개인적으로 비난하지 않았습니다. 광고 동음이의어 공격이 아닙니다.

@stuartmorgan winarm 의 thumb 2 전용 제한 사항에 대한 솔루션에 대한 논의를 알고 있습니까?

@JakeSays 나는 Dart 컴파일러 수준에서 토론을 따르지 않았습니다. 나는 ARM 지원에 대한 논의를 알지 못하지만 이것이 일어나지 않는다는 것을 의미하지는 않습니다. 아직 다트 기능 요청을 제출하지 않았다면 반드시 제출해야 합니다.

가장 큰 문제는 UWP에서 OpenGL 지원이 부족하지만 Flutter 아래에서 ANGLE을 사용하여 해결할 수 있어야 합니다.

현재 Windows 임베딩은 이미 ANGLE을 사용하고 있으며 James는 임베딩 작업 초기부터 UWP 지원을 실험하고 있으므로 이미 잘 진행되고 있습니다.

@stuartmorgan 그렇게 하겠습니다.
그리고 예, Windows Embedder가 ANGLE을 사용하고 있다는 것을 잊었습니다.

@JohnGalt1717 , 행동 강령을 검토하십시오. Flutter의 커뮤니티 표준은 전문적이고 존중하는 담론을 요구하며 사람들이 환영받는다고 느낄 수 있도록 적극적으로 최선을 다합니다.

Flutter에는 열정적이고 재능 있는 많은 사람들이 일하고 있으며 특정 개발 라인을 추구하거나 추구하지 말아야 할 충분한 이유가 있습니다. Flutter가 UWP에서 작업하도록 하는 데 열정적이라고 말씀드릴 수 있습니다. 다른 사람들도 마찬가지입니다. 일부는 또한 win32에서 작동하도록 하는 데 열정적입니다. 이것은 오픈 소스 프로젝트이며, 기여만 하면 됩니다. 그 동안, 다른 경로에 대해 작업하는 기여자가 무지하거나, 시간을 낭비하거나, 거꾸로 생각하고 있다고 암시하지 마십시오.

최근 몇 개의 게시물이 이 커뮤니티에서 우리가 열망하는 상호 존중 수준에 도달하지 못하는 이유를 알 수 없다면 덜 적극적인 역할을 수행하십시오.

/cc @timsneath @Hixie

@dnfield 내가 당신의 요점을 보지 못하는 그 일을 한 적이 없다는 것을 감안할 때. 나는 사실에 입각한 역사, 그리고 이것을 다시 작성해야 하고 다른 플랫폼과 동등하지 않게 하기 위해 취하는 경로를 설명했습니다.

당신이 주의 깊게 읽어보면, 나는 어떤 사람을 무지하다고 부르지 않았으며(말 그대로 사실을 알지 못한다는 의미이며 경멸적이지 않으며, 그 자체가 사실 진술이 아닙니다), 나는 어떤 개인을 거꾸로 생각한다고 비난하지도 않았습니다. (즉, 1월 14일 현재 점점 더 관련성이 없고 죽은 과거를 포용하면서 미래와 단절되는 레거시 플랫폼을 목표로 함)

그래서 나는 그들이 내가 사용했던 일반성과 동일시하기로 결정하고 내가 그것을 통제할 수 없다면 누군가가 어떻게 기분이 상할지 이해하지 못합니다.

당신에 대해 하지 않은 말에 기분이 상하셨다면 그렇게 느끼신 것 같아 죄송합니다. 아마도 해결책은 내 입장을 진지하게 받아들이고 논리적으로 생각하고 이러한 사실을 실제로 고려했으며 무시하지 않았으며 win32가 다음을 요구하는 창에서 어떻게 작동할 것인지에 대한 장기 계획이 있음을 입증하는 것입니다. 스토어 및 해당 스토어는 win32 arm 앱 게시를 허용하지 않습니다. 그리고 win32를 사용하는 오버헤드는 이 선택으로 가능한 기여자를 90% 이상 줄이므로 Windows가 항상 다른 플랫폼 뒤에 있도록 보장합니다. 그러면 당신이 무지하지도 않고 후진적 사고도 아니므로 내가 말한 것이 당신의 기분을 상하게 해서는 안 된다는 것이 분명할 것입니다.

대신 "나는 (나에게 지시되지 않은 것에 대해) 기분이 상했으므로 당신이 틀렸습니다"라는 메시지를 받습니다. 어떤 논쟁에서도 논쟁이 되지 않는 것입니다.

내 입장이 어떻게 표현되었든 언급되지 않았다는 점을 감안할 때, flutter는 적시에 Windows에서 실행 가능한 솔루션이 될 가능성이 없으며 iOS, Android 및 Windows용으로 작성된 애플리케이션의 패리티를 허용하지 않을 것입니다. 이 결정의 결과로 우리 팀이 최소 2개의 프레임워크(따라서 최소 2개의 프로그래밍 언어)를 사용하도록 강요하기 때문에 다음 프로젝트에서 계획한 대로 Flutter를 사용하지 않을 것이므로 선택하는 것이 좋습니다. 더 많은 오버 헤드가 있더라도 타협 대신 탁월함의 길.

James는 임베딩 작업 초기부터 UWP 지원을 실험해 왔으며 이미 잘 진행되고 있습니다.

@stuartmorgan @clarkezone UWP에서 Flutter를 실행하는 공개적으로 사용 가능한 예가 있습니까? 아주 초기 단계이더라도 이것을 시도하고 싶습니다.

저는 현재 UWP 지원의 프로토타입을 작업 중입니다. 아직 초기 단계이지만(예: 아직 픽셀을 본 적이 없음) 어떻게 할 것인지에 대한 계획이 있습니다. 그것은 내가 만든 이전 Angle 변경에 대한 약간의 수정에 따라 달라질 것입니다. 나는 그것을 코딩했지만 아직 Angle에 제출하지 않았습니다. 면책 조항: 이것은 무언가를 배송하겠다는 약속을 구성하지 않으며 여전히 가능한 것에 대한 탐색입니다. 나는 약간 더 흥미로운 진전(예: 픽셀)을 만들면 여기에 다시 보고할 것입니다.

신속한 응답 @clarkezone 에 감사드립니다

FDE 포크에서 uwptest 라는 분기를 찾았습니다. 당신이 실험하고있는 것입니까? 이 경로에 대한 업데이트를 따르고 싶습니다.

NP, 네, FDE 지점입니다. 단기적으로는 특정 이론을 증명하기 위한 임시 해킹이 많이 있을 것입니다.

안녕하세요 @clarkezone입니다! 귀하의 작업이 Microsoft의 지원을 받는지 여쭤봐도 될까요? Microsoft가 Windows 앱을 만들기 위해 Flutter를 지원할 것으로 기대할 수 있습니까? 그렇다면 Flutter에서 UI Fabric을 사용할 수 있도록 할 계획이 있습니까?

제 생각에 최근에는 직원 참여/만족을 향상시키기 위해 아름다운 기업 소프트웨어를 구축하는 데 점점 더 많은 관심이 생겼습니다. 저는 현재 그러한 프로젝트를 다수 진행하고 있습니다. 최근에 우리는 Big 4 금융 회사 중 하나를 위해 Flutter 기반 Android 애플리케이션을 출시했습니다. 이러한 기업은 내부 소프트웨어에 C# 및 Xamarin을 사용하는 경향이 있지만 직장 경험 모바일 앱에는 더 높은 품질의 UI를 기대합니다. 이 경우 Flutter가 더 나은 옵션임이 입증되었습니다. 동시에 Microsoft는 Flutter 앱을 실행할 수 있는 기업 환경에서 사용되는 훌륭한 장치를 생산하므로 이를 실현하기 위해 Microsoft 및/또는 Google의 더 많은 지원을 보는 것이 좋습니다.

안녕하세요 루카스입니다. 내 작업은 MS의 지원을 받지 않고 자유 시간에 개인적으로 수행됩니다. 다른 점에 대해서는 확실히 동의하십시오. FWIW 저는 꽤 좋은 진전을 이뤘습니다. 출력/렌더링을 위해 종단 간 작업을 하는 Flutter 러너 프로토타입이 있습니다(아직 입력 없음). 현재 작업 중인 큰/다음 작업은 당기지 않고 모든 것을 올바르게 연결하는 것입니다. user32/gdi32 등에서 .. 이 단계는 XBOX, Windows 10x 에뮬레이터와 같은 데스크탑이 아닌 장치에서 실행되는 프로토타입을 성공적으로 볼 수 있도록 하는 데 필요하며 (또 다른) 야크 면도로 증명되고 있습니다 :-)

윈도우 스토어를 추가해주세요!!!!

@ daniele777 그게 내가 작업한 것입니다;-) 상태 업데이트: 링커 오류 84개에서 10개로 감소

내가 도움이 될 수 있습니다 ?? 프로젝트를 개선하기 위해 ?? 내가 작업을 할 수 있습니까?

@ daniele777 이 시점에서는 아직 기본 PoC가 작동하지 않습니다. 링커 오류는 지워지지만 Dart를 호출할 때 빌드 파이프라인에서 무한 루프에 빠지는 빌드 문제가 있습니다. 다른 문제도 있습니다. 나는 2주 동안 휴가를 보낼 예정이므로 일단 돌아와서 PoC 단계를 거치고 나면 병렬화할 수 있는 항목이 있을 수 있습니다.

좋아 최고야!

이것이 더 빨리 도착하기를 기다릴 수 없습니다. Windows에서 현재 win32 기반 플러터를 시도했습니다. OMG 렌더가 너무 픽셀화되어 현대적인 디자인처럼 보이지만 10년 된 프레임워크를 사용하여 구현되었습니다. 4K 화면에서 볼 수 있을 것으로 예상되는 것이 아닙니다. UWP 앱 및 최신 웹 앱에서 텍스트의 부드러운 가장자리에 사용되는 win32 렌더링은 매우 구식으로 보입니다.

@nerocui - Windows에서 픽셀화된 렌더링이 표시되는 경우 UWP로 마이그레이션하는 것만으로는 해결되지 않는 다른 버그일 가능성이 매우 높습니다. 재현 단계(및 아마도 픽셀화의 스크린샷)와 함께 이에 대한 새로운 문제를 제출할 수 있습니까?

@dnfield 이미지가 픽셀화되는 것과는 다릅니다. 텍스트와 모양이 하드웨어 가속 없이 렌더링되어 가장자리가 매끄럽지 않게 보일 뿐입니다. 이것은 내가 보는 많은 win32 프로그램에서 발생합니다. 기본 템플릿 페이지에 텍스트와 버튼만 있기 때문에 재생산 단계가 없습니다.

@nerocui win32 앱에는 UWP에 비해 적절한 DPI 스케일링이 없기 때문입니다. win32 텍스트 렌더링이 제대로 작동하도록 하려면 많은 작업이 필요하지만 매우 어렵습니다.

@ JohnGalt1717 감사합니다. 정확히 제 요점입니다. Flutter는 아름다운 크로스 플랫폼 앱을 구축하는 것이어야 하지만 win32는 앱을 추악하게 만드는 유일한 것입니다. 그것은 윈도우에서의 플러터 구현을 다른 플랫폼보다 열등하게 보이게 합니다.

win32는 앱을 추악하게 만드는 유일한 것입니다.

@dnfield 가 말했듯이 이것이 사실일 가능성은 거의 없습니다. Flutter 텍스트 렌더링은 전적으로 Skia에서 (DPI에 맞게 적절하게 조정된) GL 컨텍스트로 수행됩니다. UWP API로 GL 컨텍스트를 생성해도 렌더링은 변경되지 않습니다.

설명하는 문제를 강조하는 스크린샷과 함께 버그를 신고하세요.

예를 들어 어딘가에 앤티 앨리어스 플래그를 무시하고 포함하는 것처럼 간단할 수 있습니다. 그러나 번식 단계 없이는 알 수 없습니다.

https://github.com/flutter/flutter/issues/53308
제기된 문제. 정확한/충분한 정보인지 확인해주세요.

DPI를 150% 또는 더 나쁜 175%로 설정하고 일부 텍스트를 로드하면 볼 수 있을 것이라고 생각합니다.

렌더링 세부 사항에 대한 게시를 중단하십시오. 위의 설명에 따르면 이 문제와 관련이 없으므로 주제에서 벗어납니다.

Windows 스토어에 게시할 준비가 되셨습니까? 어떤 소식?

아니요, 스토어에 게시할 준비가 되지 않았습니다. 픽셀 및 입력은 XBOX 및 Windows 10x에서 작동합니다. API에서 계속 반복 중입니다. 아직 작업이 많이 남아 있습니다.

저는 약간 다른 접근 방식에 대해 생각하고 있습니다. 아직 시도하지는 않았지만 여유 시간이 있으면 할 수 있습니다. 데스크탑에서 Skia WASM과 함께 웹용 Flutter를 사용하는 것은 어떻습니까(Blazor에서 지원 가능)? I/O에 대한 제한된 액세스가 한 가지 단점이라고 생각할 수 있지만 실제 UI 렌더링 및 이벤트 처리는 예상대로 작동해야 합니다. Windows는 PWA를 잘 지원하는 것으로 보이며(Chrome OS도 마찬가지임) 이 접근 방식은 여전히 ​​우수한 성능을 달성하면서 구현하기 더 쉬울 수 있습니다.

@lukaszciastko 아니요, 전자가 하나 더 있을 것입니다. Flutter는 모든 종류의 기본 Windows 앱(win32, Winforms, wpf)에 포함될 수 있는 기본 Windows 창(HWND)으로 렌더링되어야 합니다.
IMHO uwp는 Windows 앱의 주요 종류로 간주되어서는 안 됩니다. MS도 그러지 않았다.

@clarkezone Windows에서 실행되는 앱을 만들 수 있도록 프로젝트에 귀하의 작업이 포함되는 것을 보고 싶습니다.

Windows에서 실행되는 앱을

Windows에서 Flutter 앱을 실행할 수 있는 것은 이미 가능하며 얼마 동안 가능했습니다. 이 문제는 이제 구체적으로 UWP에 관한 것입니다.

더 명확하게 하기 위해 제목을 업데이트하겠습니다.

Windows에서 실행되는 앱을

Windows에서 Flutter 앱을 실행하는 것은 이미 가능했으며 한동안 가능했습니다. 이 문제는 이제 구체적으로 UWP에 관한 것입니다.

더 명확하게 하기 위해 제목을 업데이트하겠습니다.

Stuart, Windows에서 Flutter 앱을 빌드하고 실행하는 방법에 대한 문서를 어디에서도 본 적이 없습니다. 이 정보를 어디에서 찾을 수 있는지 알려주실 수 있습니까?

@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과 어떤 관계가 있기를 바라는 것입니다. 저는 Flutter를 사랑하고 이 SDK가 있다는 사실에 매우 기쁩니다. Windows OS에서 Win32 앱의 미래가 걱정됩니다.

Flutter 팀이 가지고 있는 지식 기반은 무엇입니까?

이 작업이 완료되면 C#에서 Flutter 플러그인을 구현하고 플러그인에서 UWP 앱에 사용할 수 있는 API, SDK 및 NuGet 패키지를 사용할 수 있다는 의미인가요?

@kinex 두 사람이 관련이 있다고 생각하는 이유가 궁금합니다. 플러그인에 대한 .net 지원을 추가하는 것은 비교적 간단하며 UWP가 필요하지 않습니다. 그래도 플러터의 범위를 벗어납니다.

@JakeSays 내 이해에서 실행 환경(이 경우 UWP)은 플러그인이 생성되는 방법과 플러그인에서 사용할 수 있는 항목을 정의합니다. 그래서 아마도 내 질문에 대한 대답은 "물론"일 수도 있지만 완전히 확신할 수는 없습니다.

Android 플러그인에서는 Kotlin(또는 Java)과 모든 Android API, SDK 및 패키지를 사용할 수 있습니다. iOS 플러그인에서는 Swift(또는 Objective-C)와 모든 iOS API, SDK 및 Pod를 사용할 수 있습니다. 나는 UWP에서도 같은 것을 기대하고 이것은 정말 굉장할 것입니다.

플러그인에서 C#을 더 쉽게 사용할 수 있도록 하는 것이 우리가 하고자 하는 일이지만 UWP 지원과 직교합니다.

UWP 러너는 플러그인에서 UWP 관련 API를 사용할 수 있음을 의미하지만 실제로 UWP 관련 API는 거의 없다는 점을 이해하고 있습니다(예: 이 설명서 에 따르면 "일반적인 규칙은 데스크톱 앱이 유니버설 Windows 플랫폼을 호출할 수 있다는 것입니다. (UWP) API.")

@stuartmorgan 그것은 사실이 아닙니다. 결국에는 프로젝트 재결합이 사실이 될 것이지만, 지금은 그렇지 않으며 그때도 플러터의 경우처럼 새 앱이 아니라 레거시 소프트웨어를 위한 것입니다. UWP 없이는 할 수 없는 작업(예: 다양한 비디오 코덱, DRM 비디오 플레이어 등의 플러그인 액세스)이 여전히 많기 때문에 플러터 팀이 취하는 접근 방식에 항상 문제가 있었습니다. . 시장에서 UWP를 실행할 수 없는 Microsoft(따라서 안전한) 운영 체제가 0개 있습니다(즉, Windows 7을 대상으로 하는 것은 터무니없고 Flutter의 목표가 되어서는 안 됩니다. Windows 10만 대상이 되어야 함). 따라서 이것이 첫날부터 기본 UWP가 아니어야 하는 이유는 0가지입니다.

설상가상으로 모든 Windows 10 S 및 변종은 win32 앱을 실행할 수 없으므로 Flutter가 해당 앱에서 잠길 수 있습니다. 또한 원격 데스크톱을 사용하여 도커 컨테이너에서 win32 앱을 실행하는 UWP 및 Windows X에서 실행하지 않는 한 ARM/ARM64 장치에서도 잠깁니다. 그래픽 성능.

따라서 google/flutter가 Windows 지원에 대해 미래 지향적인 생각을 했다면 C++ 및 .NET(대부분의 Windows 개발자는 C++이 아닌 .net을 사용함)을 허용하고 현재 및 미래의 모든 Windows 장치를 최상의 상태로 지원하는 완전히 UWP가 될 것입니다. 가능한 상호 작용. 현재 win32 접근 방식은 근시안적이며 제대로 연구되지 않았습니다(이는 Windows를 실행하는 10억 개 이상의 장치를 고려할 때 우려되는 Google 내의 정말 거대한 사각지대를 나타냄).

Skia가 이미 UWP에서 실행되고 있다는 점을 감안할 때 이것이 사실상의 환경이 아니며 Windows에 대한 Google 노력의 100% 초점이 되지 않을 이유는 거의 없습니다. (실제로 Microsoft와 협력하여 전체 Xamarin 원격 시뮬레이터를 가져오고 Windows의 iOS 장치에 직접 배포도 작동함)

@JohnGalt1717 이 문제에서 이미 여러 번 이 주장을 하셨습니다. 그것을 반복하는 것은 건설적이지 않습니다. UWP 지원 개발을 가속화하려면 이에 기여할 수 있습니다.

@stuartmorgan C# 사용에 대한 귀하의 생각이 궁금합니다. 나는 그것을 작동시키는 방법에 대한 몇 가지 아이디어가 있습니다.

@kinex 실제로 flutter 플러그인은 본질적으로 간단한 API를 통해 flutter와 상호 작용하는 C 코드입니다. C#으로 작성하려면 기본적으로 CLR을 호스팅하고 플러터 세계와 C#을 연결하는 C로 작성된 ".net 플러그인"이 필요합니다. 이론적으로 언어 환경이 대상 운영 체제에서 실행될 수 있는 한 Windows 또는 모든 언어의 Java로 플러터 플러그인을 작성하는 것이 가능합니다.

@JakeSays 저는 여기에 제출한 적이 없기 때문에 C#에 대한 현재 생각을 https://github.com/flutter/flutter/issues/64958 에 제출했습니다. 특히 C#에 관심이 있는 사람은 이 문제를 따라야 합니다.

@JakeSays 네 , 설명해주셔서 감사합니다. 더 나은 지식 없이 나는 다음과 같이 가정했습니다. C# 플러그인(.NET 라이브러리로 구현되었을 수도?)은 UWP 러너에 의해 로드되고 Dart 코드는 UWP 러너 프로세스를 통해 이를 호출할 수 있습니다. 이 가상 아키텍처에서 해당 C# 플러그인은 UWP 앱에서 호스팅하는 .NET 라이브러리와 동일한 API, SDK 및 NuGet 패키지에 액세스할 수 있습니다.

어쨌든 C# 지원에 관한 계획이 있다는 것을 알게 되어 반갑습니다. C++ 대신 C#을 사용할 수 있다면 더 많은 플러그인 작성자(=더 많은 플러그인이 더 빨라짐)와 더 안정적인 플러그인이 있을 것이라고 믿습니다.

@kinex C# 플러그인이 nuget 패키지뿐만 아니라 전체 .net 라이브러리 세트에 액세스할 수 있다는 점에서 맞습니다. C# 코드가 실행되면 전체 .net 환경(또는 경우에 따라 .net 코어)에서 실행됩니다.

FFI는 플러그인을 위한 훨씬 더 가벼운 솔루션입니다. 예를 들어 https://pub.dev/packages/win32 를 참조하십시오. 그러나 이것은 표면상 UWP 기반 러너를 구축하는 것과 관련된 문제에 대해서는 주제와 거리가 멉니다.

@timsneath 저는 ffi와 플러그인이 두 가지 다른 문제를 해결한다고 생각합니다. iirc ffi로 할 수 있는 일에는 많은 제한이 있습니다(예: 동기식).

다시, 나는 C# 플러그인에 대해 #64958을 제출했습니다. UWP가 아닌 C#에 대한 토론을 계속하십시오.

좋은 일들이 계속되고 있다
누군가 Microsoft에 여기에도 기여하도록 알려야 합니다.

@airbus5717 무슨 말씀이세요? Microsoft는 여기에서 항상 토론에 기여합니다.

제가 작업한 Flutter UWP 실험의 상태에 대한 2020년 9월 업데이트를 공유할 가치가 있다고 생각했습니다. 이것은 내가 저녁과 주말에만 작업했던 여가/최선의 프로젝트이기 때문에 진행이 내가 원하는 것보다 더 느렸습니다. 그러나 지난 6개월 동안 상당한 진전을 이루었고 다음과 같은 몇 가지 시나리오가 작동하게 되었습니다.

• AppContainer 샌드박스에서 실행되는 WinRT 입력 API와 함께 CoreWindow 를 사용하는 개념 증명 WinRT Flutter 임베더: https://github.com/clarkezone/engine
• Flutter 갤러리 를 사용한 데모 Flutter 경험이 있는 해당 테스트 Flutter UWP 실행기(C++의 115줄만!): https://github.com/clarkezone/fluttergallerywp
• 이를 사용하여 Flutter Gallery의 MSIX 패키지 버전을 Microsoft Store에 성공적으로 게시할 수 있었고 WAC API 검사를 통과하여 매장 인증을 받았습니다(마침내 :-)).

이 작업을 프로덕션 준비 상태로 만들려면 아직 해야 할 일이 많고 시간이 얼마나 걸릴지 모르겠지만 Flutter UWP가 실행 가능하다는 것은 확실합니다.

flutter create 와 도구 통합을 수행하는 방법, 핫 리로드 및 관측소 지원을 작동시키는 방법 등과 같이 해결해야 할 몇 가지 큰 문제가 남아 있습니다. 자세한 내용은 여기 .

아래 예에서는 https://github.com/miickel/flutter_particle_clock 에서 Flutter Particle clock 의 소스를 가져와 Windows를 대상으로 하는 릴리스 모드에서 빌드하고 결과 app.so 바이너리를 가져와서 Flutter Gallery에 대해 위에서 사용한 것과 동일한 Flutter Runner를 사용하는 UWP, Microsoft Store에 게시하고 내 XBOX에 설치: