Perpustakaan ini menyediakan binding karat yang aman untuk AppKit pada macOS (kualitas beta, cukup dapat digunakan) dan UIKit di iOS/TVOS (kualitas alfa, lihat repo). Ia mencoba melakukannya dengan cara yang, jika Anda telah melakukan pemrograman untuk kerangka kerja sebelumnya (dalam Swift atau Objective-C), akan terasa akrab. Ini rumit dalam karat karena model kepemilikan, tetapi beberapa pengkodean dan asumsi kreatif dapat membuat kita cukup jauh.
Ini ada di crates.io sebagian untuk memungkinkan proyek untuk melihat penggunaan yang lebih luas, yang dapat menginformasikan pengembangan. Yang mengatakan, perpustakaan ini saat ini merupakan tahap awal dan mungkin memiliki bug - penggunaan Anda tentang risiko Anda sendiri. Namun, asalkan Anda mengikuti aturan (mengenai memori/kepemilikan) itu sudah baik untuk beberapa aplikasi. Repositori inti memiliki banyak contoh untuk membantu Anda memulai.
Penting
Jika Anda bermigrasi dari 0,2 ke 0,3, Anda harus memilih
appkitatauuikitsebagai fitur diCargo.tomlAnda. Perubahan ini dilakukan untuk mendukung platform yang bukan hanya macOS/iOS/TVOS (misalnya, Gnustep, Airyx). Salah satu fitur ini diperlukan untuk bekerja;appkitdefault untuk kemudahan pengembangan.
Perhatikan bahwa peti ini bergantung pada runtime Objective-C. Berinteraksi dengan runtime membutuhkan blok yang tidak aman; Peti ini menangani interaksi yang tidak aman untuk Anda dan memberikan pembungkus yang aman, tetapi dengan menggunakan peti ini Anda memahami bahwa penggunaan
unsafeadalah suatu hal yang diberikan dan akan agak merajalela untuk kontrol yang dibungkus. Ini tidak berarti Anda tidak dapat menilai, meninjau, atau mempertanyakan penggunaan yang tidak aman - ketahuilah itu terjadi, dan sebagian besar tidak akan hilang. Masalah yang berkaitan dengan keberadaan yang tidak aman akan ditutup tanpa komentar.
Jika Anda ingin membangun dokumen untuk ini di mesin lokal Anda, Anda akan menginginkan yang berikut karena cara fitur bendera bekerja dengan cargo doc :
RUSTDOCFLAGS="--cfg docsrs" cargo +nightly doc --all-features --open
use cacao :: appkit :: { App , AppDelegate } ;
use cacao :: appkit :: window :: Window ;
# [ derive ( Default ) ]
struct BasicApp {
window : Window
}
impl AppDelegate for BasicApp {
fn did_finish_launching ( & self ) {
self . window . set_minimum_content_size ( 400. , 400. ) ;
self . window . set_title ( "Hello World!" ) ;
self . window . show ( ) ;
}
}
fn main ( ) {
App :: new ( "com.hello.world" , BasicApp :: default ( ) ) . run ( ) ;
} Untuk contoh yang lebih menyeluruh, periksa examples/ folder.
Jika Anda tertarik dengan contoh yang lebih "wastafel dapur", lihat Todos_List dengan:
cargo run --example todos_list Karena cara program AppKit dan UIKIT biasanya berfungsi, Anda didorong untuk melakukan sebagian besar pekerjaan Anda mulai dari metode did_finish_launching() dari AppDelegate Anda. Ini memastikan aplikasi memiliki waktu untuk menginisialisasi dan melakukan rumah tangga yang diperlukan di belakang layar.
Dalam hal sebagian besar karya yang berfungsi, tabel di bawah ini menampilkan tingkat dukungan untuk berbagai fitur. Daftar ini tidak lengkap hanya berdasarkan dokumentasi yang memperbarui menjadi neraka - jadi Anda terdorong untuk memeriksa dokumentasi yang dibuat kode untuk info lebih lanjut:
Perhatikan bahwa sementara iOS memiliki tanda -tanda hijau, beberapa komponen masih belum ditentukan dengan baik (misalnya, view/viewcontrollers masih sangat alfa di sana).
Platform non-apple yang shim atau menyediakan bentuk appkit mungkin dapat menggunakan sebagian besar dukungan appkit di perpustakaan ini.
| Komponen | Keterangan | Appkit | iOS | TVOS |
|---|---|---|---|---|
| Aplikasi | Inisialisasi & Peristiwa | ✅ | ✅ | |
| Jendela | Konstruksi, Penanganan, Acara | ✅ | ✅ | |
| Melihat | Konstruksi, gaya, acara | ✅ | ✅ | |
| ViewController | Konstruksi, Acara Siklus Hidup | ✅ | ✅ | |
| Warna | Warna yang didukung sistem, tema | ✅ | ✅ | |
| ListView | Daftar yang Dapat Digunakan kembali dengan barisan yang di -cache | ✅ | ||
| Tombol | Styling, Acara, Dukungan Toolbar | ✅ | ||
| Label/Textfield | Rendering & input teks | ✅ | ||
| Gambar/Imageview | Memuat, menggambar, dll | ✅ | ✅ | |
| Toolbar | Toolbar Asli Dasar | ✅ | ||
| SplitViewController | Pemandangan split (Big Sur Friendly) | ✅ | ||
| Webview | Pembungkus untuk wkwebview | ✅ | ||
| UserDefaults | Data kecil yang bertahan | ✅ | ✅ | |
| Autolayout | Lihat tata letak untuk berbagai layar | ✅ | ✅ |
Berikut ini adalah daftar fitur kargo yang dapat diaktifkan atau dinonaktifkan.
appkit : Tautan AppKit.framework .uikit : Tautan UIKit.framework (IOS/TVOS saja).cloudkit : Links CloudKit.framework dan menyediakan beberapa pembungkus di sekitar fungsi CloudKit. Saat ini tidak fitur lengkap.color_fallbacks : Menyediakan warna fallback untuk sistem yang lebih lama di mana jenis systemColor tidak ada. Fitur ini sangat jarang dan Anda mungkin tidak membutuhkannya.quicklook : Links QuickLook.framework dan menawarkan metode untuk menghasilkan gambar pratinjau untuk file.user-notifications : Tautan UserNotifications.framework dan menyediakan fungsionalitas untuk memancarkan pemberitahuan pada macOS dan iOS. Perhatikan bahwa ini mengharuskan aplikasi Anda ditandatangani kode, dan tidak akan berfungsi tanpanya.webview : Link WebKit.framework dan menyediakan kontrol WebView yang didukung oleh WKWebView . Fitur ini tidak didukung di TVOS, karena platform tidak memiliki kontrol webview. Fitur ini juga berpotensi hanya didukung untuk MacOS/iOS karena kontrol WKWebView dan berbagai dukungan pada platform non-apple.webview-downloading-macos : Mengaktifkan mengunduh file dari WebView melalui antarmuka pribadi. Ini bukan fitur yang aman untuk toko-toko, jadi berhati-hatilah sebelum mengaktifkan. Fitur ini tidak didukung di iOS (pengguna akan menangani unduhan dengan sangat berbeda) atau TVOS (tidak ada browser web sama sekali). Mengapa tidak memperluas peti Cocoa-RS yang ada?
Pertanyaan yang bagus. Pada akhirnya, peti itu (saya percaya, dan seseorang dapat mengoreksi saya jika saya salah) agak terikat dengan servo, dan saya ingin bereksperimen dengan pendekatan terbaik untuk mewakili model kakao UI di karat. Peti ini tidak mengabaikan pekerjaan mereka sepenuhnya, baik - core_foundation dan core_graphics digunakan secara internal dan diekspor kembali untuk penggunaan umum.
Mengapa saya harus menulis dalam karat, bukan bahasa X?
Dalam kasus saya , saya ingin dapat menulis aplikasi asli untuk perangkat saya (dan platform yang saya sukai untuk membangun produk) tanpa dikunci untuk menulis dalam bahasa khusus Apple ... dan tanpa menulis dalam C/C ++ atau JavaScript (Catatan: The Toolchain , bukan bahasa - ES6/TypeScript baik). Saya ingin melakukan ini karena saya bosan memukul gunung pekerjaan ketika saya ingin melompati aplikasi saya ke ekosistem lain. Saya pikir Rust menawarkan model (pertumbuhan, tetapi signifikan) yang layak untuk berbagi kode di seluruh platform dan ekosistem tanpa mengorbankan kinerja.
(Ini adalah bagian di mana internet menyala dan mengoceh tentang beberapa kombinasi elektron, qt, dan sebagainya - kita tidak repot -repot di sini karena dipukuli sampai mati di tempat lain)
Peti ini berguna bagi orang-orang yang tidak perlu menggunakan semua ekosistem Apple, tetapi ingin port pekerjaan mereka di sana dengan beberapa kemudahan relatif. Tidak diharapkan bahwa semua orang tiba -tiba ingin menulis ulang aplikasi MacOS/iOS/TVOS mereka di Rust.
Bukankah objektif-C mati?
Ya, dan tidak.
Memang benar bahwa Apple benar-benar mendukung Swift, dan untuk alasan yang baik (dan saya mengatakan ini sebagai pencinta Objective-C yang tidak malu-malu). Dengan itu, saya akan terkejut jika kami tidak memiliki dukungan ~ 5+ tahun lagi; Apple cepat tertutup, tetapi menghapus runtime Objective-C akan membutuhkan banyak waktu dan upaya. Mungkin SwiftUi membunuhnya, siapa tahu. Pembungkus di sekitar hal ini harus mungkin membuatnya lebih mudah untuk menukar backend UI yang mendasarinya setiap kali tiba saatnya.
Satu hal yang perlu diperhatikan adalah bahwa Apple telah mulai merilis kerangka kerja cepat. Untuk kasus di mana Anda membutuhkannya, harus dimungkinkan untuk melakukan kombinasi tautan dan penghubung - yang akan menginformasikan bagaimana menukar backend UI yang mendasarinya akan terjadi di beberapa titik.
Beberapa mungkin juga mengutuk Objective-C sebagai lambat. Untuk itu, saya akan mencatat yang berikut:
tl; dr itu mungkin baik -baik saja, dan Anda memiliki karat untuk kebutuhan kinerja Anda.
Mengapa tidak hanya membungkus Uikit, dan kemudian mengandalkan katalis?
Saya belum melihat satu aplikasi tunggal di mana Catalyst merasa baik. Tujuannya bagus, dan jika sampai pada titik di mana itu sepertinya jalan ke depan (misalnya, Apple hanya membunuh Appkit) maka itu tentu saja merupakan pilihan.
Anda tidak mungkin membungkus semua perilaku khusus platform di sini ...
Benar! Setiap kontrol UI berisi bidang objc , yang dapat Anda gunakan sebagai penetasan pelarian - jika kontrol tidak mendukung sesuatu, Anda bebas jatuh ke runtime Objective -C sendiri dan menanganinya.
Mengapa Anda tidak menggunakan binding untuk secara otomatis menghasilkan barang ini?
Untuk tujuan eksplorasi awal, saya telah melakukan sebagian besar ini dengan tangan, karena saya ingin menemukan pendekatan yang pas dalam model karat sebelum berkomitmen untuk mengikat generasi. Ini adalah sesuatu yang mungkin akan saya fokuskan selanjutnya karena saya memiliki barang -barang "bekerja" dengan cukup baik.
Apakah ini terkait dengan kakao, proyek Swift?
Tidak. Proyek yang dimaksud dalam pertanyaan ini bertujuan untuk memetakan bagian kakao dan UIKIT untuk menjalankan di Linux, tetapi belum melihat aktivitas dalam beberapa waktu (itu juga sangat keren!).
Penamaan proyek open source pada tahun 2020 seperti mencoba membeli domain .com : semuanya baik diambil. Untungnya, beberapa proyek dapat berbagi nama ... jadi itulah yang akan terjadi di sini.
Bukankah ini akan menipu model objek karat?
Tergantung bagaimana Anda melihatnya. Saya pribadi tidak terlalu peduli - lapisan GUI untuk platform ini adalah persyaratan sulit untuk mendukung kelas -kelas produk tertentu, dan menyerah juga berarti menyerahkan alat yang telah teruji untuk hal -hal seperti aksesibilitas dan integrasi OS yang lebih dalam. Dengan mengatakan itu, secara internal ada upaya untuk mencoba dan membuat hal -hal menghormati model Rust tentang bagaimana hal -hal yang seharusnya bekerja.
Anda dapat menganggap ini mirip dengan GTK-RS. Jika Anda ingin mendukung atau mencoba model yang lebih murni , periksa Druid atau semacamnya. :)
Lisensi ganda di bawah lisensi MIT/MPL-2.0. Lihat file yang sesuai di repositori ini untuk informasi lebih lanjut. Apple, Appkit, Uikit, Cocoa, dan merek dagang lainnya adalah Hak Cipta Apple, Inc.
Anda dapat mengikuti saya di Twitter atau mengirim email kepada saya dengan pertanyaan yang tidak sesuai dengan masalah di sini.