Harus menambahkan tautan ke sampel Van Arsdel

Saya pikir kontrol yang lebih umum dari Toolkit harus selalu menemukan cara porting ke C++ dan tersedia di Perpustakaan UI Windows. Kontrol tab ketika sudah matang dan cukup stabil juga harus dibuat.

Itu terjadi dengan kontrol Menu Utama :)

Tautan ke sampel Tab Tear-Off juga disebut dalam proposal.

Tautan ke sampel Tab Tear-Off juga disebut dalam proposal.

Apakah merobek tab memunculkan AppWindow baru, CoreWindow baru, dan bagaimana Anda menangani fallback di mana API jendela baru tidak ada?

@mdtauk sampel menggunakan API ApplicationView multi-jendela yang lebih lama saat ini, jendela dibuat dalam posisi default alih-alih di mana diseret. Saya telah menguji dengan AppWindow dan berharap dapat memperbarui sampel untuk SDK baru.

"Meskipun solusi ini telah membantu menjembatani kesenjangan platform dari WPF, mereka memiliki sejumlah keterbatasan, termasuk:"

Anda harus mencantumkan keyboard di sini juga. Ini bukan hanya tombol tab atau tombol pintas. Panah adalah sesuatu yang kami perjuangkan ketika kami tidak memiliki kontrol tab dan kami harus membuat semua orang konsisten dalam kekurangannya.

Komentar tentang pertanyaan terbuka dari apa yang kami dengar di toolkit:

1. Haruskah Tab Tearoff menjadi sesuatu yang ditangani oleh kontrol atau yang ditangani oleh aplikasi?

Saya pikir penting bagi Kontrol Tab untuk menangani menyeret dan menggabungkan kembali antara TabViews (menghosting tipe data yang sama) dan mengekspos acara drag-out, dengan kemampuan untuk memeriksa/menyadap.

Tapi saya tidak tahu apakah penting bagi TabView untuk juga mengelola siklus hidup jendela secara langsung karena itu menjadi lebih rumit. Pengembang mungkin juga ingin menyesuaikan apa yang terjadi saat menyeret tab keluar, mungkin hanya menghapusnya, atau membuat jendela khusus hanya untuk konten itu vs. jendela 'utama' baru dengan tab? Atau mereka mungkin tidak ingin menangani keharusan membuat kode untuk banyak jendela.

Mungkin lebih mudah untuk mengekspos acara dan memiliki pembantu (atau memanfaatkan yang sudah ada seperti yang ada di Windows Template Studio) untuk membantu dalam pembuatan/pengelolaan Windows. Bagian tersulit dari skenario ini adalah "transfer data" antar utas, yang setidaknya harus dibantu oleh API windowing baru.

1. Haruskah ada tombol "Tambahkan tab baru" bawaan? (Saya kira mungkin tidak, karena kontrol tidak memiliki koleksi Tab.)

Saya pikir selama ada templat dan contoh tajuk yang memadai, memiliki pelaksana yang menambahkan tombol 'tambah' itu sepele, jadi saya tidak berpikir itu perlu built-in, karena paradigma akan membutuhkan acara lain. Ini adalah sesuatu yang awalnya kami pikirkan juga dalam toolkit. :)

1. Haruskah TabItem.Icon menjadi IconElement atau IconElementSource?

Kami menggunakan IconElement untuk meniru properti NavigationViewItem. Juga, IconElementSource adalah IconElement jadi bukankah IconElement lebih baik karena lebih luas? Akan lebih baik jika ada subkelas IconElement di WinUI yang hanya dapat meng-host Image langsung (mirip dengan BitmapIcon tetapi tanpa penyembunyian paksa). Dengan begitu, properti Icon dapat meng-host apa pun baik itu Simbol Vektor/Ikon Font yang bagus atau file ico/png (pikirkan favicon skenario tipe browser).

1. Bagaimana cara aplikasi menyesuaikan tampilan tab Terpilih (mis. di Edge)?

Apakah Anda berbicara tentang properti gaya terbuka yang dapat dimodifikasi atau seperti template yang sama sekali berbeda untuk item yang dipilih?

1. API saat ini mengambil banyak inspirasi dari Toolkit. Apakah ada peluang untuk mengulangi/meningkatkan?

Satu item umpan balik yang kami dapatkan adalah tentang menyesuaikan ruang di akhir tab. Misalnya Haruskah itu hanya menjadi area templat tunggal yang kemudian dapat menggunakan perataan horizontal kiri/kanan untuk menempelkan benda-benda ke tepi vs. dua area terpisah?

Pertanyaan Lain:

• [ ] Menarik dengan drag tentang bagaimana menangani dragging ke area konten vs header juga keduanya target? Bagaimana jika aplikasi ingin mengizinkan menjatuhkan sesuatu yang lain di area tab (seperti file dari explorer)?
• [ ] Apakah "Aplikasi dapat memutuskan bagaimana posisi/ukuran tab" berbicara tentang properti TabStripPlacement ?

Juga lupa untuk memanggil Persyaratan 9, kami awalnya berdiskusi tentang apakah akan menggunakan model Edge atau tidak (seperti perilaku kontrol toolkit saat ini) atau model NavigationView di mana ia membuat chevron drop-down. Kami pikir mungkin di masa depan kami akan mendukung keduanya.

Kami akhirnya menggunakan model Edge karena lebih sederhana untuk diterapkan, karena kami tidak memerlukan objek tipe SplitObservableCollection . Saya telah mulai mengerjakan satu sebagai ujian, tetapi saya ingin tahu apakah itu akan menjadi konstruksi yang berguna untuk diekspos?

@stmoy apakah Anda menutup masalah/umpan balik terbuka dari atas yang kami dapatkan dari desain toolkit?

Bagaimana berita tentang Windows Sets yang meninggalkan model Edge Tab, memengaruhi bagaimana kontrol ini dapat dikembangkan?

Dengan Edge dan UI-nya cukup banyak ditinggalkan sekarang demi ChromiumEdge (Edgium) apakah kita perlu/ingin memikirkan kembali tampilan atau perilaku kontrol ini agar lebih sesuai dengan jenis aplikasi yang mungkin menggunakannya?

• Dialog Properti;
• MDI (Multiple Document Interfaces) - seperti Photoshop;
• Palet alat dok (Visual Studio/Blend/Adobe CC);

Belum lagi kontrol serupa seperti Pivot, dan Pita UWP dalam pengembangan. Mana yang direkomendasikan untuk kasus penggunaan mana, dan mengapa seseorang memilih salah satu dari yang lain? Panduan dan contoh harus jelas untuk menjawab pertanyaan-pertanyaan ini untuk menghindari kebingungan atau kontrol yang lebih berat digunakan daripada yang berkinerja dan lebih ringan.

Kontrol Pihak Pertama harus menggunakan kontrol yang tepat untuk tujuan yang benar, untuk mencoba memimpin dalam penggunaan yang konsisten.

Pada #629 @mdtauk memiliki saran fitur:

Mungkin ide untuk daftar ToDo. Penempatan Tab? Bawah, Kiri, Kanan.

Ya, Penempatan Tab harus ada di daftar prioritas di beberapa titik untuk mencocokkan paritas WPF untuk skenario migrasi. Itu adalah sesuatu yang kami tidak punya waktu untuk menambahkannya di versi Toolkit awal.

Saat kami melakukan cakupan fitur ini, mendukung skenario "tab lembar properti" menjadi bukan tujuan dan untuk fokus pada skenario tab browser. Kami memang melihat beberapa tumpang tindih dengan lembar properti, tetapi metafora lembar properti bukan bagian dari desain yang lancar, kami memiliki NavigationView (yang memiliki mode Kiri/Atas) untuk skenario itu sekarang.

Tampilan Navigasi adalah kontrol yang berat, dan ingin memenuhi seluruh layar. Juga Sets hilang dari peta jalan, seperti versi XAML dari Edge.

Jadi mungkin ada ruang untuk memikirkan kembali TabView/Kontrol agar lebih fleksibel dan berguna untuk masa depan.

Skenario ini dapat dimungkinkan di aplikasi UWP XAML, jika kontrol TabView memiliki kemampuan untuk menyembunyikan tombol tambah dan tutup.

Tapi ada juga kontrol Pivot, namun hanya mendukung header pivot di atas, dan Tab bisa di atas, bawah, kiri atau kanan...

Dalam toolkit yang kami dukung tidak memiliki tombol tutup, tombol tambah juga merupakan sesuatu yang harus ditambahkan sendiri oleh pelaksana. Inilah mengapa kami memiliki properti TabWidthBehavior untuk membantu menyiapkan mode yang berbeda ini antara dokumen dan tab klasik. Salah satu hal utama yang belum kami dukung adalah penentuan posisi tab.

Terima kasih untuk semua percakapan yang luar biasa! Berputar kembali...

Menarik dengan drag tentang bagaimana menangani dragging ke area konten vs header juga keduanya target? Bagaimana jika aplikasi ingin mengizinkan menjatuhkan sesuatu yang lain di area tab (seperti file dari explorer)?

Pertanyaan yang menarik. Secara naif, saya akan berpikir bahwa keduanya akan menjadi target (besar) yang sama karena TabControl menghosting area Tab strip dan area konten. Namun, model ini berantakan ketika mempertimbangkan aplikasi seperti Edge (sebagai contoh). Jika Edge dimaksimalkan dan pengguna menyeret tab keluar dari strip tab tetapi masih di atas konten karena ukurannya maksimal, pengguna mengharapkan Tab untuk membuat jendela baru.

Oleh karena itu saya pikir kita seharusnya hanya menjadikan area header/tab strip sebagai target drag/drop.

Apakah "Aplikasi dapat memutuskan bagaimana posisi/ukuran tab" berbicara tentang properti TabStripPlacement?

Ini dimaksudkan untuk menggambarkan properti "TabWidthBehavior" dan enum dan bukan TabStripPlacement. Saya memperbarui persyaratan dan menambahkan persyaratan Penempatan Tab juga (dibahas lebih lanjut di bawah).

Set hilang dari peta jalan, seperti versi XAML dari Edge.

Motivator utama untuk pekerjaan ini sekarang sebenarnya adalah aplikasi Terminal Windows baru. Kami akan terus memperluas/menjelajahi aplikasi lain untuk menggunakan kontrol Tab, tetapi fokus utama kami adalah mengaktifkan skenario mereka untuk saat ini.

Penempatan Tab harus ada di daftar prioritas di beberapa titik untuk mencocokkan paritas WPF untuk skenario migrasi. Itu adalah sesuatu yang kami tidak punya waktu untuk menambahkannya di versi Toolkit awal.

Penempatan Tab adalah ide yang luar biasa, terutama yang berkaitan dengan paritas WPF. Namun, per di atas, karena kami sebagian besar melingkupi berdasarkan apa yang dibutuhkan Terminal, ini akhirnya menjadi lebih dari "bisa" daripada "kebutuhan". Yang mengatakan, saya menambahkannya ke tabel persyaratan di atas.

Skenario ini dapat dimungkinkan di aplikasi UWP XAML, jika kontrol TabView memiliki kemampuan untuk menyembunyikan tombol tambah dan tutup.

TabControl mendukung menyembunyikan tombol tutup pada tab itu sendiri. Selain itu, tombol "Tambah" akan disediakan oleh aplikasi itu sendiri (dan bukan kontrol), jadi kami berharap dapat membuat skenario tab gaya properti menggunakan kontrol seperti yang ditentukan di atas.

Jika tombol Tambahkan tab bukan bagian dari kontrol, mungkin saya menyarankan gaya tombol dan Perintah XAML disertakan dengan kontrol, untuk memudahkan orang menerapkan tombol secara konsisten di mana pun kontrol digunakan.

@stmoy untuk skenario seret, saya pikir akan ada kasus di mana menyeret ke header dan area bisa berbeda atau sama. Akan lebih baik jika sampel dapat menunjukkan seret untuk merobek, tetapi juga misalnya menjatuhkan file di area konten utama dan cara menangkapnya (yang mungkin di luar lingkup kontrol itu sendiri, tetapi berguna untuk penggunaan itu).

gaya tombol dan Perintah XAML [untuk menambahkan Tab baru]

@mdtauk - ide bagus. Saya akan menambahkannya ke spesifikasi.

Akan lebih baik jika sampel dapat menunjukkan seret untuk merobek, tetapi juga misalnya menjatuhkan file di area konten utama dan cara menangkapnya

@michael-hawker - Setuju, sampel akan bermanfaat. Saya tidak tahu apakah itu perlu khusus Tab, karena menyeret file masuk akan ditangani oleh area konten.

Hai semuanya, hanya ingin memberi tahu Anda bahwa saya mengulangi spesifikasi Tab yang saat ini keluar untuk PR . Silakan tambahkan komentar ke PR jika Anda memiliki umpan balik!

Semoga saja mereka merasa lebih seperti tab Chrome daripada Edge.

Semoga saja mereka merasa lebih seperti tab Chrome daripada Edge.

Kami ingin desain interaksi "terasa benar", jadi pasti ajukan masalah dengan umpan balik spesifik terhadap versi pratinjau sehingga kami bisa melakukannya dengan benar sebelum kami mengirim!

Tidak yakin apakah seseorang seperti @chigy telah membuat desain comp untuk Kontrol TabView, tapi saya mencoba cepat, juga menunjukkan opsi penempatan Samping dan Bawah yang bisa datang di masa mendatang.

Saya tidak suka bahwa keadaan tombol tutup/tertekan mengubah latar belakang tombol dan bukan latar depannya. Mengubah latar belakang menambahkan terlalu banyak penekanan pada tombol (dan menjauh dari judul tab) dan yang terakhir juga akan jauh lebih elegan.

Sebagai contoh, lihat tombol tutup di Edge UWP (hanya perubahan latar depan) atau tombol bisu tab-audio di Edge (Chromium).

Saya memang mempertimbangkan untuk tetap menggunakan perubahan latar depan, tetapi merasa perubahan latar belakang akan sejalan dengan kontrol lain dan perilaku bilah judul - tetapi sebagai default itu hanya bisa menjadi latar depan.

@mdtauk - kamu keren. Terima kasih telah membuat kompilasi desain ini. Meskipun kami tidak akan melakukan penempatan samping untuk penurunan pertama dari kontrol, sangat bagus untuk melihat seperti apa bentuknya.

@chigy dan saya bekerja sama untuk membangun beberapa desain yang sejalan dengan prinsip-prinsip Windows (termasuk hal-hal seperti sudut membulat, bayangan standar, dll.) tetapi komponen desain yang Anda berikan akan membantu menginspirasi kami.

Saya tidak suka bahwa keadaan tombol tutup/tertekan mengubah latar belakang tombol dan bukan latar depannya. Mengubah latar belakang menambahkan terlalu banyak penekanan pada tombol (dan menjauh dari judul tab) dan yang terakhir juga akan jauh lebih elegan.

Pemikiran kami saat ini hanya untuk mengubah warna latar depan dan bukan latar belakang, seperti yang disarankan di sini. Ini memiliki manfaat tambahan untuk menyesuaikan sedikit lebih baik dengan sudut membulat yang kami pertimbangkan.

Tab Edge menggunakan latar belakang di belakang mesin terbang dekat, tetapi lebih kecil dari yang saya usulkan - tetapi tab Edgium belum mendukung mode Sentuh apa pun.

Ketika kami memikirkan tab samping untuk desain toolkit, kami bingung antara melakukannya secara vertikal dengan teks yang diputar seperti yang ditunjukkan @mdtauk atau tetap membuatnya horizontal dan mengambil margin yang lebih besar ke sisi kiri/kanan seperti yang biasa dilakukan OneNote sebelum desain ulang terbaru mereka dan mirip dengan WPF (yang menurut kami penting untuk kompatibilitas).

Jadi, saya sarankan untuk menyimpannya seperti yang dilakukan WPF dengan margin lebar dan horizontal, tetapi juga membuatnya sangat sederhana untuk mendukung keduanya seperti yang ditunjukkan di sini , yang merupakan alasan lain untuk mendukung #546.

@michael-hawker Saya mendukung memiliki daftar vertikal tab di sebelah kanan dengan margin lebar, dan membuatnya mudah untuk memutarnya seperti di Visual Studio.

Ini akan mempengaruhi tempat tab sebelum dan sesudah, tetapi saya akan melakukan mock up desain ketika saya kembali ke rumah pada hari Senin

Ini akan mempengaruhi tempat tab sebelum dan sesudah, tetapi saya akan melakukan mock up desain ketika saya kembali ke rumah pada hari Senin

Saya di rumah, dan inilah desainnya:

Saya telah menyempurnakan mockup desain untuk kontrol.

_menambahkan Tab Overflow dan Tab Sizing_

Seperti itu konsep tab Anda terlihat jauh lebih mirip dengan tab Edge UWP daripada tab Edge Chromium. IMO tampilan kontrol tab harus sedekat mungkin dengan kontrol tab di Edge UWP. Akrilik sebagai latar belakang kontrol tab seperti di Edge UWP juga akan cukup bagus.

Saya masih berharap tombol tab-close bisa dibuat seperti di Edge UWP, dimana tombol tersebut hanya ditampilkan untuk tab yang sedang dipilih atau pada tab mouse hover.

Untuk tim WinUI: @stmoy Rupanya tim Terminal Windows tidak dapat menggunakan akrilik sebagai latar belakang untuk kontrol tab (lihat https://github.com/microsoft/terminal/issues/1375). Tim terminal mengklaim itu karena keterbatasan arsitektur. Apakah itu sesuatu yang bisa dibantu oleh tim WinUI? Tampaknya ada beberapa penggemar latar belakang akrilik untuk kontrol tab seperti di Edge UWP.

@Felix-Dev Saya tahu Edgeium adalah desain baru yang harus dituju, tapi saya pikir desain UWP Edge sedikit lebih bagus - jadi saya ingin mencoba menjembatani kesenjangan itu

Saya masih berharap tombol tab-close bisa dibuat seperti di Edge UWP, dimana tombol tersebut hanya ditampilkan untuk tab yang sedang dipilih atau pada tab mouse hover.

CloseButtonOverlay Apakah properti yang akan melakukan itu menurut saya

@mdtauk
Untuk memperjelas, saya ingin melihat CloseButtonOverlay = OnHover menjadi default Kontrol Tab, alih-alih tombol tutup terus ditampilkan di semua tab (tidak perlu menghilangkan ruang dari judul tab imo).

Selalu terlihat adalah yang terbaik untuk pengguna sentuh, jadi saya pikir defaultnya harus seinklusif mungkin

Mungkin mode overlay untuk tombol tutup dapat dibuat bergantung pada kemampuan tampilan pengguna?

Tidak yakin apakah itu bisa menjadi masalah karena akan ada sedikit perbedaan visual di Kontrol Tab tergantung pada jenis tampilan.

Mungkin mode overlay untuk tombol tutup dapat dibuat bergantung pada kemampuan tampilan pengguna?

Tidak yakin apakah itu bisa menjadi masalah karena akan ada _slight_ perbedaan visual di Kontrol Tab tergantung pada jenis tampilan.

Itu berfungsi untuk hal-hal seperti flyout karena dapat mendeteksi jenis input yang memicunya, memberikan target sentuh yang lebih besar jika dipanggil oleh input sentuh.

Ini tidak berfungsi untuk kontrol yang selalu terlihat, karena beberapa perangkat sentuh juga akan memiliki mouse yang terpasang.

Pengembang tentu saja akan dapat mengubah opsi default, dan jika aplikasi mendapat banyak umpan balik yang meminta tombol tutup hanya ditampilkan saat mengarahkan kursor - maka mereka dapat memilih untuk mengubahnya.

Saya telah menambahkan ide untuk Tab overflow

Suka ini.

Hanya satu hal kecil. Saat ada bayangan dan sudut membulat, kita mungkin ingin sedikit celah di antara item tab yang dipilih dan tepi latar belakang.

Suka ini.

Hanya satu hal kecil. Saat ada bayangan dan sudut membulat, kita mungkin ingin sedikit celah di antara item tab yang dipilih dan tepi latar belakang.

Ingin tahu mengapa itu diperlukan... Tidakkah bayangan itu terpotong oleh bingkai Jendela? Apakah itu hanya pilihan estetika sehingga bayangan terlihat di atas?

Ukuran Tab

@mdtauk : Saya suka melihat desain ini! Saya punya beberapa pertanyaan menyelidik:

• Apakah ungu warna aksen?
• Apakah tujuan dari tangkapan layar luapan untuk menunjukkan bemper? Saya hanya ingin memastikan saya membaca gambar dengan benar.
• Berapa radius sudut tab?
• Berapa tinggi tab?
• Berapa ukuran font yang digunakan?

Saya akan menggunakan desain ini untuk berbicara dengan teman-teman kita di Terminal dan melihat apa yang mereka pikirkan. Desain ini mencakup beberapa delta dari arah kami saat ini, tetapi kami akan menggunakannya untuk membantu mendorong percakapan.

@Felix-Dev : Terima kasih atas feedbacknya; mengatasi beberapa poin Anda di bawah ini.

Seperti itu konsep tab Anda terlihat jauh lebih mirip dengan tab Edge UWP daripada tab Edge Chromium. IMO tampilan kontrol tab harus sedekat mungkin dengan kontrol tab di Edge UWP. Akrilik sebagai latar belakang kontrol tab seperti di Edge UWP juga akan cukup bagus.

Kami secara aktif mengulangi dengan berbagai tim (termasuk tim Terminal dan Edge) untuk mencoba menyelaraskan Tab di seluruh pengalaman aplikasi ini. Saat kami terus mengulangi (dan mengimplementasikan item seperti #524), desain kontrol Tab akan terlihat lebih konsisten dengan kontrol yang diperbarui.

Saya masih berharap tombol tab-close bisa dibuat seperti di Edge UWP, dimana tombol tersebut hanya ditampilkan untuk tab yang sedang dipilih atau pada tab mouse hover.

Untuk jangka pendek, kami berfokus pada penerapan skenario yang dibutuhkan Terminal dan memangkas permukaan API jika perlu. Untuk v1, kami hanya akan mendukung Persistent. Yang mengatakan, saya awalnya menentukan perilaku hover juga karena saya pikir itu ide yang bagus. Saya melacak permintaan semacam ini (seperti x-on-hover, penempatan tab, dll.) sehingga kami dapat menilai kembali pada putaran kontrol berikutnya.

Untuk tim WinUI: @stmoy Rupanya tim Terminal Windows tidak dapat menggunakan akrilik sebagai latar belakang untuk kontrol tab (lihat microsoft/terminal#1375). Tim terminal mengklaim itu karena keterbatasan arsitektur. Apakah itu sesuatu yang bisa dibantu oleh tim WinUI? Tampaknya ada beberapa penggemar latar belakang akrilik untuk kontrol tab seperti di Edge UWP.

Kami secara aktif bekerja dengan tim Terminal. Sayangnya skenario ini adalah hasil dari batasan yang diketahui dengan Pulau Xaml dan bukan dengan Tab. Kami berharap aplikasi non-Terminal dapat menggunakan latar belakang akrilik sebagai fitur "keikutsertaan" jika aplikasi menyetel TabControl.Background ke kuas akrilik.

Apakah ungu warna aksen?

Ya - Saya tidak ingin mengacaukan desain saya dengan desain resmi

Apakah tujuan dari tangkapan layar luapan untuk menunjukkan bemper? Saya hanya ingin memastikan saya membaca gambar dengan benar.

Ya, menunjukkan bagaimana tombol kiri dan kanan akan terlihat, dan bagaimana tab akan dipotong.

Berapa radius sudut tab?

4 epx - Saya tahu panduannya adalah 2epx, tetapi ketinggian 4epx dari indikator yang dipilih terlihat lebih baik dengan 4

Berapa tinggi tab?

40 eps

Berapa ukuran font yang digunakan?

14 untuk teks judul tab, 16 untuk ikon MDL2

Di Edge Canary ada bendera yang disebut Animasi pemuatan tab baru - edge://flags#new -tab-loading-animation

Bagian dari spesifikasi harus menyertakan tema dan/atau animasi implisit seperti:

• TabTambahAnimasi
• TabHapusAnimasi
• TabBeralihKeAnimasi
• TabBeralihDariAnimasi
• TabSelectedSwitchToAnimation
• TabDipilihBeralihDariAnimasi
• TabDragOutAnimation
• TabDitempatkanAnimasi

@stmoy

Kami secara aktif bekerja dengan tim Terminal. Sayangnya skenario ini adalah hasil dari batasan yang diketahui dengan Pulau Xaml dan bukan dengan Tab.

Apakah mungkin untuk mengatasi batasan ini di versi Xaml Island yang akan datang? Tampaknya ada keinginan kuat untuk latar belakang akrilik di aplikasi Terminal Windows, misalnya. Lihat https://github.com/microsoft/terminal/issues/1375#issuecomment -504625390 dan terutama gambar terakhir di pos itu (dengan akrilik latar di bilah judul). Perhatikan juga banyaknya up-vote yang didapat postingan tersebut . Posting lain dengan banyak upvotes di sini: https://github.com/microsoft/terminal/issues/1375#issuecomment -504644293

Berbicara lebih luas tentang desain UI Tab, perhatikan juga reaksi yang mendukung terhadap komentar pengguna yang lebih memilih tampilan tab Edge UWP daripada tampilan tab Edge Chromium: https://github.com/microsoft/terminal/issues/1375#issuecomment -504622788 dan posting langsung di bawahnya.

Jika tab Edge Chromium dimaksudkan untuk mewakili tampilan Tab Windows (modern) di masa depan, reaksi pengguna yang luar biasa itu mungkin menjadi alasan untuk memikirkan kembali tampilan tab yang digunakan di Edge Chromium dan di WinUI. (Juga menambahkan @chigy di sini sehingga dia dapat melihat reaksi UI tab itu di repo Terminal Windows.)

Sunting: Juga meminta perhatian @ marb2000 untuk topik ini karena tim Terminal Windows baru saja menegaskan kembali bahwa mereka "tidak akan dapat memperbaiki" masalah ini. Bagaimana tim WinUI melihat peluang untuk bilah judul akrilik (sangat diminta!) Terjadi untuk Terminal Windows? @stmoy

@marb2000 @stmoy Silakan komentari pertanyaan di bawah ini:

Juga meminta perhatian @marb2000 untuk topik ini karena tim Terminal Windows baru saja menegaskan kembali bahwa mereka "tidak akan dapat memperbaiki" masalah ini [(bilah judul akrilik di terminal)]. Bagaimana tim WinUI melihat peluang untuk bilah judul akrilik (sangat diminta!) Terjadi untuk Terminal Windows?

@marb2000 @SavoySchuler @jesbis @jevansaks

Ping semuanya salah satu dari kalian dari panggilan komunitas baru-baru ini 😁
Tentang dukungan bilah judul akrilik teknis di Kepulauan Xaml (Terminal Windows), lihat posting saya di atas dan yang sebagian sudah dijawab oleh @stmoy

Berikut adalah tiga poin utama yang diambil dari posting saya dan balasan di atas:

Untuk tim WinUI: Rupanya tim Terminal Windows tidak dapat menggunakan akrilik sebagai latar belakang untuk kontrol tab (lihat microsoft/terminal#1375). Tim terminal mengklaim itu karena keterbatasan arsitektur. Apakah itu sesuatu yang bisa dibantu oleh tim WinUI? Tampaknya ada beberapa penggemar latar belakang akrilik untuk kontrol tab seperti di Edge UWP.

Membalas oleh @stmoy :

Kami secara aktif bekerja dengan tim Terminal. Sayangnya skenario ini adalah hasil dari batasan yang diketahui dengan Pulau Xaml dan bukan dengan Tab. Kami berharap aplikasi non-Terminal dapat menggunakan latar belakang akrilik sebagai fitur "keikutsertaan" jika aplikasi menyetel TabControl.Background ke kuas akrilik.

Pertanyaan saya:

Juga meminta perhatian @marb2000 untuk topik ini karena tim Terminal Windows baru saja menegaskan kembali bahwa mereka "tidak akan dapat memperbaiki" masalah ini [(bilah judul akrilik di terminal)]. Bagaimana tim WinUI melihat peluang untuk bilah judul akrilik (sangat diminta!) Terjadi untuk Terminal Windows?

Terima kasih sudah menjawab 😁