Хайку менен болгон алтынчы күнүм: ресурстардын, иконалардын жана пакеттердин астында

Хайку менен болгон алтынчы күнүм: ресурстардын, иконалардын жана пакеттердин астында

TL; DR: Хайку - бул атайын компьютерлер үчүн иштелип чыккан операциялык система, ошондуктан анын иш тактасынын айланасын башкаларга караганда бир топ жакшыраак кылган бир нече амалдары бар. Бирок ал кантип иштейт?

жакында Мен Хайку, күтүлбөгөн жакшы системаны ачтым. Мен дагы эле анын канчалык жылмакай иштегенине таң калам, айрыкча Linux рабочий чөйрөлөрүнө салыштырмалуу. Бүгүн мен капоттун астын карап көрөм. Терең түшүнүү үчүн зарыл болгон учурда, мен баштапкы Macintosh, Mac OS X жана Linux рабочий чөйрөлөрү (freedesktop.org сайтынан XDG стандарты) менен салыштырам.

ELF файлдарындагы ресурстар

Кечээ мен IconOMatic ELF аткарылуучу файлдарындагы rdef ресурстарындагы иконаларды сактай аларын билдим. Бүгүн мен анын чындыгында кандай иштээрин көргүм келет.

Ресурстар? эсептөө от Брюс Хорн, Macintosh Finderдин түпнуска автору жана Macintosh Ресурс менеджеринин "атасы":

Мен салттуу коддоонун катаал табиятынан кооптонуп жатам. Мен үчүн, эч нерсени динамикалык түрдө өзгөртүү мүмкүнчүлүгү жок, коддо тоңдурулган тиркеме идеясы - эң жапайычылык. Иш учурунда мүмкүн болушунча өзгөртүүгө мүмкүн болушу керек. Албетте, колдонмонун кодун өзгөртүү мүмкүн эмес, бирок кодду кайра түзбөстөн бир нерсени өзгөртүүгө болобу?

Түпнуска Macintosh'то алар бул файлдарды "маалыматтар бөлүмү" жана "ресурстук бөлүмү" бар кылып, иконалар, котормолор жана ушул сыяктуу нерселерди сактоону укмуштуудай жеңилдеткен. аткарылуучу файлдарда.

Macта бул колдонулат ResEdit, графикалык программа - капысынан - түзөтүү ресурстары.

Хайку менен болгон алтынчы күнүм: ресурстардын, иконалардын жана пакеттердин астында
Оригиналдуу Macintoshто ResEdit

Натыйжада, иконаларды, меню пункттарын, котормолорду ж.б. түзөтүү мүмкүн болду. жетиштүү жеңил, бирок алар дагы эле колдонмолор менен "саякат".
Кандай болгон күндө да, бул ыкманын чоң кемчилиги бар эле: ал Apple файлдык тутумдарында гана иштеген, бул Apple Mac OS Xге өткөндө "ресурстук бөлүмдөн" баш тартканынын себептеринин бири болгон.
Mac OS Xде Apple файл тутумунан көз карандысыз чечимди каалашкан, ошондуктан алар пакеттер (NeXTден) концепциясын кабыл алышкан, алар каталогдорго караганда файлдар сыяктуу файл менеджери тарабынан "ачык эмес объекттер" катары каралат. Форматта тиркеме менен каалаган пакет .app башка нерселер менен катар, бир файл бар Info.plist (Apple'дин JSON же YAML эквивалентинде) колдонмонун метадайындарын камтыган.

Хайку менен болгон алтынчы күнүм: ресурстардын, иконалардын жана пакеттердин астында
Mac OS X колдонмо пакетинен Info.plist файлынын ачкычтары.

Пиктограммалар, UI файлдары жана башкалар сыяктуу ресурстар пакетте файлдар катары сакталат. Концепция чындыгында NeXTдеги түп тамырына кайтып келген.

Хайку менен болгон алтынчы күнүм: ресурстардын, иконалардын жана пакеттердин астында
1.0-жылы NeXTSTEP 1989 боюнча Mathematica.app: терминалдагы файлдардын каталогу катары, бирок графикалык файл башкаргычында бир объект катары көрүнөт.

Келгиле, Хайку негизделген концепцияларга, BeOSка кайрылып көрөлү. Анын иштеп чыгуучулары PEFден (PowerPC) ELFге (x86) которулганда (Linux'та колдонулгандай), ELF файлдарынын аягына ресурс бөлүмүн кошууну чечишкен. Ал өзүнүн туура ELF бөлүмүн колдонгон эмес, ал жөн гана ELF файлынын аягына тиркелген. Программанын натыйжасында strip Бинутилдерден жана башкалар муну билишпейт, жөн эле кесип салышат. Ошондуктан, BeOS боюнча ELF файлына ресурстарды кошуп жатканда, аны Linux шаймандары менен башкарбаганыңыз жакшы.

Хайку азыр эмне болуп жатат? Негизинен аздыр-көптүр бирдей.

Теориялык жактан алганда, ELF каалаган бөлүмгө ресурстарды жайгаштыруу мүмкүн болмок. irc.freenode.net сайтындагы #haiku каналындагы иштеп чыгуучулардын айтымында:

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'тун вектордук иконалар болгон эмес, анын ордуна көпчүлүк тиркемелерде алардын аткарылуучу файлдарында эки растрдык иконалар болгон).

Албетте, сиз каалаган идентификаторлор жана түрлөр менен ресурстарды кошуп, анан аларды колдонмонун өзүндө же класстын жардамы менен башка тиркемелерде окуй аласыз. 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ди жетишсиз түрдө импорттой алат; SVG деталдарынын болжол менен 90% кандайдыр бир ыктымалдуулук менен импорттолот, калган 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 сыяктуу белгилүү бир файл системаларында гана иштейт. Система көрсөткөн иконалар (Трекерде жана Иш тактасында) ушул кеңейтилген атрибуттан окулат, анткени бул чечим тез иштейт. Кээ бир жерлерде (тездик маанилүү эмес, мисалы, типтүү "Жөнүндө" терезеси) система сүрөтчөнү түздөн-түз файлдагы ресурстан алат. Бирок бул аягы эмес. Эсиңизде болсун, Mac'те колдонуучулар тиркемелердин, каталогдордун, документтердин сөлөкөттөрүн өздөрүнө алмаштыра алышат, анткени Mac'та бул "маанилүү" нерселерди жасоого болот, мисалы жаңы Slack сөлөкөтүн мурункуга алмаштыруу. Хайкуда сиз ресурсту (файлдагы) тиркеме менен келген оригиналдуу сөлөкөт, ал эми атрибутун (BFS файл тутумунда) колдонуучуга каалагандай өзгөртүү киргизүүгө мүмкүндүк берүүчү нерсе деп ойлошуңуз керек (бирок, кыйытма, иконканын үстүнө ыңгайлаштырылган сөлөкөтүн киргизүү үчүн GUI милдеттүү эмес). демейки боюнча азырынча ишке ашырыла элек).

Файл системасынын атрибуттары текшерилүүдө

Жардамы менен 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 негизиндеги системада оңой эле бир нече жүз миңден миллиондогон жеке файлдар болушу мүмкүн. Айта кетчү нерсе, бул морт жана жай, мисалы, системаны адегенде орнотуп жатканда, кадимки пакеттерди орнотууда, жаңыртууда жана алып салууда жана жүктөө көлөмүн (тамыр бөлүмү) башка алып жүрүүчүгө көчүрүүдө.

Мен 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"

Ал абдан минималисттик операциялык системаны, анын ичинде ядрону камтыйт. Ишенсеңер же ишенбейсиңерби, атүгүл ядронун өзү жүктөө көлөмүнөн (тамыр бөлүмү) алынып салынбайт, бирок пакеттен өз ордуна кылдат жүктөлөт. .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. “Стат...” каталогдорунда активдүү пакеттердин аттары жазылган тексттик файлдар, ал эми “транзакция...” каталогдорунда пакеттердин өздөрү камтылган.

"Эски активдүү абал", б.а. тизме .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 окуу үчүн гана орнотулган. Ошентип, бул файлдарды жазуудан мурун пакеттерден көчүрүү керек. Мааниси бар.

.hpkg системасы үчүн GUI интеграциясы

Эми бул жалтырак баштыктарды карап көрөлү .hpkg колдонуучунун иш чөйрөсүнө (UX) интеграциялоо менен күрөшүү. Кантсе да, Хайку жеке колдонуу үчүн арналган. Жеке мен колдонуучунун тажрыйбасын пакеттерге салыштырганда тилкени жогору койдум .app Macintosh боюнча ошол эле тажрыйба менен .hpkg. Мен абалды Linuxтагы иштөө чөйрөлөрү менен салыштырбайм, анткени бул башкаларга салыштырмалуу абдан коркунучтуу.

Төмөнкү сценарийлер эске келет:

  • Мен пакеттин мазмунун көргүм келет .hpkg
  • Мен пакетти орноткум келет
  • Мен пакетти алып салгым келет
  • Мен пакеттин бир бөлүгү катары тутумга кирген нерсени алып салгым келет
  • Мен пакеттин бир бөлүгү катары тутумга келген нерсени көчүрүп алгым келет
  • Мен пакеттин бардык көз карандылыктарын жүктөп алгым келет, ал ар бир Хайку орнотуусунун бир бөлүгү болбошу мүмкүн (мисалы, менде интернетке кирүү мүмкүнчүлүгү жок физикалык жактан обочолонгон машина бар.)
  • Мен пакеттеримди (же алардын бир бөлүгүн) жүктөө көлөмүнөн (тамыр бөлүгүнөн) өзүнчө башка жерге жылдыргым келет (анткени, мисалы, менде жетиштүү орун жок).

Бул менин күнүмдүк жумушумдан баштап негизги иштердин көбүн камтышы керек. Мейли, баштайлы.

Пакеттин мазмунун текшерүү

Mac'те Мен жөн гана пакетти оң баскыч менен чыкылдатып, аны ачып, Finderдеги мазмунду көрөм. Анткени, чындыгында бул жөн гана жашырылган каталог! (Мен пакеттер бар экенин билем .pkg тутумдун тиркемелер эмес бөлүгү үчүн, бирок жөнөкөй колдонуучулар көбүнчө алар менен иштешпейт).

Хайку боюнча Мен пакетти оң баскыч менен чыкылдатып, анын ичинде эмне бар экенин көрүү үчүн "Мазмуну" дегенди басыңыз. Бирок бул жерде эки жолу чыкылдатуу менен аларды ачуу мүмкүнчүлүгү жок файлдардын тизмеси.
Пакетти (убактылуу) орнотуунун жолу болсо жакшы болмок .hpkg файл менеджери аркылуу көрүүгө болот жана колдонуучу ишке ашыруунун чоо-жайы жөнүндө тынчсыздануунун кереги жок. (Баса, сиз ача аласыз .hpkg пакетте Expander, аны башка архивдер сыяктуу ача алат).

Хайку менен болгон алтынчы күнүм: ресурстардын, иконалардын жана пакеттердин астында
HaikuDepot интерфейси пакет файлдарынын тизмесин көрүүгө мүмкүндүк берет, бирок, мисалы, README.md эки жолу чыкылдатуу менен мазмунду көрүүнүн жолу жок.

Mac бул категорияда утат, бирок сиз каалаган HaikuDepot функциясын кошуу өтө кыйын болбошу керек.

GUI аркылуу пакетти орнотуу

Mac'те, көпчүлүк диск сүрөттөр .dmg пакеттерди камтыйт .app. Дисктин сүрөтүн эки жолу чыкылдатып, анан пакетти көчүрүңүз, мисалы, аны сүйрөө менен /Applications Finder ичинде. Бул мен үчүн айтпаса да түшүнүктүү, бирок кээ бир жаңы келгендер муну көтөрө алышпайт деп уктум. Демейки боюнча, Apple тутумдук каталогду "сунуштайт" /Applications (NeXTде бул тармактык, ошондой эле жеке эле), бирок сиз өзүңүздүн тиркемелериңизди файл серверине же подкаталогуна оңой эле кое аласыз. $HOME/Applications, эгер сизге ушундай жакса.

Хайку боюнча, пакетти эки жолу чыкылдатып, андан кийин "Орнотуу" баскычын чыкылдатыңыз, бул оңой болушу мүмкүн эмес. Эгер пакетте HaikuPortsто бар, бирок али орнотула элек көз карандылыктар болсо, эмне болот деп ойлоп жатам. Linux'та алар бул кырдаалда эмне кыларын билишпейт, бирок чечим айкын - колдонуучудан көз карандылыкты жүктөп алып, орнотуу керекпи деп сураңыз. Дал Хайку эмне кылат.

Хайку менен болгон алтынчы күнүм: ресурстардын, иконалардын жана пакеттердин астында
Мен "санитет" топтомун кол менен жүктөдүм жана аны чыкылдаттым, пакет менеджери анын көз карандылыгын кайдан алууну билет (эгер репозиторийлер системада катталган болсо). Ар бир Linux дистрибуциясы муну жасай албайт.

Дагы бир жолу - файл менеджерин колдонуу, жөн гана сүйрөп барып таштоо .hpkg пакет же ичинде /Haiku/system/packages (жалпы тутум боюнча орнотуу үчүн, демейки боюнча) же ичинде /Haiku/home/config/packages (жеке орнотуу үчүн; эки жолу басканда жеткиликтүү эмес - мен дагы эле бул жерде "конфигурация" деген сөздүн кыжырын келтирип жатам, бул учурда мен үчүн "орнотуулар" менен синоним болуп саналат). Ал эми бир нече колдонуучу концепциясы али Хайку үчүн жеткиликтүү эмес (ошондуктан, балким, бул абдан жөнөкөй - мен билбейм, балким, көп колдонуучу мүмкүнчүлүктөрү рабочий столдун чөйрөсү үчүн нерселерди керексиз татаалдаштырышы мүмкүн).

Хайку бул категорияда жеңишке ээ, анткени ал тиркемелер менен гана эмес, системалык программалар менен да иштей алат.

GUIден пакетти алып салуу

Mac'те, сиз тиркеменин сөлөкөтүн таштанды челекине сүйрөөңүз керек жана ушуну менен бүттү. Оңой!

Хайку боюнча, биринчиден, пакет тутумда кайда жайгашканын табышыңыз керек, анткени сиз аны туура жерге сейрек орнотосуз (система баарын жасайт). Адатта, сиз киришиңиз керек /Haiku/system/packages (система боюнча демейки орнотуу менен) же ичинде /Haiku/home/config/packages (Мен "конфигурация" туура эмес аталыш экенин айттымбы?). Андан кийин тиркеме жөн эле таштанды челекке сүйрөп кетет, ушуну менен.
Оңой! Бирок, мен муну айтпайт элем. Бул жерде чынында эмне болуп жатат:

Хайку менен болгон алтынчы күнүм: ресурстардын, иконалардын жана пакеттердин астында
Эгер сиз тиркемени таштанды челекине сүйрөп барсаңыз, ушундай болот /Haiku/system/packages

QtQuickApp'тагы кечээки "Hello World" тиркемесин таштандыга жылдырууга аракет кылдым. Мен система каталогун жылдырууга аракет кылган жокмун, жана бардык пакеттер система каталогуна орнотулгандыктан, пакетти алып салуу мүмкүн эмес .hpkg өзгөрүүсүз "анын мазмуну". Жөнөкөй колдонуучу коркуп, демейки боюнча дайындалган "Жокко чыгаруу" баскычын басып калат.

түшүндүрөт мырза waddlesplash:

Бул пост 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 бул категорияда бир аз айырма менен жеңишке жетти.

Комментарийлер Mr. waddlesplash:

Колдонмонун бардык көз карандылыктарын пакеттердин жыйындысы катары чогултуу үчүн программа жазуу .hpkg Хайкунун ички иштерин жакшы билген адам үчүн 15 мүнөт жетиштүү. Эгер чындап муктаждык бар болсо, бул колдоону кошуу анчалык деле кыйын эмес. Бирок мен үчүн бул сейрек кездешүүчү жагдай.

Бул сериянын кийинки макаласына чейин демибизди кармайлы.

Пакеттерди өзүнчө жерге жылдыруу

Мен мурда жазгандай, мен пакеттеримди жайгаштыргым келет .hpkg (жакшылык, же алардын бир бөлүгү) жүктөө көлөмү боюнча кадимки жайгаштыруудан өзүнчө, өзгөчө жерге (тамыр бөлүмү). Кадимки (анчалык теориялык эмес) учурда, мунун себеби, мен канчалык чоң болсо да, менин (курулган) дисктеримде бош орун жок болуп калам. Мен көбүнчө тышкы дисктерди же менин тиркемелерим жайгашкан тармак бөлүшүүлөрүн туташтырам.

Mac'те Мен жөн гана пакеттерди жылдырып жатам .app Finderдеги алынуучу дискке же тармак каталогуна, ушуну менен. Мен дагы эле тиркемени ачуу үчүн эки жолу чыкылдата алам, адаттагыдай эле жүктөө көлөмүнөн. Жөн гана!

Хайку боюнча, мага айтылгандай, бул менин көчүрүү менен жетишүүгө болот .hpkg пакеттерди алынуучу дискке же тармак каталогуна орнотуңуз, бирок андан кийин аларды тутумга орнотуу үчүн консолдогу кээ бир документтештирилбеген буйруктарды колдонушуңуз керек. Мен муну бир гана GUI аркылуу кантип жасоону билбейм.

Бул категорияда Mac утат.

мырзанын айтымында. waddlesplash:

Бул кадимки колдонууга негизделген оптималдаштыруу. Эгер бир нече колдонуучудан суроо-талап болсо, биз аны ишке ашырабыз. Кандай болгон күндө да, үчүнчү жактын ишке ашыруу мүмкүнчүлүгү бар.

Бул тууралуу кийинки макалада сүйлөшөбүз.

Тармактык каталогдор жөнүндө сөз кыла турган болсок, локалдык компьютерге көчүрүлө турган же түз эле жергиликтүү тармактан иштей турган жөнөкөй, табыла турган, жалпы тармактык тиркемелер (Zeroconf) болсо жакшы болмок (менимче LAN тараптары). Албетте, иштеп чыгуучулар аркылуу баш тартуу мүмкүнчүлүгү бар app_flags.

hpkg системасын GUI менен интеграциялоо боюнча жыйынтыктоочу отчет

Бул биринчи кезекте интеграциянын салыштырмалуу жаңылыгына байланыштуу деп ойлойм .hpkg GUI дагы эле каалаган нерсени калтырат. Кандай болбосун, UX жагынан жакшырта турган бир нече нерселер бар ...

Дагы бир нерсе: Kernel Debug Land

Мисалы, ядро ​​​​паника учурунда буйруктарды киргизе алуу сонун болмок syslog | grep usb. Ооба, Хайкуда бул Kernel Debug Land аркасында мүмкүн. Эгер баары өз убагындагыдай иштесе, өзөктүк дүрбөлөңгө түшпөстөн, бул сыйкырды кантип көрүүгө болот? 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 Peek сыяктуу GIFке экспорттой алат. Бул ffmpeg аркылуу жасалышы мүмкүн, буга чейин Хайку үчүн жеткиликтүү. арыз.
  • Скриншот программасы модалдык терезени тарта албайт, анын ордуна бүт экранды басып алат
  • WonderBrush'тун кесүү куралы менен скриншотторду кесип алып, натыйжаны файлга сактай албайсыз
  • Мага Хайкудагы кол курсору өзгөчө жаккан жок, бирок бул жылуу ностальгиялык сезимге байланыштуу деп ойлойм. Бул өзгөчө Критадагы кесүү куралын колдонууда тажатма, анткени ал туура эмес кесүүгө алып келет (бул макаладагы модалдык диалогдордун скриншотторун караңыз). Кайчылаш курсор сонун болмок. арыз.

Өзүңүз байкап көрүңүз! Анткени, Хайку долбоору түзүлгөн DVD же USB жүктөө үчүн сүрөттөрдү камсыз кылат ежедневно. Орнотуу үчүн, жөн гана сүрөттү жүктөп алып, флэш-дискке жазыңыз Etcher

Суроолоруңуз барбы? Сиздерди орус тилдүү окууга чакырабыз телеграмма каналы.

Катага сереп салуу: C жана C++ тилдеринде бутуңузга кантип ок атуу керек. Haiku OS рецепт жыйнагы

чейин жазуучу котормо: бул Хайку жөнүндө сериянын алтынчы макаласы.

Макалалардын тизмеси: биринчи экинчи үчүнчү Төртүнчү Бешинчи

Source: www.habr.com

Комментарий кошуу