TL, DR: Haiku je operační systém speciálně navržený pro PC, takže má několik triků, díky kterým je jeho desktopové prostředí mnohem lepší než ostatní. Ale jak to funguje?
Objevil jsem Haiku, nečekaně dobrý systém. Stále mě překvapuje, jak hladce to běží, zvláště ve srovnání s desktopovými prostředími Linuxu. Dnes se podívám pod pokličku. Tam, kde je to nutné pro hlubší pochopení, provedu srovnání s původními desktopovými prostředími Macintosh, Mac OS X a Linux (standard XDG z freedesktop.org).
Zdroje v souborech ELF
Včera jsem se dozvěděl, že IconOMatic umí ukládat ikony v rdef zdrojích ve spustitelných souborech ELF. Dnes chci vidět, jak to opravdu funguje.
Zdroje? z , původní autor Macintosh Finderu a „otec“ Macintosh Resource Manager:
Obávám se rigidní povahy tradičního kódování. Pro mě je nejdivočejší divočinou samotná myšlenka aplikace zamrzlé v kódu, bez možnosti cokoli dynamicky měnit. Za běhu by mělo být možné co nejvíce změnit. Samotný kód aplikace samozřejmě nelze změnit, ale určitě lze něco změnit bez překompilování kódu?
Na původním Macintoshi vytvořili tyto soubory s „datovou částí“ a „sekcí zdrojů“, díky čemuž bylo neuvěřitelně snadné ukládat věci, jako jsou ikony, překlady a podobně. ve spustitelných souborech.
Na Macu se to používá , grafický program pro – náhle – úpravu zdrojů.
ResEdit na původním počítači Macintosh
V důsledku toho bylo možné upravovat ikony, položky nabídky, překlady atd. dost snadné, ale stále „cestují“ s aplikacemi.
V každém případě měl tento přístup velkou nevýhodu: fungoval pouze na souborových systémech Apple, což byl jeden z důvodů, proč Apple při přechodu na Mac OS X opustil „sekci zdrojů“.
Na Mac OS X chtěl Apple řešení nezávislé na souborovém systému, a tak přijal koncept balíčků (od NeXT), adresářů, které správce souborů považuje za „neprůhledné objekty“, jako soubory spíše než adresáře. Libovolný balíček s aplikací ve formátu .app má mimo jiné spis Info.plist (v nějakém ekvivalentu Apple JSON nebo YAML) obsahující metadata aplikace.
Klíče pro soubor Info.plist z balíčku aplikace Mac OS X.
Prostředky, jako jsou ikony, soubory uživatelského rozhraní a další, jsou uloženy v balíčku jako soubory. Koncept se vlastně vrátil ke svým kořenům v NeXTu.
Mathematica.app na NeXTSTEP 1.0 v roce 1989: objevuje se jako adresář souborů v terminálu, ale jako jeden objekt v grafickém správci souborů.
Vraťme se k BeOS, konceptům, na kterých je Haiku založeno. Jeho vývojáři se při přechodu z PEF (PowerPC) na ELF (x86) (stejný jako v Linuxu) rozhodli přidat na konec souborů ELF sekci zdrojů. Nepoužil svou vlastní sekci ELF, byl jednoduše připojen na konec souboru ELF. V důsledku programu strip a jiní z binutils, kteří si toho nejsou vědomi, to jednoduše odřízli. Proto při přidávání prostředků do souboru ELF na BeOS je lepší s ním nemanipulovat pomocí nástrojů Linuxu.
Co se teď děje s Haiku? V podstatě víceméně to samé.
Teoreticky by bylo možné umístit zdroje do požadované části ELF. Podle vývojářů na kanálu #haiku na irc.freenode.net:
S ELF by sekce dávala větší smysl... jediný důvod, proč to tak neděláme, je ten, že jsme to dělali v BeOS."
A nemá smysl to teď měnit.
Управление ресурсами
Zdroje jsou psány ve strukturovaném „zdrojovém“ formátu: v podstatě jde o seznam zdrojů s velikostí a poté jejich obsahem. Jsem si vzpomněl .
Jak zkontrolovat zdroje v Haiku? Existuje něco jako ResEdit?
Podle :
Chcete-li zobrazit prostředky poskytované v balíčku aplikace, můžete spustitelný soubor přetáhnout do programu jako . Můžete také přejít na terminál a spustit příkaz
listres имя_файла.
Resourcer je dostupný v HaikuDepot, ale prostě mi spadne.
Jak spravovat prostředky v souborech ELF? Použitím rsrc и rdef. rdef soubory se shromažďují v rsrc. Soubor rdef je uložen ve formátu prostého textu, takže se s ním mnohem lépe pracuje. Formát souboru rsrc připojené na konec souboru ELF. Zkusme si zahrát:
~> 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 licenseProgram můžete použít xres pro kontrolu a kontrolu:
/> 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.
(...)Dobře, zkusíme to?
/> 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_VERSIONVíce o zdrojích a formátu rdef umí číst .
Standardní typy zdrojů
Přestože do zdrojů můžete vložit cokoli, existuje několik definovaných standardních typů:
app_signature: Typ aplikace MIME, pro mapování otevřených souborů, spouštění, IPC atd.app_name_catalog_entry: Vzhledem k tomu, že název aplikace je obvykle v angličtině, můžete určit místa, kde se přeložené názvy nacházejí, aby uživatelé v různých jazycích v případě potřeby viděli přeložený název aplikace.app_version: Přesně jak sis myslelapp_flags: označujeregistrarjak zpracovat žádost. Myslím, že je v tom víc, než se na první pohled zdá. Například existujeB_SINGLE_LAUNCH, který nutí systém spouštět nový aplikační proces pokaždé, když si to uživatel vyžádá (stejný princip se používá u většiny aplikací na Linuxu). JístB_MULTIPLE_LAUNCH, což způsobí spuštění procesu každý soubor. Konečně existujeB_EXCLUSIVE_LAUNCH, která nutí systém spouštět vždy pouze jeden proces bez ohledu na to, jak často jej uživatelé spouštějí (takto například běží Firefox na Linuxu; stejného výsledku lze dosáhnout v Qt aplikacích pomocí funkce ). Aplikace sB_EXCLUSIVE_LAUNCHjsou upozorněni, když se je uživatel pokusí znovu spustit: například obdrží cestu k souboru, který chce uživatel s jejich pomocí otevřít.vector_icon: Vektorová ikona aplikace (BeOS neměl vektorové ikony, většina aplikací místo toho měla ve svých spustitelných souborech dvě rastrové ikony).
Samozřejmě můžete přidávat prostředky s libovolnými ID a typy a poté je číst v samotné aplikaci nebo jiných aplikacích používajících třídu BResources. Nejprve se však podívejme na fascinující téma ikon.
Vektorové ikony ve stylu Haiku
Nejlepší formát ikon samozřejmě nezvolil pouze Haiku, v této části není situace s desktopovými prostředími Linuxu zdaleka ideální:
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.cacheUž při pohledu na to cítíte, jaký je to kus.
Samozřejmostí je škálovatelnost, která obsahuje, jak jistě chápete, vektorové ikony. Proč je tedy ještě něco jiného? Protože výsledek kreslení vektorové grafiky v malých velikostech může být méně než ideální. Chtěl bych mít různé možnosti optimalizované pro různé velikosti. V linuxových desktopových prostředích je toho dosaženo rozptýlením ikon různých velikostí po celém systému souborů.
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.pngPoznámka: neexistuje žádná koncepce různých verzí Firefoxu. Není tedy možné elegantně zvládnout situaci, kdy je v systému více verzí aplikace.
Různé ikony Firefoxu v různých verzích. Bez různých berliček to v současnosti v Linuxu zvládnout nejde.
Mac OS X to řeší trochu jemněji:
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.icnsJe vidět, že existuje jeden soubor firefox.icns v balíčku Firefox.app, obsahující všechny velikosti, takže různé verze stejné aplikace mají různé ikony.
Mnohem lepší! Ikony putují s aplikací, všechny zdroje jsou v jednom souboru.
Vraťme se k Haiku. Ohromující řešení, žádné výjimky. Podle :
Byl vyvinut speciální formát HVIF, vysoce optimalizovaný pro malé velikosti a rychlé vykreslování. Proto jsou naše ikony z velké části mnohem menší než v rastru nebo v hojně používaném formátu SVG.
A stále jsou optimalizovány:
Velikosti ikon v HVIF ve srovnání s jinými formáty.
Rozdíl je řádový!
Tady ale kouzlo nekončí. Stejný HVIF může zobrazovat různé úrovně detailů v závislosti na zobrazené velikosti, i když se jedná o vektorový formát.
Různé úrovně detailů (LOD) v závislosti na velikosti renderu
Nyní o nevýhodách: nemůžete vzít SVG, hodit to do ImageMagick a volat to den; musíte projít několika cykly, abyste vytvořili ikonu ve formátu HVIF. vysvětlení. IconOMatic však umí importovat SVG docela nedokonale; asi 90 % detailů SVG je s určitou pravděpodobností importováno, zbývajících 10 % bude nutné nakonfigurovat a změnit ručně. Přečtěte si více o tom, jak HVIF dělá svá kouzla na blogu
Přidání ikony do aplikace
Nyní mohu přidat ikonu do vytvořeného balíčku s přihlédnutím ke všem obdrženým informacím.
No, protože zrovna teď nemám chuť kreslit svou vlastní ikonu pro můj „Hello, World“ QtQuickApp, vytáhnu ji z Qt Creatoru.
/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 CreatorZkontrolujeme, zda byla ikona zkopírována:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONVypadá dobře, ale proč se nová ikona po zkopírování nezobrazí?
Zkopírovaný VICN:101:BEOS:ICONs zatím není použit jako ikona aplikace ve správci souborů
O co jsem přišel?
Komentář vývojáře:
Musíme vytvořit soubor
rdefse všemi prostředky a poté spusťte příkazrc имя.rdef, tím se vytvoří soubor.rsrc. Poté musíte spustit příkazresattr -o имя_бинарника имя.rsrc. Minimálně tyto příkazy používám k přidávání ikon do svých skriptů.
No, chtěl jsem vytvořit zdroj, ne atribut. Jsem opravdu zmatený.
Inteligentní ukládání do mezipaměti pomocí systému souborů
Otevírání a čtení atributů ELF je pomalé. Jak jsem psal výše, ikona je zapsána jako zdroj v samotném souboru. Tato metoda je spolehlivější a umožňuje přežít kopírování do jiného systému souborů. Poté se však také zkopíruje například do atributu souborového systému BEOS:ICON. Toto funguje pouze na určitých souborových systémech, jako je BFS. Ikony zobrazené systémem (v Trackeru a Deskbaru) se čtou z tohoto rozšířeného atributu, protože toto řešení funguje rychle. Na některých místech (kde rychlost není důležitá, například v typickém okně „O aplikaci“) systém obdrží ikonu přímo ze zdroje v souboru. Ale to není konec. Pamatujte, že na Macu mohou uživatelé nahradit ikony aplikací, adresářů, dokumentů svými vlastními, protože na Macu je možné dělat tyto „důležité“ věci, např. . Na Haiku byste měli o prostředku (v souboru) uvažovat jako o původní ikoně, která je součástí aplikace, a o atributu (v systému souborů BFS) jako o něčem, co uživateli umožňuje provádět změny dle libosti (ačkoli nápověda, GUI pro vložení vlastní ikony nad ikonu je volitelné).
Kontrola atributů systému souborů
S resaddr Je možné zkontrolovat a nastavit atributy systému souborů.
/> 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.
(...)Je to v podstatě "lepidlo", které provádí konverzi tam a zpět mezi (spolehlivými) zdroji a (rychlými) atributy souborového systému. A protože systém očekává příjem zdrojů a kopírování provádí automaticky, nebudu se tím dále zabývat.
Kouzlo hpkg balíčků
V současné době (nejčastěji) se k získání programů na Haiku používají balíčky .hpkg. Nenechte se zmást jednoduchým názvem: formát .hpkg funguje úplně jinak než jiné formáty s podobnými názvy, se kterými jste se setkali, má skutečné superschopnosti.
U tradičních formátů balíčků jsem byl dlouhou dobu naštvaný kvůli této skutečnosti: jednu věc stáhnete (balík) a další se nainstaluje do systému (soubory uvnitř balíčku). Při klasické instalaci balíčku je poměrně obtížné spravovat soubory (například je mazat). A to vše kvůli obsahu balení rozptýlené po celém systému souborů, včetně míst, kde průměrný uživatel nemusí mít přístup pro zápis. Vzniká tak celá třída programů - správci balíčků. Ale přenos již nainstalovaného softwaru, například na jiný počítač, vyměnitelný disk nebo souborový server, se stává ještě obtížnějším, ne-li zcela nemožným. Na typickém systému založeném na Linuxu může snadno existovat několik set tisíc až miliony jednotlivých souborů. Netřeba dodávat, že je to křehké a pomalé, například při počáteční instalaci systému, při instalaci, aktualizaci a odinstalaci běžných balíčků a při kopírování zaváděcího svazku (kořenového oddílu) na jiné médium.
Pracuji na projektu AppImage, částečné berličce pro aplikace pro koncové uživatele. Toto je formát distribuce softwaru, který shromažďuje aplikaci a všechny její závislosti do jednoho obrazu systému souborů, který je připojen při spuštění aplikace. Výrazně to zjednodušuje, protože stejný ImageMagick se náhle změní na jediný soubor, spravovaný ve správci souborů pouhými smrtelníky. Navrhovaná metoda funguje pouze pro software, jak se odráží v názvu projektu, a má také své vlastní problémy, protože lidé, kteří se podílejí na dodávání softwaru pro Linux, vždy ukazují šipku na mě.
Vraťme se k Haiku. Bylo možné najít optimální rovnováhu mezi tradičními balíčkovými systémy a dodávkou softwaru založeného na obrazech? Její balíčky .hpkg skutečně komprimované obrazy systému souborů. Když se systém zavede, jádro připojí všechny nainstalované a aktivní balíčky s přibližně následujícími zprávami jádra:
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"Super, jo? Vydržte, bude ještě chladněji!
Existuje velmi speciální balíček:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Obsahuje velmi minimalistický operační systém včetně jádra. Věřte nebo ne, ale ani samotné jádro není odstraněno ze zaváděcího svazku (kořenového oddílu), ale je pečlivě načteno na své místo z balíčku .hpkg. Páni! Již jsem zmínil, že si myslím, že část celkové sofistikovanosti a konzistence Haiku pochází ze skutečnosti, že celý systém, od jádra a základního uživatelského prostoru až po správu balíčků a runtime infrastrukturu, je vyvíjen ve spolupráci jednoho týmu. Představte si, kolik různých skupin a týmů by bylo zapotřebí k tomu, aby se něco takového v Linuxu provozovalo [Představuji si projekt PuppyLinux - cca. překladatel]. Pak si představte, jak dlouho bude trvat, než se tento přístup zavede do distribucí. Říká se: vezměte jednoduchý problém, rozdělte ho mezi různé interprety a ten se tak zkomplikuje, že už ho nebude možné vyřešit. Haiku mi v tomto případě otevřelo oči. Myslím, že přesně to se nyní děje na Linuxu (Linux je v tomto případě souhrnný termín pro zásobník Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Vrácení systému pomocí hpkg
Jak často nastává následující situace: aktualizace proběhla úspěšně a pak se ukáže, že něco nefunguje, jak má? Pokud používáte konvenční správce balíčků, je obtížné vrátit stav systému do bodu v čase před instalací nových balíčků (například v případě, že se něco pokazilo). Některé systémy nabízejí řešení ve formě snímků systému souborů, ale jsou poměrně těžkopádné a nepoužívají se na všech systémech. Haiku to řeší pomocí balíčků .hpkg. Kdykoli se balíčky v systému změní, staré balíčky nejsou smazány, ale jsou uloženy v systému v podadresářích jako /Haiku/system/packages/administrative/state-<...>/ neustále. Nedokončené operace ukládají svá data do podadresářů /Haiku/system/packages/administrative/transaction-<...>/.
Obsah /Haiku/system/packages/administrative. Adresáře „state...“ obsahují textové soubory se jmény aktivních balíčků a adresáře „transaction...“ obsahují balíčky samotné.
"Starý aktivní stav", tzn. seznam .hpkg balíčky aktivní před změnami se po každé operaci ve správci souborů zaznamenají do textového souboru /Haiku/system/packages/administrative/state-<...>/activated-packages. Podobným způsobem se do textového souboru zapíše nový „aktivní stav“. /Haiku/system/packages/administrative/activated-packages.
Adresář /Haiku/system/packages/administrative/state-<...>/ obsahuje pouze textový soubor se seznamem aktivních balíčků tohoto stavu (v případě instalace balíčků bez odstranění) a pokud byly balíčky odstraněny nebo aktualizovány - adresář stavu obsahuje staré verze balíčků.
Když systém nabootuje, na základě seznamu balíčků se rozhodne o aktivaci (připojení) balíčků. Je to tak jednoduché! Pokud se během stahování něco pokazí, můžete správci stahování říct, aby použil jiný, starší seznam. Problém je vyřešen!
Haiku downloader. Každý vstupní bod zobrazuje odpovídající "aktivní stav"
Líbí se mi přístup, kdy mají jednoduché textové soubory jako seznam „aktivního stavu“ s názvy, které jsou snadno srozumitelné .hpkg. To je v ostrém kontrastu s tím, že jsou vyrobeny pro stroje-ne-pro-lidi. z OSTree nebo Flatpak v systému souborů (na stejné úrovni jako Microsoft GUID).
Seznam aktivních balíčků pro každý bod v čase
Konfigurační data
Zřejmě v katalogu /Haiku/system/packages/administrative/writable-files obsahuje konfigurační soubory pro balíčky, ale lze do nich zapisovat. Koneckonců, jak si vzpomínáte, .hpkg namontované pouze pro čtení. Tyto soubory je tedy nutné před zápisem zkopírovat z balíčků. Má význam.
Integrace GUI pro systém .hpkg
Pojďme se nyní podívat, jak tyto lesklé tašky .hpkg vyrovnat se s integrací do pracovního prostředí uživatele (UX). Haiku je koneckonců určeno pro osobní použití. Osobně jsem nasadil laťku vysoko při srovnávání uživatelské zkušenosti s balíčky .app na Macintoshi se stejnými zkušenostmi .hpkg. Ani nebudu srovnávat situaci s pracovními prostředími na Linuxu, protože je to naprosto hrozné ve srovnání s ostatními.
Napadají mě následující scénáře:
- Chci si prohlédnout obsah balíčku
.hpkg - Chci nainstalovat balíček
- Chci odstranit balíček
- Chci odstranit něco, co přišlo do systému jako součást balíčku
- Chci zkopírovat něco, co přišlo do systému jako součást balíčku
- Chci stáhnout všechny závislosti balíčku, který nemusí být součástí každé instalace Haiku (například mám fyzicky izolovaný počítač bez přístupu k internetu.)
- Chci své balíčky (nebo jejich část) přesunout samostatně na jiné místo, odděleně od zaváděcího svazku (kořenového oddílu) (protože na něm například nemám dostatek místa).
To by mělo pokrýt většinu hlavních případů z mé každodenní práce. No, pojďme začít.
Kontrola obsahu balení
Na Macu Jednoduše kliknu pravým tlačítkem na balíček, otevře se a zobrazí se obsah ve Finderu. Koneckonců, ve skutečnosti je to jen převlečený adresář! (Vím, že existují balíčky .pkg pro část systému, která nejsou aplikacemi, ale běžní uživatelé s nimi nejčastěji neinteragují).
Na Haiku Kliknu pravým tlačítkem na balíček a poté kliknu na „Obsah“, abych viděl, co je uvnitř. Zde je ale pouze seznam souborů bez možnosti je otevřít dvojitým kliknutím.
Bylo by mnohem lepší, kdyby existoval způsob, jak (dočasně) namontovat balíček .hpkg prohlížet prostřednictvím správce souborů a uživatel by se nemusel starat o detaily implementace. (Mimochodem, můžete otevřít .hpkg balíček v Expander, který jej dokáže rozbalit jako každý jiný archiv).
Rozhraní HaikuDepot vám umožňuje zobrazit seznam souborů balíčků, ale neexistuje způsob, jak zobrazit obsah například dvojitým kliknutím na soubor README.md
V této kategorii vítězí Mac, ale přidání požadované funkce HaikuDepot by nemělo být příliš obtížné.
Instalace balíčku přes GUI
Na Macu, většina obrazů disků .dmg obsahovat balíčky .app. Dvakrát klikněte na obraz disku a poté balíček zkopírujte, například přetažením /Applications ve Finderu. To je pro mě samozřejmé, ale slyšel jsem, že někteří nováčci to nemusí zvládnout. Ve výchozím nastavení Apple „navrhuje“ adresář pro celý systém /Applications (na NeXT byl síťový i individuální), ale své aplikace můžete snadno umístit na souborový server nebo do podadresáře $HOME/Applications, pokud se vám to tak líbí.
Na Haiku, dvakrát klikněte na balíček a poté klikněte na „Instalovat“, nemůže to být jednodušší. Zajímalo by mě, co se stane, když má balíček závislosti, které jsou dostupné v HaikuPorts, ale ještě nejsou nainstalovány. Na Linuxu opravdu nevědí, co v této situaci dělat, ale řešení je zřejmé – zeptejte se uživatele, zda nepotřebuje stáhnout a nainstalovat závislosti. Přesně to, co dělá Haiku.
Ručně jsem si stáhl balíček 'sanity' a kliknul na něj, správce balíčků ví, odkud získat jeho závislosti (za předpokladu, že repozitáře jsou již v systému registrovány). Ne každá distribuce Linuxu to umí.
Dalším způsobem je použití správce souborů, stačí přetáhnout .hpkg balení nebo v /Haiku/system/packages (ve výchozím nastavení pro celosystémovou instalaci) nebo v /Haiku/home/config/packages (pro individuální instalaci; nedostupné při dvojkliku – stále mi na tomto místě vadí slovo „config“, které je pro mě v tomto případě synonymem „nastavení“). A koncept více uživatelů zatím není k dispozici ani pro Haiku (asi proto je to tak jednoduché - nevím, možná víceuživatelské možnosti zbytečně zkomplikují desktopové prostředí).
Haiku v této kategorii vítězí, protože umí pracovat nejen s aplikacemi, ale i se systémovými programy.
Odebrání balíčku z GUI
Na Macu, musíte přetáhnout ikonu aplikace do koše, a to je vše. Snadno!
Na Haiku, nejprve musíte najít, kde se balíček v systému nachází, protože jej zřídka instalujete na správné místo (systém dělá vše). Obvykle se musíte podívat dovnitř /Haiku/system/packages (s celosystémovou výchozí instalací), nebo v /Haiku/home/config/packages (Zmínil jsem se, že „config“ je nesprávné označení?). Poté se aplikace jednoduše přetáhne do koše a je to.
Snadno! To bych však neřekl. Zde je to, co se skutečně děje:
To se stane, když přetáhnete aplikaci do koše /Haiku/system/packages
Právě jsem se pokusil přesunout svou včerejší aplikaci „Hello World“ na QtQuickApp do koše. Nezkoušel jsem přesunout systémový adresář, a protože všechny balíčky jsou nainstalovány v systémovém adresáři, není možné balíček odstranit .hpkg beze změny "jeho obsah". Běžný uživatel by se vyděsil a stiskl tlačítko „Storno“ přiřazené ve výchozím nastavení.
Vysvětluje :
Tento příspěvek je starší 10 let. S největší pravděpodobností jej musíme nakonfigurovat tak, aby se varování zobrazilo pouze při přesunutí samotného balíčku. Běžní uživatelé to stejně dělat nemusí.
Dobře, možná bych to měl udělat pomocí HaikuDepot? Dvakrát kliknu na balíček dovnitř /Haiku/system/packages, počkejte, až se zobrazí tlačítko „Odinstalovat“. Ne, existuje (pouze) „Instalovat“. "Odinstalovat", kde jsi?
Jen pro zábavu jsem se pokusil zjistit, co by se stalo, kdybych kliknul na „Instalovat“ na již nainstalovaném balíčku. Dopadne to takto:
K tomu dojde, pokud se pokusíte nainstalovat již nainstalovaný balíček.
Objeví se další:
Pokud v předchozím okně kliknete na „Použít změny“, bude to vypadat takto
Předpokládám, že se jedná o softwarovou chybu, odkaz na aplikaci tam již je. [autor neuvedl odkaz - cca. překladatel]
Rychlé řešení: Přidejte tlačítko „Odinstalovat“, pokud již balíček je
/Haiku/system/packages, nebo v/Haiku/home/config/packages.
Při prohlížení seznamu balíčků nainstalovaných v HaikuDepot vidím svůj balíček v seznamu a mohu jej odstranit.
V této kategorii vítězí Mac. Umím si ale představit, že při správném nastavení bude uživatelská zkušenost na Haiku lepší než na Macu. (Jeden z vývojářů to ohodnotil takto: „Méně než hodinu na přidání specifikované funkce do HaikuDepot, pokud umíte trochu C++“, nějací dobrovolníci?)
Odebrání něčeho z balíčku
Zkusme odstranit samotnou aplikaci, ne balíček .hpkg, ze kterého pochází (pochybuji, že pro „pouhé smrtelníky“ je v tom nějaký rozdíl).
Na Macu, uživatel se souborem skutečně obvykle pracuje .dmgodkud balíček aplikace pochází .app. Obvykle obrázky .dmg se shromažďují v adresáři pro stahování a uživatel do nich zkopíruje balíčky /Applications. Předpokládá se, že mnoho uživatelů sami neví, co dělají, tuto hypotézu potvrzuje bývalý zaměstnanec Applu. (Jedna z věcí, které se mi na Macu nelíbí. A například u AppImage není žádný rozdíl mezi aplikací a balíčkem, ve kterém byla. Přetáhněte ikonu do koše = to je vše. Snadno!)
Na Haiku, existuje také rozdělení mezi apps/ и packages/, takže pochybuji, že to bylo pro uživatele jasnější. Ale co se stane, když přetáhnete aplikaci z apps/ Přidat do košíku:
To se stane, když se pokusíte odebrat aplikaci převzatou ze souboru .hpkg
Technicky je to správné (koneckonců, aplikace je v první řadě hostována na souborovém systému pouze pro čtení), ale pro uživatele to není nijak zvlášť užitečné.
Rychlé řešení: místo toho navrhněte použití GUI k odstranění
.hpkg
Jen pro zajímavost jsem zkusil duplikovat aplikaci stisknutím Alt+D. Obdržel jsem zprávu "Nelze přesunout nebo zkopírovat objekty na svazku pouze pro čtení." A to všechno proto /system (kromě /system/packages и /system/settings) je přípojný bod packagefs (pamatujte si, jak se zobrazuje ve výstupu df?). Bohužel výstup příkazu mount nevyjasňuje situaci (jak bylo řečeno v jednom z předchozích článků), mountvolume nezobrazuje to, co hledáte (zřejmě balíčky připojené přes smyčku .hpkg nejsou považovány za "svazky") a také jsem zapomněl na alternativní příkazy.
V této kategorii nevyhrál nikdo kromě AppImage (ale abych byl upřímný, je to zaujatý názor). Lze si však představit, že po úpravě bude uživatelská zkušenost na Haiku lepší než na Macu.
Poznámka: musíte zjistit, co je „svazek“ ve vztahu k „sekci“. To je pravděpodobně podobné vztahu „složka“ k „adresáři“: většina adresářů se ve správci souborů zobrazuje jako složky, ale ne všechny (například balíčky považované za soubory). Dělá ze mě tento druh zobrazení oficiálního pitomce?
Kopírování obsahu balíčku do jiného systému
Na Macu, hloupě tahám balíček .app, a protože závislosti jsou uvnitř balíčku, pohybují se společně.
Na Haiku, přetáhnu aplikaci, ale závislosti se vůbec nezpracovávají.
Rychlé řešení: Místo toho navrhneme přetažení celého balíčku `.hpkg spolu s případnými závislostmi.
V této kategorii jednoznačně vítězí Mac. Alespoň pro mě, milovníka jejich paradigmatu. Měl bych to zkopírovat do Haiku .hpkg místo aplikace, ale toto mi systém nenabízí...
Stáhněte si balíček se všemi jeho závislostmi
Ne každý stroj je neustále připojen k síti. Některé stroje (ano, koukám na vás, moderní Windows, Mac a Linux) na tohle naopak zapomínají. Je pro mě důležité, že mohu jít například do internetové kavárny, stáhnout si software na vyměnitelný disk, vložit tento disk do domácího počítače a mít jistotu, že vše bude fungovat [riskantní člověk, dělá to na Windows... - Cca. překladatel].
V důsledku toho mám tendenci skončit s nenaplněnými závislostmi na Windows a Linuxu o něco častěji než obvykle.
Na Macu toto je obvykle jeden soubor, vše, co musíte udělat, je stáhnout .dmg. Nejčastěji nemá žádné jiné závislosti než ty, které ve výchozím nastavení poskytuje samotný MacOS. Výjimkou jsou složité aplikace, které vyžadují vhodné spouštěcí prostředí, například java.
Na Haiku stáhnout balíček .hpkg řekněme stejná aplikace v jazyce Java nemusí být dostatečná, protože Java může nebo nemusí být přítomna na cílovém počítači. Existuje způsob, jak stáhnout všechny závislosti pro daný balíček .hpkg, jiné než ty, které jsou standardně nainstalovány v Haiku, a proto by měly být na každém systému Haiku?
Mac tuto kategorii s malým náskokem vyhrává.
Komentáře Mr. waddlesplash:
Chcete-li napsat program, který bude shromažďovat všechny závislosti aplikace jako sadu balíčků
.hpkgpro někoho obeznámeného s vnitřním fungováním Haiku stačí asi 15 minut. Přidání podpory pro toto není tak obtížné, pokud je to skutečně potřeba. Ale pro mě je to vzácná situace.
Zatajme dech do dalšího článku této série.
Přesouvání balíků na samostatné místo
Jak jsem psal dříve, chci umístit své balíčky .hpkg (dobře, nebo jejich část) na speciální místo, oddělené od obvyklého umístění na spouštěcím svazku (kořenovém oddílu). V obvyklém (ne tak teoretickém) případě je to důvodem, že mi neustále dochází volné místo na mých (vestavěných) discích, ať jsou jakkoli velké. A většinou připojuji externí disky nebo síťové sdílené položky, kde jsou umístěny moje aplikace.
Na Macu Jen přesouvám balíčky .app na vyměnitelný disk nebo síťový adresář ve Finderu a je to. Stále mohu poklepáním otevřít aplikaci jako normálně ze spouštěcího svazku. Prostě!
Na Haiku, jak mi bylo řečeno, toho lze dosáhnout posunutím mého .hpkg balíky na vyměnitelný disk nebo síťový adresář, ale pak musíte použít některé nezdokumentované příkazy v konzole, abyste je mohli připojit do systému. Nevím, jak to udělat pouze pomocí GUI.
V této kategorii vítězí Mac.
Podle pana waddlesplash:
Jedná se o optimalizaci založenou na běžném používání. Pokud bude poptávka od více uživatelů, implementujeme ji. V každém případě existuje možnost implementace třetí stranou.
O tom si povíme v dalším článku.
Když už mluvíme o síťových adresářích, bylo by skvělé (hádám, že LAN party) mít jednoduché, zjistitelné celosíťové aplikace (jako Zeroconf), které lze zkopírovat na místní počítač nebo spustit přímo z místní sítě. Vývojáři mají samozřejmě možnost se odhlásit přes app_flags.
Závěrečná zpráva o integraci systému hpkg s GUI
Myslím, že především kvůli relativní novosti integrace .hpkg GUI stále ponechává mnoho přání. Každopádně existuje pár věcí, které by se z hlediska UX mohly zlepšit...
Ještě jedna věc: Kernel Debug Land
Bylo by skvělé mít možnost zadávat příkazy například během paniky jádra syslog | grep usb. No, na Haiku je to možné díky Kernel Debug Land. Jak můžete vidět toto kouzlo v akci, když vše funguje, jak má, aniž byste se dostali do jaderné paniky? Snadno stisknutím Alt+PrintScn+D (debug mnemotechnická pomůcka). Hned si vzpomenu , což umožnilo původním vývojářům Macintoshe vstoupit do debuggeru (pokud byl samozřejmě nainstalován).
Závěr
Začínám chápat, že propracovanost systému Haiku vychází ze skutečnosti, že práci provádí jeden malý tým s jasným zaměřením na pracovní prostředí, s přístupnými všemi vrstvami systému.
Ostrý kontrast se světem Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, kde je vše rozbité na malé kousky do takové míry, že abstrakce sedí na abstrakci a pohání se s berličkami.
Došlo také k pochopení toho, jak systém .hpkg kombinuje osvědčené postupy tradičních správců balíčků, Snappy, Flatpak, AppImage, dokonce i btrfs, a mísí je s přístupem Macu „jen funguje“.
Jako by se mi v hlavě něco „přepnulo“ a já pochopil, jak funguje systém .hpkg ví, jak se odvalit, jen tím, že se na ni podívá. Ale to nejsem já, ale krása a jednoduchost systému. Hodně z toho je inspirováno duchem původního Macu.
Ano, prohlížení v prohlížeči může být trhané a běhat jako šnek, aplikace mohou chybět (žádné Gtk, Electron - vývojáři usoudili, že se sofistikovaností moc neladí), video a 3D akcelerace možná úplně chybí, ale přesto líbí tento systém. Tyto věci se totiž dají napravit a dříve nebo později se objeví. Je to jen otázka času a možná trochu červených očí.
Nemohu nabídnout pomoc, ale myslím, že to začne od nynějška rok Haiku na ploše.
Náhodné problémy
Možná již požadavky existují, nebo je mám otevřít?
- BeScreenCapture by měl být schopen exportovat do GIF jako Peek. To lze provést pomocí ffmpeg, který je již dostupný pro Haiku. .
- Software pro snímky obrazovky nedokáže zachytit modální okno, místo toho zachytí celou obrazovku
- Snímky obrazovky nemůžete oříznout pomocí nástroje pro oříznutí WonderBrush a poté uložit výsledek do souboru
- Kurzor ruky v Haiku se mi nijak zvlášť nelíbí, ale myslím, že to souvisí s hřejivým nostalgickým pocitem. To je obzvláště nepříjemné při použití nástroje oříznutí v Kritě, protože to vede k nepřesnému oříznutí (viz snímky obrazovek modálních dialogů v tomto článku). Zaměřovací kurzor by byl skvělý. .
Zkus to sám! Projekt Haiku koneckonců poskytuje vygenerované obrazy pro bootování z DVD nebo USB . Chcete-li nainstalovat, stačí stáhnout obrázek a zapsat jej na flash disk pomocí
Máte nějaké dotazy? Zveme vás na rusky mluvící .
Přehled chyb:
Z překlad: toto je šestý článek ze série o Haiku.
Seznam článků:
Zdroj: www.habr.com