Minu kuues päev Haiku'ga: allpool ressursse, ikoone ja pakette.

TL;DR: Haiku — operatsioonisüsteem, mis on spetsiaalselt kavandatud isiklikele arvutitele, mistõttu on sellel mitu nõksu, mis muudavad töö keskkonna palju paremaks kui teised. Kuidas see aga töötab?

Hiljuti Avastasin Haiku, üllatavalt hea süsteemi. Olen siiani rabatud selle sujuvast toimimisest, eriti võrreldes Linuxi töö keskkondadega. Täna uurin, mida kõike see endast kujutab. Seal, kus see on vajalik süvitsi minekuks, teen võrdluse originaalse Macintosh'i, Mac OS X ja Linuxi töö keskkondadega (freedesktop.org'i standard XDG).

Ressursid ELF failides

Eile sain teada, et IconOMatic suudab salvestada ikoone rdef ressurssides ELF täidesaatvates failides. Täna tahan vaadata, kuidas see tegelikult töötab.

Ressursid? Tsitaat alates Bruce Horn, originaalse Macintosh Finderi looja ja Macintosh Resource Manageri “isa”:

Mind häirib traditsioonilise koodikirjutamise jäik iseloom. Minu jaoks on idee rakendusest, mis on külmutatud koodis, ilma võimaluseta midagi dünaamiliselt muuta — äärmiselt tobe. Tuleb olla võimalus muuta nii palju kui võimalik käitamise ajal. Loomulikult ei saa rakenduse koodi muuta, aga kas midagi ei saa vahetada ka ilma koodi uuesti kompileerimata?

Originaalses Macintosh'is tehti nii, et nende failide puhul on olemas “andmeosa” ja “ressursside osa”, mis teeb äärmiselt lihtsaks erinevate asjade, näiteks ikoone, tõlkeid jne, salvestamise täidesaatvates failides.

Mac'is kasutatakse selleks ResEdit, graafiline programm — üllatus, üllatus — ressursside redigeerimiseks.

ResEdit originaalses Macintosh'is

Tänu sellele sai võimalikuks redigeerida ikoone, menüüelemente, tõlkeid jne, piisavalt lihtsalt, kuid need “rändavad” ikkagi rakendustega.
Igal juhul sellel lähenemisel oli suur puudus: see töötas ainult Apple'i failisüsteemide peal, mis oli üheks põhjuseks, miks Apple loobus “ressursside osast” üleminekul Mac OS X-le.
Mac OS X-s soovis Apple lahendust, mis ei sõltuks failisüsteemist, mistõttu kasutati pakettide (NeXT-ist) kontseptsiooni, kaustu, mida failihaldur käsitleb kui “läbipaistmatuid objekte”, nagu faile, mitte kaustu. Iga rakenduse pakett formaadis .app oman, muu hulgas, faili Info.plist (millel on mingisugune analoog JSON-ile või YAML-ile Apple'ilt), mis sisaldab rakenduse metaandmeid.

Info.plist faili võtmed Mac OS X rakenduste paketis.

Ressursid, nagu ikoonid, UI-failid ja muud, salvestatakse pakendis failidena. Kontseptsioon on tegelikult tagasi käinud NeXTi algusesse.

Mathematica.app NeXTSTEP 1.0-s 1989. aastal: kuvatakse kaustana failide terminalis, kuid kui ühtne objekt graafilises failihalduris.

Rääkides BeOSist, mille kontseptsioonid on aluseks Haikule. Selle arendajad, liikudes PEF-ilt (PowerPC) ELF-ile (x86), mis on sama, mida kasutatakse Linuxis, otsustasid lisada ressursside sektsiooni ELF failide lõppu. Selleks ei kasutatud sobivat ELF sektsiooni, see lihtsalt lisati ELF faili lõppu. strip ja muud binutils'i tööriistad, mis ei tea sellest, lõikavad selle välja. Seega, BeOSI ELF failide ressursse lisades on parem mitte kasutada Linuxi tööriistu.

Kuidas on olukord Haikuga praegu? Üldiselt on see enam-vähem sama.

Teoreetiliselt oleks võimalik ressursse paigutada ELF vajalikkesse sektsioonidesse. Vastavalt arendajatele kanalis #haiku irc.freenode.net:

ELF sektsioonil oleks rohkem mõtet ... ainus põhjus, miks me nii ei tee, on see, et BeOS-is tehti nii.
Ja selle muutmine ei ole praegu vajalik.

Ressursside haldamine

Ressursid kirjutatakse struktureeritud "ressursi" formaati: see on põhimõtteliselt loend ressurssidest koos suurustega ja nende sisuga. Meenus format ar.
Kuidas kontrollida ressursse Haikus? Kas on midagi nagu ResEdit?
Vastavalt dokumentatsioon:

Kasutades rakenduse pakis tarnitud ressurside vaatamiseks, saab käivitada programmi, nagu Resourcer. Samuti saab terminalis käivitada käsu listres failinimi.

Resourcer on HaikuDepotis, kuid mul see lihtsalt kokku kukub.

Kuidas hallata ressursse ELF-failides? Kasutades rsrc ja rdef. rdef failid kogub rsrc. Fail rdef salvestatakse tavalises tekstiformaadis, seega on selle töötamine palju lihtsam. Fail format rsrc lisatakse ELF faili lõppu. Proovime mängida:

~> rc -h
Haiku Resource Compiler 1.1
Rdef skripti kompileerimiseks ressursifailiks:
    rc [valikud] [-o ] ...
Ressursifaili tagasi rdef skriptiks konverteerimiseks:
    rc [valikud] [-o ] -d ...
Valikud:
    -d --decompile       loo rdef skript ressursifailist
       --auto-names      koostage ressursinimed ID sümbolite põhjal
    -h --help            näita seda teadet
    -I --include    lisa  lisateede loendisse
    -m --merge           ära kustuta väljundfaili olemasolevaid sisu
    -o --output          täpsusta väljundfaili nimi, vaikimisi on out.xxx
    -q --quiet           ära kuva vigu
    -V --version         näita tarkvara versiooni ja litsentsi

Saate kasutada programmi xres kontrollimiseks ja haldamiseks:

/> 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.
(...)

Olgu, proovime siis?

/> 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

Rohkem ressursidest ja vormingust rdef saab lugeda siin.

Standardsed ressursitüübid

Kuigi ressursse võib lisada mis tahes sisu, on olemas mitmeid kindlaid standardtüüpe:

• app_signature: rakenduse MIME tüüp, failide avamise, käivitamise, IPC jne jaoks.
• app_name_catalog_entry: Kuna rakenduse nimi on tavaliselt inglise keeles, saab siia märkida kohad, kus asuvad tõlgitud nimed, et erinevaid keeli rääkivad kasutajad saaksid vajadusel näha rakenduse tõlgitud nime.
• app_version: just see, mida te arvasite
• app_flags: osutab registrar kuidas rakendust käidelda. Ma arvan, et seal on midagi enamat, kui see esmapilgul näib. Näiteks, on olemas B_SINGLE_LAUNCH, mis sunnib süsteemi käivitama uue rakenduse protsessi iga kord, kui kasutaja seda küsib (sama põhimõtet kasutatakse enamikus rakendustes Linuxis). On olemas B_MULTIPLE_LAUNCH, mis sunnib käivitama protsessi iga faili. Lõpuks on olemas B_EXCLUSIVE_LAUNCH, mis sunnib süsteemi käivitama ainult ühe protsessi korraga, sõltumata sellest, kui tihti kasutajad seda käivitavad (näiteks, nii käivitatakse Firefox Linuxis; sama tulemust saab saavutada Qt rakendustes, kasutades funktsiooni QtSingleApplication). Rakendused, mis B_EXCLUSIVE_LAUNCH saavad teateid, kui kasutaja püüab neid uuesti käivitada: näiteks saavad nad faili tee, mida kasutaja soovib avada nende kaudu.
• vector_icon: Rakenduse vektoriikoon (BeOS-is ei olnud vektoriikone, enamikul rakendustest oli nende asemel kaks rasterikoonut täitjatefailides).

Loomulikult saab lisada ressursse mis tahes soovitud ID-de ja tüüpidega, mille järgnevalt saab lugeda rakenduses või teistes rakendustes klassi BResourcesabil. Aga alustuseks peame peatuma põneval ikoonide teemal.

Vektoriikoonid Haiku stiilis

Muidugi ei valinud ainult Haiku parimat ikooniformaati, selles osas on Linuxi töölaudades olukord kaugel ideaalist:

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

Sellist vaadates võib juba tunda, mida see tükk tähendada võiks.

Muidugi on olemas skaleeritavad vektorikoonid. Miks siis on midagi muud? Sest vektorgraafika renderdamise tulemus väikestes mõõtmetes võib olla halvem kui ideaalne. Tahaks olla erinevaid variatsioone, optimeeritud erinevatele suurustele. Linuxi töökoormustes saavutatakse seda ikoonide hajutamisega failisüsteemis, millel on erinevad suurused.

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

Pange tähele: ei ole olemas erinevaid Firefoxi versioone. Seetõttu ei saa olukorda, kus arvutis on mitu rakenduse versiooni, väga täpselt töödelda.

Erinevad Firefoxi ikoonid erinevates versioonides. Praegu ei ole seda võimalik Linuxis ilma erinevate lahendusteta töödelda.

Mac OS X töötab veidi rafineeritumalt:

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

On näha, et on olemas üks fail firefox.icns pakendis Firefox.app, mis sisaldab kõiki suurusi, seega erinevates versioonides ühel rakendusel on erinevad ikoonid.
Oluliselt parem! Ikoonid reisivad koos rakendusega, kõik ressursid ühes failis.

Naaseme Haiku juurde. Geniaalne lahendus, ilma eranditeta. Vastavalt dokumentatsioon:

On välja töötatud eriline, väikeste suuruste ja kiire renderdamise jaoks kõrgelt optimeeritud formaat HVIF. Seetõttu on meie ikoonid enamasti palju väiksemad kui raster- või laialdaselt kasutatavad SVG formaadis.

Ja nad on tõepoolest optimeeritud:

HVIF ikooni suurused võrreldes teiste formaatidega.

Erinevus on kümneid kordi!

Aga maagia ei lõpe siin. Üks ja sama HVIF võib näidata erinevaid detailitasemeid sõltuvalt kuvatavast suurusest, hoolimata sellest, et see on vektorgraafika formaat.

Erinevad detailitasemed (LOD) sõltuvalt renderdamise suurusest

Nüüd puudutame puudusi: ei saa lihtsalt võtta SVG-d, visata seda ImageMagick'i ja sellega lõpetada, tuleb läbi käia mitu tsüklit, et luua ikoon HVIF formaadis. Siin selgitusi. Kuid IconOMatic võib SVG-d küllaltki ebakompetentselt importida; umbes 90% SVG üksikasjadest imporditakse mingil tõenäosusel, ülejäänud 10% tuleb seadistada ja käsitsi muuta. Võite lugeda rohkem sellest, kuidas HVIF oma maagiat teeb saab blogist Lea Genson

Ikoni lisamine rakendusse

Nüüd saan lisada ikooni pakendile, mille olen loonud eelmisel korral, arvestades kogu saadud teavet.
Kuna mul ei ole nüüd erilist soovi joonistada oma ikooni minu 'Tere, Maailm' QtQuickApp jaoks, siis võtaksin selle Qt Creatorist.

/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

Kontrollime, et ikoon oleks kopeeritud:

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

Tundub hästi, kuid miks, kui uus ikoon on kopeeritud, see ei kuva?

Kopeeritud VICN:101:BEOS:ICONs ei ole veel rakenduse ikoonina failihalduris kasutusel.

Mida ma siis vahele jätsin?

Arendaja kommentaar:

On vaja luua fail rdef kõigi ressurssidega, seejärel käitada käsk rc nimi.rdef, see loob faili .rsrc. Siis tuleb käitada käsk resattr -o nimi_binaar nime.rsrc. Minimaalselt kasutan sarnaseid käske oma skriptide ikoonide lisamiseks.

Oli ju vaja luua ressurss, mitte atribuut. Olen täiesti segaduses.

Nutikas vahemälu failisüsteemi kasutamine.

ELF atribuutide avamine ja lugemine toimub aeglaselt. Nagu ma eelnevalt mainisin, kirjutatakse ikoon ressursina faili endasse. See meetod on usaldusväärsem, võimaldades ellu jääda kopeerimisel teise failisüsteemi. Siiski kopeeritakse see ka failisüsteemi atribuudiks, näiteks BEOS:ICON. See töötab ainult teatud failisüsteemides, näiteks BFS. Süsteemile kuvatavad ikoonid (Trackeris ja Deskbaris) loetakse sellest laiendatud atribuudist, kuna selline lahendus töötab kiiresti. Mõnes kohas (kus kiirus ei ole oluline, näiteks 'Teave programmi kohta' aken) saab süsteem ikooni otse ressursist failis. Kuid see ei ole veel kõik. Pea meeles, et Macis said kasutajad asendada rakenduste, kataloogide ja dokumentide ikoone oma ikoonidega, kuna Macis on võimalus teha selliseid 'olulisi' asju, näiteks Slack uue ikooni asendamine eelneva. Haikus tuleb ressursi (failis) võtta kui rakendusega kaasasolevat algset ikooni, ning atribuut (BFS failisüsteemis) kui midagi, mis võimaldab kasutajal soovi korral muudatusi teha (kuigi, näpunäide, graafiline liides kasutajateikooni vahetamiseks vaikeikooni kohal pole veel teostatud).

Failisüsteemi atribuutide kontrollimine

EL-i abil resaddr on võimalik kontrollida ja seada failisüsteemi atribuute.

/> 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.
(...)

Olenemata sellest, see on nagu „liim“, mis viib ressursid ja failisüsteemi atribuudid usaldusväärsete ja kiirete vahel edasi-tagasi. Kuna süsteem eeldab ressursside hankimist ja kopeerib selle automaatselt, ei pea ma sellest enam muretsema.

hpkg pakettide võlu

Praegu (kõige sagedamini) kasutatakse Haikus programmide hankimiseks pakette .hpkg. Ärge laske end petta lihtsast nimest: .hpkg formaat töötab täiesti teisiti kui teised sarnaste nimedega formaadid, millega olete kokku puutunud, tal on reaalsed supervõimed.

Traditsiooniliste pakettide formaatidega olen ma kaua aega mures olnud järgmise asja pärast: laadid alla ühe (paketi), aga süsteemi installitakse teine (pakettide sees olevad failid). Failidega on üsna keeruline toime tulla (näiteks neid kustutada), kui paketti installitakse traditsiooniliselt. Ja kõik see sellepärast, et paketi sisu jaotub kogu failisüsteemi, sealhulgas kohtadesse, kuhu tavaline kasutaja ei pruugi kirjutamisõigust omada. See loob terve klassi programme — paketihaldureid. Ning juba installitud tarkvara, näiteks teisele masinale, eemaldatavale kettale või failiserverisse liigutamine on veelgi keerulisem, kui mitte täiesti võimatu. Tavalises Linuxi süsteemis võib kergesti eksisteerida sadu tuhandeid või koguni miljoneid isoleeritud faile. Loomulikult on see samal ajal habras ja aeglane, näiteks süsteemi esialgse installimise, traditsiooniliste pakettide installimise, uuendamise ja kustutamise ning alglaadimise mahtude (juurkatalooge) teisele seadmele kopeerimise juures.

Töötan projekti AppImage kallal, mis on osaline tugimeetod lõppkasutajate rakenduste jaoks. See on tarkvara levitamise formaat, mis kogub rakenduse ja kõik selle sõltuvused ühe failisüsteemi pildina, mis mountitakse rakenduse käivitamisel. See lihtsustab asju märgatavalt, kuna sama ImageMagick muutub ootamatult üheks failiks, mida lihtsad surelikud saavad failihalduris hallata. Pakutud meetod töötab ainult tarkvara jaoks, nagu projekt nimigi peegeldab, ning omab ka oma haigeid kohti, kuna Linuxi tarkvara tarnimisega tegelejad suunavad alati süüdistused minu suunas.

Tagasi Haiku juurde. Kas leidus tasakaal traditsiooniliste paketisüsteemide ja piltidele põhineva tarkvara tarnimise vahel? Selle paketid .hpkg on tegelikult tihendatud failisüsteemi pildid. Süsteemi käivitamisel monteerib kernel kõik installitud ja aktiivsed paketid järgmiste kerneliteadete puhul:

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

Lahe, eks? Hoidke kinni, edasi läheb veelgi huvitavamaks!

On üks väga eriline pakett:

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

See sisaldab üsna minimalistlikku operatsioonisüsteemi, sealhulgas kernelit. Uskuge või mitte, kuid isegi kernel ei kaevata käivitusmahtudest (juurpartitsioon) välja, vaid laaditakse hoolikalt oma kohta paketti. .hpkgAga vau! Olen juba maininud, et minu arvates põhineb Haiku terviklikkus ja rafineerituse tunne asjaolul, et kogu süsteemi - kernelist ja põhikasutajakeskkonnast kuni pakettide haldamise ja töökeskkonna infrastruktuurini - arendab sama meeskond ühiselt. Kujutage ette, kui palju erinevaid gruppe ja meeskondi oleks vaja, et midagi sarnast Linuxi baasil käivitada. [kujuneb mul meeles PuppyLinuxi projekt, - tõlkija märkus]. Seejärel kujutage ette, kui kaua kuluks, et see lähenemine distrodesse rakendada. Öeldakse ju, et võtke lihtne ülesanne ja jagage see erinevate täitjatega, ning see muudab selle niivõrd keeruliseks, et see läheb lahendamatuks. Haiku avas selle koha pealt mu silmad. Arvan, et just see juhtub praegu Linuxiga (Linux, siin mõeldud kui kogum, mis viitab Linuxi/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu virnale).

Süsteemi tagasikäik hpkg abil

Kuidas sageli juhtub järgmine olukord: värskendus läks edukalt, kuid hiljem selgub, et midagi ei tööta nii, nagu peab? Tavaliste paketihaldurite kasutamine muudab süsteemi seisundi taastamise enne uute pakettide installimist keeruliseks (näiteks kui midagi läheb valesti). Mõned süsteemid pakuvad lahendusi failisüsteemi klonide abil, kuid need on üsna kohmakad ning neid ei rakendata kõikides süsteemides. Haikus on see lahendatud pakettide abil. .hpkg. Iga kord, kui süsteemis pakette muudetakse, ei eemaldata vanu pakette, vaid need säilitatakse süsteemis alamkaustades vormingus. /Haiku/system/packages/administrative/state-<...>/ püsivalt. Kõik lõpetamata toimingud salvestavad oma andmed alamkaustades. /Haiku/system/packages/administrative/transaction-<...>/.

Sisu /Haiku/system/packages/administrative. „State…“ kaustad sisaldavad tekstifaile aktiivsete pakettide nimedega, „transaction…“ – ise paketid.

„Vana aktiivne seisund“, s.t. nimekiri .hpkg pakettidest, mis olid aktiivsed muudatuste eel, salvestatakse pärast iga toimingut failihalduris tekstifailina. /Haiku/system/packages/administrative/state-<...>/activated-packages. Sarnasel viisil kirjutatakse uus „aktiivne seisund“ tekstifaili. /Haiku/system/packages/administrative/activated-packages.

Kataloog /Haiku/system/packages/administrative/state-<...>/ sisaldab ainult tekstifaili aktiivsete pakettide nimekirjaga sellest seisundist (kui pakette installiti ilma eemaldamata), ja kui pakette eemaldati või uuendati – state kaust sisaldab vanu versioone pakettidest.

Süsteemi käivitamisel otsustatakse pakettide aktiveerimise (mäountimise) üle pakettide nimekirja alusel. Nii lihtne ongi! Kui käivitamisel läheb midagi valesti, saab laadimishaldurile öelda kasutada teist, vanemat nimekirja. Ülesanne on lahendatud!

Haiku laadimishaldur. Iga sisenemiskoht vastab vastavale „aktiivsele seisundile“.

Mulle meeldib lähenemine lihtsate tekstifailide kasutamiseks „aktiivse seisundi“ nimekirjana, kus on salvestatud arusaadavad nimed. .hpkg. See on terav vastand masinatele mõeldud keerulistele süsteemidele. OSTree või Flatpakist failisüsteemis (samas tasemes, kus on ka Microsoft GUID). Aktiivsete pakettide nimekiri igas ajahetkes.

Konfiguratsiooniandmed.

Tundub, et kaustas

on seadistusfailid paketid, kuid kirjutamiseks saadaval. Nagu mäletate, /Haiku/system/packages/administrative/writable-files mäountitakse ainult lugemiseks. Seega tuleb need failid enne kirjutamist paketidest kopeerida. See on mõistlik. .hpkg GUI integreerimine .hpkg süsteemiga.

GUI integreerimine süsteemi .hpkg

Nüüd vaatame, kuidas need säravad paketid .hpkg kliendi töökeskkonda (UX) integreerumisega hakkama saavad. Lõppude lõpuks on Haiku mõeldud isiklikuks kasutamiseks. Isiklikult olen seadnud kõrged ootused, võrdledes kasutajakogemust pakettide .app Macintoshis sama kogemusega .hpkg. Ma ei hakka isegi võrrelda olukorda Linuxi töökeskkondades, sest see on absoluutselt kohutav võrreldes ükskõik millise teisega.

Mulle tulevad meelde järgmised stsenaariumid:

• Ma tahan paketi sisu vaadata .hpkg
• Ma tahan paketti installida
• Ma tahan paketti eemaldada
• Ma tahan eemaldada midagi, mis tuli süsteemi koos paketiga
• Ma tahan kopeerida midagi, mis tuli süsteemi koos paketiga
• Ma tahan alla laadida kõik paketi sõltuvused, mis ei pruugi olla osa igast Haiku installatsioonist (näiteks mulle on füüsiliselt isoleeritud masin, millel pole internetiühendust).
• Ma tahan oma pakette (noh, või nende osa) eraldi teise kohta liikuda, eraldi alglaadimise mahust (juurkett) (sest näiteks mul on seal ruumipuudus).

See peaks katma enamiku minu igapäevase töö põhijuhtumeid. Noh, alustame.

Paketi sisu kontrollimine

Macis klõpsan ma lihtsalt paketi peal paremalla ja avan selle sisu Finderis. Lõppude lõpuks on see lihtsalt maskeeritud kataloog! (Ma tean, et on olemas paketid .pkg süsteemi osade jaoks, mis ei ole rakendused, kuid tavalised kasutajad ei puutu nendega enamasti kokku).

Haikus klõpsan paketi peal paremalla, seejärel valin "Contents", et vaadata, mis sees on. Kuid siin on lihtsalt failide nimekiri ilma võimaluseta neid topeltklõpsuga avada.
Oleks palju parem, kui oleks võimalik (ajutine) paketi mountimine .hpkg failihalduri kaudu vaatamiseks, nii et kasutaja ei peaks muretsema teostuse detailide pärast. (Muide, paketti saab avada .hpkg Expanderis , mis võib selle välja pakkida nagu iga teine arhiiv).HaikuDepot liideses saab vaadata paketi failide nimekirja, kuid pole viisi sisu vaatamiseks, näiteks topeltklõpsates README.md

Selles kategoorias võidab Mac, kuid vajaliku funktsionaalsuse lisamine HaikuDepotis ei tohiks tekitada suuri raskusi.

Paketi installimine GUI kaudu

Paketihalduse installimine GUI kaudu

Macis, enamik ketaspilte .dmg sisaldab pakette .app. Avame ketaspildi kahekordse klõpsuga, seejärel kopeerime paketi, näiteks lohistades selle /Applications Finderis. Minu jaoks tundub see iseenesestmõistetav, kuid olen kuulnud, et mõned algajad võivad sellega raskustes olles. Vaikimisi /Applications (NeXT-is oli see võrgus, samuti individuaalne), kuid oma rakendusi on lihtne paigutada ka failiserverisse või alamkausta $HOME/Applications, kui see teile sobib.

Haikus, kahekordne klõps paketile, seejärel klõps "Install", lihtsam ei saa olla. Mind huvitab, mis juhtub, kui paketil on sõltuvused, mis on saadaval HaikuPorts'is, kuid veel mitte installitud. Linuxis ei osata selles olukorras tõesti midagi teha, aga lahendus on ilmne — küsida kasutajalt, kas ta soovib sõltuvusi alla laadida ja installida. Just seda teebki Haiku.

Allalaadisin paketi 'sanity' käsitsi ja klõpsasin sellele, pakettide haldur teab, kust võtta selle sõltuvused (tingimusel, et hoidlad on juba süsteemis kirjas). Mitte iga Linuxi distributsioon ei oska seda.

Veel üks viis on failihalduri kasutamine, piisab lihtsalt paketi lohistamisest .hpkg kausta, või /Haiku/system/packages (üldiseks paigaldamiseks, vaikimisi), või /Haiku/home/config/packages (individuaalse paigaldamise jaoks; ei ole saadaval kahekordse klõpsuga — mind häirib endiselt sõna "config" siin, mis minu jaoks on sel juhul sünonüüm "settings"-ile). Aga mitme kasutaja kontseptsioon pole Haiku jaoks veel saadaval (ilmselt ongi seetõttu kõik nii lihtne — ma ei tea, võib-olla muudab mitmikkasutuse võimalused isikliku arvuti töökeskkonna jaoks liiga keeruliseks).

Selles kategoorias võidab Haiku, sest oskab töötada mitte ainult rakendustega, vaid ka süsteemiprogrammidega.

Paketi eemaldamine GUI-st

Macis, tuleb rakenduse ikoon lohistada prügikasti, ja sellega asi piirdub. Lihtne!

Haikus, kõigepealt peate leidma, kus paketid süsteemis asuvad, kuna te harva installite neid õigesse kohta (kõike teeb süsteem). Tüüpiliselt tuleb otsida /Haiku/system/packages (üldise paigaldamise jaoks vaikimisi), või /Haiku/home/config/packages (ma juba ütlesin, et "config" ei ole õige nimetus?). Siis lohistatakse rakendus lihtsalt prügikasti ja sellega asi piirdub.
Lihtne! Siiski, ma ei ütleks nii. Siin on, mis tegelikult juhtub:

Siit saab teada, mis juhtub, kui tõukate rakenduse prügikasti. /Haiku/system/packages

Lihtsalt proovisin viia oma eilse rakenduse "Tere, maailm" QtQuickApp-s prügikasti. Ma ei üritanud süsteemi katalooge liigutada, ja kuna kõik paketid installitakse süsteemi katalooge — ei saa paketti kustutada .hpkg ilma et muuta "tema sisu". Tavaline kasutaja ehmuks, vajutades vaikimisi "Tühista" nuppu.

Selgitab mr. waddlesplash:

Sellel teatega on juba üle 10 aasta. Tõenäoliselt peaksime selle seadistama nii, et hoiatust kuvataks ainult paketi liigutamisel. Tavalised kasutajad ei pea niikuinii seda tegema.

Noh, võib-olla peaksin proovima seda teha HaikuDepot'i kasutades? Topeltklikin paketti /Haiku/system/packages, oodates, et kuvatakse "Eemalda" nupp. Ei, on (ainult) "Installi". "Eemalda", kus sa oled?

Proovisin nalja pärast, mis juhtub, kui vajutan "Installi" juba installitud paketi jaoks. Tuleb välja nii:

Nii juhtub, kui proovite installida juba installitud paketti.

Järgmine ilmub:

Kui eelmisel aknas vajutada "Rakenda muudatused" — tuleb välja nii

Eeldan, et see on tarkvaralööve, pilet on juba avatud. [autor ei jaganud linki, — tõlkija märkus]

Kiire lahendus: lisada "Eemalda" nupp, kui pakett on juba olemas /Haiku/system/packages, või /Haiku/home/config/packages.

HaikuDepot's installitud pakettide nimekirja vaadates näen oma paketti nimekirjas ja saan selle eemaldada.

Selles kategoorias võidab Mac. Aga ma suudan ette kujutada, et korraliku seadistuse korral võiks Haiku kasutajakogemus olla parem kui Macil. (Üks arendajatest hindas seda nii: "Kuna vähe aega, et lisada näidatud funktsionaalsust HaikuDepot'is, kui tead veidi C++-st", on vabatahtlikke?)

Mõne asja eemaldamine paketist

Proovime eemaldada rakenduse ennast, mitte paketti .hpkg, millest see ilmnes (kahtlen, et "tavalistele surelikel" on mingi vahe).

Macis, kasutaja töötab tegelikult tavaliselt faili .dmg, kust tuleb rakenduse pakett .app. Tavaliselt tekivad pildid .dmg allalaadimiste kataloogis, kuid paketid kopeeritakse kasutaja poolt /Applications. On arvamus, et paljud kasutajad ei tea, mida nad teevad, ja seda hüpoteesi kinnitab endine Apple'i töötaja. (Üks asi, mis mulle Mac'i juures ei meeldi. Aga näiteks AppImage'i puhul ei ole vahet rakenduse ja paketi vahel, milles see oli. Lihtsalt tõmba ikoon prügikasti = ja see on kõik. Lihtne!)

Haikus, samuti on eristamine rakenduste/ ja pakettide/, nii et ma kahtlen, et kasutajatele on see selgemaks muutunud. Aga mis juhtub, kui tõmbad rakenduse rakenduste/ prügikasti:

Siin on see, mis juhtub, kui proovid rakendust kustutada, mis on saadud failist .hpkg

Tehniliselt on see õige (sest rakendus on paigutatud ainult lugemiseks mõeldud failisüsteemile), aga see ei ole kasutajale eriti kasulik.

Kiire lahendus: selle asemel pakkuda GUI kaudu kustutamist .hpkg

Huvi pärast proovisin rakendust dubleerida, vajutades Alt+D. Sai teate «Ei saa objekte kirjutada või kopeerida ainult lugemiseks mõeldud sõltumatu mahamonteerimisega». Ja see on kõik, sest /system (lisaks /system/packages ja /system/settings) on packagefs'i mountpunkt (pead meeles, kuidas see kuvab väljundis df?). К сожалению, вывод команды mount ei selgita olukorda (nagu oli öeldud ühes varasemas artiklis), mountvolume ei näita soovitud (näib, et ainult loop kaudu monteeritud paketid .hpkg ei loe «mahdudena»), ja unustasin ka alternatiivsed käsud.

Selles kategoorias ei võitnud keegi peale AppImage'i (aga see on, kui olla täiesti aus, kallutatud arvamus). Siiski võib eeldada, et pärast kohandamist on Haiku kasutajakogemus parem kui Mac'il.

Märkus: tuleb välja selgitada, mis on «maht» seoses «kotiga». Tõenäoliselt on see võrreldav «kausta» ja «katalooge» vahel: enamus katalooge kuvatakse failihalduris kaustadena, kuid mitte kõik neist (näiteks paketid, mida töödeldakse failidena). Kas need väljendid teevad mind ametlikult nerdiks?

Paketi sisu kopeerimine teisele süsteemile

Macis, tõmban lihtsalt paketti .app, ja kuna sõltuvused on paketti sees - need liiguvad koos.

Haikus, tõmban rakenduse, aga sõltuvusi ei töödeldud üldse.

Kiire lahendus: laske selle asemel pakkuda paketi «.hpkg» täielikult koos sõltuvustega, kui need on olemas.

Selles kategoorias on Mac selgelt võitja. Vähemalt mina, kes armastan nende paradigmat. Haiku peaks seda kopeerima. .hpkg rakenduse asemel, kuid süsteem ei paku mulle sellist ...

Paketi allalaadimine koos kõigi selle sõltuvustega

Kaugel on iga masin pidevalt ühendatud. Vastupidi, mõned masinad (jah, ma vaatan teid, modernsed Windows, Mac ja Linux) unustavad selle. Minu jaoks on oluline, et ma saaksin näiteks minna internetikohvikusse, tõmmata tarkvara eemaldatavasse seadmesse, sisestada see seade kodukompjutaatorisse ja olla kindel, et kõik töötab [riskialti inimene, tehes seda Windowsis... — tlk. märk].

Seetõttu satun ma natuke sagedamini, kui peaksin, tavaliselt rahulolematute sõltuvuste pärast Windowsis ja Linuxis.

Macis see on tavaliselt üks fail, kõik, mis on vajalik — alla laadida .dmg. Enamasti ei ole tal sõltuvusi peale nende, mis MacOS-i vaikimisi kaasas. Erandiks võib olla keerulised rakendused, mis vajavad vastavat töökeskkonda, näiteks java.

Haikus alla laadida pakett .hpkg näiteks sama rakenduse jaoks java, võib osutuda ebapiisavaks, kuna java võib olla nii kohal kui ka puududa sihtmasinal. Kas on võimalik alla laadida kõik sõltuvused antud paketi jaoks .hpkg, välja arvatud need, mis installitakse Haikus vaikimisi ja seega peaksid olema igas Haiku süsteemis?

Selles kategoorias võidab Mac väikese edumaaga.

Kommenteerib hr. waddlesplash:

Et kirjutada programm, mis kogub kõik rakenduse sõltuvused pakettide kogumina .hpkg kellegi jaoks, kes tunneb Haiku sisemist ülesehitust, piisab umbes 15 minutist. Toetuse lisamine pole sugugi keeruline, kui see on tõeline vajadus. Kuid minu jaoks on see haruldane olukord.

Hoidke hinge kinni, kuni järgmine artikkel selles tsüklis ilmub.

Pakettide liigutamine eraldi kohta

Nagu ma juba varem mainisin, tahan panna oma paketid .hpkg (noh, või nende osa) eraldi kohta, mis on eraldatud tavalise paigutuse laadimiskettal (juurkonnal). Tavalises olukorras (mitte sugugi teoreetilises) on põhjuseks see, et minu (sise)kettal lõpeb pidevalt vaba ruum, hoolimata sellest, kui suured nad on. Ja ma ühendangi tavaliselt välised kettad või võrguteenused, kus minu rakendused asuvad.

Macis ma lihtsalt liigutan pakette .app kaardile või võrgu katalooge Finderis, ja sellega kõik. Ma saan ikka veel kahekordse klõpsuga avada rakenduse nagu tavaliselt tegin seda käivitusmahu kaudu. Lihtne!

Haikus, nagu mulle öeldi, seda saab saavutada mu muude .hpkg pakettide liigutamisega kaardile või võrgu katalooge, kuid seejärel tuleb kasutada mõningaid dokumenteerimata käske terminalis, et need süsteemi monteerida. Ma ei tea, kuidas seda teha, kasutades ainult graafilist liidest.

Selles kategoorias võidab Mac.

Vastavalt mr. waddlesplashile:

Siin on optimeerimine arvutuste põhjal tavalise kasutuse jaoks. Kui nõudlus suureneb rohkem kui ühe kasutaja jaoks, rakendame seda kindlasti. Igatahes on võimalus kolmanda osapoole rakendamiseks.

Räägime sellest järgmises artiklis.

Kui rääkida võrgu kataloogidest: oleks suurepärane (eeldan LAN-pidusid) omada lihtsaid, tuvastatavaid, võrguülesande rakendusi (näiteks Zeroconfi kaudu), mida saab kopeerida lokaalsesse arvutisse või käivitada otse kohalikust võrgust. Muidugi on arendajatel võimalus sellest loobuda läbi app_flags.

Lõpparuande integratsioonisüsteemist hpkg koos GUI-ga

Ma arvan, et peamiselt sellel põhjusel, et suhteliselt uue integratsiooniga .hpkg GUI-ga jätkub veel ruumi parendamiseks. Igatahes on mitmeid asju, mida kasutajakogemuse osas saaks parandada…

Veel üks asi: Kernel Debug Land

Oleks suurepärane, kui kernel panics ajal oleks võimalik sisestada käske, näiteks syslog | grep usb. Noh, Haikus on see võimalik Kernel Debug Landi tõttu. Kuidas aga näha seda maagiat toimimas, kui sul läheb kõik hästi ilma kernel panicsita? Lihtne, klõpsates Alt+PrintScn+D (mnemoonika Debug). Mulle meenuvad kohe Programmer’s Key, mis võimaldas algsetel Macintosh arendajatel pääseda debugeerimisse (kui see oli loomulikult installitud).

Kokkuvõte

Hakkasin mõistma, et Haiku süsteemi keerukus tuleneb sellest, et tööd teeb väike meeskond, millel on selge suund töökeskkonnale, kui kõik süsteemi kihid on kergesti ligipääsetavad.
Terav kontrast Linuxi / GNU / dpkg / apt / systemd / Xorg / dbus / Gtk / GNOME / XDG / Ubuntu maailmaga, kus kõik on tükkideks purustatud sellisel määral, et abstraktsioon istub abstraktsioonil ja toetub kõigi kaudu.
Samuti tuli mõistmine, kuidas süsteem .hpkg kombineerib parimaid tavasid traditsioonilistest paketihalduritest, Snappy, Flatpak, AppImage, isegi btrfs, ja segab need kokku Maci põhimõttega "lihtsalt töötab".

Nagu midagi «lülitus» mu peas ja ma sain aru, kuidas süsteem .hpkg suudab tagasi pöörduda, — lihtsalt vaadates seda. Aga see ei ole mina, vaid süsteemi ilu ja lihtsus. Paljuski on siin tunda algse Mac'i vaimu.

Jah, lehekülgede sirvimine brauseris võib olla tõrkuv ja toimida nagu limukas, rakendusi võib puududa (Gtk, Electron — arendajad järeldasid, et need ei sobi hästi elegantsiga), video ja 3D kiirendamine võib täielikult puududa, kuid siiski mulle meeldib see süsteem. Need asjad on parandatavad ja need tulevad varem või hiljem. See on vaid aja ja võib-olla veidi punaste silmade küsimus.

Ma ei saa abi pakkuda, kuid arvan, et just sellest hetkest algab aasta Haiku töölaual.

Juhuslikud probleemid

Võib-olla on juba päringud esitatud, või pean ma need avama?

• BeScreenCapture peaks saama GIF-formaadis eksportida, nagu Peek. Selle võib teha ffmpeg'iga, mis on juba Haikus olemas. Päring.
• Ekraanipildi loomise programm ei saa teha pilti mudelaknast, vaid hoopis kogu ekraanist
• Ekraanipilte ei saa kärpida WonderBrush'i kärpimise tööriistaga ja seejärel salvestada tulemust failina
• Mulle ei meeldi eriti Haiku käe ikoon, kuid arvan, et see on seotud sooja nostalgiaga. See häirib eriti Kritas kärpimise tööriista kasutamisel, kuna see toob kaasa ebatäpse kärpimise (vt ekraanipilte mudeldialoogidest selle artikli sissejuhatuses). Ristkülikukujuline kursori oleks suurepärane. Päring.

Proovige ise! Lõppude lõpuks pakub Haiku projekt allalaetavaid pilte DVD-le või USB-le, mis on loodud iga päev. Paigaldamiseks piisab pildi allalaadimisest ja selle kirjutamisest mälupulgale, kasutades Etcher

Kas teil on küsimusi? Kutsume teid venekeelsesse telegrami kanalisse.

Vigade ülevaade: Kuidas end C ja C++-ga jalga lasta. Haiku OS retseptide kogu

Alates autor tõlge: see on kuues artikkel Haiku teemal.

Artiklite nimekiri: Esimene Teine Kolmas Neljas Viies

Allikas: habr.com