Hari ini kita akan berbicara tentang bagaimana grafik Phantom UI diatur.
(Apa itu Phantom OS, Anda dapat mengetahuinya dengan
membaca artikel-artikel ini .)
Lebih tepatnya - bagaimana UI grafis ini lahir. Untuk waktu yang lama, Phantom hanya memiliki kesimpulan grafis - hampir tidak mungkin untuk menyampaikan apa pun ke sistem dengan mouse.
Sekarang waktunya telah tiba untuk membuat paling tidak sederhana - tetapi aplikasi, yang berarti - Anda memerlukan UI. Bagaimanapun - sistem, kita akan jujur, itu tampak menakutkan. Dan ini bukan mode sekarang.
Apa yang tersedia di awal proyek UI? Pada prinsipnya - banyak.
Faktanya, ada grafis - driver video, subsistem jendela dalam mode hanya-tampilan, font bitmap, subsistem acara jendela (acara), kontrol fokus jendela, dan primitif terkait.
Sekarang langkah-langkahnya dan sedikit lagi.
Subsistem driver video dapat menjalankan fungsi probe () dari beberapa driver secara bergantian, menerima permintaan dari mereka untuk resolusi maksimum dan bitness warna, plus kemampuan untuk bekerja dalam mode akselerator 2D. Sistem ini membutuhkan warna minimum 24-bit. Pada level ini, kami memiliki framebuffer (layar dalam memori), mouse, dan beberapa jenis bitblt primitif.
Bitblt primitif - tiga tipe dasar diimplementasikan - penyalinan penuh grafik (dengan persegi panjang terpotong), penyalinan dengan mempertimbangkan transparansi biner akun (piksel benar-benar transparan atau sangat buram) dan z-buffer. Yaitu, kemampuan untuk menyalin pada layar hanya piksel yang memiliki koordinat z lebih besar dari koordinat z dari piksel yang ada - untuk menyelesaikan sebagian tumpang tindih jendela.
Lapisan fungsi berikutnya adalah subsistem jendela. Di sini ada konsep jendela, dekorasi jendela (bingkai, jendela judul dengan tombol), koordinat x / y / z jendela dan serangkaian fungsi yang bertanggung jawab untuk menggambar jendela di layar dan mengendalikan pergerakannya di sepanjang sumbu.
Acara berikut mengikuti - antrian mikrotask, yang diproses oleh driver tingkat bawah untuk rendering dan mengelola keadaan windows.
Perlu dicatat bahwa pikiran terbaik umat manusia mengklaim bahwa sistem jendela-grafik yang akan bekerja secara stabil dan tanpa masalah dalam lingkungan yang tidak dapat dibaca tidak dapat ditulis tanpa antrian peristiwa. Upaya saya yang sederhana untuk mengabaikan pernyataan ini sejauh ini hanya menegaskannya. Sangat sulit untuk menghilangkan antrian pesan dan membuat semua utas meminta acara jendela untuk program dan kadang-kadang menyebabkan perang di layar.
Oleh karena itu, sebagian besar primitif sistem jendela yang berkaitan dengan sesuatu yang lebih besar dari gambar di dalam jendela diimplementasikan melalui antrian pesan. Permintaan mengirim ke antrian pesan "menggambar area ini di layar" atau "mengatur ulang jendela di atas yang lain", dan utas terpisah di bagian bawah mengeksekusi mereka teratur dan serius.
Ini hanya mendapatkan aliran peristiwa dari mouse (ditekan, diseret), keyboard (ditekan, dilepaskan) dan sistem jendela itu sendiri (peristiwa sekunder - setelah menggerakkan jendela ke atas, menggambar ulang area layar).
Tugas terpisah pada tingkat arus peristiwa adalah apa yang disebut fokus. Jendela yang terfokus menerima aliran acara dari keyboard, dan memang itu jelas disorot di layar sebagai titik mengatasi aktivitas pengguna. Selain tugas yang jelas untuk memilih jendela untuk mengarahkan acara, sistem ini juga menginformasikan jendela tentang kehilangan fokus, yang kadang-kadang penting.
Level selanjutnya adalah grafik primitif untuk menggambar di jendela.
Ada dua opsi utama untuk implementasi. Tua, ekonomis - ketika sebuah jendela tidak menyimpan salinan dari apa yang ditarik ke dalamnya. Jika jendela seperti itu dihapus, dan Anda perlu menggambar yang terhapus lagi (misalnya, jendela dikembalikan ke layar dari tepi), maka jendela memanggil fungsi dari programnya, dan fungsi ini harus menggambar semua yang diperlukan. Ini adalah model yang khas dan sangat merepotkan karena berbagai alasan. Yang kedua dipilih di Phantom - setiap jendela memiliki bitmap di mana isi jendela saat ini digambar. Sistem grafis selalu dapat merujuk ke salinan ini dan memperbaruinya di layar tanpa menarik program pengguna.
Perhatikan bahwa jendela milik program pengguna (dan bukan kernel) di Phantom, tentu saja, gigih, disimpan dalam memori persisten dan setelah mem-boot ulang OS menyimpan semua yang tergambar di dalamnya. Ini, kebetulan, secara mengejutkan bermanfaat dan menyederhanakan kode aplikasi di beberapa tempat menjadi tidak senonoh.
Seperangkat gambar primitif memungkinkan kode aplikasi, seperti biasa, untuk menggambar titik, garis, bitmap, baris teks dalam font bitmap, dan beberapa hal kecil lainnya di jendela.
Pada kekayaan subsistem grafis ini pada awal proyek "UI Phantom Baru" dan berakhir. Pada prinsipnya, kit pria ini sudah cukup banyak, tetapi hanya untuk pengguna. Tidak ada input
Lebih tepatnya, ada dukungan yang belum sempurna untuk konsep "tombol", tetapi hanya dengan mouse, hanya di bilah alat dan hanya untuk menutup jendela. :)
Tugas pengembangan adalah sebagai berikut:
- TrueType Tanpa ini, sayang sekali.
- Acara keyboard dan kontrol keyboard. Setidaknya dasar.
- Untuk berpikir tentang lokalisasi tata letak - setidaknya alfabet Cyrillic, tetapi meletakkan dasar untuk mengubah tata letak.
- Kontrol - tombol, tombol radio, bidang teks, label, menu dan sebagainya.
- Fokus kontrol adalah pilihan titik kontrol di dalam jendela.
- Beberapa jenis komponen layar untuk mengelola windows di layar. Bilah tugas?
- Sebenarnya, gambar kontrol dan secara umum beberapa jenis desain UI - tidak boleh seperti pertanian kolektif seperti sebelumnya.
Seperti ini:
Di perjalanan, ternyata alpha-blending juga diperlukan, yaitu transparansi sebagian piksel ketika melapiskan gambar. Nah, menjadi jelas bahwa sudah waktunya untuk menyentuh Unicode untuk ambing.
Pendekatan berat ini dibagi menjadi tiga bagian besar: Desain, Trump, sisanya.
Tentang desain, singkatnya: Ada desain UI gratis di Internet tanpa persyaratan penggunaan yang jahat. Tiga hari untuk mencari dan memilih, waktu tanpa akhir untuk pemotongan artistik elemen grafis.
Jenis truf
Saya takut akan hal ini, tetapi ternyata sia-sia. Ada libfreetype, ada contoh aplikasi, setelah dua hari rendering font vektor bekerja cukup baik dalam mode uji.
Namun, ada kehalusan, dan tidak semua jalan telah dibahas. Yaitu. Bekerja dengan font dari kernel - is. Font-font tersebut kemudian digerakkan oleh hardcode ke dalam biner kernel. Ini tidak dapat dihindari untuk font sistem, tetapi kode pengguna harus memiliki mekanisme pemuatannya sendiri. Dan meskipun beberapa FS di Phantom, tentu saja, adalah dan akan, model ini tidak wajar baginya. Anda harus dapat menyimpan font di objek yang persisten dan membawanya melalui jaringan.
Yang kedua lebih sederhana - rookery font gratis berlimpah, dan organisasi mereka tidak akan lama.
Tapi yang pertama ...
Anda mungkin tidak tahu, tetapi variabel string di Phantom memiliki properti tak terduga untuk programmer yang tidak terbiasa kegigihan. Mereka dapat mengganti file. Aliran byte adalah aliran byte. Tidak hanya itu, itu juga, menurut definisi, memori dipetakan - ini adalah variabel. Artinya, pada prinsipnya, apa yang kami simpan di OS biasa dalam sebuah file, di Phantom, Anda bisa memasukkannya ke dalam variabel string. Saya sering bertindak - dan kompiler Phantom bahkan memiliki desain - untuk menyedot file menjadi string konstan. Jadi di userland, Phantoms melakukan penetrasi, misalnya, bitmap. Tetapi ini juga merupakan metode yang memalukan, karena pada saat runtime variabel ini perlu di-parseed untuk mendapatkan representasi objek yang dapat dioperasikan. Namun, untuk bitmap, maka, untuk menghormati konsep Phantom, semuanya baik-baik saja di sini. Kami mengkompilasi file grafik menjadi string ketika mengkompilasi, ketika Phantom pertama kali diluncurkan, itu dikonversi ke objek biner persisten dari jenis bitmep, dan itu sudah digunakan kemudian setelah sejumlah reboot OS dan tidak memerlukan sumber asli. Ini juga harus dilakukan dengan font, tetapi agak kurang umum. Saat bekerja, font vektor dirender menjadi raster, dan perlu menyimpan raster yang di-render seperti itu. Ini bukan trik atau masalah - mereka dapat dilipat lagi menjadi objek Phantom seperti bitmap, tetapi sudah ada beberapa jenis infrastruktur yang diperlukan - gaya font-style-style-style-size-glyph (kode UTF) glyph bitmap.
Ini tidak terlalu sulit, tetapi, tampaknya, tugas dari tahap selanjutnya. Sementara font-font dirasterisasi atas banding.
Unicode
Merender font menurut definisi melibatkan bekerja dengan Unicode. Ini, tentu saja, bagus, karena kita harus mulai kapan-kapan. Bahkan, itu cukup untuk melengkapi penyaji dengan konverter dari UTF-8 ke UTF-32 (dan ini adalah nomor mesin terbang di font), unduh font dengan alfabet Cyrillic dan ini bagian dari pelokalan bekerja. Apalagi jika kita menginginkan bahasa lain, maka perlu dan cukup untuk mengganti font. Namun, font dasar yang dipilih mengandung banyak - untuk Eropa, pasti cukup. Cina akan membutuhkan penggantian font, ya.
Bekerja dengan keyboard
Tidak ada tanda-tanda aksi militer sama sekali, tetapi, lebih dari harapan, saya harus berjuang. Ternyata driver keyboard lama masih ... berharap untuk melihat perangkat keras dari IBM PC XT. Ya, abad lalu. Faktanya adalah bahwa pengontrol keyboard mampu (mampu!) Untuk mengubah kode pindai keyboard modern (yang disebut set kode kedua) menjadi yang kuno.
Ternyata karena terlambat QEMU, pertobatan semacam itu, tampaknya, akhirnya dibuang. Atau tanpa sengaja bangkrut. Namun faktanya, pengemudi menolak bekerja. Dengan kesedihan, selama satu jam, dengan bantuan beberapa ibu, aku mengantar pengemudi dari UOS yang ramah ke Phantom. Hanya untuk mengetahui bahwa dia memiliki masalah yang sama. Set pertama. Saya harus menulis ulang tabel kode pindai dan pengurai. Saya tidak kembali ke pengemudi lama, dan itulah sebabnya. Ternyata driver dari uOS memiliki antarmuka yang lebih elegan ke sistem. Yaitu, ia kembali ke sana bukan, seperti kebiasaan, sepasang (kode karakter, kode pemindaian tombol), tetapi satu karakter UTF-32 32-bit. Ternyata di UTF ada rentang kode khusus yang dialokasikan untuk penggunaan lokal, dan itu lebih dari cukup untuk semua tombol fungsi yang mungkin. Bekerja dengan aliran peristiwa dalam kode UI jauh lebih sederhana.
Selain itu, lokalisasi jatuh sempurna pada model seperti itu. Sudah cukup untuk overlay tabel ASCII-> UTF32 untuk bahasa yang diinginkan (set karakter), dan sorakan - kita punya Cyrillic. Yah - hampir sampai. Sekarang akan perlu untuk transcode ke dalam UTF-8, atau untuk membuat ulang jeroan beberapa bagian UI ke UTF-32. Saya juga telah menempatkan momen ini sebagai prioritas rendah.
Kontrol
Tombol, radio, kotak centang, dan elemen UI spesifik lainnya.
Infrastruktur umum meliputi:
- Mekanisme untuk menyimpan kontrol terkait dengan jendela
- Elemen visualisasi kontrol tipikal - bingkai, latar belakang, teks, ikon, dll.
- Transmisi ke kontrol acara dan pola reaksi tipikal (push / toggle)
- Melacak kejadian mouse dan melayang-layang keadaan
- Panggilan balik dan pembuatan peristiwa sekunder untuk menginformasikan tentang perubahan status
Kontrol fokus
Agar kontrol (tombol, misalnya) digunakan tanpa mouse, beberapa hal diperlukan.
- Kemampuan untuk memilihnya dari keyboard
- Tampilkan pilihan ini
- Respons keyboard
- Deteksi kehilangan fokus.
Yang terakhir adalah yang paling sulit.
Faktanya, kontrol fokus dengan keyboard dan mouse, dan ini adalah satu dan entitas yang sama - jika kita memilih bidang teks dengan mouse, itu akan merespon tombol. Jika setelah itu Anda menekan TAB, hak untuk bekerja dengan keyboard akan beralih ke yang lain.
Tugas terpisah adalah bahwa beberapa kontrol dapat dikelompokkan dan statusnya perlu diperbarui dengan cara yang terkait. Menekan radiobathorn “memeras” tetangganya.
Sekali lagi, kembali ke fakta bahwa kita sedang menulis OS yang persisten. Ini berarti bahwa kontrol potensial dapat disimpan dalam RAM yang persisten dan selamat dari reboot sistem kernel.
Artinya, hubungannya dengan nukleus akan baik untuk diminimalkan. Setiap pointer ke memori non-persisten (sebenarnya ke kernel) setelah reboot akan tidak valid dan harus dikembalikan. Ini berarti bahwa penunjuk seperti itu tidak memiliki hak untuk menyimpan informasi tentang status kontrol. Posisi kursor sebagai bilangan bulat - ya. Pointer ke buffer di kernel yang posisinya ditentukan oleh posisi kursor tidak. Baik atau ya, hanya bilangan bulat yang masih ada dan itu lebih penting. Ini dalam praktiknya tidak terlalu memberatkan, tetapi kita harus ingat.
Akhirnya, bilah tugas. Ini adalah hal semacam itu di bagian bawah (samping, atas) layar di mana pengguna menusuk jika ia kehilangan jendela.
Pada prinsipnya, ini seharusnya sudah menjadi bagian dari tanah pengguna, tetapi ... kernel sudah aktif menggunakan GUI, jadi untuk saat ini bagian ini juga akan berada di bagian bawah. Saya harap sementara.
Total
Menurut pendapat saya, tugas-tugas yang ditetapkan ke arah ini secara umum telah diselesaikan. Tentu saja, tidak ada batasan untuk kesempurnaan, tetapi, menurut saya, antarmuka telah mengambil langkah nyata dari peretas menjadi universal.