Bagaimana dengan .ui saja?

Mungkinkah perbedaan ini berguna untuk kasus non-pulau juga, atau akan lebih membingungkan?

Atau jika ini terutama untuk membantu membedakan antara misalnya WPF dan WinUI Xaml dalam solusi yang sama lalu bagaimana dengan konvensi seperti .winui.xaml atau .island.xaml ? Itu mungkin akan membuatnya lebih mudah untuk menggunakan alat yang ada.

Apakah ini untuk skenario Kepulauan XAML atau di mana saja? Untuk setiap skenario lain, saya tidak melihat apa nilainya, selain menciptakan kebingungan dan memaksa orang untuk bermigrasi (dan mungkin merusak kompatibilitas mundur untuk banyak alat seperti versi VS yang lebih lama). Konvensi seperti "whatever.winui.xaml" mungkin tidak terlalu merusak, tetapi saya masih melihatnya berguna dalam lingkup Pulau, tidak di tempat lain.

Mengubah judul yang diberikan, saya tidak ingin membatasi diskusi menjadi hanya Kepulauan XAML.

Saya katakan tetap menggunakan .xaml. Cakupan (dan nama) dari WinUi mungkin berubah untuk menyertakan platform lain di samping windows (Mungkin melalui UnoPlatform?). Apa yang terjadi jika nama proyek diubah?

Saya lebih condong ke arah NO. Microsoft telah melakukan terlalu banyak penggantian nama untuk produk dan layanan yang terkadang merugikan produk/layanan atau penggunanya (pendapat). Ini adalah nama lain lagi.

Apakah ini untuk skenario Kepulauan XAML atau di mana saja? Untuk setiap skenario lain, saya tidak melihat apa nilainya, selain menciptakan kebingungan dan memaksa orang untuk bermigrasi (dan mungkin merusak kompatibilitas mundur untuk banyak alat seperti versi VS yang lebih lama). Konvensi seperti "whatever.winui.xaml" mungkin tidak terlalu merusak, tetapi saya masih melihatnya berguna dalam lingkup Pulau, tidak di tempat lain.

Di mana pun

Saya pikir XAML harus tetap .xaml tetapi jika sesuatu yang baru muncul baik untuk menggantikan atau berguna bersama XAML tradisional, maka ekstensi .winui dapat berguna untuk itu. #804 :)

Permintaan ini benar-benar membingungkan saya ... Saya harus membaca masalah ini dua kali untuk memahami apa yang sedang terjadi ... Ini BENAR-BENAR akan memecah ekosistem xaml lebih dari dialek yang berbeda yang pernah dilakukan ..

Kehilangan kata-kata sekarang...

@liquidboy yah itu setidaknya satu umpan balik yang jelas untuk tidak membuat perubahan ini :) Terima kasih telah meminjamkan suara Anda.

Saya suka ide dari @jesbis , mungkin kita bisa menambahkan *.islands.xaml yang membantu untuk lebih mudah membedakan perbedaan antara file XAML yang berjalan dalam konteks Kepulauan vs. tidak.

Penasaran: apakah lebih baik memiliki .islands.xaml yang hanya berlaku untuk file XAML di sebuah Pulau, atau hanya menggunakan .winui.xaml sebagai ekstensi keseluruhan di mana saja? Saya tidak yakin mana yang lebih saya sukai dari dua ide itu.

Pilihan saya adalah untuk ".islands.xaml" atau serupa dengan pola yang direkomendasikan (tetapi tidak diterapkan secara ketat) di pulau-pulau, dan di mana pun file .xaml masih merupakan file .xaml. Dengan begitu, kami menghindari dampak yang tidak perlu kepada orang-orang yang tidak menggunakan pulau.

Kekhawatiran terbesar saya datang dari semua perkakas. Saya tidak punya masalah dengan ekstensi yang berbeda, tetapi ini berarti bahwa setiap alat yang bergantung pada ekstensi file .xaml perlu diperbarui (saya memikirkan hal-hal seperti R#, XamlStyler , dll). Dukungan perkakas di sekitar xaml sudah terasa seperti sedang berjuang, dan ini sepertinya akan memperburuknya.

$0,02 saya

Mungkin judul masalah harus diubah menjadi sesuatu seperti:
Haruskah file XAML disertakan untuk Kepulauan Xaml, memiliki ekstensi file yang berbeda dengan proyek WinUI 3?

Saya sangat mendukung untuk menyimpan .xaml di sana. Mungkin Anda menggunakan .ui.xaml atau .xaml.ui tetapi teknologinya kuat dan bantuan tetap tersedia. Di sisi lain, sayangnya xaml memiliki beberapa stigma di sekitarnya setelah jebakan kinerja wpf, silverlight, dan windows phone, sehingga nama file yang lebih bersih dapat membantu mengubah sudut. Saya masih menyukai xaml, tetapi kita tidak perlu bingung lagi tentang nama teknologi kecuali jika dipikirkan dengan jelas.

Saya pikir itu ide yang baik untuk memilikinya hanya sebagai .ui karena jika winui pernah menjadi lintas platform (seperti banyak barang windows), itu akan lebih cocok.

Ini berarti bahwa itu akan menjadi bukti di masa depan.

File kode akan memiliki ekstensi .ui.cs yang cukup jelas dan mudah dibaca.

.winui.xaml

Jadi itu berarti kita akan memiliki file .winui.xaml.cs? astaga..

Gunakan format json. Ini tahun 2020.

JSON keras dan tidak terlalu ramah untuk digunakan.

Gunakan format json. Ini tahun 2020.

Format JSON adalah untuk komputer untuk membaca, bukan untuk manusia. Sulit dibaca dan tidak terlihat bagus.

Saya pikir .winui akan membuat pemula menyerah. Karena kita akan berpikir kita harus belajar bahasa baru. Dan sekarang kami memiliki WinForms dan WPF dan UWP dan SL dan ASP dan ASP.NET Core. Kita harus menghabiskan lebih banyak waktu untuk mempelajarinya tetapi tidak mewarisi. Saya tidak berpikir kita harus selalu membuat teknologi baru.

Maaf, saya dan banyak teman saya tidak suka belajar hal baru. Jika kita tidak berharap menjadi minoritas, maka kita harus membuat teknologi dapat diwariskan dan dapat digunakan kembali dan kompatibel.

Menurut pendapat saya, solusi yang lebih elegan untuk "XAML yang mana" adalah bergantung pada namespace xmlns default, seperti yang disarankan oleh @grokys dalam komentar ini: https://github.com/AvaloniaUI/AvaloniaVS/issues/95# issuecomment -541078633

Kami tidak melakukan ini dengan UWP, tetapi mungkin kami dapat mengubahnya untuk WinUI.

Menurut pendapat saya, solusi yang lebih elegan untuk "yang mana XAML" akan bergantung pada namespace xmlns default, seperti yang disarankan oleh @grokys dalam komentar ini: AvaloniaUI/AvaloniaVS#95 (komentar)

Kami tidak melakukan ini dengan UWP, tetapi mungkin kami dapat mengubahnya untuk WinUI.

Anda dapat memperkenalkan yang setara dengan Doctype, seperti HTML?

Anda dapat memperkenalkan yang setara dengan Doctype, seperti HTML?

Mungkin, tapi kita tidak harus melakukannya. Namespace default harus yang membedakan setiap platform yang berbeda (mereka melakukannya di belakang kode)

Dukungan perkakas di sekitar xaml sudah terasa seperti sedang berjuang, dan ini sepertinya akan memperburuknya.

@keboo ini sangat menyentuh saya, dan merupakan sesuatu yang saya dorong dengan keras untuk kami perbaiki dan lakukan dengan benar.
Fakta bahwa kita berada di dunia di mana kita tidak dapat membedakan mereka (untuk skenario pulau) adalah produk dari bagaimana perkakas telah berkembang selama bertahun-tahun. Semuanya benar-benar terpisah, dan hampir tidak mungkin untuk merasionalisasi perbedaan antara dialek yang berbeda. Saya ingin mengubah ini, dan mulai membuat penguraian dan kompilasi XAML sesuatu yang dapat dengan mudah dibagikan di semua dialek XAML, di mana dalam contoh ini, WinUI dan WPF menggunakan mesin dasar yang sama. Perkakas tersebut harus mampu-plugin seperti yang dideklarasikan oleh namespace default dan dapat dikustomisasi jika diperlukan. Menurut pendapat saya, kita tidak perlu lebih dari itu untuk membuat skenario ini bekerja dengan baik. Meskipun ini adalah upaya besar, bagi saya itu adalah hal yang benar untuk kita semua lakukan.

@stevenbrix Platform saat ini akan memahami ketika XAML digunakan dalam situasi Pulau, tetapi apa yang saya baca dalam pertanyaan tentang masalah ini, adalah cara bagi pengembang untuk memberi tahu dan memahami bagaimana file .xaml akan digunakan dalam WinUI 3.0 proyek.

Adapun perkakas XAML secara umum, perlu dilakukan ulang total dari pengalaman waktu desain IMO. Ekspresi Blend adalah yang terakhir kali desain dan pengembangan XAML terasa tingkat atas.

Karena sifat XAML, baik itu bentuk tertulis, dan bentuk visual. Desain visual XAML telah mengambil kursi belakang untuk membawa Intellisense ke kualitas yang baik. Jika ada pengalaman desain XAML yang kuat, berkinerja, dan mudah diprototipe dan dipoles - yang dapat menghidupkan kembali komunitas.

Pendekatan plugin, yang tidak memerlukan banyak pekerjaan untuk dilakukan oleh vendor kontrol atau toolkit, sambil tetap memberikan waktu desain yang baik, palet alat, pengalaman properti elemen - bisa sangat membantu. Saat XAML beralih ke faktor bentuk non-tradisional lainnya, alur kerja desain perlu dipertimbangkan. Tampilan Dua Panel (Neo dan Duo), permukaan XAML yang dihosting non-jendela, integrasi Shell, proyek kerangka kerja campuran (pulau xaml, campuran GDI dan WinUI), Hololens Spatial 3D, Rotating Surface Hubs, dll.

Tapi mungkin markup deklaratif bukan lagi cara ideal untuk menanganinya. Atau mungkin harus ada lebih banyak pemisahan antara konten XAML, dan gaya XAML? Seperti halnya HTML dan CSS?

WinUI terasa seperti kesempatan yang baik untuk tidak hanya membawa hal-hal sebagaimana adanya, tetapi juga untuk merencanakan dekade mendatang.

Tidak. Saya tidak mengerti maksudnya. Itu tidak menyelesaikan apa pun.
Jika ada, itu menciptakan masalah dengan editor yang sudah mengetahui ekstensi xaml.
Saya bekerja dengan wpf, uwp dan bentuk xaml setiap hari dan saya tidak pernah bingung karena ekstensi.

Bukankah inti dari Xaml lebih mudah untuk perkakas? Tidak bisakah perkakas mencari tahu ini tanpa bergantung pada ide kuno tentang ekstensi file?

Maksud saya secara umum, jika tidak ada yang berubah dalam kerangka UI, yaitu masih XAML, jangan lakukan itu.

Jika itu adalah kerangka UI yang benar-benar baru, maka saya tidak akan melihat masalah.

Saya juga tidak tahu mengapa Anda ingin membedakan komponen XAML untuk pulau dengan islands.xaml yang diusulkan. Apakah itu akan melakukan sesuatu yang berbeda dalam perkakas atau hanya untuk keterbacaan dalam suatu solusi?

Pikiran pertama saya adalah bahwa saya sama sekali tidak menyukai ide ini. Tapi mungkin saya tidak melihat masalah sebenarnya yang bisa dipecahkannya, dan mungkin saya tidak mengerti maksudnya.

Jika ada file dengan xaml di dalamnya, saya ingin itu menjadi file .xaml. Di masa lalu, tidak pernah terpikir oleh saya bahwa saya ingin memiliki file .xaml UWP yang diberi nama berbeda dari file .xaml WPF.

Hal berikutnya adalah bahwa nama kerangka kerja dalam ekstensi file tampaknya bukan ide yang baik, karena nama kerangka kerja mungkin berubah, dan XAML adalah 4ever XAML.

Jadi, pendapat saya adalah: Pasti tetap dengan .xaml.

Tapi apa saja pilihan dengan ekstensi file .xaml?
Ekstensi file .islands.xaml lainnya? Itu berarti bahwa ekstensi file digunakan tidak hanya untuk menggambarkan format, tetapi juga isi file. Mhm... Tapi kelebihan yang satu ini bisa kamu jadikan optional untuk developer. Jika mereka ingin menggunakannya, mereka dapat memanggil file mereka .islands.xaml dan perkakas akan mengambilnya dengan ikon yang berbeda, dll.

Namespace default lainnya juga merupakan opsi yang valid. Tapi itu berarti untuk perkakas yang harus melihat ke dalam setiap file .xaml untuk mengetahui jenis file itu. Dan itu juga berarti bahwa dialek XAML sedikit menyimpang karena namespace root yang lain.

Tapi sekarang pemikiran yang sama sekali berbeda:

Jika saya melakukannya dengan benar, semua perubahan ini hanya sangat membantu untuk kasus Pulau XAML di mana Anda menggabungkan platform dalam solusi yang sama, bukan? Karena jika hanya menggunakan WinUI, Anda tahu setiap file XAML menggunakan WinUI. Saya tidak yakin apakah Kepulauan XAML akan menjadi skenario utama untuk WinUI atau tidak. Di masa lalu ketika WPF diperkenalkan, kami juga memiliki interop WPF dan WinForms, dan sejujurnya, saya jarang melihat pengembang menggunakan kontrol WPF dalam aplikasi WinForms mereka. Sebagai gantinya, mereka terus menggunakan WinForms di WInForms dan mereka memulai proyek baru dengan WPF alih-alih WinForms. Dan mungkin hal yang sama berlaku untuk WinUI 3, dan saya pikir itu akan terjadi. Kepulauan XAML adalah cara yang bagus untuk memodernisasi, tetapi menurut pengalaman saya, pengembang hanya akan melakukannya jika mereka benar-benar membutuhkan kontrol dari WinUI di aplikasi WPF/WinForms mereka. Jika tidak, mereka melanjutkan di tumpukan lama dan mereka memulai aplikasi baru di tumpukan baru. Perhatikan bahwa ini tidak harus menjadi kebenaran, itu hanya pengalaman saya. :-)

Itu berarti kita berbicara tentang mengubah nama file untuk skenario yang mungkin bukan skenario utama untuk platform. Dan saya rasa itu sebabnya saya pikir itu tidak layak. Bagaimana jika pengembang WPF/UWP/Silverlight/Windows Phone membuat proyek WinUI 3 baru? Mereka akan berpikir

Mengapa mereka mengubah ekstensi file .xaml menjadi ...?

Tolong jangan hapus ekstensi file .xaml.

Tolong jangan pergi mengubah ekstensi!

Bertahun-tahun yang lalu kami mulai menggunakan ekstensi .paml di Avalonia tetapi pada akhirnya kembali ke .xaml karena masalah yang ditimbulkannya: sudah ada perkakas di IDE untuk menangani XAML (tidak peduli seberapa buruknya , setidaknya itu sesuatu!).

Jika kita mengharapkan setiap dialek XAML memiliki ekstensi filenya sendiri, maka setiap proyek yang ingin menggunakan XAML harus menulis 100% perkakas dari awal - bahkan hal-hal seperti perkakas untuk mengganti nama file akan membutuhkan untuk ditulis ulang setiap kali untuk juga mengganti nama kelas codebehind dll.

Seperti @stevenbrix disebutkan di atas, ada cara yang sangat baik untuk mengetahui dialek XAML mana yang digunakan file yang merupakan namespace default di bagian atas file. Sebagai langkah pertama, buat perkakas menghormati ini.

Kemudian buka layanan bahasa XAML, sediakan API untuk berinteraksi dengan desainer dan semua orang bisa mendapatkan keuntungan ;)

cantik tolong ;)

Satu lagi alasan untuk tidak: UWP sudah berjuang dengan masalah adopsi. Mengganti namanya menjualnya sebagai teknologi lain, daripada "itu kurang lebih sama dengan wpf".
Sudah ada masalah yang lebih besar dengan WinUI 3.0 yang melanggar perubahan yang secara signifikan akan merusak ekosistem uwp yang ada. Jangan menambahkan hal lain yang berbeda.
Itu masih xaml, hanya mengenai set API yang berbeda, sama seperti c# masih c# bahkan saya menggunakannya untuk kerangka UI yang berbeda. Kode dan API yang dapat saya gunakan berubah, tetapi bahasanya masih sama.

Saya memilih tidak, saya tidak melihat manfaat, hanya menambah kebingungan.

Satu lagi alasan untuk tidak: UWP sudah berjuang dengan masalah adopsi. Mengganti namanya menjualnya sebagai teknologi lain, daripada "itu kurang lebih sama dengan wpf".
Sudah ada masalah yang lebih besar dengan WinUI 3.0 yang melanggar perubahan yang secara signifikan akan merusak ekosistem uwp yang ada. Jangan menambahkan hal lain yang berbeda.
Itu masih xaml, hanya mengenai set API yang berbeda, sama seperti c# masih c# bahkan saya menggunakannya untuk kerangka UI yang berbeda. Kode dan API yang dapat saya gunakan berubah, tetapi bahasanya masih sama.

@dotMorten Ha, saya memiliki pemikiran yang sama dengan C#. Jika kita memanggil file .xaml .winui , kita harus memanggil file .cs .wincode untuk membuatnya konsisten. :-)

Mungkin saya masih kehilangan sesuatu, tetapi bagi saya itu menyebabkan lebih banyak kebingungan dan saya tidak melihat manfaat sebenarnya dari itu.

2 sen saya, tolong gunakan _.xaml_.
Tolong satukan hal-hal daripada menyimpang.

Bagaimana jika Anda ingin berbagi cuplikan XAML kecil antara WPF dan WinUI? Saya kira pasti ada BEBERAPA tumpang tindih, bukan? Itu akan membuat proyek bersama menjadi kurang berguna... atau benarkah ada perbedaan besar? Jika sebagian besar XAML serupa, pertahankan ekstensi yang sama. Jika formatnya PALING berbeda dari XAML transisi maka mungkin agak lebih dapat diterima untuk mengubah ekstensi. Pertanyaan sebenarnya kemudian adalah seberapa dekat formatnya dengan aslinya?

XAML juga digunakan di Xamarin yang menargetkan tidak hanya Windows tetapi iOS, Android, macOS...

Mengganti .xaml dengan .winui akan menciptakan situasi di mana Xamarin akan menyimpan .xaml untuk file XAML (mengapa seseorang akan menggunakan .winui untuk iOS atau Android?) dan target Windows seperti UWP/WPF... akan pindah ke .winui untuk file XAML .

TL;DR satu format file/konvensi dua nama (.winui untuk Windows, .xaml untuk Xamarin), bagi saya itu membingungkan.

Ekstensi harus .xaml sebagai sintaks konten xaml, ekstensi lain hanya akan membuat kebingungan.
Saya memilih sesuatu seperti .winui.xaml

tetap dengan ".xaml", Ini kuat

Saya harus mengatakan, Microsoft memiliki masalah penamaan patologis!

Dan yang satu ini benar-benar mengungguli mereka semua.

Tidak

Jika Anda perlu memiliki UWP XAML dan WPF XAML dalam file proyek yang sama, gunakan Custom Tool yang baru.

Dengan cara ini, alat akan mendeteksi jika file XAML menggunakan UWP XAML atau WPF XAML dan mengirimkannya ke kompiler yang benar melalui target msbuild.

Cara yang lebih baik adalah dengan membakukan bahasa XAML, sehingga kita dapat mengembangkan compiler umum, format biner, dan framework lib.

Itulah bagaimana saya akan melakukannya!

Karena Anda meminta, jangan lakukan itu.

Jika perkakas tidak dapat membaca file untuk melihat perbedaannya, maka WORSE CASE harus menjadi konvensi ".winui.xaml" yang tidak diperlukan atau sejenisnya. Sekali lagi kuncinya adalah NOT-REQUIRED . Hanya file ekstensi xaml yang berfungsi dengan baik tetapi mungkin kehilangan beberapa alat yang disempurnakan.

Sementara saya memahami ide di balik ini, saya pikir ini adalah solusi yang buruk.
Pertama, WinUI adalah nama komersial kerangka kerja, bukan format file. Bagaimana jika seseorang memutuskan versi 4 perlu mengubah nama menjadi UniversalUI atau yang lainnya? Anda akan diakhiri dengan nama kerangka kerja yang berbeda dari ekstensi file, berbeda dari format file. Ini bisa menjadi mimpi buruk.

Kedua, dapat merusak kompatibilitas dengan alat dan dokumentasi yang ada. Pengembang masa depan tidak dapat menjelaskan bahwa file WinUI adalah xaml internal sehingga mereka tidak akan menemukan dokumen xaml sebagai dokumen yang relevan.

Ketiga, itu akan memecah lebih banyak bahasa UI yang digunakan dalam produk Microsoft. Saya benar-benar merasa kita perlu lebih ke standar di Xaml, jadi produknya tidak begitu penting. C# sama untuk Xamarin, Net Core, Windows 10 atau WPF, mengapa XAML harus berbeda?

Biarkan orang mengatur proyek mereka dan mengatur kode sehingga tidak membingungkan bagi mereka.

Gunakan format json. Ini tahun 2020.

@rickydatta Bahkan pada tahun 2020 web menggunakan HTML alih-alih JSON untuk menentukan antarmuka pengguna. Ada banyak alasan mengapa bahasa markup seperti HTML dan XAML bagus untuk mendefinisikan UI. JSON bagus untuk beberapa hal, tetapi tidak untuk mendefinisikan UI. Saat Anda menggunakan JSON untuk UI dan Anda mencoba membangun fitur seperti pengikatan data, referensi sumber daya statis, dll., Anda akan melihatnya menjadi sangat tidak terbaca. Tapi itu di luar topik di sini, jadi biarkan saja. Jika Anda menginginkan JSON, silakan buat masalah baru dan lihat bagaimana komunitas bereaksi terhadapnya. :-)

Saya benar-benar mencoba untuk menghindari berkomentar di sini karena sebagian besar dari ini telah dikatakan, tetapi saya sudah menyerah. Maaf. Saya lemah.

Jangan lakukan ini.

Jika Anda ingin melakukan perubahan, perlu ada seperangkat manfaat yang jelas yang lebih besar daripada negatifnya.

Apa manfaat potensialnya?

• Ini akan menghindari kemungkinan kebingungan bagi orang-orang yang memiliki beberapa file .xaml yang seluruhnya berisi kontrol WinUI dan beberapa file .xaml yang tidak.
• Membantu mengaktifkan perkakas untuk menentukan cara bekerja dengan konten file .xaml yang berpotensi berbeda.

Itu dia.
Saya telah membaca ulang seluruh utas ini tiga kali, dan saya tidak dapat melihat manfaat potensial lainnya yang tercantum di sini.

Apa potensi kerugiannya?

• Itu akan menimbulkan kebingungan.
  -- "Apakah ekstensi baru ini?" "Apa yang harus saya buka?" "Apa bedanya dengan ...?" "Mengapa mereka mengubahnya?"
  -- Ekstensi apa yang Anda gunakan untuk file yang hanya berisi beberapa kontrol WinUI, saat mencampur elemen UWP XAML dan WinUI3 yang ada? Atau apakah saran ini menyiratkan bahwa kemampuan ini akan hilang? (Lihat, hanya dengan membuat saran untuk mengubah ekstensi file, Anda sudah memperkenalkan lebih banyak kebingungan dan FUD. Jika hal-hal seperti ekstensi file masih dapat berubah, mungkin saya harus menunggu untuk melihat WinUI, dalam kapasitas apa pun, hingga lebih stabil .Beberapa orang telah menyuruhku untuk menyelidiki Flutter. Mungkin masa depan yang lebih baik bagiku terletak di sana.)
  -- Pemahaman saya tentang salah satu nilai jual Pulau Xaml di aplikasi WPF yang ada adalah bahwa itu berarti kemampuan untuk menggunakan kembali keterampilan dan pengetahuan yang ada dalam bekerja dengan XAML. Perubahan ini menunjukkan bahwa ini bukan hanya XAML, jadi ini adalah hal lain yang harus dipelajari, dan juga penghalang potensial lainnya untuk adopsi.)

• Ini tidak perlu.
  -- Jika orang ingin memecah file dalam suatu solusi, mereka sudah dapat melakukannya dengan berbagai cara: proyek yang berbeda; direktori yang berbeda; awalan atau akhiran pada nama file; menggunakan beberapa/sub-ekstensi; atau bersarang file di dalam VS Solution explorer. Tidak jelas bagaimana ekstensi baru atau memaksa semua orang untuk menggunakan beberapa/sub ekstensi lebih baik daripada opsi ini.
  -- [Default] Namespaces di dalam file sudah memberi tahu perkakas dialek XAML apa yang digunakan dan apa yang mungkin dengannya. (Mungkin ada beberapa masalah yang tidak terdokumentasi di area ini yang berarti ini tidak mungkin, tetapi jika itu masalahnya, maka informasi lebih lanjut diperlukan tentang mengapa mengubah ekstensi file adalah solusi terbaik untuk masalah itu.)

• Itu mengabaikan sejarah.
  -- Saya sebelumnya telah bekerja dengan solusi yang berisi proyek yang menargetkan WPF, Silverlight, dan Windows Phone. Mereka semua menggunakan dialek XAML yang berbeda tetapi saya tidak pernah bingung tentang mana yang digunakan atau apa yang dapat saya lakukan dalam file. Saya telah bekerja dengan solusi yang mengandung XAML untuk UWP dan Xamarin.Forms tetapi tidak mengalami kebingungan yang diprediksi dalam asumsi di balik masalah ini. Saya juga telah berbicara dengan banyak pengembang lain dengan solusi serupa, dan saya belum pernah mendengar orang lain mengatakan bahwa menggunakan ekstensi yang berbeda akan membantu mereka.
  -- Dari semua kritik yang saya dengar tentang perbedaan dialek XAML, kebingungan berdasarkan penamaan file tidak pernah menjadi salah satunya.
  -- Pengembang umumnya tidak suka ketika Anda memberi tahu mereka bagaimana mereka harus memberi nama dan menyusun file dan proyek tanpa alasan yang bagus. Akan jauh lebih baik untuk mendokumentasikan panduan dan praktik yang direkomendasikan/disarankan untuk skenario seperti bekerja dengan proyek yang berisi file dengan konten serupa.
  -- Salah satu alasan besar mengapa penggunaan ekstensi yang lebih luas pada file tidak pernah dilakukan adalah karena File Explorer (atau apa pun yang mencantumkan konten sistem file--termasuk pemilih dan dialog yang disediakan OS) dapat membawa lebih banyak kebingungan ketika mereka ( dikonfigurasi untuk--yang merupakan default) menyembunyikan ekstensi file yang diketahui. Ini dapat membuat MyClass.winui.xaml terlihat seperti MyClass.winui yang kemudian menimbulkan pertanyaan dan kebingungan tentang apa file itu, dari mana asalnya, mengapa ditampilkan, dll.
  -- Menambahkan beberapa/sub ekstensi meningkatkan panjang file sehingga meningkatkan kemungkinan mengalami masalah terkait MAXPATH. Mungkin suatu hari ini tidak akan menjadi masalah, tetapi kami belum sampai di sana. Saya tidak suka melihat pengembang dipaksa untuk memberikan file mereka (dan kelas, karena keduanya biasanya disinkronkan) nama yang kurang deskriptif karena perkakas sekarang membutuhkan enam karakter tambahan untuk ekstensi.

• Ini menciptakan lebih banyak pekerjaan untuk pengembang perkakas. (Baik di dalam maupun di luar Microsoft.)
  - Lebih banyak kasus untuk ditangani.
  -- Lebih banyak skenario untuk didokumentasikan dan diuji.
  -- Lebih sedikit waktu yang dihabiskan untuk perbaikan bug dan fitur baru. Dengan alat XAML saat ini dianggap kurang di belakang teknologi lain dan lambat untuk membuat alat khusus, mengapa melakukan sesuatu yang membuat pembuatan alat baru lebih lambat?

• Ini berisiko menetapkan preseden yang sangat buruk.
  -- Jika ini terjadi, mengapa tidak tepat untuk mengganti semua file .xaml saat ini dengan .wpf , .uwp , .xamarinforms , dll.? Atau .xaml2006 , .xaml20009 , .xaml-uwp5 jika namespace yang mendasarinya, daripada di mana mereka digunakan adalah masalah utama? Akan ada potensi manfaat minimal (seperti dalam kasus ini), tetapi akan dilihat oleh banyak orang sebagai cara Microsoft menyarankan penamaan file. (Saya tidak akan terkejut jika seseorang tidak membuat proposal seperti itu hanya dengan melihat diskusi di sini.)
  - Saya tidak mengetahui (tetapi senang untuk dikoreksi tentang) setiap MS menyediakan perkakas yang menangani file secara berbeda berdasarkan sub-ekstensi tetapi melakukan ini kemungkinan akan memaksa Visual Studio (dan lainnya?, termasuk Windows Shell?) menjadi perlu mampu menangani skenario ini. Kemudian, begitu kemampuan itu ada, saya dapat membayangkan godaan untuk memperkenalkan berbagai saran penamaan yang kompleks tetapi tidak perlu diusulkan dan diperkenalkan terlalu banyak untuk beberapa pengembang, yang menyebabkan kebingungan bagi kita semua.

Singkatnya, proposal tersebut akan membawa kebingungan dan lebih banyak pekerjaan untuk manfaat teoretis dalam keadaan terbatas. Jika Anda melakukan ini, saya akan menyerah pada pengembangan Windows.

Terima kasih kepada semua orang karena telah meminjamkan suara Anda. Kami mendengarmu! Kami mengumpulkan cukup banyak masukan, sehingga kami dapat dengan tegas mengatakan bahwa mengubah ekstensi .xaml tidak dapat dilakukan .

Bukan maksud kami untuk memecah ekosistem atau merusak alat pihak ketiga (dan ada banyak). Kami setuju bahwa XAML adalah bahasanya, dan WinUI 3 adalah Kerangka UI yang menggunakan XAML. Untuk semua alasan ini, dan alasan lainnya, masuk akal untuk terus menggunakan ekstensi xaml.

Tim kami masih harus mengerjakan beberapa pekerjaan rumah dan mengevaluasi alternatif lain yang harus kami konsultasikan dengan masyarakat nanti. Misalnya:

1. Tidak melakukan apapun. Pengalaman dev Kepulauan XAML akan seperti itu: File XAML dalam proyek yang berbeda (mungkin ini bukan masalah besar). WInUI 3 akan menggunakan namespace yang sama, dan itu tidak masalah karena itu akan menjadi satu-satunya bahasa XAML yang digunakan pada proyek.

2. Gunakan ruang nama untuk membedakan antar UI berdasarkan XAML. Hari ini, WPF XAML dan UWP XAML menggunakan ruang nama yang sama, mungkin WinUI 3 harus menggunakan ruang nama yang berbeda seperti yang dilakukan Xamarin Forms ( "http://xamarin.com/schemas/2014/forms"), jadi kompiler, alat, dan desainer dapat membedakan file. Di sisi lain, ini akan menciptakan dialek, meskipun ini terjadi hari ini. Secara teori, ini akan memudahkan pengembang untuk menyalin dan menempelkan contoh XAML dari dokumen/blog, meskipun sayangnya, ada banyak contoh yang tidak menyertakan ruang nama.

3. Lakukan sesuatu, tetapi hanya untuk Kepulauan. Tidak perlu membeda-bedakan sama sekali framework UI. Kita bisa menggunakan konvensi. Misalnya, di masa mendatang, aplikasi WPF dengan Pulau XAML dapat berisi file XAML di folder tertentu (folder pulau?). Ini mirip dengan lokalisasi UWP (Strings/en-US/Resources.resw).

Terima kasih sekali lagi atas tanggapan Anda . Saya akan membuka diskusi baru ketika kita matang lebih banyak ide.

Menyertakan garis gaya snippit atau doctype untuk file pulau, sudah cukup untuk perkakas.

Jika menyukai ide .ui.xaml karena ini adalah kompromi yang baik. Ini masih merupakan ekstensi XAML yang valid, dan juga dapat membantu memilih editor dan ikon yang benar. Ini juga lebih efisien daripada membuka dan mem-parsing lusinan/ratusan file XAML hanya untuk menemukan jenisnya.

@marb2000 WinUI 3 adalah Kerangka UI yang menggunakan XAML

Seharusnya: WinUI 3 adalah Kerangka UI yang dapat menggunakan XAML. Karena tidak memerlukan penggunaan XAML dan tidak memerlukan ketergantungan pada bahasa XAML.

Kami setuju bahwa XAML adalah bahasanya

Itu bagus, dan banyak ruang nama yang disebut XAML perlu diganti namanya di WinUI: apa pun yang tidak ada hubungannya dengan bahasa XAML.

De-penekanan UWP telah menyakitkan untuk disaksikan. Sekarang, ketika Anda melakukan pencarian di saluran 9 untuk konten UWP, Anda mendapatkan konten Xamarin. Ini adalah taktik yang jelas. Tolong berhenti mencoba mengubah UWP menjadi sesuatu yang lain! Investasikan kembali, gandakan, dan buat itu berhasil. UWP tidak memerlukan koreksi kursus, perlu tim Xamarin dan Office untuk bergabung. Politik internal Microsoft membunuh UWP.

@Noemata Apakah ini catatan resmi?