Мој шести дан са Хаикуом: испод хаубе ресурса, икона и пакета

ТЛ; ДР: Хаику је оперативни систем посебно дизајниран за рачунаре, тако да има неколико трикова који његово десктоп окружење чине много бољим од осталих. Али како то функционише?

Недавно Открио сам хаику, неочекивано добар систем. Још увек сам задивљен колико глатко ради, посебно у поређењу са Линук десктоп окружењима. Данас ћу погледати испод хаубе. Тамо где је потребно за дубље разумевање, направићу поређења са оригиналним Мацинтосх, Мац ОС Кс и Линук десктоп окружењима (КСДГ стандард са фреедесктоп.орг).

Ресурси у ЕЛФ датотекама

Јуче сам сазнао да ИцонОМатиц може да сачува иконе у рдеф ресурсима у ЕЛФ извршним датотекама. Данас желим да видим како то заиста функционише.

Ресурси? Цитат из Бруце Хорн, оригинални аутор Мацинтосх Финдер-а и "отац" Мацинтосх Ресоурце Манагер-а:

Забринут сам због круте природе традиционалног кодирања. За мене је сама идеја апликације замрзнуте у коду, без могућности да се било шта динамички промени, најлуђе дивљаштво. Требало би да буде могуће променити што је више могуће током рада. Наравно, сам код апликације се не може променити, али сигурно се нешто може променити без поновног компајлирања кода?

На оригиналном Мацинтосх-у су направили да ове датотеке имају „одељак са подацима“ и „одељак са ресурсима“, што је учинило невероватно лаким чување ствари попут икона, превода и слично. у извршним датотекама.

На Мац-у се ово користи РесЕдит, графички програм за - изненада - уређивање ресурса.

РесЕдит на оригиналном Мацинтосх-у

Као резултат тога, постало је могуће уређивати иконе, ставке менија, преводе итд. довољно лако, али и даље „путују“ са апликацијама.
У сваком случају, овај приступ је имао велики недостатак: радио је само на Аппле системима датотека, што је био један од разлога зашто је Аппле напустио „секцију ресурса“ када је прешао на Мац ОС Кс.
На Мац ОС Кс-у, Аппле је желео решење независно од система датотека, па су усвојили концепт пакета (од НеКСТ-а), директоријума које менаџер датотека третира као „непрозирне објекте“, као датотеке уместо директоријума. Било који пакет са апликацијом у формату .app има, између осталог, фајл Info.plist (у некој врсти Аппле-овог еквивалента ЈСОН или ИАМЛ) који садржи метаподатке апликације.

Кључеви за датотеку Инфо.плист из Мац ОС Кс апликацијског пакета.

Ресурси, као што су иконе, УИ датотеке и други, чувају се у пакету као датотеке. Концепт се заправо вратио својим коренима у НеКСТ-у.

Матхематица.апп на НеКСТСТЕП 1.0 1989: појављује се као директоријум датотека у терминалу, али као један објекат у графичком менаџеру датотека.

Вратимо се на БеОС, концепте на којима се Хаику заснива. Његови програмери, када су прешли са ПЕФ (ПоверПЦ) на ЕЛФ (к86) (исто као што се користи на Линуку), одлучили су да додају одељак ресурса на крај ЕЛФ датотека. Није користио свој одговарајући ЕЛФ одељак, већ је једноставно додат на крај ЕЛФ датотеке. Као резултат програма strip а други из бинутила, несвесни овога, једноставно га одсеку. Стога, када додајете ресурсе у ЕЛФ датотеку на БеОС-у, боље је не манипулисати њоме помоћу Линук алата.

Шта се сада дешава са Хаикуом? У суштини, мање-више исто.

У теорији, било би могуће поставити ресурсе у жељени одељак ЕЛФ-а. Према програмерима на #хаику каналу на ирц.фрееноде.нет:

Са ЕЛФ-ом би одељак имао више смисла... једини разлог зашто то не радимо на тај начин је зато што је тако урађено у БеОС-у."
И нема смисла ово сада мењати.

Управљање ресурсима

Ресурси су написани у структурираном формату „ресурса“: у суштини листа ресурса са величинама, а затим њихов садржај. Сетила сам се ар формат.
Како проверити ресурсе у Хаику-у? Постоји ли нешто као РесЕдит?
Према документација:

Да бисте видели ресурсе обезбеђене у пакету апликације, можете превући извршну датотеку у програм као што је Ресоурцер. Такође можете отићи на терминал и покренути команду listres имя_файла.

Ресоурцер је доступан у ХаикуДепот-у, али мени се једноставно руши.

Како управљати ресурсима у ЕЛФ датотекама? Користећи rsrc и rdef. rdef датотеке се прикупљају у rsrc. Филе rdef се чува у формату обичног текста, тако да је много лакше радити са њим. Формат датотеке rsrc додато на крај ЕЛФ датотеке. Хајде да покушамо да играмо:

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

Можете користити програм xres за проверу и контролу:

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

Ок, да пробамо?

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

Више о ресурсима и формату rdef можете прочитати овде.

Стандардни типови ресурса

Иако можете било шта ставити у ресурсе, постоји неколико дефинисаних стандардних типова:

• app_signature: МИМЕ тип апликације, за мапирање отворених датотека, покретање, ИПЦ, итд.
• app_name_catalog_entry: Пошто је назив апликације обично на енглеском, можете одредити места на којима се налазе преведени називи, тако да ће корисници различитих језика по жељи видети преведено име апликације.
• app_version: тачно оно што сте мислили
• app_flags: означава registrar како обрадити пријаву. Мислим да ту има више него што се на први поглед чини. На пример, постоји B_SINGLE_LAUNCH, што приморава систем да покрене нови процес апликације сваки пут када корисник то затражи (исти принцип се користи за већину апликација на Линук-у). Једи B_MULTIPLE_LAUNCH, што доводи до покретања процеса сваки фајл. Коначно постоји B_EXCLUSIVE_LAUNCH, што приморава систем да покреће само један процес у исто време, без обзира на то колико често га корисници покрећу (на пример, овако ради Фирефок на Линук-у; исти резултат се може постићи у Кт апликацијама помоћу функције КтСинглеАпплицатион). Пријаве са B_EXCLUSIVE_LAUNCH су обавештени када корисник поново покуша да их покрене: на пример, добију путању датотеке коју корисник жели да отвори уз њихову помоћ.
• vector_icon: Икона векторске апликације (БеОС није имао векторске иконе, већина апликација је уместо тога имала две растерске иконе у својим извршним датотекама).

Наравно, можете додати ресурсе са било којим жељеним ИД-овима и типовима, а затим их прочитати у самој апликацији или другим апликацијама користећи класу BResources. Али прво, погледајмо фасцинантну тему икона.

Векторске иконе у хаику стилу

Наравно, није само Хаику изабрао најбољи формат икона; у овом делу ситуација са Линук десктоп окружењима је далеко од идеалне:

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

Гледајући ово, већ се осећа о каквом се комаду ради.

Наравно, постоји скалабилан, који садржи, као што разумете, векторске иконе. Зашто онда постоји још нешто? Зато што резултат цртања векторске графике у малим величинама може бити мање него идеалан. Желео бих да имам различите опције оптимизоване за различите величине. У Линук десктоп окружењима, ово се постиже расипањем икона различитих величина по систему датотека.

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

Имајте на уму: не постоји концепт различитих верзија Фирефок-а. Дакле, није могуће елегантно решити ситуацију да имате више верзија апликације на систему.

Различите иконе Фирефока у различитим верзијама. Тренутно је немогуће ово решити у Линуку без разних штака.

Мац ОС Кс то решава мало суптилније:

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

Види се да постоји један фајл firefox.icns у пакету Firefox.app, који садржи све величине тако да различите верзије исте апликације имају различите иконе.
Много боље! Иконе путују са апликацијом, сви ресурси су у једној датотеци.

Вратимо се хаикуу. Невероватно решење, без изузетака. Према документација:

Развијен је посебан ХВИФ формат, високо оптимизован за мале величине и брзо приказивање. Стога су наше иконе углавном много мање него у растеру или у широко коришћеном СВГ формату.

И још увек су оптимизовани:

Величине икона у ХВИФ у поређењу са другим форматима.

Разлика је ред величине!

Али магија се овде не завршава. Исти ХВИФ може приказати различите нивое детаља у зависности од приказане величине, иако је у векторском формату.

Различити нивои детаља (ЛОД) у зависности од величине рендера

Сада о недостацима: не можете узети СВГ, бацити га у ИмагеМагицк и назвати га дан; морате проћи кроз неколико циклуса да бисте креирали икону у ХВИФ формату. Овде објашњења. Међутим, ИцонОМатиц може да увози СВГ прилично несавршено; око 90% СВГ детаља се увози са извесном вероватноћом, преосталих 10% ће морати да се конфигуришу и промене ручно. Прочитајте више о томе како ХВИФ чини своју магију може се на блогу Леах Гансон

Додавање иконе у апликацију

Сада могу да додам икону у креирани пакет последњи пут, узимајући у обзир све примљене информације.
Па, пошто тренутно нисам посебно нестрпљив да нацртам сопствену икону за своју „Здраво, свет“ КтКуицкАпп, извлачим је из Кт Цреатор-а.

/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

Хајде да проверимо да ли је икона копирана:

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

Изгледа добро, али зашто се не појављује када се нова икона копира?

Копирана ВИЦН:101:БЕОС:ИЦОНс се још увек не користи као икона апликације у менаџеру датотека

Шта сам пропустио?

Коментар програмера:

Морамо да креирамо датотеку rdef са свим ресурсима, а затим извршите команду rc имя.rdef, ово ће креирати датотеку .rsrc. Затим морате покренути команду resattr -o имя_бинарника имя.rsrc. У најмању руку, користим команде попут ових за додавање икона својим скриптама.

Па, хтео сам да направим ресурс, а не атрибут. Стварно сам збуњен.

Паметно кеширање помоћу система датотека

Отварање и читање ЕЛФ атрибута је споро. Као што сам горе написао, икона је написана као ресурс у самој датотеци. Овај метод је поузданији и омогућава вам да преживите копирање у други систем датотека. Међутим, онда се такође копира у атрибут система датотека, на пример BEOS:ICON. Ово ради само на одређеним системима датотека, као што је БФС. Иконе које приказује систем (у Трацкер-у и Дескбар-у) се читају из овог проширеног атрибута, јер ово решење брзо функционише. На неким местима (где брзина није важна, на пример, типичан прозор „О“), систем прима икону директно из ресурса у датотеци. Али ово није крај. Запамтите, на Мац-у корисници могу да замене иконе апликација, директоријума, докумената својим, пошто је на Мац-у могуће урадити ове „важне“ ствари, нпр. замена нове Слацк иконе претходном. На Хаику-у, требало би да замислите ресурс (у датотеци) као оригиналну икону која долази са апликацијом, а атрибут (у БФС систему датотека) као нешто што омогућава кориснику да прави промене по вољи (иако, наговештај, ГУИ за уметање прилагођене иконе на врх иконе је опционо). још увек није примењено подразумевано).

Провера атрибута система датотека

Са resaddr Могуће је проверити и подесити атрибуте система датотека.

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

То је у суштини „лепак“ који врши конверзију напред-назад између (поузданих) ресурса и (брзих) атрибута система датотека. А пошто систем очекује да добије ресурсе и аутоматски врши копирање, нећу даље да бринем о томе.

Магија хпкг пакета

Тренутно (најчешће) се пакети користе за добијање програма на Хаику-у .hpkg. Немојте да вас завара једноставно име: формат .хпкг функционише потпуно другачије од других формата са сличним именима на које сте наишли, има стварне супермоћи.

Са традиционалним форматима пакета, дуго сам био узнемирен због ове чињенице: преузимате једну ствар (пакет), а друга се инсталира на систем (датотеке унутар пакета). Прилично је тешко управљати датотекама (на пример, избрисати их) када инсталирате пакет на традиционалан начин. И све због садржаја пакета расути по читавом систему датотека, укључујући места где просечан корисник можда нема приступ писању. Ово доводи до читаве класе програма - менаџери пакета. Али преношење већ инсталираног софтвера, на пример, на другу машину, преносиви диск или сервер датотека постаје још теже, ако не и потпуно немогуће. На типичном систему заснованом на Линук-у, лако може постојати неколико стотина хиљада до милион појединачних датотека. Непотребно је рећи да је ово и крхко и споро, на пример када се иницијално инсталира систем, када инсталирате, ажурирате и деинсталирате обичне пакете и када копирате волумен за покретање (роот ​​партицију) на други медиј.

Радим на пројекту АппИмаге, делимичном штаку за апликације за крајње кориснике. Ово је формат дистрибуције софтвера који прикупља апликацију и све њене зависности у једну слику система датотека која се монтира када се апликација покрене. Значајно поједностављује ствари, пошто се исти ИмагеМагицк изненада претвара у једну датотеку, којом управљају обични смртници у менаџеру датотека. Предложени метод функционише само за софтвер, као што се види у називу пројекта, а такође има и сопствени скуп проблема, пошто људи који су укључени у испоруку софтвера за Линук увек показују стрелицу на мене.

Вратимо се хаикуу. Да ли је било могуће пронаћи оптималну равнотежу између традиционалних система пакета и испоруке софтвера заснованог на сликама? Њени пакети .hpkg заправо компримоване слике система датотека. Када се систем покрене, кернел монтира све инсталиране и активне пакете са приближно следећим порукама кернела:

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"

Кул, да? Држите се, биће још хладније!

Постоји веома посебан пакет:

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

Садржи веома минималистички оперативни систем, укључујући кернел. Веровали или не, чак ни само језгро није уклоњено из запремине покретања (роот ​​партиције), већ се пажљиво учитава на своје место из пакета .hpkg. Вау! Већ сам поменуо да мислим да део укупне софистицираности и доследности Хаикуа потиче од чињенице да је цео систем, од кернела и језгра корисничког простора до управљања пакетима и инфраструктуре за време извршавања, развијен у сарадњи једног тима. Замислите колико би различитих група и тимова било потребно да се овако нешто покрене на Линук-у [Замишљам пројекат ПуппиЛинук – прибл. преводилац]. Затим замислите колико ће времена бити потребно да овај приступ буде усвојен у дистрибуцијама. Кажу: узмите једноставан проблем, поделите га између различитих извођача, и он ће постати толико компликован да га више неће бити могуће решити. Хаику ми је у овом случају отворио очи. Мислим да се управо то сада дешава на Линук-у (Линук је у овом случају заједнички израз за Линук/ГНУ/дпкг/апт/системд/Ксорг/дбус/Гтк/ГНОМЕ/КСДГ/Убунту стек).

Враћање система користећи хпкг

Колико често се дешава следећа ситуација: ажурирање је било успешно, а онда се испостави да нешто не ради како би требало? Ако користите конвенционалне менаџере пакета, тешко је вратити стање система на тренутак пре него што су нови пакети инсталирани (на пример, у случају да нешто пође по злу). Неки системи нуде заобилазна решења у облику снимака система датотека, али су прилично гломазни и не користе се на свим системима. Хаику ово решава помоћу пакета .hpkg. Кад год се пакети промене у систему, стари пакети се не бришу, већ се чувају у систему у поддиректоријумима као што је /Haiku/system/packages/administrative/state-<...>/ стално. Недовршене операције чувају своје податке у поддиректоријумима /Haiku/system/packages/administrative/transaction-<...>/.

Садржај /Haiku/system/packages/administrative. Директоријуми „стање...“ садрже текстуалне датотеке са именима активних пакета, а директоријуми „трансакција...“ садрже саме пакете.

„Старо активно стање“, тј. листа .hpkg пакети активни пре промена се снимају после сваке операције у менаџеру датотека у текстуалној датотеци /Haiku/system/packages/administrative/state-<...>/activated-packages. На сличан начин, ново „активно стање“ се уписује у текстуалну датотеку /Haiku/system/packages/administrative/activated-packages.

Директоријум /Haiku/system/packages/administrative/state-<...>/ садржи само текстуалну датотеку са листом активних пакета овог стања (у случају инсталације пакета без уклањања), а ако су пакети уклоњени или ажурирани - директоријум стања садржи старе верзије пакета.

Када се систем покрене, на основу листе пакета, доноси се одлука да се пакети активирају (монтирају). То је тако једноставно! Ако нешто пође по злу током преузимања, можете рећи менаџеру преузимања да користи другу, старију листу. Проблем решен!

Хаику довнлоадер. Свака улазна тачка приказује одговарајуће "активно стање"

Свиђа ми се приступ једноставних текстуалних датотека као листе „активног стања“, са именима која су лака за разумевање .hpkg. Ово је у потпуној супротности са прављењем за машине, а не за људе. хрпа из ОСТрее или Флатпак у систему датотека (на истом нивоу као Мицрософт ГУИД).

Листа активних пакета за сваки тренутак

Подаци о конфигурацији

Очигледно, у каталогу /Haiku/system/packages/administrative/writable-files садржи конфигурационе датотеке за пакете, али се у њих може писати. Уосталом, као што се сећате, .hpkg монтиран само за читање. Дакле, ове датотеке морају бити копиране из пакета пре писања. Има значење.

ГУИ интеграција за .хпкг систем

Хајде сада да видимо како ове сјајне торбе .hpkg носи са интеграцијом у радно окружење корисника (УКС). На крају крајева, хаику је намењен за личну употребу. Лично сам високо поставио летвицу када упоредим корисничко искуство са пакетима .app на Мацинтосх-у са истим искуством на .hpkg. Нећу ни да поредим ситуацију са радним окружењима на Линуксу, јер је апсолутно ужасна у поређењу са било којим другим.

Падају ми на памет следећи сценарији:

• Желим да видим садржај пакета .hpkg
• Желим да инсталирам пакет
• Желим да уклоним пакет
• Желим да уклоним нешто што је ушло у систем као део пакета
• Желим да копирам нешто што је ушло у систем као део пакета
• Желим да преузмем све зависности пакета, што можда није део сваке Хаику инсталације (на пример, имам физички изоловану машину без приступа интернету.)
• Желим да преместим своје пакете (или њихов део) одвојено на другу локацију, одвојено од волумена за покретање (роот ​​партиција) (јер, на пример, немам довољно простора на њему).

Ово би требало да покрије већину великих случајева из мог свакодневног рада. Па, хајде да почнемо.

Провера садржаја пакета

На Мац-у Једноставно кликнем десним тастером миша на пакет да га отворим и погледам садржај у Финдер-у. На крају крајева, у стварности је то само прикривени директоријум! (Знам да постоје пакети .pkg за део система који нису апликације, али обични корисници најчешће не ступају у интеракцију са њима).

Он Хаику Кликнем десним тастером миша на пакет, затим кликнем на „Садржај“ да видим шта је унутра. Али ево само листе датотека без могућности да их отворите двоструким кликом.
Било би много боље да постоји начин да се (привремено) монтира пакет .hpkg да се види кроз менаџер датотека, а корисник не би морао да брине о детаљима имплементације. (Успут, можете отворити .hpkg упаковати у Expander, који га може распаковати као и сваку другу архиву).

ХаикуДепотов интерфејс вам омогућава да видите листу датотека пакета, али не постоји начин да видите садржај тако што ћете, на пример, двапут кликнути на РЕАДМЕ.мд

Мац побеђује у овој категорији, али додавање ХаикуДепот функционалности коју желите не би требало да буде превише тешко.

Инсталирање пакета преко ГУИ

На Мац-у, већина слика дискова .dmg садрже пакете .app. Двапут кликните на слику диска, а затим копирајте пакет, на пример, превлачењем у њега /Applications у Финдеру. Ово се подразумева за мене, али чуо сам да неки новајлије можда неће моћи да се носе са овим. Подразумевано, Аппле „предлаже“ системски директоријум /Applications (на НеКСТ-у је било умрежено као и појединачно), али можете лако да ставите своје апликације на сервер датотека или у поддиректоријум $HOME/Applications, ако вам се тако свиђа.

Он Хаику, двапут кликните на пакет, а затим кликните на „Инсталирај“, не може бити лакше. Питам се шта се дешава ако пакет има зависности које су доступне у ХаикуПорт-овима, али још увек нису инсталиране. На Линук-у заиста не знају шта да раде у овој ситуацији, али решење је очигледно - питајте корисника да ли треба да преузме и инсталира зависности. Управо оно што Хаику ради.

Ручно сам преузео 'санити' пакет и кликнуо на њега, менаџер пакета зна одакле да добије његове зависности (под претпоставком да су спремишта већ регистрована на систему). То не може свака дистрибуција Линука.

Други начин је да користите менаџер датотека, само превуците и отпустите .hpkg пакету или у /Haiku/system/packages (за инсталацију на нивоу система, подразумевано), или у /Haiku/home/config/packages (за индивидуалну инсталацију; није доступно када се двапут кликне - и даље ме нервира реч „цонфиг“ на овом месту, која је за мене у овом случају синоним за „подешавања“). А концепт више корисника још увек није доступан чак ни за Хаику (то је вероватно разлог зашто је тако једноставан – не знам, можда ће вишекорисничке могућности непотребно закомпликовати ствари за десктоп окружење).

Хаику побеђује у овој категорији јер може да ради не само са апликацијама, већ и са системским програмима.

Уклањање пакета из ГУИ

На Мац-у, потребно је да превучете икону апликације у канту за отпатке и то је све. Лако!

Он Хаику, прво, морате да пронађете где се пакет налази на систему, јер га ретко инсталирате на право место (систем ради све). Обично морате погледати унутра /Haiku/system/packages (са подразумеваном инсталацијом на нивоу система) или у /Haiku/home/config/packages (Да ли сам споменуо да је „цонфиг“ погрешан назив?). Затим се апликација једноставно превлачи у канту за смеће и то је то.
Лако! Међутим, не бих то рекао. Ево шта се заиста дешава:

Ово се дешава ако превучете апликацију у канту за смеће /Haiku/system/packages

Управо сам покушао да преместим своју јучерашњу "Хелло Ворлд" апликацију на КтКуицкАпп-у у смеће. Нисам покушао да преместим системски директоријум, а пошто су сви пакети инсталирани у системском директоријуму, немогуће је уклонити пакет .hpkg bez promene "његов садржај". Обичан корисник би се уплашио и притиснуо дугме „Откажи“ које је подразумевано додељено.

Објашњава господин. ваддлеспласх:

Овај пост је стар преко 10 година. Највероватније морамо да га конфигуришемо тако да се упозорење појављује само када се сам пакет премести. Обични корисници то ионако не морају да раде.

У реду, можда би ово требало да урадим користећи ХаикуДепот? Двапут кликнем на пакет /Haiku/system/packages, чекајући да се појави дугме „Деинсталирај“. Не, постоји (само) „Инсталирај“. "Деинсталирај", где си?

Само из забаве, покушао сам да видим шта ће се догодити ако кликнем на „Инсталирај“ на већ инсталираном пакету. Испада овако:

Ово се дешава ако покушате да инсталирате већ инсталирани пакет.

Следеће се појављује:

Ако кликнете на „Примени промене“ у претходном прозору, то ће изгледати овако

Претпостављам да је ово софтверска грешка; веза до апликације је већ тамо. [аутор није навео линк – цца. преводилац]

Брзо решење: Додајте дугме „Деинсталирај“ ако је пакет већ унутра /Haiku/system/packages, или у /Haiku/home/config/packages.

Када прегледам листу пакета инсталираних у ХаикуДепот-у, видим свој пакет на листи и могу да га уклоним.

Мац побеђује у овој категорији. Али могу да замислим да ће уз правилно подешавање корисничко искуство на Хаику-у бити боље него на Мац-у. (Један од програмера је то оценио на следећи начин: „Мање од сат времена за додавање наведене функционалности у ХаикуДепот, ако знате мало Ц++“, има ли добровољаца?)

Уклањање нечега из пакета

Хајде да покушамо да уклонимо саму апликацију, а не пакет .hpkg, из које је дошло (сумњам да за „обичне смртнике“ постоји разлика).

На Мац-у, корисник заправо обично ради са датотеком .dmgодакле долази пакет апликације .app. Обично слике .dmg се акумулирају у директоријуму преузимања, а пакете корисник копира /Applications. Верује се да многи корисници сами не знају шта раде, ову хипотезу потврђује бивши запосленик компаније Аппле. (Једна од ствари које не волим на Мац-у. И, на пример, са АппИмаге-ом нема разлике између апликације и пакета у коме је била. Превуците икону у смеће = то је то. Лако!)

Он Хаику, постоји и подела између apps/ и packages/, па сумњам да је ово корисницима постало јасније. Али шта се дешава ако превучете апликацију из apps/ Додај у колица:

Ово се дешава када покушате да уклоните апликацију преузету из датотеке .hpkg

Технички је то исправно (на крају крајева, апликација је у првом реду хостована на систему датотека само за читање), али није нарочито корисна за корисника.

Брзо решење: предложите коришћење ГУИ за брисање уместо тога .hpkg

Само из забаве, покушао сам да дуплирам апликацију притиском на Алт+Д. Добио сам поруку „Није могуће преместити или копирати објекте на волумену само за читање“. И све због тога /system (Осим тога /system/packages и /system/settings) је тачка монтирања пакета (запамтите како се појављује у излазу df?). Нажалост, излаз команде mount не разјашњава ситуацију (као што је речено у једном од претходних чланака), mountvolume не приказује оно што тражите (очигледно пакети монтирани преко петље .hpkg се не сматрају „волуменима“), а заборавио сам и алтернативне команде.

У овој категорији нико није победио осим АппИмаге-а (али ово је, да будемо потпуно искрени, пристрасно мишљење). Међутим, може се замислити да ће након подешавања корисничко искуство на Хаику-у бити боље него на Мац-у.

Напомена: потребно је да сазнате шта је „волумен“ у односу на „одељак“. Ово је вероватно слично односу између „директоријума“ и „директоријума“: већина директоријума се појављује као фасцикле у менаџеру датотека, али не сви (на пример, пакети који се третирају као датотеке). Да ли ме овакав приказ чини званичним штребером?

Копирање садржаја пакета на други систем

На Мац-у, глупо вучем пакет .app, а пошто су зависности унутар пакета, оне се крећу заједно.

Он Хаику, превлачим апликацију, али се зависности уопште не обрађују.

Брзо решење: Хајде да уместо тога предложимо превлачење целог пакета `.хпкг, заједно са свим зависностима, ако их има.

Мац очигледно побеђује у овој категорији. Бар за мене, љубитеља њихове парадигме. Требало би да га копирам у Хаику .hpkg уместо апликације, али ми систем ово не нуди...

Преузмите пакет са свим његовим зависностима

Није свака машина повезана на мрежу све време. Напротив, неке машине (да, гледам вас, модерни Виндовс, Мац и Линук) заборављају на ово. Важно ми је да могу да одем, на пример, у интернет кафе, преузмем софтвер на преносиви диск, убацим овај диск у свој кућни рачунар и будем сигуран да ће све функционисати [ризичан момак, ради ово на Виндовс-у... - прибл. преводилац].

Као резултат тога, имам тенденцију да завршим са неиспуњеним зависностима од Виндовс-а и Линук-а мало чешће него обично.

На Мац-у ово је обично једна датотека, све што треба да урадите је да преузмете .dmg. Најчешће, нема других зависности осим оних које подразумевано обезбеђује сам МацОС. Изузетак су сложене апликације које захтевају одговарајуће окружење за извршавање, на пример јава.

Он Хаику преузимање пакета .hpkg јер, рецимо, иста апликација у Јави, можда неће бити довољна, пошто јава може али не мора бити присутна на циљној машини. Постоји ли начин да преузмете све зависности за дати пакет .hpkg, осим оних који су подразумевано инсталирани у Хаику-у и стога би требало да буду на сваком Хаику систему?

Мац побеђује у овој категорији са малом разликом.

Коментари Мр. ваддлеспласх:

Написати програм за прикупљање свих зависности апликације као скуп пакета .hpkg за некога ко је упознат са унутрашњим радом хаикуа, око 15 минута је довољно. Додавање подршке за ово није тако тешко ако постоји стварна потреба за тим. Али за мене је ово ретка ситуација.

Задржимо дах до следећег чланка у овој серији.

Премештање пакета на другу локацију

Као што сам раније написао, желим да ставим своје пакете .hpkg (добро, или део њих) на посебно место, одвојено од уобичајеног постављања на запремину покретања (коренска партиција). У уобичајеном (не тако теоретском) случају, разлог за то је што ми стално понестаје слободног простора на мојим (уграђеним) дисковима, ма колико они били велики. И обично повезујем екстерне дискове или мрежне дељене локације на којима се налазе моје апликације.

На Мац-у Само премештам пакете .app на преносиву диск јединицу или мрежни директоријум у Финдер-у, и то је то. Још увек могу двапут да кликнем да отворим апликацију као што бих иначе урадио из запремине покретања. Само!

Он Хаику, као што ми је речено, то се може постићи померањем мог .hpkg пакете на преносиву диск јединицу или мрежни директоријум, али тада морате да користите неке недокументоване команде у конзоли да бисте их монтирали на систем. Не знам како да ово урадим користећи само ГУИ.

Мац побеђује у овој категорији.

Према речима г. ваддлеспласх:

Ово је оптимизација заснована на нормалној употреби. Ако постоји потражња од више корисника, ми ћемо то имплементирати. У сваком случају, постоји могућност имплементације треће стране.

О томе ћемо говорити у следећем чланку.

Говорећи о мрежним директоријумима, било би сјајно (претпостављам ЛАН забаве) имати једноставне апликације које се могу открити широм мреже (као што је Зероцонф) које се могу копирати на локални рачунар или покренути директно са локалне мреже. Наравно, програмери имају опцију да се одустану преко app_flags.

Коначни извештај о интеграцији хпкг система са ГУИ

Мислим да је то првенствено због релативне новине интеграције .hpkg ГУИ и даље оставља много да се пожели. У сваком случају, постоји неколико ствари које би се могле побољшати у погледу корисничког искуства...

Још једна ствар: Кернел Дебуг Ланд

Било би сјајно да можете да уносите команде током панике кернела, на пример syslog | grep usb. Па, на Хаику-у је то могуће захваљујући Кернел Дебуг Ланд-у. Како можете видети ову магију на делу ако све функционише како треба, а да не упадате у панику кернела? Лако притиском на Алт+ПринтСцн+Д (мнемоника за отклањање грешака). одмах се сетим Програмерски кључ, што је омогућило оригиналним Мацинтосх програмерима да уђу у програм за отклањање грешака (ако су га имали инсталиран, наравно).

Закључак

Почињем да схватам да софистицираност Хаику система потиче од чињенице да посао обавља један мали тим са јасним фокусом на радно окружење, са доступним свим слојевима система.
Оштар контраст са светом Линук/ГНУ/дпкг/апт/системд/Ксорг/дбус/Гтк/ГНОМЕ/КСДГ/Убунту, где је све разбијено на ситне делове до те мере да апстракција седи на апстракцији и вози штакама.
Постојало је и разумевање како систем .hpkg комбинује најбоље праксе традиционалних менаџера пакета, Снаппи, Флатпак, АппИмаге, чак и бтрфс, и комбинује их са Мац-овим приступом „само ради“.

Као да ми се нешто „пребацило“ у глави и схватио сам како систем .hpkg зна да се откотрља, само гледајући је. Али то нисам ја, већ лепота и једноставност система. Велики део овога је инспирисан духом оригиналног Мац-а.

Да, прегледање у претраживачу може бити трзаво и ради као пуж, апликације можда недостају (нема Гтк, Елецтрон - програмери су закључили да не иду добро са софистицираношћу), видео и 3д убрзање могу бити потпуно одсутни, али ја и даље свиђа овај систем. На крају крајева, ове ствари се могу исправити и оне ће се појавити пре или касније. Само је питање времена и можда мало црвених очију.

Не могу да понудим помоћ, али мислим да ће од сада кренути година Хаикуа на десктопу.

Случајни проблеми

Можда већ има захтева или да их отворим?

• БеСцреенЦаптуре би требало да може да извози у ГИФ као што је Пеек. Ово се може урадити помоћу ффмпег, који је већ доступан за Хаику. Примена.
• Софтвер за снимање екрана не успева да ухвати модални прозор, већ цео екран
• Не можете да исечете снимке екрана користећи ВондерБрусх алатку за исецање, а затим сачувате резултат у датотеку
• Не свиђа ми се посебно ручни курсор у хаикуу, али мислим да има везе са топлим носталгичним осећањем. Ово је посебно неугодно када користите алатку за исецање у Крити, јер доводи до нетачног исецања (погледајте снимке екрана модалних дијалога у овом чланку). Курсор укрштенице би био диван. Примена.

Пробајте сами! На крају крајева, Хаику пројекат обезбеђује слике за покретање са ДВД-а или УСБ-а, генерисане дневно. Да бисте инсталирали, само преузмите слику и запишите је на флеш диск помоћу бакрописац

Имате било каквих питања? Позивамо вас на руско говорење телеграм канал.

Преглед грешке: Како пуцати себи у ногу у Ц и Ц++. Хаику ОС збирка рецепата

Из аутор превод: ово је шести чланак у серији о хаикуу.

Списак чланака: Прво Други трећи Четврто Пети

Извор: ввв.хабр.цом