TL; DR: Haiku is 'n bedryfstelsel wat spesifiek vir rekenaars ontwerp is, so dit het verskeie truuks wat sy rekenaaromgewing baie beter maak as ander. Maar hoe werk dit?
Ek het Haiku ontdek, 'n onverwags goeie stelsel. Ek is steeds verbaas oor hoe glad dit loop, veral in vergelyking met Linux-lessenaaromgewings. Vandag gaan kyk ek onder die enjinkap. Waar nodig vir 'n diepgaande begrip, sal ek vergelykings tref met die oorspronklike Macintosh, Mac OS X en Linux lessenaar omgewings (XDG standaard van freedesktop.org).
Hulpbronne in ELF-lêers
Gister het ek geleer dat IconOMatic ikone in rdef-hulpbronne in ELF-uitvoerbares kan stoor. Vandag wil ek sien hoe dit regtig werk.
Hulpbronne? van , die oorspronklike skrywer van die Macintosh Finder en die "vader" van die Macintosh Hulpbronbestuurder:
Ek is bekommerd oor die rigiede aard van tradisionele kodering. Vir my is die idee van 'n toepassing wat in kode gevries is, sonder die vermoë om iets dinamies te verander, die wildste wreedheid. Dit moet moontlik wees om soveel as moontlik tydens looptyd te verander. Natuurlik kan die toepassingskode self nie verander word nie, maar iets kan tog verander word sonder om die kode te hersaamstel?
Op die oorspronklike Macintosh het hulle hierdie lêers 'n "data-afdeling" en 'n "hulpbronafdeling" gemaak, wat dit ongelooflik maklik gemaak het om dinge soos ikone, vertalings en dies meer te stoor. in uitvoerbare lêers.
Op Mac word dit gebruik , 'n grafiese program vir - skielik - redigering van hulpbronne.
Herbewerk op die oorspronklike Macintosh
As gevolg hiervan het dit moontlik geword om ikone, spyskaartitems, vertalings, ens. maklik genoeg, maar hulle “reis” steeds met die toepassings.
In elk geval, hierdie benadering het 'n groot nadeel gehad: dit het net op Apple-lêerstelsels gewerk, wat een van die redes was waarom Apple die "hulpbronafdeling" laat vaar het toe hy na Mac OS X oorgeskakel het.
Op Mac OS X wou Apple 'n lêerstelsel-onafhanklike oplossing hê, en daarom het hulle die konsep van pakkette (van NeXT) aangeneem, gidse wat deur die lêerbestuurder as "ondeursigtige voorwerpe" behandel word, soos lêers eerder as gidse. Enige pakket met 'n toepassing in die formaat .app het, onder andere, 'n lêer Info.plist (in een of ander soort Apple se ekwivalent van JSON of YAML) wat toepassingsmetadata bevat.
Sleutels vir die Info.plist-lêer vanaf die Mac OS X-toepassingspakket.
Hulpbronne, soos ikone, UI-lêers en ander, word as lêers in die pakket gestoor. Die konsep het eintlik teruggegaan na sy wortels in NeXT.
Mathematica.app op NeXTSTEP 1.0 in 1989: verskyn as 'n gids van lêers in die terminaal, maar as 'n enkele voorwerp in die grafiese lêerbestuurder.
Kom ons keer terug na BeOS, die konsepte waarop Haiku gebaseer is. Die ontwikkelaars daarvan, toe hulle van PEF (PowerPC) na ELF (x86) oorgeskakel het (dieselfde as wat op Linux gebruik word), het besluit om 'n hulpbronafdeling aan die einde van die ELF-lêers by te voeg. Dit het nie sy eie behoorlike ELF-afdeling gebruik nie, dit is eenvoudig aan die einde van die ELF-lêer aangeheg. As gevolg van die program strip en ander van binutils, wat nie hiervan bewus is nie, sny dit eenvoudig af. Daarom, wanneer hulpbronne by 'n ELF-lêer op BeOS gevoeg word, is dit beter om dit nie met Linux-nutsgoed te manipuleer nie.
Wat gaan nou aan met Haiku? Basies, min of meer dieselfde.
In teorie sou dit moontlik wees om hulpbronne in die gewenste afdeling van die ELF te plaas. Volgens die ontwikkelaars op die #haiku-kanaal op irc.freenode.net:
Met ELF sou die afdeling meer sin maak ... die enigste rede waarom ons dit nie so doen nie, is omdat dit is wat ons in BeOS gedoen het."
En daar is geen sin om dit nou te verander nie.
Hulpbron bestuur
Hulpbronne word in 'n gestruktureerde "hulpbron"-formaat geskryf: in wese 'n lys van hulpbronne met groottes en dan hul inhoud. Ek het onthou .
Hoe om hulpbronne in Haiku na te gaan? Is daar iets soos ResEdit?
Volgens :
Om die hulpbronne wat in die toepassingspakket verskaf word te sien, kan jy die uitvoerbare lêer na 'n program soos . U kan ook na die terminale gaan en die opdrag uitvoer
listres имя_файла.
Resourcer is beskikbaar in HaikuDepot, maar dit crash net vir my.
Hoe om hulpbronne in ELF-lêers te bestuur? Met behulp van rsrc и rdef. rdef lêers word ingesamel rsrc. lêer rdef word in gewone teks formaat gestoor, so dit is baie makliker om mee te werk. Lêerformaat rsrc aan die einde van die ELF-lêer aangeheg. Kom ons probeer speel:
~> 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 licenseJy kan die program gebruik xres vir kontrolering en beheer:
/> 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.
(...)Goed, kom ons probeer?
/> 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_VERSIONMeer oor hulpbronne en formaat rdef jy kan lees .
Standaard hulpbrontipes
Alhoewel jy enigiets in hulpbronne kan plaas, is daar 'n paar gedefinieerde standaardtipes:
app_signature: MIME toepassing tipe, vir lêer oop kartering, bekendstelling, IPC, ens.app_name_catalog_entry: Aangesien die toepassingsnaam gewoonlik in Engels is, kan u die plekke spesifiseer waar die vertaalde name geleë is, sodat gebruikers van verskillende tale die vertaalde toepassingsnaam sal sien indien verlang.app_version: presies wat jy gedink hetapp_flags: dui aanregistrarhoe om die aansoek te verwerk. Ek dink daar is meer daaraan as wat ons op die oog af sien. Daar is byvoorbeeldB_SINGLE_LAUNCH, wat die stelsel dwing om 'n nuwe toepassingsproses te begin elke keer as die gebruiker dit versoek (dieselfde beginsel word vir die meeste toepassings op Linux gebruik). EetB_MULTIPLE_LAUNCH, wat veroorsaak dat die proses duur elke lêer. Uiteindelik is daarB_EXCLUSIVE_LAUNCH, wat die stelsel dwing om net een proses op 'n slag te begin, maak nie saak hoe gereeld gebruikers dit begin nie (dit is byvoorbeeld hoe Firefox op Linux werk; dieselfde resultaat kan in Qt-toepassings bereik word deur die funksie te gebruik ). Aansoeke metB_EXCLUSIVE_LAUNCHword in kennis gestel wanneer die gebruiker probeer om hulle weer te laat loop: hulle ontvang byvoorbeeld die pad van die lêer wat die gebruiker met hul hulp wil oopmaak.vector_icon: Vektortoepassingsikoon (BeOS het nie vektorikone gehad nie, die meeste toepassings het eerder twee rasterikone in hul uitvoerbare lêers gehad).
Natuurlik kan u hulpbronne met enige verlangde ID's en tipes byvoeg, en dit dan in die toepassing self of ander toepassings lees deur die klas te gebruik BResources. Maar eers, kom ons kyk na die fassinerende onderwerp van ikone.
Vektor-ikone in Haiku-styl
Natuurlik het Haiku nie net die beste ikoonformaat gekies nie; in hierdie deel is die situasie met Linux-lessenaaromgewings ver van ideaal:
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.cacheAs jy hierna kyk kan jy al voel watter stuk dit is.
Natuurlik is daar skaalbaar, wat, soos u kan verstaan, vektorikone bevat. Hoekom is daar dan enigiets anders? Omdat die resultaat van die teken van vektorgrafika in klein groottes minder as ideaal kan wees. Ek wil graag verskillende opsies hê wat vir verskillende groottes geoptimaliseer is. In Linux-lessenaaromgewings word dit bereik deur ikone van verskillende groottes deur die lêerstelsel te verstrooi.
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.pngNeem asseblief kennis: daar is geen konsep van verskillende weergawes van Firefox nie. Dit is dus nie moontlik om die situasie van veelvuldige weergawes van 'n toepassing op die stelsel grasieus te hanteer nie.
Verskillende Firefox-ikone in verskillende weergawes. Dit is tans onmoontlik om dit in Linux te hanteer sonder verskeie krukke.
Mac OS X hanteer dit 'n bietjie meer subtiel:
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.icnsDit kan gesien word dat daar een lêer is firefox.icns in die pakket Firefox.app, wat alle groottes bevat sodat verskillende weergawes van dieselfde toepassing verskillende ikone het.
Baie beter! Ikone reis saam met die toepassing, alle hulpbronne is in een lêer.
Kom ons keer terug na Haiku. 'n Verstommende oplossing, geen uitsonderings nie. Volgens :
'n Spesiale HVIF-formaat, hoogs geoptimaliseer vir klein groottes en vinnige weergawe, is ontwikkel. Daarom is ons ikone vir die grootste deel baie kleiner as in raster of in die algemeen gebruikte SVG-formaat.
En hulle is steeds geoptimaliseer:
Ikoongroottes in HVIF in vergelyking met ander formate.
Die verskil is 'n orde van grootte!
Maar die magie eindig nie hier nie. Dieselfde HVIF kan verskillende vlakke van detail wys, afhangende van die grootte wat vertoon word, al is dit 'n vektorformaat.
Verskillende vlakke van detail (LOD) afhangende van leweringgrootte
Nou oor die nadele: jy kan nie SVG neem, dit in ImageMagick gooi en dit 'n dag noem nie; jy moet deur verskeie siklusse gaan om 'n ikoon in HVIF-formaat te skep. verduidelikings. IconOMatic kan SVG egter redelik onvolmaak invoer; ongeveer 90% van SVG-besonderhede word met 'n mate van waarskynlikheid ingevoer, die oorblywende 10% sal met die hand gekonfigureer en verander moet word. Lees meer oor hoe HVIF sy towerkrag doen in die blog
Voeg 'n ikoon by die toepassing
Nou kan ek 'n ikoon by die geskepde pakket voeg , met inagneming van al die inligting wat ontvang is.
Wel, aangesien ek nie nou besonder gretig is om my eie ikoon vir my "Hallo, Wêreld" QtQuickApp te teken nie, trek ek dit uit 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 CreatorKom ons kyk of die ikoon gekopieer is:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONLyk goed, maar hoekom verskyn dit nie wanneer die nuwe ikoon gekopieer word nie?
Die gekopieerde VICN:101:BEOS:ICONs word nog nie as 'n toepassingikoon in die lêerbestuurder gebruik nie
Wat het ek gemis?
Ontwikkelaar se opmerking:
Ons moet 'n lêer skep
rdefmet alle hulpbronne, voer dan die opdrag uitrc имя.rdef, sal dit die lêer skep.rsrc. Dan moet jy die opdrag uitvoerresattr -o имя_бинарника имя.rsrc. Op 'n minimum gebruik ek opdragte soos hierdie om ikone by my skrifte te voeg.
Wel, ek wou 'n hulpbron skep, nie 'n eienskap nie. Ek is regtig deurmekaar.
Slim kas met behulp van die lêerstelsel
Die oopmaak en lees van ELF-kenmerke is stadig. Soos ek hierbo geskryf het, is die ikoon geskryf as 'n hulpbron in die lêer self. Hierdie metode is meer betroubaar en laat jou toe om kopiëring na 'n ander lêerstelsel te oorleef. Dit word egter dan ook byvoorbeeld na die lêerstelsel-kenmerk gekopieer BEOS:ICON. Dit werk net op sekere lêerstelsels, soos BFS. Die ikone wat deur die stelsel gewys word (in Tracker en Deskbar) word uit hierdie uitgebreide kenmerk gelees, want hierdie oplossing werk vinnig. Op sommige plekke (waar spoed nie belangrik is nie, byvoorbeeld 'n tipiese "About"-venster), ontvang die stelsel die ikoon direk vanaf die hulpbron in die lêer. Maar dit is nie die einde nie. Onthou, op Mac kan gebruikers ikone van toepassings, gidse, dokumente vervang met hul eie, aangesien dit op Mac moontlik is om hierdie "belangrike" dinge te doen, byvoorbeeld . Op Haiku moet jy aan die hulpbron (in die lêer) dink as die oorspronklike ikoon wat by die toepassing kom, en die kenmerk (in die BFS-lêerstelsel) as iets wat die gebruiker toelaat om veranderinge na goeddunke aan te bring (hoewel, wenk, die GUI vir die invoeging van 'n pasgemaakte ikoon bo-op die ikoon is opsioneel). nog nie by verstek geïmplementeer nie).
Kontroleer lêerstelselkenmerke
Met resaddr Dit is moontlik om lêerstelselkenmerke na te gaan en in te stel.
/> 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.
(...)Dit is in wese die "gom" wat die omskakeling heen en weer tussen (betroubare) hulpbronne en (vinnige) lêerstelsel-kenmerke uitvoer. En aangesien die stelsel verwag om hulpbronne te ontvang en die kopiëring outomaties doen, sal ek my nie verder daaroor bekommer nie.
Die magie van hpkg-pakkette
Tans word (meestal) pakkette gebruik om programme op Haiku te bekom .hpkg. Moenie deur die eenvoudige naam geflous word nie: die .hpkg-formaat werk heeltemal anders as ander formate met soortgelyke name wat jy teëgekom het, dit het ware superkragte.
Met tradisionele pakketformate was ek vir 'n lang tyd ontsteld oor hierdie feit: jy laai een ding af (pakket), en 'n ander is op die stelsel geïnstalleer (lêers binne die pakket). Dit is nogal moeilik om lêers te bestuur (byvoorbeeld om dit uit te vee) wanneer 'n pakket op die tradisionele manier geïnstalleer word. En dit alles omdat die inhoud van die pakkie versprei deur die lêerstelsel, insluitend plekke waar die gemiddelde gebruiker dalk nie skryftoegang het nie. Dit gee aanleiding tot 'n hele klas programme - pakketbestuurders. Maar die oordrag van reeds geïnstalleerde sagteware, byvoorbeeld, na 'n ander masjien, verwyderbare skyf of lêerbediener word selfs moeiliker, indien nie heeltemal onmoontlik nie. Op 'n tipiese Linux-gebaseerde stelsel kan daar maklik 'n paar honderdduisend tot miljoene individuele lêers wees. Nodeloos om te sê, dit is beide broos en stadig, byvoorbeeld wanneer 'n stelsel aanvanklik geïnstalleer word, wanneer gereelde pakkette geïnstalleer, opgedateer en verwyder word, en wanneer die selflaaivolume (wortelpartisie) na 'n ander medium gekopieer word.
Ek werk aan die AppImage-projek, 'n gedeeltelike kruk vir eindgebruikerstoepassings. Dit is 'n sagtewareverspreidingsformaat wat 'n toepassing en al sy afhanklikhede in 'n enkele lêerstelselbeeld versamel wat gemonteer word wanneer die toepassing begin. Vereenvoudig dinge aansienlik, aangesien dieselfde ImageMagick skielik verander in 'n enkele lêer, wat in 'n lêerbestuurder deur blote sterflinge bestuur word. Die voorgestelde metode werk net vir sagteware, soos weerspieël in die naam van die projek, en het ook sy eie stel probleme, aangesien mense wat betrokke is by die lewering van sagteware vir Linux altyd die pyl na my wys.
Kom ons keer terug na Haiku. Was dit moontlik om die optimale balans tussen tradisionele pakketstelsels en beeldgebaseerde sagteware-aflewering te vind? Haar pakkies .hpkg eintlik saamgeperste lêerstelselbeelde. Wanneer die stelsel selflaai, monteer die kern alle geïnstalleerde en aktiewe pakkette met ongeveer die volgende kernboodskappe:
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"Cool, ja? Hou vas, dit sal nog koeler wees!
Daar is 'n baie spesiale pakket:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Dit bevat 'n baie minimalistiese bedryfstelsel, insluitend die kern. Glo dit of nie, selfs die kern self word nie van die selflaaivolume (wortelpartisie) verwyder nie, maar word versigtig uit die pakket op sy plek gelaai .hpkg. Sjoe! Ek het reeds genoem dat ek dink 'n deel van Haiku se algehele gesofistikeerdheid en konsekwentheid kom uit die feit dat die hele stelsel, van die kern en kerngebruikersruimte tot pakketbestuur en runtime-infrastruktuur, saam deur een span ontwikkel word. Stel jou voor hoeveel verskillende groepe en spanne dit sal neem om so iets op Linux te laat loop [Ek stel my die PuppyLinux-projek voor - ongeveer. vertaler]. Stel jou dan voor hoe lank dit sal neem vir hierdie benadering om in verdelings aangeneem te word. Hulle sê: vat 'n eenvoudige probleem, verdeel dit tussen verskillende kunstenaars, en dit sal so ingewikkeld raak dat dit nie meer moontlik sal wees om dit op te los nie. Haiku het in hierdie geval my oë oopgemaak. Ek dink dit is presies wat nou op Linux gebeur (Linux is in hierdie geval 'n kollektiewe term vir die Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu-stapel).
Stelsel terugrol met hpkg
Hoe gereeld kom die volgende situasie voor: die opdatering was suksesvol, en dan blyk dit dat iets nie werk soos dit moet nie? As jy konvensionele pakketbestuurders gebruik, is dit moeilik om die toestand van die stelsel terug te keer na 'n tydstip voordat nuwe pakkette geïnstalleer is (byvoorbeeld in die geval dat iets verkeerd geloop het). Sommige stelsels bied oplossings in die vorm van lêerstelsel-kiekies, maar dit is redelik omslagtig en word nie op alle stelsels gebruik nie. Haiku los dit op met behulp van pakkette .hpkg. Wanneer pakkette in die stelsel verander, word die ou pakkette nie uitgevee nie, maar word dit in die stelsel gestoor in subgidse soos /Haiku/system/packages/administrative/state-<...>/ voortdurend. Onvoltooide bedrywighede stoor hul data in subgidse /Haiku/system/packages/administrative/transaction-<...>/.
inhoud /Haiku/system/packages/administrative. Die "staat..."-gidse bevat tekslêers met die name van aktiewe pakkette, en die "transaksie..."-gidse bevat die pakkette self.
"Ou aktiewe toestand", m.a.w. lys .hpkg pakkette wat aktief is voor veranderinge word na elke bewerking in die lêerbestuurder in 'n tekslêer aangeteken /Haiku/system/packages/administrative/state-<...>/activated-packages. Op 'n soortgelyke manier word 'n nuwe "aktiewe toestand" in 'n tekslêer geskryf /Haiku/system/packages/administrative/activated-packages.
Каталог /Haiku/system/packages/administrative/state-<...>/ bevat slegs 'n tekslêer met 'n lys van aktiewe pakkette van hierdie toestand (in die geval van installering van pakkette sonder verwydering), en as pakkette verwyder of opgedateer is - die staatsgids bevat ou weergawes van pakkette.
Wanneer die stelsel opstart, gebaseer op die lys van pakkette, word 'n besluit geneem om pakkette te aktiveer (monteer). Dis so eenvoudig! As iets verkeerd loop tydens die aflaai, kan jy die aflaaibestuurder sê om 'n ander, ouer lys te gebruik. Probleem opgelos!
Haiku-aflaaier. Elke toegangspunt vertoon 'n ooreenstemmende "aktiewe toestand"
Ek hou van die benadering om eenvoudige tekslêers as die "aktiewe toestand"-lys te hê, met name wat maklik is om te verstaan .hpkg. Dit staan in skrille kontras met om-vir-masjiene-nie-vir-mense gebou te wees nie. van OSTree of Flatpak in die lêerstelsel (op dieselfde vlak as Microsoft GUID).
Lys van aktiewe pakkette vir elke tydstip
Konfigurasie data
Blykbaar in die katalogus /Haiku/system/packages/administrative/writable-files bevat konfigurasielêers vir pakkette, maar hulle is skryfbaar. Na alles, soos jy onthou, .hpkg gemonteerde leesalleen. Hierdie lêers moet dus uit die pakkette gekopieer word voordat dit geskryf word. Het die betekenis.
GUI-integrasie vir .hpkg-stelsel
Kom ons kyk nou hoe hierdie blink sakke .hpkg hanteer integrasie in die gebruiker se werksomgewing (UX). Haiku is immers bedoel vir persoonlike gebruik. Persoonlik stel ek die lat hoog as ek gebruikerservaring met pakkette vergelyk .app op Macintosh met dieselfde ervaring op .hpkg. Ek sal nie eers die situasie met werksomgewings op Linux vergelyk nie, want dit is absoluut verskriklik in vergelyking met enige ander.
Die volgende scenario's kom by my op:
- Ek wil die inhoud van 'n pakket bekyk
.hpkg - Ek wil 'n pakket installeer
- Ek wil die pakkie verwyder
- Ek wil iets verwyder wat as deel van 'n pakket in die stelsel gekom het
- Ek wil iets kopieer wat as deel van 'n pakket in die stelsel gekom het
- Ek wil al die afhanklikhede van 'n pakket aflaai, wat dalk nie deel van elke Haiku-installasie is nie (byvoorbeeld, ek het 'n fisies geïsoleerde masjien met geen internettoegang nie.)
- Ek wil my pakkette (of 'n deel daarvan) afsonderlik na 'n ander plek skuif, apart van die selflaaivolume (wortelpartisie) (omdat ek byvoorbeeld nie genoeg spasie daarop het nie).
Dit behoort die meeste van die groot gevalle van my daaglikse werk te dek. Wel, kom ons begin.
Kontroleer pakketinhoud
Op Mac Ek klik eenvoudig met die rechtermuisknop op die pakkie om dit oop te maak en die inhoud in Finder te sien. Na alles, in werklikheid is dit net 'n vermomde gids! (Ek weet daar is pakkette .pkg vir 'n deel van die stelsel wat nie toepassings is nie, maar gewone gebruikers het meestal nie met hulle interaksie nie).
Op Haiku Ek regsklik op die pakkie, klik dan op "Inhoud" om te sien wat binne is. Maar hier is net 'n lys van lêers sonder die vermoë om dit oop te maak deur te dubbelklik.
Dit sal baie beter wees as daar 'n manier is om die pakket (tydelik) te monteer .hpkg om deur 'n lêerbestuurder bekyk te word, en die gebruiker hoef nie bekommerd te wees oor implementeringsbesonderhede nie. (Terloops, jy kan oopmaak .hpkg pak in Expander, wat dit soos enige ander argief kan uitpak).
HaikuDepot se koppelvlak laat jou toe om 'n lys van pakketlêers te sien, maar daar is geen manier om die inhoud te sien deur byvoorbeeld README.md te dubbelklik nie
Die Mac wen in hierdie kategorie, maar die toevoeging van die HaikuDepot-funksie wat jy wil hê, behoort nie te moeilik te wees nie.
Installeer 'n pakket via GUI
Op Mac, meeste skyfbeelde .dmg pakkies bevat .app. Dubbelklik op die skyfbeeld en kopieer dan die pakket, byvoorbeeld deur dit in te sleep /Applications in Finder. Dit spreek vanself vir my, maar ek het gehoor dat sommige nuwelinge dit dalk nie kan hanteer nie. By verstek "stel" Apple 'n stelselwye gids voor /Applications (op NeXT was dit genetwerk sowel as individueel), maar jy kan maklik jou toepassings op 'n lêerbediener of in 'n subgids plaas $HOME/Applications, as jy daarvan hou.
Op Haiku, dubbelklik op die pakket, klik dan op "Installeer", dit kan nie makliker wees nie. Ek wonder wat gebeur as 'n pakket afhanklikhede het wat in HaikuPorts beskikbaar is, maar nog nie geïnstalleer is nie. Op Linux weet hulle regtig nie wat om in hierdie situasie te doen nie, maar die oplossing is voor die hand liggend - vra die gebruiker of hulle afhanklikhede moet aflaai en installeer. Presies wat Haiku doen.
Ek het die 'sanity'-pakket met die hand afgelaai en daarop geklik, die pakketbestuurder weet waar om sy afhanklikhede vandaan te kry (met die veronderstelling dat die bewaarplekke reeds in die stelsel geregistreer is). Nie elke Linux-verspreiding kan dit doen nie.
Nog 'n manier is om 'n lêerbestuurder te gebruik, net sleep en los .hpkg pakkie of in /Haiku/system/packages (vir 'n stelselwye installasie, by verstek), of in /Haiku/home/config/packages (vir individuele installasie; nie beskikbaar wanneer jy dubbelklik nie - ek is steeds geïrriteerd vir die woord "config" op hierdie plek, wat vir my in hierdie geval sinoniem is met "instellings"). En die konsep van veelvuldige gebruikers is nog nie eens vir Haiku beskikbaar nie (dit is waarskynlik hoekom dit so eenvoudig is – ek weet nie, miskien sal multi-gebruiker-vermoëns dinge onnodig kompliseer vir 'n lessenaar-rekenaaromgewing).
Haiku wen in hierdie kategorie omdat dit nie net met toepassings kan werk nie, maar ook met stelselprogramme.
Verwyder 'n pakket uit die GUI
Op Mac, moet jy die toepassingsikoon na die asblik sleep, en dit is al. Maklik!
Op Haiku, eerstens moet u uitvind waar die pakket op die stelsel geleë is, want u installeer dit selde op die regte plek (die stelsel doen alles). Gewoonlik moet jy inkyk /Haiku/system/packages (met 'n stelselwye verstekinstallasie), of in /Haiku/home/config/packages (Het ek genoem dat "config" 'n verkeerde benaming is?). Dan word die toepassing eenvoudig na die asblik gesleep, en dit is dit.
Maklik! Ek sou dit egter nie sê nie. Hier is wat regtig gebeur:
Dit is wat gebeur as jy 'n toepassing na die asblik sleep /Haiku/system/packages
Het sopas probeer om my gister se "Hello World"-toepassing op QtQuickApp na die asblik te skuif. Ek het nie probeer om die stelselgids te skuif nie, en aangesien alle pakkette in die stelselgids geïnstalleer is, is dit onmoontlik om die pakket te verwyder .hpkg sonder verandering "die inhoud daarvan". 'n Gewone gebruiker sal bang word en die "Kanselleer"-knoppie druk wat by verstek toegewys is.
Verduidelik :
Hierdie pos is meer as 10 jaar oud. Heel waarskynlik moet ons dit so instel dat die waarskuwing slegs verskyn wanneer die pakket self geskuif word. Gereelde gebruikers hoef dit in elk geval nie te doen nie.
Goed, miskien moet ek dit doen met HaikuDepot? Ek dubbelklik op die pakket in /Haiku/system/packages, wag vir die "Deïnstalleer"-knoppie om te verskyn. Nee, daar is (slegs) "Installeer". "Deïnstalleer", waar is jy?
Net vir die plesier het ek probeer kyk wat sou gebeur as ek "Installeer" op 'n reeds geïnstalleerde pakket klik. Dit blyk so uit:
Dit gebeur as jy probeer om 'n reeds geïnstalleerde pakket te installeer.
Volgende verskyn:
As jy op "Pas veranderinge toe" in die vorige venster klik, sal dit so lyk
Ek neem aan dat dit 'n sagtewarefout is; die skakel na die toepassing is reeds daar. [die skrywer het nie 'n skakel verskaf nie - ongeveer. vertaler]
Vinnige oplossing: Voeg 'n "Deïnstalleer"-knoppie by as die pakket reeds in is
/Haiku/system/packages, of in/Haiku/home/config/packages.
Wanneer ek die lys van pakkette bekyk wat in HaikuDepot geïnstalleer is, sien ek my pakket in die lys en kan dit verwyder.
Die Mac wen in hierdie kategorie. Maar ek kan my voorstel dat met behoorlike opstelling die gebruikerservaring op Haiku beter sal wees as op Mac. (Een van die ontwikkelaars het dit so beoordeel: "Minder as 'n uur om die gespesifiseerde funksionaliteit by HaikuDepot te voeg, as jy 'n bietjie C++ ken", enige vrywilligers?)
Verwyder iets uit 'n pakkie
Kom ons probeer om die toepassing self te verwyder, nie die pakket nie .hpkg, waaruit dit gekom het (ek twyfel of daar vir "blote sterflinge" enige verskil is).
Op Mac, die gebruiker werk eintlik gewoonlik met die lêer .dmgwaar kom die toepassingspakket vandaan .app. Gewoonlik beelde .dmg word opgehoop in die aflaaigids, en pakkette word deur die gebruiker gekopieer na /Applications. Daar word geglo dat baie gebruikers self nie weet wat hulle doen nie, hierdie hipotese word bevestig deur 'n voormalige Apple-werknemer. (Een van die dinge waarvan ek nie hou op Mac nie. En, byvoorbeeld, met AppImage is daar geen verskil tussen die toepassing en die pakket waarin dit was nie. Sleep die ikoon na die asblik = dit is dit. Maklik!)
Op Haiku, is daar ook 'n skeiding tussen apps/ и packages/, so ek twyfel of dit dit vir gebruikers duideliker gemaak het. Maar wat gebeur as jy 'n toepassing sleep van apps/ Voeg by mandjie:
Dit is wat gebeur wanneer jy probeer om 'n toepassing wat uit 'n lêer geneem is, te verwyder .hpkg
Tegnies is dit korrek (die toepassing word immers in die eerste plek op 'n leesalleen-lêerstelsel gehuisves), maar dit is nie besonder nuttig vir die gebruiker nie.
Vinnige oplossing: stel voor dat u GUI gebruik om eerder uit te vee
.hpkg
Net vir die pret het ek probeer om die toepassing te dupliseer deur Alt+D te druk. Ek het die boodskap ontvang "Kan nie voorwerpe op 'n leesalleen-volume skuif of kopieer nie." En dit alles omdat /system (behalwe /system/packages и /system/settings) is die pakketfs-monteerpunt (onthou hoe dit in die uitvoer verskyn df?). Ongelukkig is die uitvoer van die opdrag mount verduidelik nie die situasie nie (soos in een van die vorige artikels gesê is), mountvolume wys nie waarna jy soek nie (blykbaar pakkette gemonteer via lus .hpkg word nie as "volumes" beskou nie, en ek het ook die alternatiewe opdragte vergeet.
Niemand het in hierdie kategorie gewen nie, behalwe AppImage (maar dit is, om heeltemal eerlik te wees, 'n bevooroordeelde mening). 'n Mens kan jou egter voorstel dat die gebruikerservaring op Haiku beter sal wees as op Mac.
Let wel: jy moet uitvind wat 'n "volume" is in verhouding tot 'n "afdeling". Dit is waarskynlik soortgelyk aan die verhouding van "gids" tot "gids": die meeste dopgehou verskyn as vouers in die lêerbestuurder, maar nie almal nie (pakkette word byvoorbeeld as lêers hanteer). Maak hierdie soort vertoning my 'n amptelike nerd?
Kopieer die inhoud van 'n pakket na 'n ander stelsel
Op Mac, Ek sleep dom die pakkie .app, en aangesien die afhanklikhede binne die pakket is, beweeg hulle saam.
Op Haiku, Ek sleep die toepassing, maar die afhanklikhede word glad nie verwerk nie.
Vinnige oplossing: Kom ons stel eerder voor om die hele `.hpkg-pakket te sleep, saam met enige afhanklikhede, indien enige.
Die Mac wen duidelik in hierdie kategorie. Ten minste vir my, 'n liefhebber van hul paradigma. Ek moet dit na Haiku kopieer .hpkg in plaas van 'n toepassing, maar die stelsel bied my dit nie...
Laai 'n pakket af met al sy afhanklikhede
Nie elke masjien is heeltyd aan die netwerk gekoppel nie. Inteendeel, sommige masjiene (ja, ek kyk na jou, moderne Windows, Mac en Linux) vergeet hiervan. Dit is vir my belangrik dat ek byvoorbeeld na 'n internetkafee kan gaan, sagteware op 'n verwyderbare skyf kan aflaai, hierdie skyf in my tuisrekenaar kan plaas en seker kan wees dat alles sal werk [ riskante ou, doen dit op Windows ... - ongeveer. vertaler].
As gevolg hiervan, is ek geneig om 'n bietjie meer gereeld as gewoonlik met onvervulde afhanklikhede op Windows en Linux te eindig.
Op Mac dit is gewoonlik een lêer, al wat jy hoef te doen is aflaai .dmg. Dikwels het dit geen ander afhanklikhede as dié wat by verstek deur MacOS self verskaf word nie. 'n Uitsondering is komplekse toepassings wat 'n toepaslike uitvoeringsomgewing vereis, byvoorbeeld java.
Op Haiku laai pakket af .hpkg want byvoorbeeld dieselfde toepassing in java is dalk nie voldoende nie, aangesien java op die teikenmasjien teenwoordig kan wees of nie. Is daar 'n manier om alle afhanklikhede vir 'n gegewe pakket af te laai .hpkg, anders as dié wat by verstek in Haiku geïnstalleer is en dus op elke Haiku-stelsel moet wees?
Die Mac wen hierdie kategorie met 'n klein marge.
Kommentaar mnr. waddleplash:
Om 'n program te skryf om al die afhanklikhede van 'n toepassing as 'n stel pakkette te versamel
.hpkgvir iemand wat vertroud is met die innerlike werking van Haiku, is ongeveer 15 minute genoeg. Om ondersteuning hiervoor by te voeg, is nie so moeilik as daar 'n werklike behoefte daaraan is nie. Maar vir my is dit 'n seldsame situasie.
Kom ons hou asem op tot die volgende artikel in hierdie reeks.
Verskuiwing van pakkette na 'n aparte plek
Soos ek vroeër geskryf het, wil ek my pakkies plaas .hpkg (wel, of 'n deel daarvan) na 'n spesiale plek, apart van die gewone plasing op die selflaaivolume (wortelpartisie). In die gewone (nie so teoretiese) geval is die rede hiervoor dat ek gedurig min vrye spasie op my (ingeboude) skywe het, maak nie saak hoe groot hulle is nie. En ek koppel gewoonlik eksterne aandrywers of netwerkaandele aan waar my toepassings geleë is.
Op Mac Ek skuif net pakkies .app na 'n verwyderbare skyf of netwerkgids in Finder, en dit is dit. Ek kan steeds dubbelklik om die toepassing oop te maak soos ek gewoonlik vanaf die selflaaivolume sou doen. Net!
Op Haiku, soos ek vertel is, kan dit bereik word deur my te skuif .hpkg pakkette na 'n verwyderbare skyf of netwerkgids, maar dan moet jy 'n paar ongedokumenteerde opdragte in die konsole gebruik om dit op die stelsel te monteer. Ek weet nie hoe om dit te doen met slegs die GUI nie.
Die Mac wen in hierdie kategorie.
Volgens mnr. waddleplash:
Dit is 'n optimalisering gebaseer op normale gebruik. As daar aanvraag van meer as een gebruiker is, sal ons dit implementeer. In elk geval is daar die moontlikheid van derdeparty-implementering.
Ons sal in die volgende artikel hieroor praat.
Van netwerkgidse gepraat, dit sal wonderlik wees (ek raai LAN-partye) om eenvoudige, opspoorbare, netwerkwye toepassings (soos Zeroconf) te hê wat na die plaaslike rekenaar gekopieer kan word of direk vanaf die plaaslike netwerk kan hardloop. Natuurlik het ontwikkelaars die opsie om te onttrek via app_flags.
Finale verslag oor die integrasie van die hpkg-stelsel met die GUI
Ek dink dit is hoofsaaklik as gevolg van die relatiewe nuutheid van die integrasie .hpkg die GUI laat nog veel te wense oor. In elk geval, daar is 'n paar dinge wat verbeter kan word in terme van UX ...
Nog een ding: Kernel Debug Land
Dit sal wonderlik wees om byvoorbeeld opdragte tydens kernpaniek in te voer syslog | grep usb. Wel, op Haiku is dit moontlik danksy Kernel Debug Land. Hoe kan jy hierdie magie in aksie sien as alles werk soos dit moet sonder om in 'n kernpaniek te raak? Maklik deur Alt+PrintScn+D te druk (Debug mnemonic). Ek onthou dadelik , wat die oorspronklike Macintosh-ontwikkelaars toegelaat het om die ontfouter te betree (as een natuurlik geïnstalleer is).
Gevolgtrekking
Ek begin verstaan dat die gesofistikeerdheid van die Haiku-stelsel spruit uit die feit dat die werk deur een klein span uitgevoer word met 'n duidelike fokus op die werksomgewing, met alle lae van die stelsel toeganklik.
'n Skerp kontras met die wêreld van Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, waar alles in so 'n mate in klein stukkies opgebreek is dat abstraksie op abstraksie sit en met krukke dryf.
Daar was ook 'n begrip van hoe die stelsel .hpkg kombineer die beste praktyke van tradisionele pakketbestuurders, Snappy, Flatpak, AppImage, selfs btrfs, en meng dit met die Mac se "werk net"-benadering.
Dit was asof iets in my kop “geskakel” het, en ek het verstaan hoe die stelsel .hpkg weet hoe om weg te rol, net deur na haar te kyk. Maar dit is nie ek nie, maar die skoonheid en eenvoud van die stelsel. Baie hiervan is geïnspireer deur die gees van die oorspronklike Mac.
Ja, om in die blaaier te blaai kan rukkerig wees en soos 'n slak loop, toepassings kan ontbreek (nee Gtk, Electron - die ontwikkelaars het tot die gevolgtrekking gekom dat dit nie goed pas met gesofistikeerdheid nie), video en 3d-versnelling kan heeltemal afwesig wees, maar ek het steeds hou van hierdie stelsel. Hierdie dinge kan immers reggestel word en dit sal vroeër of later verskyn. Dit is net 'n kwessie van tyd en dalk 'n bietjie rooi oog.
Ek kan nie hulp aanbied nie, maar ek dink dit sal van nou af begin jaar van Haiku op lessenaar.
Ewekansige probleme
Miskien is daar reeds versoeke, of moet ek dit oopmaak?
- BeScreenCapture behoort in staat te wees om na GIF uit te voer soos Peek. Dit kan gedoen word met ffmpeg, reeds beskikbaar vir Haiku. .
- Skermskootsagteware slaag nie daarin om 'n modale venster vas te vang nie, maar neem eerder die hele skerm vas
- Jy kan nie skermkiekies sny met WonderBrush se snyinstrument en dan die resultaat in 'n lêer stoor nie
- Ek hou nie juis van die handwyser in Haiku nie, maar ek dink dit het te make met die warm nostalgiese gevoel. Dit is veral irriterend wanneer die sny-instrument in Krita gebruik word, aangesien dit onakkurate sny tot gevolg het (sien skermkiekies van modale dialoë in hierdie artikel). 'n Dwarshaarwyser sal wonderlik wees. .
Probeer dit self! Die Haiku-projek verskaf immers beelde vir selflaai vanaf DVD of USB, gegenereer . Om te installeer, laai net die prent af en brand dit op 'n USB-flash drive met behulp van
Het jy vrae? Ons nooi jou uit na die Russiessprekende .
Foutoorsig:
Van vertaling: dit is die sesde artikel in die reeks oor Haiku.
Lys van artikels:
Bron: will.com