Flutter: Tambahkan dukungan untuk UWP

Mungkin tidak untuk saat ini, lihat #10881.

Saya ingin memasukkan diri saya ke permintaan fitur ini, akan luar biasa bahwa Flutter mendukung Windows 10 UWP.

Ini juga harus mencakup Xbox One, yang dapat Anda targetkan di Xamarin/UWP

Ya silahkan. Dukungan Windows pasti akan menjadi pengubah permainan.

ini tidak resmi, tetapi Anda dapat memeriksa proyek ini. https://github.com/google/flutter-desktop-embedding Saya pikir glfw juga tersedia di windows sehingga Anda dapat mencoba :wink:

Man ... Saya ingin xplat nyata :)

Saya baru saja mengetik permintaan fitur yang sama ... Saya harap ini mendapat daya tarik!

Sebagai pengguna dengan beberapa perangkat Windows, MacOS, dan Chrome OS di rumah saya... model terbaru Surface Pro secara konsisten menjadi driver harian saya setiap tahun; sejak rilis SP4. Tampaknya menjadi sangat populer di kampus dan di tempat kerja sekarang juga. Namun, sedikitnya pilihan aplikasi UWP berkualitas tinggi terus menjadi masalah terbesar bagi saya.

Saya percaya keanggunan & kemudahan Flutter berpotensi memberikan insentif yang dibutuhkan pengembang/korps, untuk menyertakan Win10 dalam strategi multi-platform mereka... dan dalam prosesnya, semoga mempromosikan Flutter ke status/populeritas yang sama seperti Java; untuk pertimbangan eksekutif TI, saat memilih alat & platform untuk pengembangan produk.

Xamarin, Ionic dll termasuk UWP, jadi mengapa Flutter?

Menghapus tugas, karena ini adalah bug payung yang sangat luas. Subtugas tertentu dilacak dalam bug individual, yang akan mendapatkan penerima tugas dan pencapaian tertentu seperti biasa.

Menghapus dari proyek Window MVP. Kami masih mengevaluasi UWP sebagai target, dan kemungkinan besar akan mendukungnya pada akhirnya, tetapi fokus awalnya adalah mengaktifkan Win32 untuk membatasi ruang lingkup.

Saya pikir ini adalah sebuah kesalahan. Semua platform yang tidak mendukung uwp tidak didukung pada 20 Januari 2020. Yaitu pada saat ini sudah siap.

Tidak ada gunanya mendukung platform lama ketika Anda tidak perlu melakukannya karena migrasi massal sedang terjadi saat ini secara agresif.

Satu-satunya fokus harus uwp dan wpf harus diabaikan.

Semua platform yang tidak mendukung uwp tidak didukung mulai 20 Januari 2020

Keputusan untuk fokus pada API Win32 terlebih dahulu bersifat teknis, bukan berdasarkan platform target.

wpf harus diabaikan

Saat ini tidak ada rencana untuk menggunakan WPF.

Maaf, win32 harus diabaikan.

Mengapa?

Karena win32 membatasi flutter pada platform windows. Uwp tidak karena pada saat Anda memiliki ini di luar tidak akan ada platform windows yang didukung yang tidak mendukung uwp, namun ada platform di windows yang tidak mendukung win32 (arm64 yang akan membutuhkan pembangunan kembali sepenuhnya)

Jelasnya, siapa pun yang tertarik untuk berkontribusi dalam upaya dukungan UWP masih diterima dan didorong untuk melakukannya.

namun ada platform di windows yang tidak mendukung win32 (arm64 yang memerlukan pembangunan kembali seluruhnya)

Windows 10 pada ARM mendukung Win32, Anda hanya perlu mengkompilasi aplikasi di bawah ARM64, seperti halnya dengan UWP.

Semua platform yang tidak mendukung uwp tidak didukung pada 20 Januari 2020. Yaitu pada saat ini sudah siap.

Dukungan untuk Windows 8.1 berakhir pada 2023. Tidak mendukung UWP.

@stuartmorgan Hai, saya tertarik untuk mengerjakan dukungan UWP.

Anda menyebutkan di atas "Kami masih mengevaluasi UWP sebagai target" - Saya ingin tahu apa yang Anda temukan.

Terima kasih,
-Jake

@Kapranov98 Saya baru saja selesai bereksperimen dengan porting flutter ke Windows 10 ARM. Win32/UWP adalah yang paling sedikit masalah. Dart sendiri membutuhkan perubahan substansial untuk berjalan di WinARM. Kode khusus ARM di dart tidak pernah dirancang untuk berjalan pada apa pun kecuali sistem posix'ish (ios, android, linux, dll). Belum lagi WinARM hanya mendukung set instruksi Thumb-2, dan seperti yang saya pahami, dart jit menggunakan set instruksi ARM (walaupun saya perlu mendapatkan verifikasi resmi untuk ini). Membuat pelabuhan bekerja akan menjadi upaya yang cukup besar.

@Jakesays apakah Anda mencoba mengaktifkan /appcontainer sebagai bagian dari eksperimen Anda?

Anda menyebutkan di atas "Kami masih mengevaluasi UWP sebagai target" - Saya ingin tahu apa yang Anda temukan.

Saya akan segera memulai dokumen awal untuk mengumpulkan informasi dan menautkannya dari sini. Tidak ada banyak spesifik pada saat ini (dan setelah dokumen awal ada, hal-hal seperti hasil penyelidikan ARM Anda akan sangat diterima sebagai tambahan). Ketika saya mengatakan "masih mengevaluasi" maksud saya bahwa kami masih berencana untuk mendukungnya di masa depan, dan sebagai bagian dari itu akan mengevaluasi semua yang perlu dilakukan. Karena itu bukan fokus kami untuk MVP awal, tidak banyak penyelidikan aktif saat ini.

Bagian dari itu akan melibatkan pemecahan aspek-aspek tertentu, karena seperti yang ditunjukkan oleh komentar di atas, ada sejumlah elemen yang berbeda, masing-masing dengan tantangannya sendiri.

Apakah percakapan ini berubah sekarang karena Windows 10 X adalah suatu hal? Win32 akan dapat berjalan di Windows 10 X tetapi saya pikir UWP akan jauh lebih cocok. Apakah Flutter berencana untuk mendukung perangkat layar ganda sama sekali? Surface Duo dan Surface Neo?

@nerocui Seperti yang saya pahami, Duo adalah perangkat Android jadi saya membayangkan Flutter akan berfungsi dengan baik (setidaknya di satu layar). Saya tidak yakin CPU mana yang dijalankan Neo, tetapi jika itu ARM maka Flutter hampir mati di dalam air. Dart saat ini tidak menghasilkan kode perakitan yang kompatibel untuk winarm (winarm menggunakan instruksi thumb-2 secara eksklusif, dan IIRC Dart menggunakan instruksi thumb-2 dan arm). Ini akan menjadi usaha non-sepele untuk membuatnya bekerja.

@JakeSays Neo menggunakan Intel Lakefield jadi x86. Saya lebih peduli tentang bagian UWP dari cerita. Pada perangkat seluler seperti Neo, siklus hidup terkelola dari model aplikasi UWP akan berguna. Win32 tidak akan ideal untuk masa pakai baterai. Juga, aplikasi win32 di Neo akan berjalan dalam wadah, yang buruk untuk kinerja. Menargetkan UWP sebenarnya adalah langkah yang sangat cerdas. Baik Android dan iOS menjalankan model aplikasi terkelola, UWP harus membawa lebih banyak konsistensi. Windows 8 dapat diabaikan, tidak ada statistik yang menunjukkan pangsa pasar yang berarti.

@nerocui Ok maka bergetar ke target UWP harus dimungkinkan. Masalah terbesar adalah kurangnya dukungan OpenGL di UWP, tetapi itu harus diselesaikan dengan menggunakan ANGLE di bawah flutter.

Saya mencari di UWP tetapi target saya adalah ARM/WinIOT.

@JakeSays UWP seharusnya baik-baik saja untuk sebagian besar perangkat, tetapi itu memusingkan untuk Windows di ARM. Ironisnya, flutter UWP (jika pernah datang) harus tetap ditiru pada perangkat Windows berbasis ARM. Tingkat penyelesaian apa yang Anda capai untuk port flutter/uwp?

@nerocui Saya berhenti mengerjakannya setelah saya menemukan masalah Dart.

Sementara UWP pasti diinginkan, Win32 jelas tidak akan kemana-mana. Microsoft baru-baru ini mengumumkan bahwa mereka menambahkan dukungan Win32 ke Windows Store. Juga, banyak game terus dikembangkan di bawah platform Win32.

Yap, Microsoft menerima aplikasi Win32 di Store dan digunakan secara luas di dunia selain UWP. Aplikasi Win32 memiliki kinerja terbaik tetapi memiliki batas konsumsi baterai. Win32 hanya memiliki 2 status Running atau Not Responding (Freeze), tetapi UWP memiliki lebih banyak status (lebih bersahabat dengan perangkat seluler) seperti Running in background, Suspended.

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

Baterai penting untuk perangkat seluler seperti laptop atau perangkat Windows 10x

Ini harus menjadi percakapan sederhana:

Pada 14 Januari ada 0 versi windows yang didukung yang tidak mendukung UWP.

Ada versi utama dari windows yang tidak mendukung aplikasi win32 yang digunakan untuk mereka di toko atau sebaliknya.

Win32 adalah platform warisan. Jika Anda mempertahankan sistem yang lebih lama, tentu saja, win32 itu. Tapi flutter adalah semua kode baru. Ada 0 alasan untuk menulisnya untuk API yang lawas dan tidak didukung, ketika itu dapat ditulis untuk UWP dan didukung di mana pun di mana windows didukung.

Tapi flutter adalah semua kode baru.

Ini tidak benar-benar terjadi; Saya telah berbicara dengan orang-orang yang tertarik dengan skenario add-to-app untuk memungkinkan adopsi Flutter di aplikasi Win32 yang ada.

Ada 0 alasan untuk menulisnya untuk API yang lawas dan tidak didukung, ketika itu dapat ditulis untuk UWP dan didukung di mana pun di mana windows didukung.

Komentar di atas sudah menjelaskan bahwa mendukung perangkat tersebut bukanlah masalah sederhana dari Win32 vs UWP. Demikian pula, pembatasan sandboxing yang diperlukan untuk beberapa penerapan atau model distribusi akan berlaku untuk mesin, yang merupakan basis kode besar yang sudah ada, bukan pengembangan bidang hijau, jadi ada juga kerumitan di sana.

Argumen ini juga mengabaikan fakta bahwa ada banyak orang yang mengembangkan kode baru yang peduli dengan basis instalasi, bukan versi yang didukung. Kenyataannya adalah bahwa Windows 7 masih merupakan bagian yang sangat besar dari basis instalasi, dan itu tidak mungkin berubah secara dramatis dalam waktu dekat.

Ada alasan bagus untuk mendukung UWP, dan seperti yang telah saya katakan beberapa kali, kami berencana untuk mendukungnya di masa mendatang. Menyederhanakan secara signifikan pengorbanan yang terlibat untuk mengklaim bahwa keputusannya sederhana tidak akan mempercepat proses itu. Sekali lagi, siapa pun yang merasa sangat mendukung UWP tentu dipersilakan untuk berkontribusi pada pengembangan embedding UWP.

@stuartmorgan apakah Anda mengetahui ada diskusi tentang solusi untuk ibu jari 2 hanya pembatasan winarm?

@stuartmorgan UWP bisa digunakan di aplikasi win32/Winforms/WPF. Pulau XAML mudah dan didukung dengan baik. Win32 tidak berfungsi pada winarm seperti yang dijelaskan oleh @JakeSays. Jadi argumen Anda 0 masuk akal dan bukan pembenaran untuk flutter yang menargetkan api lawas untuk kasus penyematan flutter di aplikasi lawas.

Selanjutnya untuk semua perkembangan BARU:

Basis instalasi Windows 7 jatuh seperti batu. WinARM akan meningkat secara besar-besaran di tahun depan. Windows 7 akan <5% dari pasar Windows (kurang dari 50 juta perangkat dan tidak ada yang membayar untuk perangkat lunak) pada bulan Juli dengan tarif saat ini) dan di sana terpental di bagian bawah dengan Windows XP dan Vista (hampir semata-mata karena sistem tertanam di mana mereka tidak akan pernah meluncurkan aplikasi berbasis Flutter baru tanpa mengganti OS dengannya karena kurangnya dukungan.

Pernyataan Anda dan seluruh pendekatan Win32 ini menunjukkan kegagalan untuk memahami bagaimana versi Windows berkembang dan kemudian turun (sebelum revisi Windows 10 tanpa akhir, yang semuanya memiliki UWP sehingga aliran ini tidak relevan):

1. Versi baru dirilis, adopsi sangat lambat pada perangkat baru saja dan hanya di ruang konsumen.
2. (Menang 7 => 10) Perangkat konsumen diperbarui lebih cepat dan pangsa pasar tumbuh.
3. Pertumbuhan dibatasi oleh geeks teknologi yang tidak menyukai perubahan yang mengklaim bahwa versi baru lebih buruk daripada versi lama meskipun sebenarnya tidak.
4. Bisnis terus duduk di sela-sela karena versi baru memperoleh pangsa pasar mayoritas di ruang konsumen.
5. Microsoft mengumumkan tanggal pensiun dukungan dan patch untuk versi lama Windows karena konsumen mulai mengabaikan tech Geeks dan menyadari versi baru jauh lebih baik daripada yang lama. Adopsi mencapai sekitar 50%.
6. Bisnis melalui tekanan dari pengguna yang lebih menyukai versi baru; perangkat lunak yang bekerja lebih baik pada versi baru; dan tenggat waktu yang menjulang untuk keusangan mulai menerapkan versi baru pada perangkat keras pengganti. Adopsi mencapai sekitar 60-65%
7. Manajer TI yang berpikiran maju mulai melakukan peluncuran versi baru yang terkontrol berdasarkan grup demi grup.
8. Tenggat waktu tampak berbulan-bulan lagi, dan manajer TI lainnya hanya menyelesaikannya, mengeluh tentang masalah karena mereka tidak merencanakannya dengan benar dan membanting Windows (ini adalah ahli teknologi dari atas) untuk masalah mereka. Pangsa pasar naik dari 65% menjadi 90% dalam 6-8 bulan saat tenggat waktu untuk dukungan selesai.
9. Satu-satunya sistem yang tersisa tertanam yang membayar ekstra untuk patch keamanan karena tingginya biaya penggantian sistem ini yang dirancang perangkat keras untuk OS sebelumnya dan umumnya memerlukan penggantian perangkat keras.
10. Sistem yang disematkan mulai diretas, sehingga bisnis mendapatkan keuntungan biaya dan mulai mengganti perangkat keras.
11. Hanya orang-orang yang tersisa menggunakan OS adalah negara dunia ke-3 yang tidak dapat menggunakan apa pun dan diretas bukanlah masalah.

Kami berada di #8 sekarang. Jika pengembang menargetkan Windows 7 untuk perangkat lunak baru, mereka tidak mengetahui sejarah. Peluncuran Windows 10 persis mengikuti peluncuran Windows 7 sebelumnya. Ada 0 alasan untuk menargetkan #9 karena mereka tidak meluncurkan pembaruan perangkat lunak utama bahkan dengan flutter tambahan di aplikasi win32 di antara rilis perangkat keras.

Jadi:

1. Pulau XAML menangani aplikasi win32 tambahan Anda dengan argumen flutter di dalamnya. Dan hampir 0% orang yang benar-benar membeli (dan tidak mencuri) perangkat lunak akan menggunakan platform yang tidak dapat menggunakan pulau XAML pada bulan September tahun ini tepat saat desktop flutter akan cukup stabil untuk produksi.
2. Tidak ada pasar logis untuk menargetkan Windows 7 untuk aplikasi baru. Sama sekali tidak seorang pun dengan pemahaman sejarah dan bagaimana pasar desktop bekerja antara konsumen dan bisnis akan menulis aplikasi baru di win32 kecuali ada pemblokir mutlak pada API (yang sangat diragukan bahwa sebagian besar API dicerminkan sekarang). Dan bahkan jika mereka melakukannya, itu akan berjalan di Windows 10 dan dengan demikian tidak ada alasan mengapa mereka tidak dapat menggunakan Kepulauan XAML untuk bergetar di aplikasi win32 itu.

Jadi keputusan bergetar untuk menggunakan win32 adalah konyol dan menunjukkan kegagalan total untuk memahami pasar Windows. (yang tidak mengejutkan keluar dari Google dengan sedih)

@ JohnGalt1717 Saya mungkin salah, tetapi masalah saya dengan winarm tidak ada hubungannya dengan win32. Juga, dan ini hanya saran, tetapi Anda mungkin ingin sedikit menolak retorika. Menggunakan istilah-istilah seperti bodoh dan membuat klaim yang luas dan tidak berdasar benar-benar menghambat penyampaian maksud Anda.

Menjalankan Flutter di winarm bukanlah upaya sepele, seperti yang telah ditunjukkan beberapa kali di utas ini. Menjalankan Flutter di win32 adalah upaya yang cukup sepele karena memerlukan sedikit perubahan untuk flutter itu sendiri. Masuk akal untuk memulai dengan buah gantung rendah (win32), terutama mengingat bahwa sebagian besar minat yang saya lihat tentang Flutter dan windows adalah tentang desktop. Ini tidak ada hubungannya dengan win32 vs uwp dan lebih berkaitan dengan fakta bahwa kenyataannya ada BANYAK sistem win32 di luar sana SEKARANG.

@JakeSays WinArm tidak mengizinkan aplikasi win32 dipublikasikan ke toko di Arm. (selain Office) Selain masalah kompilasi.

Bagian mana dari klaim saya yang tidak terbukti? Data 100% mendukung posisi saya. Pada saat Flutter untuk desktop siap dirilis di Windows, akan ada 5% atau kurang dari mesin Windows yang tidak dapat menjalankan UWP dan banyak lagi yang tidak dapat Anda terapkan aplikasi win32. (yaitu semua perangkat ARM termasuk Duo atau Neo atau apa pun yang menjalankan windows, dan semua versi pihak ke-3 yang ditingkatkan.)

Menjalankan flutter untuk dijalankan di bawah UWP yang berfungsi pada WinArm dan WinX64 dan WinX86 seharusnya tidak lebih sulit daripada win32. Ini juga membuat Anda memeriksa ejaan di kotak teks dll., penskalaan yang tepat berdasarkan DPI tanpa heroik, dan dukungan budaya yang lebih baik di luar kotak. (belum lagi pemutaran media jauh lebih baik dan lebih mudah daripada win32. Yaitu saya dapat memutar video terenkripsi widevine, playready, AES secara sepele dengan 3 baris kode di UWP. Melakukan hal yang sama di win32 adalah upaya besar-besaran. Untuk tidak mengatakan apa pun tentang teks .

Tidak ada "buah gantung rendah" dengan win32 versus UWP. UWP adalah desktop. Segala sesuatu yang lain adalah desktop lama. (selain Silverlight jelas) Mereka kembali mem-porting UWP dan itu adalah API untuk platform lama untuk mendukung perusahaan yang tidak menulis ulang aplikasi mereka. Mereka telah menambahkan pulau XAML untuk persis kasus penggunaan yang diuraikan dalam menambahkan Flutter ke aplikasi yang ada (dan apa pun UWP).

"Ada BANYAK sistem win32 di luar sana SEKARANG".

Begini tampilan diagram di bulan September: 5% orang yang menjalankan windows akan terkunci pada bulan September. Dari 5% itu, hampir tidak ada yang membeli perangkat lunak berdasarkan data historis. Pada bulan Oktober 5% pengguna windows akan menggunakannya di ARM dan akan dikunci dari Win32.

Jadi pilihlah racunmu.

Namun perhatikan saat Anda melakukannya, bahwa jumlah orang yang terkunci dari UWP akan terus berkurang, sedangkan jumlah orang yang terkunci dari Win32 akan terus bertambah. Jadi Anda secara efektif menjamin penulisan ulang dalam 12-24 bulan jika Anda menggunakan win32 alih-alih UWP semua untuk pasar yang sekarat yang bagaimanapun juga tidak dapat Anda dukung secara efektif, karena Microsoft tidak akan memperbaiki bug di Windows 7, hanya keamanan pembaruan bagi mereka yang membayarnya. (yang bagaimanapun tidak akan menggunakan aplikasi dengan flutter)

Ini juga memastikan bahwa pemutar video versi Windows akan selalu dibatasi secara besar-besaran karena peningkatan besar-besaran yang diperlukan agar DRM berfungsi di Win32, tidak akan ada pemeriksa ejaan sebaris atau koreksi otomatis bagi mereka yang menggunakan keyboard sentuh perangkat lunak. , dan hal-hal budaya akan jauh lebih sulit untuk diperbaiki.

Ini disebut berpikir mundur.

Jika Anda tidak menyukai kata bodoh, itu bukan masalah saya. Jika Anda tidak tahu fakta dan sejarah, maka menurut definisi Anda bodoh. Dalam hal ini berbahaya begitu. Jika Anda ingin menggunakan kata yang benar secara sosial yang belum dilarang, beri tahu saya apa yang Anda ingin saya gunakan dan saya akan mencari dan menggantinya.

Katakan di mana saya sebenarnya salah. Dan bahkan jika asumsi dan proyeksi saya sedikit meleset, beri tahu saya bagaimana pernyataan saya dari waktu ke waktu tidak benar dan kurang berbahaya dan kurang berhasil daripada alternatif yang jauh lebih berhasil, jauh lebih banyak bug, dan waktu yang jauh lebih sulit untuk mencapai paritas dengan platform lain dari waktu ke waktu untuk hal-hal seperti video, pemeriksaan ejaan, dll. Tidak peduli bagaimana Anda mengirisnya, saat ini tahun depan hampir tidak ada yang akan menggunakan Windows 7. Dan itu berarti bahwa Flutter akan 100% tersedia untuk hampir semua orang di setiap situasi jika dilakukan di UWP dan bukan win32. Versus win32 yang melayani OS mati dan mengunci pengembang yang bergetar keluar dari pasar baru dan berkembang untuk WinARM.

Sebagai contoh, saya dapat, sekarang, di UWP membuat pemutar video dengan semua fungsi pemutar video saat ini, ditambah keterangan plus DRM di UWP dalam beberapa menit dengan dokumentasi luar biasa yang dapat digunakan oleh Flutter sebagai bagian dari perpustakaan video bergetar. Saya tahu pasti bahwa mereka sedang mengerjakan teks dan DRM untuk pemutar video flutter sekarang. Dan saya tidak perlu tahu apa-apa selain panggilan UWP. Itu berarti menyediakan fungsionalitas video lengkap di Flutter dengan UWP adalah hal yang sepele dan hampir semua C# dapat melakukannya yang merupakan sekelompok besar orang versus mereka yang tahu cara menggunakan C++, membuat permukaan DirectX, dan membuat enkoder/dekoder/transkoder media dan kaitkan semuanya. (ya, di win32 Anda tidak dapat memainkan banyak format tanpa pustaka khusus yang didukung di luar kotak di UWP) Upaya untuk membuat produk yang sama antara UWP (bahkan jika ditulis dalam C++) versus win32 adalah sekitar 1/100 jumlah waktu.

Hal yang sama berlaku untuk komunikasi serial, bluetooth, pelacakan lokasi, dll. dll. dll. (dan pelacakan lokasi dan API sensor baru saja, di Windows 10 2020/H1, datang ke win32 dan tidak akan berfungsi di versi windows sebelumnya 10 sehingga Anda mengandalkan semua orang yang menggunakan versi terbaru Windows 10 bahkan untuk memiliki akses ke fungsi ini, dibandingkan 100% pengguna di Windows 10 yang memiliki akses ke fungsionalitas UWP untuk api ini.) Beri nama fungsionalitas yang Anda anggap biasa saja dengan plugin untuk flutter untuk Android/iOS dan Anda akan melihat hal yang sama: Menerapkannya sepele di UWP versus win32 dan dengan demikian Anda jauh lebih mungkin untuk mengimplementasikannya di UWP daripada jika Anda menulis flutter untuk desktop di win32 selain dari semua masalah lainnya.

@JakeSays Masih menunggu Anda untuk menunjukkan sesuatu yang tidak sopan (atau salah) dengan apa yang saya katakan. Dari apa yang saya tahu, Anda hanya tidak menyukai sebuah kata, yang saya gunakan dengan benar. Dan, yang paling penting, saya menggunakannya secara abstrak, bukan untuk melawan Anda atau siapa pun secara pribadi. Itu bukan serangan ad homonim.

@stuartmorgan apakah Anda mengetahui ada diskusi tentang solusi untuk ibu jari 2 hanya pembatasan winarm?

@JakeSays Saya belum mengikuti diskusi di tingkat kompiler Dart; Saya tidak mengetahui diskusi seputar dukungan ARM, tetapi itu tidak berarti itu tidak terjadi. Anda pasti harus mengajukan permintaan fitur Dart jika Anda belum melakukannya.

Masalah terbesar adalah kurangnya dukungan OpenGL di UWP, tetapi itu harus diselesaikan dengan menggunakan ANGLE di bawah flutter.

Penyematan Windows saat ini sudah menggunakan ANGLE, dan James telah bereksperimen dengan dukungan UWP sejak awal pekerjaannya pada penyematan itu, jadi itu sudah berjalan dengan baik.

@stuartmorgan saya akan melakukannya.
Dan ya saya lupa bahwa windows embedder menggunakan ANGLE.

@JohnGalt1717 , harap tinjau Kode Etik kami . Standar komunitas Flutter memerlukan wacana yang profesional dan penuh hormat, dan secara aktif melakukan yang terbaik untuk membuat orang merasa diterima.

Ada banyak orang yang bersemangat dan berbakat yang bekerja di Flutter, dan banyak alasan bagus untuk mengejar atau tidak mengejar jalur pengembangan tertentu. Saya dapat memberi tahu Anda bahwa Anda bersemangat membuat Flutter bekerja di UWP. Begitu juga yang lain. Beberapa juga bersemangat untuk membuatnya bekerja di win32. Ini adalah proyek open source, yang diperlukan untuk mewujudkannya adalah kontribusi. Sementara itu, harap hindari menyarankan bahwa kontributor yang bekerja di jalur alternatif tidak tahu apa-apa, membuang-buang waktu, atau terlibat dalam pemikiran mundur.

Jika Anda tidak dapat melihat mengapa beberapa posting terakhir Anda gagal naik ke tingkat saling menghormati yang kami cita-citakan di komunitas ini, silakan ambil peran yang kurang aktif.

/cc @timsneath @Hixie

@dnfield mengingat saya tidak melakukan hal-hal itu, saya gagal memahami maksud Anda. Saya menguraikan sejarah faktual, dan jalan yang diambil untuk memastikan bahwa ini harus ditulis ulang, dan tidak akan mencapai paritas dengan platform lain.

Jika Anda membaca dengan seksama, saya tidak pernah menyebut siapa pun bodoh (yang secara harfiah berarti tidak mengetahui fakta dan tidak menghina, itu sendiri merupakan pernyataan fakta), saya juga tidak menuduh individu berpikir mundur. (Yaitu menargetkan platform warisan yang memotong Anda dari masa depan sambil merangkul masa lalu yang mati dan semakin tidak relevan pada 14 Januari)

Jadi saya gagal memahami bagaimana orang akan tersinggung kecuali mereka memutuskan untuk mengidentifikasi dengan generalitas yang saya gunakan dan saya tidak bisa mengendalikannya.

Jika Anda merasa tersinggung dengan pernyataan yang tidak dibuat tentang Anda, saya minta maaf karena Anda merasa seperti itu. Mungkin solusinya adalah mengambil posisi saya dengan serius dan memikirkannya secara logis dan menunjukkan bahwa Anda memang memperhitungkan fakta-fakta ini dan tidak mengabaikannya dan Anda memiliki beberapa rencana jangka panjang tentang bagaimana win32 akan bekerja pada windows yang memerlukan toko dan toko itu tidak mengizinkan penerbitan aplikasi lengan win32. Dan overhead menggunakan win32 akan memastikan bahwa windows selalu berada di belakang platform lain saat Anda memotong kemungkinan kontributor hingga 90+% dengan pilihan ini. Maka akan jelas bahwa Anda tidak bodoh atau berpikiran terbelakang dan dengan demikian apa yang saya katakan seharusnya tidak menyinggung Anda.

Sebaliknya, saya mendapatkan "Saya tersinggung (tentang sesuatu yang tidak ditujukan kepada saya), jadi Anda salah". Yang bukan argumen dalam debat apa pun.

Mengingat bahwa tidak satu pun dari posisi saya yang telah dibahas tidak peduli bagaimana hal itu diungkapkan, jelas bahwa flutter tidak mungkin pada waktu yang tepat menjadi solusi yang layak di windows dan memungkinkan paritas aplikasi yang ditulis untuk iOS, Android, dan windows. Yang memastikan bahwa tim saya tidak akan menggunakan flutter seperti yang direncanakan pada proyek kami berikutnya karena Anda memaksa kami untuk menggunakan setidaknya 2 kerangka kerja (dan dengan demikian setidaknya 2 bahasa pemrograman) sebagai hasil dari keputusan ini, jadi saya sebaiknya memilih a jalan keunggulan bukannya kompromi bahkan jika ada lebih banyak overhead.

James telah bereksperimen dengan dukungan UWP sejak awal pekerjaannya pada penyematan itu, jadi itu sudah berjalan dengan baik.

@stuartmorgan @clarkezone Apakah ada contoh yang tersedia untuk umum menjalankan Flutter di UWP? Saya ingin mencoba ini meskipun dalam tahap yang sangat awal.

Saya sedang mengerjakan prototipe dukungan UWP saat ini. Ini masih sangat awal (misalnya saya belum melihat piksel) tapi saya punya rencana bagaimana melakukannya. Itu akan tergantung pada amandemen kecil pada perubahan Angle sebelumnya yang saya buat.. Saya sudah mengkodekannya tetapi belum diserahkan ke Angle. Penafian: ini bukan merupakan komitmen untuk mengirimkan sesuatu, ini masih merupakan eksplorasi tentang apa yang mungkin. Saya akan melaporkan kembali ke sini ketika saya telah membuat kemajuan yang sedikit lebih menarik (misalnya piksel).

Terima kasih atas tanggapannya yang cepat @clarkezone

Saya menemukan di garpu FDE Anda sebuah cabang bernama uwptest . Apakah itu salah satu yang Anda bereksperimen? Saya ingin mengikuti pembaruan Anda tentang rute ini.

NP, ya, itu cabang FDE. Dalam jangka pendek akan ada banyak peretasan sementara untuk membuktikan teori-teori tertentu.

Hai, @clarkezone! Bolehkah saya bertanya, apakah pekerjaan Anda didukung oleh Microsoft? Bisakah kita mengharapkan Microsoft untuk mendukung Flutter untuk membuat aplikasi Windows? Jika demikian, apakah ada rencana untuk membuat UI Fabric tersedia untuk Flutter?

Saya pikir, baru-baru ini semakin banyak minat dalam membangun perangkat lunak perusahaan yang indah untuk meningkatkan keterlibatan/kepuasan karyawan. Saat ini saya sedang mengerjakan sejumlah proyek semacam itu. Baru-baru ini, kami merilis aplikasi Android berbasis Flutter untuk salah satu firma keuangan Empat Besar. Sementara perusahaan-perusahaan tersebut cenderung menggunakan C# dan Xamarin untuk perangkat lunak internal mereka, mereka mengharapkan kualitas UI yang lebih tinggi untuk aplikasi seluler pengalaman kerja mereka - dalam hal ini, Flutter terbukti menjadi pilihan yang lebih baik. Pada saat yang sama, Microsoft memproduksi perangkat hebat yang digunakan di lingkungan perusahaan yang dapat menjalankan aplikasi Flutter tersebut, jadi akan sangat bagus untuk melihat lebih banyak dukungan dari Microsoft dan/atau Google untuk mewujudkannya.

Halo Lukasz. Pekerjaan saya tidak didukung oleh MS, itu dilakukan secara pribadi di waktu luang saya. Setuju dengan poin Anda yang lain. FWIW Saya telah membuat beberapa kemajuan yang cukup bagus, saya memiliki prototipe Flutter runner yang bekerja ujung-ke-ujung untuk output/rendering (belum ada input), tugas besar/berikutnya yang sedang saya kerjakan adalah membuat semuanya terhubung dengan benar tanpa menarik di user32/gdi32 dll. langkah ini diperlukan untuk dapat berhasil melihat prototipe berjalan di perangkat non-desktop seperti XBOX, emulator Windows 10x dan terbukti (lain) yak shave :-)

Tolong tambahkan Windows Store !!!!

@daniele777 itulah yang sedang saya kerjakan ;-) Pembaruan status: turun dari 84 kesalahan tautan menjadi 10

Bisa saya bantu ?? untuk meningkatkan proyek ?? dapat melakukan saya tugas?

@daniele777 tidak pada titik ini, PoC dasar masih berfungsi. Kesalahan penaut dihapus tetapi ada masalah pembangunan saat Dart masuk ke loop tak terbatas dalam pipa pembangunan. Ada juga masalah lain. Saya akan berlibur selama beberapa minggu maka tidak ada kemajuan sedikit pun setelah saya kembali dan kami melalui fase PoC mungkin ada item yang dapat diparalelkan yang akan saya laporkan di sini dalam kemungkinan itu.

baik-baik saja semua yang terbaik!

Tidak bisa menunggu ini untuk sampai di sini lebih cepat. Saya mencoba flutter berbasis win32 saat ini di windows. OMG rendernya sangat pixelated sehingga terlihat seperti desain modern tetapi diimplementasikan menggunakan kerangka kerja 10 tahun. Ini bukan sesuatu yang diharapkan untuk dilihat di layar 4k. Terbiasa dengan tepi halus pada teks di aplikasi UWP dan aplikasi web modern, rendering win32 terlihat sangat kuno.

@nerocui - jika Anda melihat rendering pixelated di Windows, kemungkinan besar itu adalah bug berbeda yang tidak akan diperbaiki hanya dengan bermigrasi ke UWP. Bisakah Anda mengajukan masalah baru tentang itu dengan langkah-langkah untuk mereproduksi (dan mungkin tangkapan layar pikselasi)?

@dnfield Ini tidak seperti gambar yang pixelated. Hanya saja teks dan bentuknya dirender (sepertinya) tanpa akselerasi hardware sehingga ujung-ujungnya tidak terlihat mulus. Ini terjadi pada banyak program win32 yang saya lihat. Tidak ada langkah reproduksi, karena hanya teks dan tombol pada halaman template default.

@nerocui Itu karena aplikasi win32 tidak memiliki penskalaan DPI yang tepat dibandingkan dengan UWP. MUNGKIN dengan banyak pekerjaan untuk membuat rendering teks win32 berfungsi dengan baik, tetapi SANGAT sulit.

@ JohnGalt1717 Terima kasih, itulah poin saya. Flutter seharusnya tentang membangun aplikasi lintas platform yang indah, tetapi win32 adalah satu-satunya hal yang membuat aplikasi jelek. Itu membuat implementasi flutter pada windows terlihat lebih rendah daripada platform lain.

win32 adalah satu-satunya hal yang membuat aplikasi jelek

Seperti yang dikatakan @dnfield , sangat tidak mungkin hal ini terjadi. Render teks bergetar sedang dilakukan sepenuhnya oleh Skia, ke dalam konteks GL (diskalakan dengan benar untuk DPI). Membuat konteks GL dengan API UWP tidak akan mengubah rendering.

Harap laporkan bug dengan tangkapan layar yang menyoroti masalah yang Anda gambarkan.

Ini mungkin sesederhana penyematan yang mengabaikan tanda anti-alias di suatu tempat misalnya. Tetapi tanpa langkah-langkah untuk mereproduksi, kami tidak dapat mengetahuinya.

https://github.com/flutter/flutter/issues/53308
Masalah yang diajukan. Silakan lihat apakah itu info yang akurat/cukup.

Saya kira jika Anda mengatur DPI Anda ke 150% atau lebih buruk 175% dan memuat beberapa teks, Anda akan melihatnya.

Silakan berhenti memposting di sini tentang detail rendering; itu tidak terkait dengan masalah ini, sesuai penjelasan saya di atas, dan karenanya di luar topik.

siap dipublikasikan di windows store? ada berita?

Tidak, belum siap untuk dipublikasikan ke toko. Piksel dan input berfungsi di XBOX dan Windows 10x. Masih mengulangi pada API. Masih banyak pekerjaan yang tersisa.

Saya telah memikirkan pendekatan yang sedikit berbeda - saya belum mencobanya tetapi mungkin melakukannya jika saya menemukan waktu luang - bagaimana dengan menggunakan Flutter untuk Web dengan Skia WASM di desktop (yang dapat didukung oleh Blazor)? Saya dapat menganggap akses terbatas ke I/O sebagai satu kelemahan, tetapi rendering UI dan penanganan acara yang sebenarnya harus berfungsi seperti yang diharapkan. Windows tampaknya memiliki dukungan yang baik untuk PWA (begitu juga Chrome OS), dan pendekatan ini mungkin lebih mudah diterapkan sambil tetap mencapai kinerja yang baik.

@lukaszciastko tidak, itu akan menjadi satu Elektron lagi. Flutter harus dirender ke jendela Windows asli (HWND), yang pada gilirannya dapat disematkan ke semua jenis aplikasi Windows asli (win32, Winforms, wpf).
IMHO uwp tidak boleh dianggap sebagai jenis utama aplikasi Windows. Bahkan MS tidak melakukannya.

@clarkezone Saya tidak sabar untuk melihat pekerjaan Anda digulirkan ke proyek sehingga kami dapat menjalankan aplikasi yang berjalan di Windows

jadi kita bisa aplikasi yang berjalan di Windows

Sudah dimungkinkan untuk menjalankan aplikasi Flutter di Windows , dan telah dilakukan selama beberapa waktu. Masalah ini sekarang khusus tentang UWP.

Saya akan memperbarui judul untuk membuatnya lebih jelas.

jadi kita bisa aplikasi yang berjalan di Windows

Sudah dimungkinkan untuk menjalankan aplikasi Flutter di Windows, dan telah dilakukan selama beberapa waktu. Masalah ini sekarang khusus tentang UWP.

Saya akan memperbarui judul untuk membuatnya lebih jelas.

Stuart, saya belum melihat dokumentasi tentang cara membuat dan menjalankan aplikasi Flutter di Windows. Bisakah Anda memberi tahu saya di mana saya dapat menemukan info ini?

@steskalja Anda memiliki beberapa dokumen di sini https://github.com/flutter/flutter/wiki/Desktop-shells#create
Dalam resume, Anda harus berada di cabang master dan menjalankan:
flutter config --enable-windows-desktop

Dalam proyek Anda ingin mencobanya:
flutter create . // Akan menambahkan folder windows, hati-hati dengan perubahan folder android dan ios,
flutter run -d windows

Lebih khusus lagi, pemikiran saya seputar dev ini. adalah berharap ada hubungan dengan Project Union. Saya suka flutter dan sangat senang bahwa SDK ini adalah sesuatu. Saya prihatin dengan masa depan aplikasi Win32 di OS Windows.

Apa basis pengetahuan yang dimiliki tim flutter?

Ketika Anda menyelesaikan ini, apakah itu berarti kami dapat mengimplementasikan plugin Flutter di C# dan menggunakan dari plugin semua paket API, SDK, dan NuGet yang tersedia untuk aplikasi UWP?

@kinex Saya ingin tahu mengapa Anda menganggap keduanya terkait. Menambahkan dukungan .net untuk plugin akan relatif mudah, dan tidak memerlukan UWP. Ini agak di luar ruang lingkup untuk flutter.

@JakeSays Dari pemahaman saya lingkungan eksekusi (UWP dalam kasus ini) mendefinisikan bagaimana plugin dibuat dan apa yang tersedia untuk plugin. Jadi mungkin jawaban untuk pertanyaan saya adalah "tentu saja", tetapi saya tidak sepenuhnya yakin.

Di plugin Android, Anda dapat menggunakan Kotlin (atau Java) dan API, SDK, dan paket Android apa pun. Di plugin iOS, Anda dapat menggunakan Swift (atau Objective-C) dan API, SDK, dan Pod iOS apa pun. Saya mengharapkan hal yang sama dengan UWP dan itu akan membuat ini benar-benar luar biasa.

Mempermudah penggunaan C# dalam plugin adalah sesuatu yang ingin kami lakukan, tetapi ortogonal terhadap dukungan UWP.

Pelari UWP berarti dapat menggunakan API khusus UWP dalam plugin, tetapi pemahaman saya adalah bahwa sangat sedikit API yang benar-benar khusus UWP (mis., per dokumentasi ini "Aturan umumnya adalah bahwa aplikasi desktop dapat memanggil Platform Windows Universal (UWP) API.")

@stuartmorgan Itu sebenarnya tidak benar. Akhirnya dengan reuni proyek yang AKAN menjadi kenyataan, tetapi tidak sekarang dan bahkan kemudian itu untuk perangkat lunak lama, bukan aplikasi baru seperti halnya dengan flutter. Ada banyak hal yang tidak dapat Anda lakukan tanpa UWP (yaitu mengakses plugin untuk berbagai codec video, pemutar video DRM, dll.) Itulah sebabnya saya selalu memiliki masalah dengan pendekatan yang diambil oleh tim flutter . Ada 0 sistem operasi yang didukung oleh Microsoft (dan dengan demikian aman) yang tidak dapat menjalankan UWP di pasar (yaitu menargetkan Windows 7 konyol dan tidak boleh menjadi tujuan Flutter, hanya Windows 10 yang harus menjadi target). Jadi, ada 0 alasan mengapa ini bukan UWP asli sejak hari pertama.

Lebih buruk lagi, semua Windows 10 S dan varian TIDAK BISA menjalankan aplikasi win32 sehingga flutter akan dikunci dari itu. Mereka juga akan dikunci dari perangkat ARM/ARM64 juga kecuali jika mereka berjalan di UWP dan Windows X yang menjalankan aplikasi win32 dalam wadah buruh pelabuhan menggunakan Remote Desktop akan memiliki pengalaman yang jauh lebih buruk daripada aplikasi UWP asli sebagai hasilnya, terutama ketika datang ke kinerja grafis.

Jadi jika google/flutter berpikiran maju dengan dukungan Windows, itu sepenuhnya akan menjadi UWP sejak hari pertama yang memungkinkan C++ dan .NET (sebagian besar pengembang Windows menggunakan .net, bukan C++) DAN mendukung semua perangkat windows saat ini DAN masa depan dengan yang terbaik kemungkinan interaktivitas. Pendekatan win32 saat ini berpandangan pendek dan kurang diteliti (yang menunjukkan blindspot yang sangat besar di dalam Google yang memprihatinkan mengingat miliaran perangkat yang menjalankan windows).

Mengingat bahwa Skia sudah berjalan di UWP, ada sedikit alasan mengapa ini tidak menjadi lingkungan de facto dan fokus 100% dari upaya Google di Windows. (dan sungguh, bekerja dengan Microsoft untuk membuat seluruh simulator jarak jauh Xamarin dan menyebarkan langsung ke perangkat iOS di Windows juga berfungsi)

@JohnGalt1717 Anda telah membuat argumen ini beberapa kali dalam masalah ini; mengulanginya tidak konstruktif. Jika Anda ingin mempercepat pengembangan dukungan UWP, Anda dipersilakan untuk berkontribusi di dalamnya.

@stuartmorgan Saya ingin tahu pendapat Anda tentang penggunaan c#. Saya punya beberapa ide tentang bagaimana membuatnya bekerja.

@kinex sebenarnya plugin flutter pada dasarnya hanyalah kode C yang berinteraksi dengan flutter melalui api sederhana. Untuk menulisnya dalam C# pada dasarnya memerlukan ".net plugin" yang ditulis dalam C yang akan menjadi host CLR dan menjembatani dunia flutter dan c#. Secara teoritis dimungkinkan untuk menulis plugin flutter di java di windows, atau bahasa apa pun selama lingkungan bahasa dapat berjalan di sistem operasi target.

@JakeSays Saya mengajukan https://github.com/flutter/flutter/issues/64958 dengan pemikiran saya saat ini tentang C#, karena saya tampaknya tidak pernah mengajukannya di sini. Siapa pun yang tertarik dengan C # secara khusus harus mengikuti masalah itu.

@JakeSays Ok terima kasih atas klarifikasinya. Tanpa pengetahuan yang lebih baik, saya berasumsi seperti ini: Plugin C# (mungkin diimplementasikan sebagai .NET library?) akan dimuat oleh runner UWP dan kode Dart dapat memanggilnya melalui proses runner UWP. Dalam arsitektur imajiner ini, plugin C# tersebut dapat mengakses paket API, SDK, dan NuGet yang sama seperti perpustakaan .NET mana pun yang dihosting oleh aplikasi UWP.

Bagaimanapun, senang mengetahui ada rencana mengenai dukungan C#. Saya percaya akan ada lebih banyak pembuat plugin (= lebih banyak plugin lebih cepat) dan plugin yang lebih stabil jika C# dapat digunakan daripada C++.

@kinex Anda benar bahwa plugin c# akan memiliki akses ke perpustakaan .net lengkap, serta paket nuget. Ketika kode c# dijalankan, ia berjalan di lingkungan .net penuh (atau .net core sesuai kasusnya).

FFI adalah solusi plugin yang jauh lebih ringan. Lihat https://pub.dev/packages/win32 , misalnya. Tapi ini jauh di luar topik untuk masalah yang seolah-olah tentang membangun pelari berbasis UWP.

@timsneath Saya pikir ffi dan plugin memecahkan dua masalah yang berbeda. iirc ada banyak batasan dengan apa yang dapat Anda lakukan dengan ffi (misalnya sinkron).

Sekali lagi, saya telah mengajukan #64958 untuk plugin C#; silakan lanjutkan diskusi apa pun tentang C# tetapi bukan UWP di sana.

hal-hal baik terjadi
seseorang harus memberi tahu Microsoft untuk berkontribusi di sini juga

@airbus5717 apa maksudmu? Microsoft berkontribusi pada diskusi di sini sepanjang waktu.

Saya pikir ada baiknya membagikan pembaruan September 2020 tentang keadaan eksperimen Flutter UWP yang telah saya kerjakan. Kemajuan lebih lambat dari yang saya inginkan karena ini adalah proyek waktu luang/usaha terbaik yang telah saya kerjakan hanya pada malam hari dan pada akhir pekan. Namun, saya telah dapat membuat kemajuan yang layak selama enam bulan terakhir atau lebih dan membuat beberapa skenario berfungsi yaitu:

• penyematan bukti konsep WinRT Flutter menggunakan CoreWindow bersama dengan API input WinRT yang berjalan di kotak pasir AppContainer: https://github.com/clarkezone/engine
• uji coba Flutter UWP runner yang sesuai (hanya 115 baris c++!) dengan pengalaman Flutter demo menggunakan Flutter Gallery : https://github.com/clarkezone/fluttergalleryuwp
• menggunakan ini saya berhasil menerbitkan versi paket MSIX dari Galeri Flutter ke Microsoft Store, melewati pemeriksaan API WAC untuk sertifikasi toko (akhirnya :-))

Masih banyak yang harus dilakukan untuk membuatnya menjadi sesuatu yang siap produksi dan saya tidak tahu berapa lama waktu yang dibutuhkan, tetapi ini jelas menunjukkan bahwa Flutter UWP layak.

Ada beberapa masalah besar yang tersisa untuk dipecahkan seperti bagaimana melakukan integrasi perkakas dengan flutter create , bagaimana membuat hot reload dan dukungan observatorium bekerja dan banyak lagi. Lebih detail di sini .

Pada contoh di bawah ini, saya dapat mengambil sumber jam Flutter Particle dari https://github.com/miickel/flutter_particle_clock membangunnya dalam mode rilis yang menargetkan Windows, ambil biner app.so yang dihasilkan, bungkus untuk UWP menggunakan Flutter Runner yang sama seperti yang digunakan di atas untuk Flutter Gallery, publikasikan ke Microsoft Store dan instal di XBOX saya: