Hari keenam saya dengan Haiku: di bawah tenda sumber daya, ikon dan paket


TL; DR : Haiku adalah sistem operasi yang dirancang khusus untuk PC, jadi ia memiliki beberapa trik untuk membuat lingkungan kerjanya lebih baik daripada yang lain. Tetapi bagaimana cara kerjanya?


Baru-baru ini saya menemukan Haiku, sistem yang tidak terduga bagus. Masih kagum pada betapa lancar kerjanya, terutama dibandingkan dengan lingkungan desktop Linux. Hari ini saya mencari di bawah tenda. Di mana diperlukan untuk pemahaman mendalam, saya akan membuat perbandingan dengan lingkungan kerja Macintosh, Mac OS X dan Linux asli (standar XDG dari freedesktop.org).


Sumberdaya dalam File ELF


Kemarin, saya mengetahui bahwa IconOMatic dapat menyimpan ikon di sumber daya ref di ELF executable. Hari ini saya ingin melihat cara kerjanya.


Sumber daya? Kutipan dari Bruce Horne , penulis asli program Macintosh Finder dan "bapak" dari Macintosh Resource Manager:


Saya khawatir tentang sifat keras penulisan kode tradisional. Bagi saya, gagasan aplikasi yang dibekukan dalam kode tanpa kemampuan untuk mengubah apa pun secara dinamis adalah keliaran terliar. Seharusnya dimungkinkan untuk mengubah sebanyak mungkin pada tahap runtime. Tentu saja, kode aplikasi itu sendiri tidak dapat diubah, tetapi sesuatu dapat diubah tanpa mengkompilasi ulang kode?

Pada Macintosh asli, mereka membuat file-file ini memiliki "bagian data" dan "bagian sumber daya", yang membuatnya sangat mudah untuk menyimpan berbagai hal, seperti ikon, terjemahan, dll. dalam file yang dapat dieksekusi.


Di Mac, ResEdit digunakan untuk ini, program grafis untuk - tiba-tiba - mengedit sumber daya.



ResEdit pada Macintosh asli


Akibatnya, dimungkinkan untuk mengedit ikon, item menu, terjemahan, dll. cukup mudah, tetapi mereka masih "bepergian" dengan aplikasi.
Bagaimanapun, pendekatan ini memiliki kelemahan besar: itu hanya bekerja pada sistem file Apple, yang merupakan salah satu alasan mengapa Apple meninggalkan "bagian sumber daya" ketika beralih ke Mac OS X.
Pada Mac OS X, Apple menginginkan solusi sistem file independen, sehingga mereka menerapkan konsep paket (dari NeXT), direktori yang diperlakukan oleh manajer file sebagai "objek buram," seperti file, bukan direktori. Paket apa pun dengan aplikasi dalam format .app memiliki, antara lain, file Info.plist (dalam beberapa analog JSON atau YAML dari Apple) yang berisi metadata aplikasi.



Kunci untuk file Info.plist dari paket aplikasi Mac OS X.


Sumber daya, misalnya ikon, file UI dan lainnya, disimpan dalam paket sebagai file. Konsep ini sebenarnya telah dikembalikan ke dasar-dasar di NeXT.



Mathematica.app pada NeXTSTEP 1.0 pada tahun 1989: ditampilkan sebagai direktori dengan file di terminal, tetapi sebagai objek tunggal dalam manajer file grafis.


Kembali ke BeOS, yang menjadi dasar Haiku. Ketika pindah dari PEF (PowerPC) ke ELF (x86) (yang sama digunakan di Linux), pengembangnya memutuskan untuk menambahkan bagian sumber daya ke akhir file ELF. Untuk ini, bagian ELF kita sendiri yang tepat tidak digunakan, itu hanya ditambahkan ke akhir file ELF. Akibatnya, program strip dan binutils lainnya, yang tidak mengetahui hal ini, cukup memutusnya. Oleh karena itu, menambahkan sumber daya ke file ELF di BeOS, lebih baik tidak bekerja dengan alat Linux.


Apa yang terjadi dengan Haiku sekarang? Secara prinsip, kurang lebih sama.


Secara teori, Anda dapat menempatkan sumber daya di bagian kanan ELF. Menurut pengembang di saluran #haiku di jaringan irc.freenode.net:


Dengan ELF, bagian ini akan lebih masuk akal ... satu-satunya alasan kami tidak melakukan ini adalah karena mereka melakukannya di BeOS "
Dan itu tidak layak diubah sekarang.

Manajemen sumber daya


Sumber daya ditulis dalam format "sumber daya" terstruktur: pada kenyataannya, ini adalah daftar sumber daya dengan ukuran dan kemudian isinya. Saya ingat format ar .
Bagaimana cara memeriksa sumber daya di Haiku? Apakah ada sesuatu seperti ResEdit?
Menurut dokumentasi :


Untuk melihat sumber daya yang disediakan dalam paket aplikasi, Anda dapat menyeret file yang dapat dieksekusi ke program seperti Sumber Daya . Anda juga dapat pergi ke terminal dan menjalankan perintah listres _ .

Ada Resourcer di HaikuDepot, tetapi bagi saya itu hanya crash.


Bagaimana cara mengelola sumber daya dalam file ELF? Menggunakan rsrc dan rdef . file rdef dikumpulkan dalam rsrc . File rdef disimpan dalam format teks biasa, jadi bekerja dengannya jauh lebih mudah. File rsrc ditambahkan ke akhir file ELF. Mari kita coba main:


 ~> rc -h Haiku Resource Compiler 1.1To compile an rdef script into a resource file: rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script: rc [options] [-o <file>] -d <file>...Options: -d --decompile create an rdef script from a resource file --auto-names construct resource names from ID symbols -h --help show this message -I --include <dir> add <dir> to the list of include paths -m --merge do not erase existing contents of output file -o --output specify output file name, default is out.xxx -q --quiet do not display any error messages -V --version show software version and license 

Anda dapat menggunakan program xres untuk memverifikasi dan mengelola:


 /> xres Usage: xres ( -h | --help ) xres -l <file> ... xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to the given commands. (...) 

Oke, ayo coba?


 /> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type ID size name ------ ----------- ----------- -------------------- 'MIMS' 1 36 BEOS:APP_SIG 'APPF' 1 4 BEOS:APP_FLAGS 'MSGG' 1 421 BEOS:FILE_TYPES 'VICN' 101 7025 BEOS:ICON 'VICN' 201 91 kActionBack 'VICN' 202 91 kActionForward 'VICN' 203 300 kActionForward2 'VICN' 204 101 kActionStop 'VICN' 206 243 kActionGoStart 'MSGG' 205 1342 kActionGo 'APPV' 1 680 BEOS:APP_VERSION 

Anda dapat membaca lebih lanjut tentang sumber daya dan format rdef sini .


Jenis Sumber Daya Standar


Meskipun Anda bisa memasukkan apa saja ke sumber daya, ada beberapa tipe standar yang didefinisikan:


  • app_signature : jenis aplikasi MIME, untuk mencocokkan file yang dibuka, peluncuran, IPC, dll.
  • app_name_catalog_entry : Karena nama aplikasi biasanya dalam bahasa Inggris, di sini Anda dapat menentukan di mana letak nama yang diterjemahkan, sehingga pengguna dari berbagai bahasa akan melihat nama aplikasi yang diterjemahkan jika diinginkan.
  • app_version : persis apa yang Anda pikirkan
  • app_flags : memberi tahu registrar cara menangani aplikasi. Saya pikir ada sesuatu yang lebih daripada yang terlihat pada pandangan pertama. Misalnya, ada B_SINGLE_LAUNCH , yang memaksa sistem untuk memulai proses aplikasi baru setiap kali, atas permintaan pengguna (prinsip yang sama digunakan untuk sebagian besar aplikasi Linux). Ada B_MULTIPLE_LAUNCH yang memaksa untuk memulai proses untuk setiap file . Akhirnya, ada B_EXCLUSIVE_LAUNCH , yang memaksa sistem untuk memulai hanya satu proses pada satu waktu, tidak peduli seberapa sering pengguna memulainya (misalnya, Firefox juga mulai di Linux; hasil yang sama dapat dicapai dalam aplikasi Qt menggunakan fungsi QtSingleApplication ). Aplikasi dengan B_EXCLUSIVE_LAUNCH diberitahu ketika pengguna mencoba menjalankannya lagi: misalnya, mereka mendapatkan jalur file yang ingin dibuka oleh pengguna dengan bantuan mereka.
  • vector_icon : Ikon aplikasi vektor (Tidak ada ikon vektor di BeOS, sebagian besar aplikasi malah memiliki dua ikon raster dalam file yang dapat dieksekusi).

Tentu saja, Anda dapat menambahkan sumber daya dengan ID dan jenis yang diinginkan, dan kemudian membacanya di aplikasi itu sendiri atau aplikasi lain menggunakan kelas BResources . Tapi pertama-tama, mari kita memikirkan tema ikon yang menarik.


Ikon vektor dalam gaya Haiku.


Tentu saja, tidak hanya Haiku memilih format ikon terbaik, pada bagian ini situasi dengan lingkungan kerja Linux jauh dari ideal:


 me@host:~$ ls /usr/share/icons/hicolor/ 128x128 256x256 512x512 index.theme 160x160 28x28 64x64 scalable 16x16 32x32 72x72 symbolic 192x192 36x36 8x8 22x22 42x42 96x96 24x24 48x48 icon-theme.cache 

Melihat ini, Anda sudah bisa merasakan apa itu sepotong.


Tentu saja, ada ikon vektor yang dapat diskalakan, yang dapat Anda pahami. Lalu mengapa ada hal lain? Karena hasil rendering grafik vektor dalam ukuran kecil bisa lebih buruk daripada ideal. Saya ingin berbagai opsi dioptimalkan untuk berbagai ukuran. Di lingkungan kerja Linux ini dicapai dengan menyebarkan ikon dengan ukuran berbeda pada sistem file.


 me@host:~$ find /usr/share/icons/ -name 'firefox.*' /usr/share/icons/HighContrast/16x16/apps/firefox.png /usr/share/icons/HighContrast/22x22/apps/firefox.png /usr/share/icons/HighContrast/24x24/apps/firefox.png /usr/share/icons/HighContrast/256x256/apps/firefox.png /usr/share/icons/HighContrast/32x32/apps/firefox.png /usr/share/icons/HighContrast/48x48/apps/firefox.png /usr/share/icons/elementary-xfce/apps/128/firefox.png /usr/share/icons/elementary-xfce/apps/16/firefox.png /usr/share/icons/elementary-xfce/apps/22/firefox.png /usr/share/icons/elementary-xfce/apps/24/firefox.png /usr/share/icons/elementary-xfce/apps/32/firefox.png /usr/share/icons/elementary-xfce/apps/48/firefox.png /usr/share/icons/elementary-xfce/apps/64/firefox.png /usr/share/icons/elementary-xfce/apps/96/firefox.png /usr/share/icons/hicolor/128x128/apps/firefox.png 

Harap dicatat: tidak ada konsep versi Firefox yang berbeda. Dengan demikian, Anda tidak dapat secara halus menangani situasi dengan kehadiran beberapa versi aplikasi dalam sistem.



Ikon Firefox berbeda dalam versi berbeda. Belum dimungkinkan untuk menangani ini di Linux tanpa berbagai kruk.


Mac OS X menangani sedikit lebih canggih:


 Mac:~ me$ find /Applications/Firefox.app | grep icns /Applications/Firefox.app/Contents/MacOS/crashreporter.app /Contents/Resources/crashreporter.icns /Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns /Applications/Firefox.app/Contents/Resources/document.icns /Applications/Firefox.app/Contents/Resources/firefox.icns 

Dapat dilihat bahwa ada satu file firefox.icns di paket Firefox.app yang berisi semua ukuran, jadi versi berbeda dari aplikasi yang sama memiliki ikon yang berbeda.
Jauh lebih baik! Ikon bepergian dengan aplikasi, semua sumber daya dalam satu file.


Kembali ke Haiku. Keputusan yang mengejutkan, tanpa pengecualian. Menurut dokumentasi :


Format HVIF khusus, sangat dioptimalkan dikembangkan untuk ukuran kecil dan rendering cepat. Oleh karena itu, sebagian besar ikon kami jauh lebih kecil daripada di raster atau dalam format SVG yang banyak digunakan.

Dan mereka dioptimalkan:



Ukuran ikon di HVIF dibandingkan dengan format lain.


Perbedaannya adalah urutan besarnya!


Tetapi keajaiban tidak berakhir di sini. HVIF yang sama dapat menunjukkan tingkat detail yang berbeda tergantung pada ukuran yang ditampilkan, meskipun itu adalah format vektor.



Berbagai tingkat detail (LOD) tergantung pada ukuran render


Sekarang tentang kekurangannya: Anda tidak dapat mengambil SVG, letakkan di ImageMagick dan akhiri di sana, Anda harus melalui beberapa siklus untuk membuat ikon dalam format HVIF. Berikut penjelasannya. Namun, IconOMatic dapat mengimpor SVG secara tidak sempurna; sekitar 90% bagian SVG diimpor dengan beberapa probabilitas, sisanya 10% perlu disesuaikan dan diubah secara manual. Anda dapat membaca lebih lanjut tentang bagaimana HVIF melakukan keajaiban di blog Lea Ganson.


Menambahkan ikon ke aplikasi


Sekarang saya dapat menambahkan ikon ke paket yang dibuat terakhir kali , dengan mempertimbangkan semua informasi yang diterima.
Yah, karena saya tidak terlalu bersemangat untuk menggambar ikon saya sendiri untuk QtQuickApp "Hello World" - saya menariknya keluar dari Qt Creator.


 /Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt\ Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt\ Creator 

Mari kita periksa apakah ikonnya sudah disalin:


 /Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp resources:type ID size name ------ ----------- ----------- -------------------- 'VICN' 101 152238 BEOS:ICON 

Ini terlihat bagus, tetapi mengapa, ketika ikon baru disalin, itu tidak muncul?



Salinan VICN: 101: BEOS: ICONs belum digunakan sebagai ikon untuk aplikasi di manajer file


Apa yang saya lewatkan?


Komentar Pengembang:


Penting untuk membuat file rdef dengan semua sumber daya, kemudian jalankan perintah rc .rdef , ini akan membuat file .rsrc . Maka Anda perlu menjalankan perintah resattr -o _ .rsrc . Minimal, saya menggunakan perintah serupa untuk menambahkan ikon ke skrip saya.

Yah, saya ingin membuat sumber daya, bukan atribut. Saya langsung bingung.


Caching sistem file cerdas


Membuka dan membaca atribut ELF lambat. Seperti yang saya tulis di atas, ikon ditulis sebagai sumber daya dalam file itu sendiri. Metode ini lebih dapat diandalkan, memungkinkan Anda untuk tetap menyalin ke sistem file lain. Namun, kemudian juga disalin ke atribut sistem file, misalnya BEOS:ICON . Ini hanya berfungsi pada sistem file tertentu, seperti BFS. Ikon yang ditampilkan oleh sistem (dalam Pelacak dan Deskbar) dibaca dari atribut yang diperluas ini, karena solusi seperti itu bekerja dengan cepat. Di beberapa tempat (di mana kecepatan tidak penting, misalnya, jendela "Tentang" yang khas), sistem menerima ikon langsung dari sumber daya dalam file. Tapi ini bukan akhirnya. Ingat, pada Mac, pengguna dapat mengganti ikon aplikasi, direktori, dokumen dengan miliknya, karena pada Mac dimungkinkan untuk melakukan hal-hal "penting" ini, misalnya, mengganti ikon Slack baru dengan yang sebelumnya . Di Haiku, Anda harus menggunakan sumber daya (dalam file) sebagai ikon sumber yang menyertai aplikasi, dan atribut (dalam sistem file BFS) sebagai sesuatu yang memungkinkan pengguna untuk membuat perubahan yang diinginkan (meskipun, sedikit petunjuk, antarmuka grafis untuk memasukkan ikon pengguna di atas ikon adalah default belum diterapkan).


Memeriksa atribut sistem file


Dengan resaddr ada kemampuan untuk memeriksa dan mengatur atribut dari sistem file.


 /> resattr Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ] Reads resources from zero or more input files and adds them as attributes to the specified output file, or (in reverse mode) reads attributes from zero or more input files and adds them as resources to the specified output file. If not existent the output file is created as an empty file. (...) 

Pada dasarnya, ini adalah "lem" yang melakukan konversi bolak-balik antara sumber daya (andal) dan atribut sistem file (cepat). Dan karena sistem mengasumsikan penerimaan sumber daya dan melakukan salinan secara otomatis, saya tidak akan khawatir tentang hal ini lebih lanjut.


Paket hpkg ajaib


Saat ini (paling sering) paket .hpkg digunakan untuk mendapatkan .hpkg Haiku. Jangan terkecoh dengan nama sederhana: format .hpkg bekerja dengan cara yang sangat berbeda dari format lain dengan nama serupa yang Anda temui, memiliki kekuatan super nyata.


Dengan format paket tradisional, saya merasa kesal untuk waktu yang lama karena fakta ini: Anda mengunduh satu (paket), dan yang lain diinstal pada sistem (file di dalam paket). Cukup sulit untuk mengelola file (misalnya, menghapusnya) ketika menginstal paket dengan cara tradisional. Dan semua karena isi paket tersebar di seluruh sistem file , termasuk tempat-tempat di mana rata-rata pengguna mungkin tidak memiliki akses tulis. Hal yang sama menghasilkan seluruh kelas program - manajer paket . Tetapi mentransfer perangkat lunak yang sudah diinstal, misalnya, ke komputer lain, disk yang dapat dilepas atau server file menjadi lebih sulit, jika bukan tidak mungkin. Dalam sistem berbasis Linux yang khas, beberapa ratus ribu hingga jutaan file terpisah dapat dengan mudah ada. Tak perlu dikatakan bahwa itu rapuh dan lambat, misalnya, selama instalasi awal sistem, selama instalasi, memperbarui dan menghapus paket-paket reguler, serta ketika menyalin volume boot (partisi root) ke media lain.


Saya sedang mengerjakan proyek AppImage, kruk parsial untuk aplikasi pengguna akhir. Ini adalah format distribusi perangkat lunak yang mengumpulkan aplikasi dan semua dependensinya menjadi satu gambar sistem file yang dipasang ketika aplikasi dimulai. Ini sangat menyederhanakan banyak hal, karena ImageMagick yang sama tiba-tiba berubah menjadi satu file, dikelola dalam file manager oleh manusia biasa. Metode yang diusulkan hanya berfungsi untuk perangkat lunak, seperti tercermin dalam nama proyek, dan juga memiliki set luka sendiri, karena orang-orang yang memasok perangkat lunak untuk Linux selalu mengarahkan panah mereka pada saya.


Kembali ke Haiku. Apakah Anda berhasil menemukan keseimbangan optimal antara sistem paket tradisional dan pengiriman perangkat lunak berbasis gambar? Paket .hpkg sebenarnya .hpkg gambar sistem file terkompresi. Ketika sistem melakukan boot, kernel akan me-mount semua paket yang diinstal dan aktif dengan kira-kira pesan kernel berikut:


 KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg" KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg" KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg" KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg" KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg" 

Keren ya Tunggu, itu akan menjadi lebih dingin!


Ada paket yang sangat spesial:


 KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg" 

Ini berisi sistem operasi yang sangat minim, termasuk kernel. Percaya atau tidak, bahkan kernel itu sendiri tidak diekstraksi dari volume boot (partisi root), tetapi hati-hati dimuat ke tempatnya dari paket .hpkg . Wow! Saya sudah menyebutkan bahwa, bagi saya, bagian dari kecanggihan dan koherensi keseluruhan Haiku adalah karena seluruh sistem dari kernel dan ruang pengguna dasar, serta pengelolaan paket dan infrastruktur lingkungan kerja, dikembangkan bersama oleh satu tim. Bayangkan berapa banyak grup dan perintah yang diperlukan untuk menjalankan yang berbasis Linux seperti ini [Saya bayangkan proyek PuppyLinux - kira-kira. penerjemah] . Kemudian bayangkan berapa lama waktu yang dibutuhkan untuk menerapkan pendekatan ini dalam distribusi. Mereka mengatakan: ambil tugas sederhana, dibagi di antara pemain yang berbeda, dan itu akan menjadi sangat rumit sehingga tidak akan diselesaikan. Haiku dalam hal ini membuka mata saya. Saya pikir inilah yang sebenarnya terjadi di Linux sekarang (Linux dalam hal ini adalah istilah kolektif untuk Linux / GNU / dpkg / apt / systemd / Xorg / dbus / Gtk / GNOME / XDG / Ubuntu stack).


Rollback sistem menggunakan hpkg


Seberapa sering situasi berikut terjadi: pembaruan berhasil, dan kemudian ternyata ada sesuatu yang tidak berfungsi sebagaimana mestinya? Jika Anda menggunakan manajer paket yang biasa, sulit untuk mengembalikan keadaan sistem ke titik waktu sebelum menginstal paket baru (misalnya, dalam kasus ketika terjadi kesalahan). Beberapa sistem menawarkan solusi dalam bentuk snapshot dari sistem file, tetapi mereka cukup rumit, dan juga tidak digunakan pada semua sistem. Di Haiku, ini diselesaikan menggunakan paket .hpkg . Setiap kali paket dalam sistem berubah, paket lama tidak dihapus, tetapi disimpan dalam sistem dalam subdirektori dalam bentuk /Haiku/system/packages/administrative/state-<...>/ secara permanen. Operasi yang tertunda menyimpan data mereka di subdirektori /Haiku/system/packages/administrative/transaction-<...>/ .



Konten /Haiku/system/packages/administrative . Direktori "status ..." berisi file teks dengan nama paket aktif, "transaksi ..." - paket itu sendiri.


"Keadaan aktif lama", mis. daftar paket .hpkg yang aktif sebelum perubahan ditulis setelah setiap operasi di manajer file dalam file teks / /Haiku/system/packages/administrative/state-<...>/activated-packages ...>/ /Haiku/system/packages/administrative/state-<...>/activated-packages . Dengan cara yang sama, "keadaan aktif" yang baru ditulis dalam file teks /Haiku/system/packages/administrative/activated-packages .


Direktori /Haiku/system/packages/administrative/state-<...>/ hanya berisi file teks dengan daftar paket aktif dari kondisi ini (jika paket diinstal tanpa menghapus instalan), dan jika paket dihapus atau diperbarui, direktori state berisi versi lama dari paket .


Ketika sistem melakukan booting, berdasarkan daftar paket, keputusan dibuat untuk mengaktifkan (mount) paket. Sangat sederhana! Jika terjadi kesalahan selama unduhan, Anda dapat memberi tahu pengelola unduhan untuk menggunakan daftar yang lebih lama dan berbeda. Masalahnya terpecahkan!



Haiku bootloader. Setiap titik entri menampilkan "keadaan aktif" yang sesuai


Saya suka pendekatan dengan file teks sederhana sebagai daftar "keadaan aktif", di mana nama-nama .hpkg . Ini sangat berbeda dengan tumpukan OSTree atau Flatpak yang dibuat untuk mesin-tetapi-bukan-orang dalam sistem file (level yang sama dengan Microsoft GUID).



Daftar paket aktif untuk setiap titik waktu


Data konfigurasi


Rupanya, direktori /Haiku/system/packages/administrative/writable-files berisi file konfigurasi untuk paket, tetapi dapat ditulis. Bagaimanapun, seperti yang Anda ingat, .hpkg hanya dipasang untuk membaca. Oleh karena itu, file-file ini harus disalin dari paket sebelum menulis. Masuk akal.


Integrasi GUI untuk sistem .hpkg


Sekarang mari kita lihat bagaimana paket .hpkg brilian ini .hpkg dengan integrasi ke dalam ruang kerja pengguna (UX). Bagaimanapun, Haiku dimaksudkan untuk penggunaan pribadi. Secara pribadi, saya menetapkan bilah tinggi dengan membandingkan pengalaman pengguna dengan paket .app di Macintosh dengan pengalaman yang sama pada .hpkg . Saya bahkan tidak akan membandingkan situasi dengan lingkungan kerja di Linux, karena itu benar-benar mengerikan dibandingkan dengan yang lain.


Skenario berikut muncul dalam pikiran:


  • Saya ingin melihat isi paket .hpkg
  • -,
  • -,
  • , Haiku ( , .)
  • (, ) , ( ) ( , , ).

. , .



Mac Finder. ! ( , .pkg , , ).


Haiku , "Contents" , . .
, () .hpkg , . ( , .hpkg Expander , ).



HaikuDepot , , , README.md


Mac , HaikuDepot .


GUI


Mac , .dmg .app . , , , /Applications Finder. , , . - Apple "" /Applications ( NeXT , ), $HOME/Applications , .


Haiku , , "Install", . , , , HaikuPorts, . Linux , , — , . , Haiku.



'sanity' , , ( , ). Linux .


— , .hpkg /Haiku/system/packages ( , -), /Haiku/home/config/packages ( ; — "config" , "settings"). Haiku (, — , , ).


Haiku, , .


GUI


Mac , , . Mudah!


Haiku , -, , , ( ). /Haiku/system/packages ( -), /Haiku/home/config/packages ( , "config" — ?). , .
Mudah! , . :



, /Haiku/system/packages


", " QtQuickApp. ,.hpkg " " . , "", -.


mr. waddlesplash :


10 . , . .

, , , HaikuDepot? /Haiku/system/packages , , "Uninstall". -, () «Install». «Uninstall», ?


, , "Install" . :



, .


:



"Apply changes" —


, , . [ , — . penerjemah]


: "Uninstall", /Haiku/system/packages , /Haiku/home/config/packages .

, HaikuDepot, .


Mac. , Haiku , Mac. ( : " HaikuDepot, ++", ?)


-


, .hpkg , (, " " - ).


Mac , .dmg , .app . .dmg , /Applications . , , , Apple. ( , Mac. , , AppImage , . = . !)


Haiku , apps/ packages/ , , . , apps/ :



, .hpkg


( , ), .


: GUI .hpkg

, Alt+D. " ". , /system ( /system/packages /system/settings ) packagefs (, df ?). , mount ( ), mountvolume ( loop .hpkg ""), .


, AppImage ( , , ). , , Haiku , Mac.


: , "" «». , "" «": , ( , , ). ?



Mac , .app , — .


Haiku , , .


: ```.hpkg , , .

Mac. , . Haiku .hpkg , ...



. , (, , Windows, Mac Linux) . , -, , , [ , Windows… — . ].


, , Windows Linux.


Mac , — .dmg . , , MacOS -. , , java.


Haiku .hpkg , , java, , java , . .hpkg , , Haiku - , , Haiku?


Mac.


mr. waddlesplash:


, .hpkg -, Haiku, 15 . , . .

.



, .hpkg (, ) , ( ). ( ) — , () , . , .


Mac .app Finder, . . !


Haiku , , .hpkg , , . , , GUI.


Mac.


mr. waddlesplash:


. , , . .

.


: ( LAN ) , , (, Zeroconf), . , app_flags .


hpkg c GUI


, - .hpkg GUI . , , UX...


: Kernel Debug Land


kernel panic , syslog | grep usb . , Haiku Kernel Debug Land. , kernel panic? , Alt+PrintScn+D ( Debug). Programmer's Key , Macintosh ( , ).


Kesimpulan


, Haiku , .
Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, , .
, .hpkg , Snappy, Flatpak, AppImage, btrfs, " " Mac.


- "" , , .hpkg , — . , . Mac.


, , , ( Gtk, Electron — , ), 3d , . . , , .


, Haiku .



, ?


  • BeScreenCapture GIF, Peek. ffmpeg, Haiku. .
  • ,
  • WonderBrush, —
  • Haiku, , . Krita, (. ). . .

Coba sendiri! Bagaimanapun, proyek Haiku menyediakan gambar unduhan harian dari DVD atau USB. Untuk menginstal, cukup unduh gambar dan tulis ke USB flash drive menggunakan Etcher


Punya pertanyaan? Kami mengundang Anda ke saluran telegram berbahasa Rusia.


Gambaran Umum Bug: Cara memotret kaki Anda di C dan C ++. Koleksi Resep OS Haiku


Dari penulis terjemahan: ini adalah artikel keenam dari seri Haiku.


Daftar artikel: pertama kedua ketiga keempat kelima keenam ketujuh kedelapan kesembilan

Source: https://habr.com/ru/post/id464819/


All Articles