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

TL; ДР: Хаику е оперативен систем специјално дизајниран за компјутери, па затоа има неколку трикови кои ја прават неговата работна околина многу подобра од другите. Но, како функционира?

Неодамна, Го открив Хаику, неочекувано добар систем. Сè уште сум изненаден од тоа колку непречено работи, особено во споредба со десктоп околините на Linux. Денес ќе погледнам под хаубата. Онаму каде што е потребно за длабинско разбирање, ќе направам споредби со оригиналните Macintosh, Mac OS X и Linux десктоп околини (стандард XDG од freedesktop.org).

Ресурси во датотеките ELF

Вчера дознав дека IconOMatic може да зачувува икони во rdef ресурси во извршните датотеки ELF. Денес сакам да видам како навистина функционира.

Ресурси? Цитат од Брус Хорн, оригиналниот автор на Пронаоѓачот на Мекинтош и „таткото“ на Менаџерот за ресурси на Мекинтош:

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

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

На Mac ова се користи Повторно уредување, графичка програма за - одеднаш - уредување ресурси.

Повторно уредување на оригиналниот Macintosh

Како резултат на тоа, стана можно да се уредуваат икони, ставки од менито, преводи итн. доволно лесно, но сепак „патуваат“ со апликациите.
Во секој случај, овој пристап имаше голем недостаток: работеше само на датотечните системи на Apple, што беше една од причините зошто Apple го напушти „делот за ресурси“ кога се пресели во Mac OS X.
На Mac OS X, Apple сакаше решение независно од датотечниот систем, па го усвоија концептот на пакети (од NeXT), директориуми кои менаџерот на датотеки ги третира како „непроѕирни објекти“, како датотеки наместо директориуми. Било кој пакет со апликација во формат .app има, меѓу другото, досие Info.plist (во некој вид на еквивалент на Apple на JSON или YAML) што содржи метаподатоци за апликацијата.

Копчиња за датотеката Info.plist од пакетот апликации за Mac OS X.

Ресурсите, како што се иконите, датотеките на UI и други, се зачувани во пакетот како датотеки. Концептот всушност се врати на своите корени во NeXT.

Mathematica.app на NeXTSTEP 1.0 во 1989 година: се појавува како директориум со датотеки во терминалот, но како единствен објект во графичкиот менаџер на датотеки.

Да се ​​вратиме на BeOS, концептите на кои се базира Хаику. Неговите развивачи, кога се префрлија од PEF (PowerPC) на ELF (x86) (исто како што се користи на Linux), решија да додадат дел за ресурси на крајот од датотеките ELF. Не користеше сопствен соодветен дел ELF, едноставно беше додаден на крајот од датотеката ELF. Како резултат на програмата strip а други од бинутили, не свесни за ова, едноставно го отсекуваат. Затоа, кога додавате ресурси во датотека ELF на BeOS, подобро е да не манипулирате со алатките на Linux.

Што се случува со Хаику сега? Во суштина, горе-долу истото.

Теоретски, би било можно да се постават ресурси во саканиот дел од ELF. Според програмерите на каналот #haiku на irc.freenode.net:

Со ELF делот би имал повеќе смисла... единствената причина зошто не го правиме тоа на тој начин е затоа што тоа е она што го направивме во BeOS“.
И нема смисла да се менува ова сега.

Менаџирање со ресурси

Ресурсите се напишани во структуриран формат на „ресурси“: во суштина листа на ресурси со големини и потоа нивната содржина. се сетив ar формат.
Како да ги проверите ресурсите во Хаику? Дали има нешто како ResEdit?
Според документација:

За да ги видите ресурсите дадени во пакетот со апликации, можете да ја повлечете извршната датотека на програма како Ресурс. Можете исто така да отидете на терминалот и да ја извршите командата listres имя_файла.

Ресурсерот е достапен во HaikuDepot, но едноставно ми се урива.

Како да управувате со ресурсите во датотеките ELF? Користење на rsrc и rdef. rdef датотеките се собираат во rsrc. Датотека rdef се чува во формат на обичен текст, така што е многу полесно да се работи. Формат на датотека rsrc додадена на крајот од датотеката ELF. Ајде да се обидеме да играме:

~> 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: Тип на апликација MIME, за мапирање на отворени датотеки, стартување, IPC итн.
• app_name_catalog_entry: Бидејќи името на апликацијата обично е на англиски јазик, можете да ги наведете местата каде што се наоѓаат преведените имиња, така што корисниците на различни јазици ќе го видат преведеното име на апликацијата ако сакате.
• app_version: токму она што го мислеше
• app_flags: укажува registrar како да се обработи апликацијата. Мислам дека има повеќе отколку што изгледа. На пример, постои B_SINGLE_LAUNCH, што го принудува системот да стартува нов процес на апликација секој пат кога корисникот ќе го побара (истиот принцип се користи за повеќето апликации на Linux). Јадете B_MULTIPLE_LAUNCH, предизвикувајќи процесот да работи секоја датотека. Конечно постои B_EXCLUSIVE_LAUNCH, што го принудува системот да стартува само еден процес во исто време, без разлика колку често корисниците го стартуваат (на пример, вака работи Firefox на Linux; истиот резултат може да се постигне во Qt апликациите користејќи ја функцијата QtSingleApplication). Апликации со B_EXCLUSIVE_LAUNCH се известуваат кога корисникот ќе се обиде повторно да ги изврши: на пример, ја добиваат патеката на датотеката што корисникот сака да ја отвори со нивна помош.
• vector_icon: Векторска икона за апликација (BeOS немаше векторски икони, наместо тоа, повеќето апликации имаа две растерски икони во нивните извршни датотеки).

Се разбира, можете да додавате ресурси со какви било сакани ID и типови, а потоа да ги прочитате во самата апликација или други апликации користејќи ја класата BResources. Но, прво, да ја погледнеме фасцинантната тема за иконите.

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

Се разбира, не само Хаику го избра најдобриот формат на икони; во овој дел, ситуацијата со десктоп околините на Linux е далеку од идеална:

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

Гледајќи го ова веќе може да почувствувате какво парче е тоа.

Се разбира, постои скалабилно, кое содржи, како што можете да разберете, векторски икони. Зошто тогаш има нешто друго? Бидејќи резултатот од цртање векторски графики во мали димензии може да биде помалку од идеален. Би сакал да имам различни опции оптимизирани за различни големини. Во десктоп околините на Linux, ова се постигнува со расфрлање на икони со различни големини низ датотечниот систем.

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

Ве молиме имајте предвид: не постои концепт на различни верзии на Firefox. Така, не е возможно благодатно да се справиме со ситуацијата кога има повеќе верзии на апликација на системот.

Различни икони на Firefox во различни верзии. Во моментов е невозможно да се справи со ова во Linux без разни патерици.

Mac OS X се справува со тоа малку посуптилно:

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, што ги содржи сите големини, така што различните верзии на истата апликација имаат различни икони.
Многу подобро! Иконите патуваат со апликацијата, сите ресурси се во една датотека.

Да се ​​вратиме на Хаику. Воодушевувачко решение, без исклучоци. Според документација:

Беше развиен специјален формат HVIF, високо оптимизиран за мали димензии и брзо прикажување. Затоа, нашите икони во најголем дел се многу помали отколку во растер или во широко користениот SVG формат.

И тие сè уште се оптимизирани:

Големините на иконите во HVIF во споредба со другите формати.

Разликата е ред на големина!

Но, магијата не завршува тука. Истиот HVIF може да прикаже различни нивоа на детали во зависност од прикажаната големина, иако е векторски формат.

Различни нивоа на детали (LOD) во зависност од големината на рендерот

Сега за недостатоците: не можете да земете SVG, да го фрлите во ImageMagick и да го наречете еден ден; треба да поминете низ неколку циклуси за да креирате икона во формат HVIF. Тука објаснувања. Сепак, IconOMatic може да увезе SVG сосема несовршено; околу 90% од деталите за SVG се увезуваат со одредена веројатност, а останатите 10% ќе треба да се конфигурираат и променат рачно. Прочитајте повеќе за тоа како HVIF ја прави својата магија некој може да во блогот Леа Гансон

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

Сега можам да додадам икона во креираниот пакет последен пат, земајќи ги предвид сите добиени информации.
Па, бидејќи не сум особено желен да нацртам своја икона за мојата „Здраво, свет“ QtQuickApp во моментов, ја повлекувам од Qt Creator.

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

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

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

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

Копираниот VICN:101:BEOS:ICONs сè уште не се користи како икона за апликација во менаџерот на датотеки

Што пропуштив?

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

Треба да создадеме датотека rdef со сите ресурси, а потоа извршете ја командата rc имя.rdef, ова ќе ја создаде датотеката .rsrc. Потоа треба да ја извршите командата resattr -o имя_бинарника имя.rsrc. Во најмала рака, користам команди како овие за да додавам икони на моите скрипти.

Па, сакав да создадам ресурс, а не атрибут. Навистина сум збунет.

Паметно кеширање со користење на датотечен систем

Отворањето и читањето на атрибутите на ELF е бавно. Како што напишав погоре, иконата е напишана како ресурс во самата датотека. Овој метод е посигурен и ви овозможува да преживеете копирање во друг датотечен систем. Сепак, тој потоа се копира и на атрибутот датотечен систем, на пример BEOS:ICON. Ова работи само на одредени датотечни системи, како што е BFS. Иконите прикажани од системот (во Tracker и Deskbar) се читаат од овој проширен атрибут, бидејќи ова решение работи брзо. На некои места (каде што брзината не е важна, на пример, типичен прозорец „За“), системот ја прима иконата директно од ресурсот во датотеката. Но, ова не е крајот. Запомнете, на Mac, корисниците можеа да ги заменат иконите на апликации, директориуми, документи со свои, бидејќи на Mac е можно да се прават овие „важни“ работи, на пример заменувајќи нова Slack икона со претходната. На Хаику, треба да го замислите ресурсот (во датотеката) како оригиналната икона што доаѓа со апликацијата, а атрибутот (во датотечниот систем BFS) како нешто што му овозможува на корисникот да прави промени по желба (иако, навестување, графичкиот интерфејс за вметнување приспособена икона на врвот на иконата е опционален).се уште не е стандардно имплементиран).

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

Со 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. Не ве залажува едноставното име: форматот .hpkg работи сосема поинаку од другите формати со слични имиња што сте ги сретнале, тој има вистински супермоќи.

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

Работам на проектот AppImage, делумна патерица за апликации за крајни корисници. Ова е формат на дистрибуција на софтвер кој собира апликација и сите нејзини зависности во една слика на датотечен систем што се монтира кога ќе стартува апликацијата. Значително ги поедноставува работите, бидејќи истиот ImageMagick одеднаш се претвора во една датотека, управувана во менаџер на датотеки од обични смртници. Предложениот метод работи само за софтвер, како што се гледа во името на проектот, а исто така има и свои проблеми, бидејќи луѓето вклучени во испораката на софтвер за Linux секогаш ја вперуваат стрелката кон мене.

Да се ​​вратиме на Хаику. Дали беше можно да се најде оптимална рамнотежа помеѓу традиционалните системи на пакети и испораката на софтвер базирана на слики? Нејзините пакети .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"

Содржи многу минималистички оперативен систем, вклучувајќи го и кернелот. Верувале или не, дури и самиот кернел не се отстранува од волуменот за подигање (root партиција), туку е внимателно вчитан на своето место од пакетот .hpkg. Леле! Веќе спомнав дека мислам дека дел од севкупната софистицираност и конзистентност на Хаику произлегува од фактот што целиот систем, од кернелот и основниот кориснички простор до управувањето со пакети и инфраструктурата за време на траење, е развиен заеднички од еден тим. Замислете колку различни групи и тимови би биле потребни за да се изврши вакво нешто на Linux [Го замислувам проектот PuppyLinux - прибл. преведувач]. Потоа замислете колку време ќе биде потребно за овој пристап да се примени во дистрибуциите. Велат: земете едноставен проблем, поделете го на различни изведувачи и тој ќе стане толку комплициран што веќе нема да може да се реши. Хаику во овој случај ми ги отвори очите. Мислам дека ова е токму она што се случува на Linux сега (Linux во овој случај е колективен термин за стекот Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Враќање на системот со помош на hpkg

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

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

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

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

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

Преземач на хаику. Секоја влезна точка прикажува соодветна „активна состојба“

Ми се допаѓа пристапот да има едноставни текстуални датотеки како список на „активна состојба“, со имиња што се лесно разбирливи .hpkg. Ова е во целосна спротивност со тоа што е создаден за машини-не-за-луѓе. во еден куп од OSTree или Flatpak во датотечниот систем (на исто ниво како Microsoft GUID).

Список на активни пакети за секоја точка во времето

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

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

Интеграција на GUI за .hpkg систем

Ајде сега да видиме како овие сјајни чанти .hpkg да се справат со интеграцијата во работната средина на корисникот (UX). На крајот на краиштата, Хаику е наменет за лична употреба. Лично, ја поставив лентата високо кога го споредувам корисничкото искуство со пакетите .app на Macintosh со истото искуство на .hpkg. Нема ни да ја споредувам ситуацијата со работните средини на Linux, бидејќи е апсолутно страшна во споредба со сите други.

Следниве сценарија ми доаѓаат на ум:

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

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

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

На Mac Едноставно кликнете со десното копче на пакетот за да го отворам и да ја прегледам содржината во Finder. На крајот на краиштата, во реалноста тоа е само маскиран директориум! (Знам дека има пакети .pkg за дел од системот кој не е апликации, туку обичните корисници најчесто не комуницираат со нив).

На хаику Десен клик на пакетот, а потоа кликнувам на „Содржина“ за да видам што има внатре. Но, тука е само список на датотеки без можност да се отворат со двоен клик.
Многу подобро би било кога би имало начин за (привремено) монтирање на пакувањето .hpkg да се гледа преку менаџер на датотеки и корисникот нема да мора да се грижи за деталите за имплементацијата. (Патем, можете да отворите .hpkg пакет во Expander, што може да го отпакува како и секоја друга архива).

Интерфејсот на HaikuDepot ви овозможува да прегледате листа на датотеки со пакети, но не постои начин да ја видите содржината со, на пример, двоен клик на README.md

Mac победи во оваа категорија, но додавањето на функционалноста на HaikuDepot што ја сакате не треба да биде премногу тешко.

Инсталирање пакет преку GUI

На Mac, повеќето слики од дискот .dmg содржат пакувања .app. Кликнете двапати на сликата на дискот и потоа копирајте го пакетот, на пример, со влечење во него /Applications во Пронаоѓач. Ова се подразбира за мене, но слушнав дека некои почетници можеби нема да можат да се справат со ова. Стандардно, Apple „предлага“ директориум низ целиот систем /Applications (на NeXT беше мрежен како и индивидуален), но лесно можете да ги ставите вашите апликации на сервер за датотеки или во поддиректориум $HOME/Applications, ако ти се допаѓа така.

На хаику, кликнете двапати на пакетот, потоа кликнете на „Инсталирај“, не може да биде полесно. Се прашувам што ќе се случи ако пакетот има зависности што се достапни во HaikuPorts, но сè уште не се инсталирани. На Linux тие навистина не знаат што да прават во оваа ситуација, но решението е очигледно - прашајте го корисникот дали треба да презема и инсталира зависности. Токму она што го прави Хаику.

Рачно го преземав пакетот „разумност“ и кликнав на него, менаџерот на пакети знае од каде да ги добие своите зависности (под претпоставка дека складиштата се веќе регистрирани на системот). Не секоја дистрибуција на Линукс може да го стори тоа.

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

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

Отстранување пакет од GUI

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

На хаику, прво, треба да пронајдете каде се наоѓа пакетот на системот, бидејќи ретко го инсталирате на вистинското место (системот прави сè). Обично треба да погледнете внатре /Haiku/system/packages (со стандардна инсталација на целиот систем), или во /Haiku/home/config/packages (Дали спомнав дека „config“ е погрешно име?). Потоа апликацијата едноставно се влече во корпата за отпадоци, и тоа е тоа.
Лесно! Сепак, не би го рекол тоа. Еве што навистина се случува:

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

Само што се обидов да ја преместам мојата вчерашна апликација „Hello World“ на QtQuickApp во ѓубрето. Не се обидов да го преместам системскиот директориум, и бидејќи сите пакети се инсталирани во системскиот директориум, невозможно е да се отстрани пакетот .hpkg без промена „неговата содржина“. Обичен корисник ќе се исплаши и ќе го притисне копчето „Откажи“ стандардно доделено.

Објаснува г. прскање:

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

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

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

Ова се случува ако се обидете да инсталирате веќе инсталиран пакет.

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

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

Претпоставувам дека ова е софтверска грешка; врската до апликацијата е веќе таму. [авторот не даде врска - прибл. преведувач]

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

Кога ја гледам листата на пакети инсталирани во HaikuDepot, го гледам мојот пакет во списокот и можам да го отстранам.

Mac победи во оваа категорија. Но, можам да замислам дека со соодветно поставување, корисничкото искуство на Хаику ќе биде подобро отколку на Mac. (Еден од програмерите го оцени вака: „Помалку од еден час за додавање на наведената функционалност на HaikuDepot, ако знаете малку C++“, дали има волонтери?)

Отстранување нешто од пакетот

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

На Mac, корисникот всушност обично работи со датотеката .dmgод каде доаѓа пакетот за апликација .app. Обично слики .dmg се акумулираат во директориумот за преземања, а пакетите се копирани од корисникот во /Applications. Се верува дека многу корисници самите не знаат што прават, оваа хипотеза ја потврдува поранешен вработен во Apple. (Една од работите што не ми се допаѓаат на Mac. И, на пример, со AppImage нема разлика помеѓу апликацијата и пакетот во кој беше. Повлечете ја иконата во корпата за отпадоци = тоа е тоа. Лесно!)

На хаику, постои и поделба меѓу apps/ и packages/, па се сомневам дека ова им го направи појасно на корисниците. Но, што се случува ако повлечете апликација од apps/ Додади го во кошничка:

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

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

Брзо решение: наместо тоа, предложете користење на GUI за бришење .hpkg

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

Никој не победи во оваа категорија освен AppImage (но ова, да бидам целосно искрен, е пристрасно мислење). Сепак, може да се замисли дека по дотерување, корисничкото искуство на Хаику ќе биде подобро отколку на Mac.

Забелешка: треба да откриете што е „том“ во однос на „дел“. Ова веројатно е слично на односот „папка“ со „директориум“: повеќето директориуми се појавуваат како папки во менаџерот на датотеки, но не сите од нив (пакетите третирани како датотеки, на пример). Дали овој вид на прикажување ме прави официјален нерд?

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

На Mac, глупаво го влечам пакетот .app, и бидејќи зависностите се внатре во пакетот, тие се движат заедно.

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

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

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

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

Не секоја машина е постојано поврзана на мрежата. Напротив, некои машини (да, те гледам тебе, модерни Windows, Mac и Linux) забораваат на ова. За мене е важно да одам, на пример, во интернет кафе, да преземам софтвер на отстранлив диск, да го вметнам овој диск во мојот домашен компјутер и да бидам сигурен дека сè ќе работи [ризично момче, правејќи го ова на Windows... - прибл. преведувач].

Како резултат на тоа, имам тенденција да завршувам со неисполнети зависности од Windows и Linux малку почесто од вообичаеното.

На Mac ова е обично една датотека, сè што треба да направите е да преземете .dmg. Најчесто, нема други зависности освен оние што ги обезбедува самиот MacOS стандардно. Исклучок се сложените апликации кои бараат соодветна средина за извршување, на пример java.

На хаику преземете пакет .hpkg за, да речеме, истата апликација во java, можеби не е доволна, бидејќи Java може или не може да биде присутна на целната машина. Дали постои начин да се преземат сите зависности за даден пакет .hpkg, освен оние што се стандардно инсталирани во Хаику и затоа треба да бидат на секој хаику систем?

Mac победи во оваа категорија со мала разлика.

Коментари г. прскање со вода:

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

Да го задржиме здивот до следната статија од оваа серија.

Преместување на пакети на посебна локација

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

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

На хаику, како што ми беше кажано, тоа може да се постигне со поместување на мојот .hpkg пакети на отстранлив диск или мрежен директориум, но потоа треба да користите некои недокументирани команди во конзолата за да ги монтирате на системот. Не знам како да го направам ова користејќи само GUI.

Mac победи во оваа категорија.

Според г. прскање со вода:

Ова е оптимизација заснована на нормална употреба. Доколку има побарувачка од повеќе од еден корисник, ние ќе ја имплементираме. Во секој случај, постои можност за имплементација од трета страна.

Ќе зборуваме за ова во следната статија.

Зборувајќи за мрежните директориуми, би било одлично (претпоставувам LAN партии) да имате едноставни, откриени, мрежни апликации (како Zeroconf) кои можат да се копираат на локалниот компјутер или да работат директно од локалната мрежа. Се разбира, програмерите имаат можност да се откажат преку app_flags.

Финален извештај за интеграцијата на hpkg системот со GUI

Мислам дека тоа пред се поради релативната новост на интеграцијата .hpkg GUI сè уште остава многу да се посакува. Како и да е, има неколку работи кои би можеле да се подобрат во однос на UX...

Уште една работа: Земја за отстранување грешки на кернелот

Би било одлично да можете да внесувате команди за време на паника на кернелот, на пример syslog | grep usb. Па, на Хаику тоа е можно благодарение на земјиштето за отстранување грешки на кернелот. Како можете да ја видите оваа магија на дело ако сè работи како што треба без да влезете во паника на јадрото? Лесно со притискање на Alt+PrintScn+D (Дебагирајте мнемоник). Веднаш се сеќавам Програмерски клуч, што им овозможи на оригиналните развивачи на Macintosh да влезат во дебагерот (ако некој е инсталиран, се разбира).

Заклучок

Почнувам да разбирам дека софистицираноста на системот Хаику доаѓа од фактот што работата ја извршува еден мал тим со јасен фокус на работната средина, со достапни сите слоеви на системот.
Остар контраст со светот на Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, каде што сè е скршено на мали парчиња до таа мера што апстракцијата седи на апстракција и вози со патерици.
Имаше и разбирање за тоа како системот .hpkg ги комбинира најдобрите практики на традиционалните менаџери на пакети, Snappy, Flatpak, AppImage, дури и btrfs, и ги спојува со пристапот „само функционира“ на Mac.

Како нешто да ми се „префрли“ во главата и сфатив како е системот .hpkg знае да се оттргне, само гледајќи во неа. Но, тоа не сум јас, туку убавината и едноставноста на системот. Голем дел од ова е инспирирано од духот на оригиналниот Mac.

Да, прелистувањето во прелистувачот може да биде откачено и да работи како полжав, може да недостасуваат апликации (нема Gtk, Electron - програмерите заклучија дека не одат добро со софистицираноста), видеото и 3d забрзувањето може да бидат целосно отсутни, но јас сè уште ми се допаѓа овој систем. На крајот на краиштата, овие работи можат да се поправат и тие ќе се појават порано или подоцна. Тоа е само прашање на време, а можеби и малку црвенило.

Не можам да понудам помош, но мислам дека од сега ќе почне година на Хаику на десктоп.

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

Можеби веќе има барања или да ги отворам?

• BeScreenCapture треба да може да извезува во GIF како Peek. Ова може да се направи со користење на ffmpeg, веќе достапен за Хаику. Апликација.
• Софтверот за слики од екранот не успева да сними модален прозорец, наместо да го сними целиот екран
• Не можете да исечете слики од екранот користејќи ја алатката за сечење на WonderBrush и потоа да го зачувате резултатот во датотека
• Не ми се допаѓа особено рачниот курсор во Хаику, но мислам дека има врска со топлото носталгично чувство. Ова е особено досадно кога се користи алатката за сечење во Krita, бидејќи резултира со неточно сечење (видете слики од екранот на модалните дијалози во оваа статија). Курсорот за вкрстување би бил прекрасен. Апликација.

Пробајте го сами! На крајот на краиштата, проектот Хаику обезбедува слики за подигање од ДВД или USB, генерирани секојдневно. За да инсталирате, само преземете ја сликата и напишете ја на флеш-уред користејќи ја Етчер

Дали имате прашања? Ве покануваме на рускиот јазик телеграмски канал.

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

Од авторот превод: ова е шеста статија од серијата за Хаику.

Список на статии: Првиот Вториот Третиот Четврто Петтиот

Извор: www.habr.com