🥇O meu sexto día con Haiku: baixo o capó de recursos, iconas e paquetes

TL, RD: Haiku é un sistema operativo deseñado especificamente para PCs, polo que ten varios trucos que fan que o seu entorno de escritorio sexa moito mellor que outros. Pero como funciona?

Recentemente Descubrín o Haiku, un sistema inesperadamente bo. Aínda me sorprende o bo funcionamento, especialmente en comparación cos entornos de escritorio Linux. Hoxe vou botarlle unha ollada debaixo do capó. Cando sexa necesario para unha comprensión profunda, farei comparacións cos entornos de escritorio orixinais de Macintosh, Mac OS X e Linux (estándar XDG de freedesktop.org).

Recursos en ficheiros ELF

Onte souben que IconOMatic pode gardar iconas en recursos rdef en executables ELF. Hoxe quero ver como funciona realmente.

Recursos? Cita de Bruce Horn, o autor orixinal do Macintosh Finder e o "pai" do Macintosh Resource Manager:

Preocúpame a natureza ríxida da codificación tradicional. Para min, a idea mesma dunha aplicación conxelada no código, sen a capacidade de cambiar nada de forma dinámica, é o salvaxismo máis salvaxe. Debería ser posible cambiar o máximo posible durante o tempo de execución. Por suposto, o código da aplicación en si non se pode cambiar, pero seguramente se pode cambiar algo sen recompilar o código?

No Macintosh orixinal, fixeron que estes ficheiros tivesen unha "sección de datos" e unha "sección de recursos", o que fixo incriblemente fácil gardar cousas como iconas, traducións e similares. en ficheiros executables.

En Mac úsase isto Reeditar, un programa gráfico para -de súpeto- editar recursos.

Reeditar no Macintosh orixinal

Como resultado, fíxose posible editar iconas, elementos de menú, traducións, etc. o suficientemente sinxelo, pero aínda así "viaxan" coas aplicacións.
En calquera caso, este enfoque tiña un gran inconveniente: só funcionaba nos sistemas de ficheiros de Apple, que foi un dos motivos polos que Apple abandonou a "sección de recursos" ao pasar a Mac OS X.
En Mac OS X, Apple quería unha solución independente do sistema de ficheiros, polo que adoptou o concepto de paquetes (de NeXT), directorios que son tratados como "obxectos opacos" polo xestor de ficheiros, como ficheiros en lugar de directorios. Calquera paquete cunha aplicación no formato .app ten, entre outras cousas, un ficheiro Info.plist (nalgunha especie de equivalente de Apple de JSON ou YAML) que contén metadatos da aplicación.

Claves para o ficheiro Info.plist do paquete de aplicacións de Mac OS X.

Os recursos, como iconas, ficheiros de IU e outros, almacénanse no paquete como ficheiros. O concepto realmente volveu ás súas raíces en NeXT.

Mathematica.app en NeXTSTEP 1.0 en 1989: aparece como un directorio de ficheiros no terminal, pero como un único obxecto no xestor de ficheiros gráfico.

Volvamos a BeOS, os conceptos nos que se basea o Haiku. Os seus desenvolvedores, ao cambiar de PEF (PowerPC) a ELF (x86) (o mesmo que se usa en Linux), decidiron engadir unha sección de recursos ao final dos ficheiros ELF. Non usou a súa propia sección ELF, simplemente se engadía ao final do ficheiro ELF. Como resultado do programa strip e outros de binutils, sen saber isto, simplemente cortan. Polo tanto, ao engadir recursos a un ficheiro ELF en BeOS, é mellor non manipulalo con ferramentas Linux.

Que está pasando co Haiku agora? Basicamente, máis ou menos o mesmo.

En teoría, sería posible colocar recursos na sección desexada do ELF. Segundo os desenvolvedores da canle #haiku en irc.freenode.net:

Con ELF a sección tería máis sentido... a única razón pola que non o facemos así é porque é o que fixemos en BeOS".
E non ten sentido cambiar isto agora.

Xestión de recursos

Os recursos están escritos nun formato de "recurso" estruturado: esencialmente unha lista de recursos con tamaños e despois o seu contido. Lembreime formato ar.
Como comprobar os recursos en Haiku? Hai algo como ResEdit?
Conforme documentación:

Para ver os recursos proporcionados no paquete da aplicación, pode arrastrar o ficheiro executable a un programa como Recurso. Tamén podes ir ao terminal e executar o comando listres имя_файла.

O recurso está dispoñible en HaikuDepot, pero só me falla.

Como xestionar os recursos en ficheiros ELF? Usando rsrc и rdef. rdef os ficheiros recóllense en rsrc. Arquivo rdef gárdase en formato de texto sinxelo, polo que é moito máis doado traballar. Formato de ficheiro rsrc anexo ao final do ficheiro ELF. Imos tentar xogar:

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

Podes usar o programa xres para a comprobación e control:

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

Vale, imos probar?

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

Máis información sobre recursos e formato rdef podes ler aquí.

Tipos de recursos estándar

Aínda que podes poñer calquera cousa en recursos, hai algúns tipos estándar definidos:

app_signature: tipo de aplicación MIME, para a asignación de ficheiros abertos, inicio, IPC, etc.
app_name_catalog_entry: Dado que o nome da aplicación adoita estar en inglés, pode especificar os lugares onde se atopan os nomes traducidos, para que os usuarios de diferentes idiomas vexan o nome da aplicación traducido se o desexa.
app_version: exactamente o que pensaches
app_flags: indica registrar como tramitar a solicitude. Creo que hai máis do que parece. Por exemplo, hai B_SINGLE_LAUNCH, que obriga ao sistema a lanzar un novo proceso de aplicación cada vez que o solicita o usuario (o mesmo principio úsase para a maioría das aplicacións en Linux). Comer B_MULTIPLE_LAUNCH, facendo que o proceso se execute para cada arquivo. Finalmente hai B_EXCLUSIVE_LAUNCH, o que obriga ao sistema a lanzar só un proceso á vez, por moito que os usuarios o lancen (por exemplo, así funciona Firefox en Linux; o mesmo resultado pódese conseguir nas aplicacións Qt mediante a función). QtSingleApplication). Aplicacións con B_EXCLUSIVE_LAUNCH son notificados cando o usuario intenta executalos de novo: por exemplo, reciben a ruta do ficheiro que o usuario quere abrir coa súa axuda.
vector_icon: Icona de aplicación vectorial (BeOS non tiña iconas vectoriais, a maioría das aplicacións tiñan dúas iconas de trama nos seus ficheiros executables).

Por suposto, pode engadir recursos con calquera ID e tipo desexado e despois lelos na propia aplicación ou noutras aplicacións que utilicen a clase BResources. Pero primeiro, vexamos o fascinante tema das iconas.

Iconas vectoriales en estilo Haiku

Por suposto, non só Haiku escolleu o mellor formato de icona; nesta parte, a situación cos entornos de escritorio Linux dista moito de ser ideal:

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

Mirando isto xa se pode sentir o que é unha peza.

Por suposto, hai escalable, que contén, como podes entender, iconas vectoriais. Por que entón hai outra cousa? Porque o resultado de debuxar gráficos vectoriais en tamaños pequenos pode ser menos que ideal. Gustaríame ter diferentes opcións optimizadas para diferentes tamaños. En entornos de escritorio Linux, isto conséguese espallando iconas de diferentes tamaños por todo o sistema de ficheiros.

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

Teña en conta: non hai concepto de versións diferentes de Firefox. Así, non é posible xestionar con gracia a situación de ter varias versións dunha aplicación no sistema.

Diferentes iconas de Firefox en diferentes versións. Actualmente é imposible manexar isto en Linux sen varias muletas.

Mac OS X o manexa un pouco máis sutilmente:

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

Pódese ver que hai un ficheiro firefox.icns no paquete Firefox.app, que contén todos os tamaños para que as diferentes versións da mesma aplicación teñan iconas diferentes.
Moito mellor! As iconas viaxan coa aplicación, todos os recursos están nun só ficheiro.

Volvemos ao haiku. Unha solución alucinante, sen excepcións. Dacordo con documentación:

Desenvolveuse un formato especial HVIF, altamente optimizado para tamaños pequenos e renderizado rápido. Polo tanto, as nosas iconas na súa maior parte son moito máis pequenas que no formato ráster ou no formato SVG moi utilizado.

E aínda están optimizados:

Tamaños das iconas en HVIF en comparación con outros formatos.

A diferenza é unha orde de magnitude!

Pero a maxia non remata aquí. O mesmo HVIF pode mostrar diferentes niveis de detalle dependendo do tamaño que se mostra, aínda que sexa un formato vectorial.

Diferentes niveis de detalle (LOD) dependendo do tamaño do render

Agora sobre as desvantaxes: non podes levar SVG, bótao a ImageMagick e chamalo un día; tes que pasar por varios ciclos para crear unha icona en formato HVIF. Aquí explicacións. Non obstante, IconOMatic pode importar SVG de forma bastante imperfecta; preto do 90 % dos detalles SVG impórtanse con certa probabilidade, o 10 % restante terá que ser configurado e cambiado manualmente. Lea máis sobre como HVIF fai a súa maxia unha lata no blog Leah Ganson

Engadir unha icona á aplicación

Agora podo engadir unha icona ao paquete creado derradeira vez, tendo en conta toda a información recibida.
Ben, como non estou especialmente ansioso por debuxar a miña propia icona para a miña QtQuickApp "Ola, mundo" agora mesmo, saco de 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

Comprobamos que a icona foi copiada:

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

Parece ben, pero por que cando se copia a nova icona non aparece?

O VICN:101:BEOS:ICON copiado aínda non se utiliza como icona de aplicación no xestor de ficheiros

Que botei de menos?

Comentario do programador:

Necesitamos crear un ficheiro rdef con todos os recursos, despois executa o comando rc имя.rdef, isto creará o ficheiro .rsrc. A continuación, cómpre executar o comando resattr -o имя_бинарника имя.rsrc. Como mínimo, uso comandos coma estes para engadir iconas aos meus scripts.

Ben, quería crear un recurso, non un atributo. Estou moi confuso.

Almacenamento intelixente en caché mediante o sistema de ficheiros

A apertura e lectura de atributos ELF é lenta. Como escribín arriba, a icona está escrita como un recurso no propio ficheiro. Este método é máis fiable e permítelle sobrevivir ao copiar a outro sistema de ficheiros. Non obstante, entón tamén se copia no atributo do sistema de ficheiros, por exemplo BEOS:ICON. Isto só funciona en determinados sistemas de ficheiros, como BFS. As iconas que mostra o sistema (en Tracker e Deskbar) lense desde este atributo estendido, porque esta solución funciona rapidamente. Nalgúns lugares (onde a velocidade non é importante, por exemplo, unha ventá típica "Acerca de"), o sistema recibe a icona directamente do recurso no ficheiro. Pero este non é o final. Lembre, en Mac, os usuarios poderían substituír iconas de aplicacións, directorios, documentos polos seus propios, xa que en Mac é posible facer estas cousas "importantes", por exemplo substituíndo unha nova icona de Slack pola anterior. En Haiku, debes pensar no recurso (no ficheiro) como a icona orixinal que vén coa aplicación, e no atributo (no sistema de ficheiros BFS) como algo que permite ao usuario facer cambios a vontade (aínda que, unha pista, a GUI para inserir unha icona personalizada na parte superior da icona é opcional).aínda non está implementada por defecto).

Comprobación dos atributos do sistema de ficheiros

Con resaddr É posible comprobar e configurar os atributos do sistema de ficheiros.

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

É esencialmente o "pegamento" que realiza a conversión de ida e volta entre os recursos (fiables) e os atributos (rápidos) do sistema de ficheiros. E como o sistema espera recibir recursos e fai a copia automaticamente, non me preocuparei máis por iso.

A maxia dos paquetes hpkg

Actualmente (a maioría das veces) utilízanse paquetes para obter programas en Haiku .hpkg. Non te deixes enganar polo simple nome: o formato .hpkg funciona de forma completamente diferente a outros formatos con nomes similares que atopaches, ten auténticos superpoderes.

Cos formatos de paquete tradicionais, estiven molesto durante moito tempo por este feito: descargas unha cousa (paquete) e outra está instalada no sistema (arquivos dentro do paquete). É bastante difícil xestionar ficheiros (por exemplo, borralos) ao instalar un paquete de xeito tradicional. E todo porque o contido do paquete espallados por todo o sistema de ficheiros, incluídos os lugares onde o usuario medio pode non ter acceso de escritura. Isto dá lugar a toda unha clase de programas - xestores de paquetes. Pero transferir software xa instalado, por exemplo, a outra máquina, disco extraíble ou servidor de ficheiros faise aínda máis difícil, se non completamente imposible. Nun sistema típico baseado en Linux, pode haber facilmente varios centos de miles ou millóns de ficheiros individuais. Nin que dicir ten que isto é fráxil e lento, por exemplo cando se instala inicialmente un sistema, cando se instalan, actualizan e desinstalan paquetes habituais e cando se copia o volume de arranque (partición raíz) noutro medio.

Estou traballando no proxecto AppImage, unha muleta parcial para aplicacións de usuarios finais. Este é un formato de distribución de software que recolle unha aplicación e todas as súas dependencias nunha única imaxe do sistema de ficheiros que se monta cando se inicia a aplicación. Simplifica significativamente as cousas, xa que o mesmo ImageMagick convértese de súpeto nun único ficheiro, xestionado nun xestor de ficheiros por simples mortais. O método proposto só funciona para o software, como se reflicte no nome do proxecto, e tamén ten o seu propio conxunto de problemas, xa que as persoas implicadas na entrega de software para Linux sempre apuntan a frecha cara a min.

Volvemos ao haiku. Foi posible atopar o equilibrio óptimo entre os sistemas de paquetes tradicionais e a entrega de software baseado en imaxes? Os seus paquetes .hpkg imaxes realmente comprimidas do sistema de ficheiros. Cando se inicia o sistema, o núcleo monta todos os paquetes instalados e activos con aproximadamente as seguintes mensaxes do núcleo:

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"

Xenial, si? Espera aí, será aínda máis fresco!

Hai un paquete moi especial:

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

Contén un sistema operativo moi minimalista, incluíndo o núcleo. Créao ou non, mesmo o propio núcleo non se elimina do volume de arranque (partición raíz), senón que se carga coidadosamente no seu lugar desde o paquete. .hpkg. Vaia! Xa mencionei que creo que parte da sofisticación e coherencia xeral de Haiku vén do feito de que todo o sistema, desde o núcleo e o espazo de usuario principal ata a xestión de paquetes e a infraestrutura de execución, é desenvolvido en colaboración por un só equipo. Imaxina cantos grupos e equipos diferentes serían necesarios para executar algo así en Linux [Imaxino o proxecto PuppyLinux - aprox. tradutor]. A continuación, imaxina canto tempo tardará en adoptar este enfoque nas distribucións. Din: toma un problema sinxelo, divídeo entre distintos intérpretes, e será tan complicado que xa non será posible resolvelo. Haiku neste caso abriume os ollos. Creo que isto é exactamente o que está a suceder en Linux agora (Linux neste caso é un termo colectivo para a pila Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Reversión do sistema usando hpkg

Cantas veces ocorre a seguinte situación: a actualización foi exitosa e despois resulta que algo non funciona como debería? Se usa xestores de paquetes convencionais, é difícil devolver o estado do sistema a un punto no tempo anterior a que se instalasen novos paquetes (por exemplo, no caso de que algo saíse mal). Algúns sistemas ofrecen solucións en forma de instantáneas do sistema de ficheiros, pero son bastante engorrosos e non se usan en todos os sistemas. Haiku resolve isto usando paquetes .hpkg. Sempre que os paquetes cambian no sistema, os paquetes antigos non se eliminan, senón que gárdanse no sistema en subdirectorios como /Haiku/system/packages/administrative/state-<...>/ constantemente. As operacións sen rematar almacenan os seus datos en subdirectorios /Haiku/system/packages/administrative/transaction-<...>/.

Contido /Haiku/system/packages/administrative. Os directorios "estado..." conteñen ficheiros de texto cos nomes dos paquetes activos, e os directorios "transacción..." conteñen os propios paquetes.

"Estado activo antigo", é dicir. lista .hpkg os paquetes activos antes de que se rexistren os cambios despois de cada operación no xestor de ficheiros nun ficheiro de texto /Haiku/system/packages/administrative/state-<...>/activated-packages. Do mesmo xeito, un novo "estado activo" escríbese nun ficheiro de texto /Haiku/system/packages/administrative/activated-packages.

Directorio /Haiku/system/packages/administrative/state-<...>/ contén só un ficheiro de texto cunha lista de paquetes activos deste estado (no caso de instalar paquetes sen eliminalos), e se os paquetes foron eliminados ou actualizados - o directorio de estado contén versións antigas dos paquetes.

Cando o sistema arranca, baseándose na lista de paquetes, tómase a decisión de activar (montar) paquetes. É así de sinxelo! Se algo sae mal durante a descarga, podes indicarlle ao xestor de descargas que utilice unha lista máis antiga. Problema resolto!

Descargador de haiku. Cada punto de entrada mostra un "estado activo" correspondente

Gústame o enfoque de ter ficheiros de texto sinxelos como lista de "estado activo", con nomes fáciles de entender .hpkg. Isto está en marcado contraste con ser construído para máquinas, non para as persoas. nunha morea de OSTree ou Flatpak no sistema de ficheiros (no mesmo nivel que Microsoft GUID).

Lista de paquetes activos para cada momento

Datos de configuración

Ao parecer, no catálogo /Haiku/system/packages/administrative/writable-files contén ficheiros de configuración para paquetes, pero son escribibles. Despois de todo, como lembras, .hpkg montado de só lectura. Polo tanto, estes ficheiros deben ser copiados dos paquetes antes de escribir. Ten o significado.

Integración de GUI para o sistema .hpkg

Vexamos agora como son estes bolsos brillantes .hpkg xestionar a integración no entorno de traballo do usuario (UX). Despois de todo, haiku está pensado para uso persoal, despois de todo. Persoalmente, poño o listón alto cando comparo a experiencia do usuario cos paquetes .app en Macintosh coa mesma experiencia activada .hpkg. Nin sequera compararei a situación cos ambientes de traballo en Linux, porque é absolutamente terrible en comparación con outros.

Véñenme á mente os seguintes escenarios:

Quero ver o contido dun paquete .hpkg
Quero instalar un paquete
Quero eliminar o paquete
Quero eliminar algo que entrou no sistema como parte dun paquete
Quero copiar algo que entrou no sistema como parte dun paquete
Quero descargar todas as dependencias dun paquete, que quizais non formen parte de todas as instalacións de Haiku (por exemplo, teño unha máquina illada fisicamente sen acceso a Internet).
Quero mover os meus paquetes (ou parte deles) por separado a outro lugar, separado do volume de arranque (partición raíz) (porque, por exemplo, non teño espazo suficiente nel).

Isto debería cubrir a maioría dos casos principais do meu traballo diario. Ben, imos comezar.

Comprobando o contido do paquete

En Mac Simplemente fago clic co botón dereito no paquete para abrilo e ver o contido no Finder. Despois de todo, en realidade é só un directorio disfrazado! (Sei que hai paquetes .pkg para unha parte do sistema que non son aplicacións, pero os usuarios comúns a maioría das veces non interactúan con elas).

En haiku Fago clic co botón dereito no paquete e, a continuación, en "Contido" para ver o que hai dentro. Pero aquí hai só unha lista de ficheiros sen a posibilidade de abrilos facendo dobre clic.
Sería moito mellor se houbese unha forma de montar o paquete (temporalmente). .hpkg para ser visto a través dun xestor de ficheiros e o usuario non tería que preocuparse polos detalles de implementación. (Por certo, podes abrir .hpkg paquete en Expander, que pode descomprimilo como calquera outro arquivo).

A interface de HaikuDepot permítelle ver unha lista de ficheiros de paquetes, pero non hai forma de ver o contido facendo, por exemplo, dobre clic en README.md.

O Mac gaña nesta categoría, pero engadir a funcionalidade de HaikuDepot que queres non debería ser demasiado difícil.

Instalación dun paquete mediante GUI

En Mac, a maioría das imaxes de disco .dmg conteñen paquetes .app. Fai dobre clic na imaxe do disco e copia o paquete, por exemplo, arrastrándoo /Applications no Finder. Isto é evidente para min, pero escoitei que algúns novatos quizais non poidan xestionar isto. Por defecto, Apple "suxire" un directorio para todo o sistema /Applications (en NeXT estaba en rede e individual), pero pode colocar facilmente as súas aplicacións nun servidor de ficheiros ou nun subdirectorio $HOME/Applications, se che gusta así.

En haiku, fai dobre clic no paquete e despois fai clic en "Instalar", non podería ser máis sinxelo. Pregúntome que pasa se un paquete ten dependencias dispoñibles en HaikuPorts pero aínda non instaladas. En Linux realmente non saben que facer nesta situación, pero a solución é obvia: pregúntalle ao usuario se precisa descargar e instalar dependencias. Exactamente o que fai Haiku.

Descarguei o paquete 'sanity' manualmente e fixen clic nel, o xestor de paquetes sabe de onde obter as súas dependencias (asumindo que os repositorios xa están rexistrados no sistema). Non todas as distribucións de Linux poden facelo.

Outra forma é usar un xestor de ficheiros, só tes que arrastrar e soltar .hpkg paquete ou en /Haiku/system/packages (para unha instalación de todo o sistema, por defecto) ou en /Haiku/home/config/packages (para instalación individual; non dispoñible ao facer dobre clic - aínda me molesta a palabra "config" neste lugar, que para min neste caso é sinónimo de "configuración"). E o concepto de varios usuarios aínda non está dispoñible para Haiku (probablemente por iso sexa tan sinxelo; non o sei, quizais as capacidades multiusuario compliquen innecesariamente as cousas para un ambiente de escritorio).

Haiku gaña nesta categoría porque pode funcionar non só con aplicacións, senón tamén con programas do sistema.

Eliminando un paquete da GUI

En Mac, cómpre arrastrar a icona da aplicación á papeleira, e iso é todo. Doadamente!

En haiku, en primeiro lugar, debes atopar onde se atopa o paquete no sistema, porque raramente o instalas no lugar correcto (o sistema fai todo). Normalmente hai que mirar dentro /Haiku/system/packages (cunha instalación predeterminada en todo o sistema) ou en /Haiku/home/config/packages (Mencionei que "config" é un nome incorrecto?). A continuación, a aplicación simplemente é arrastrada ao lixo e xa está.
Doadamente! Non obstante, eu non diría iso. Aquí está o que realmente está pasando:

Isto é o que ocorre se arrastras unha aplicación ao lixo dende /Haiku/system/packages

Acabo de tentar mover a aplicación "Hello World" de onte en QtQuickApp ao lixo. Non tentei mover o directorio do sistema, e dado que todos os paquetes están instalados no directorio do sistema, é imposible eliminar o paquete .hpkg sen cambios "o seu contido". Un usuario común asustríase e preme o botón "Cancelar" asignado por defecto.

Explica Señor. waddlesplash:

Esta publicación ten máis de 10 anos. O máis probable é que necesitemos configuralo para que o aviso apareza só cando se move o propio paquete. Os usuarios habituais non precisan facelo de todos os xeitos.

Vale, quizais debería facelo usando HaikuDepot? Fago dobre clic no paquete /Haiku/system/packages, agardando a que apareza o botón "Desinstalar". Non, hai (só) "Instalar". "Desinstalar", onde estás?

Só por diversión, tentei ver que pasaría se facía clic en "Instalar" nun paquete xa instalado. Resulta así:

Isto ocorre se tentas instalar un paquete xa instalado.

A continuación aparece:

Se fai clic en "Aplicar cambios" na xanela anterior, aparecerá así

Supoño que se trata dun erro de software; a ligazón á aplicación xa está alí. [o autor non proporcionou unha ligazón - aprox. tradutor]

Solución rápida: engade un botón "Desinstalar" se o paquete xa está dentro /Haiku/system/packages, ou en /Haiku/home/config/packages.

Cando vexo a lista de paquetes instalados en HaikuDepot, vexo o meu paquete na lista e podo eliminalo.

O Mac gaña nesta categoría. Pero podo imaxinar que cunha configuración adecuada, a experiencia do usuario en Haiku será mellor que en Mac. (Un dos desenvolvedores calificouno deste xeito: "Menos dunha hora para engadir a funcionalidade especificada a HaikuDepot, se coñeces un pouco de C++", hai voluntarios?)

Eliminando algo dun paquete

Tentemos eliminar a propia aplicación, non o paquete .hpkg, do que procedía (dubido que para os “meros mortais” haxa diferenza).

En Mac, o usuario adoita traballar co ficheiro .dmgde onde vén o paquete da aplicación .app. Normalmente imaxes .dmg acumúlanse no directorio de descargas e os paquetes son copiados polo usuario /Applications. Crese que moitos usuarios mesmos non saben o que están a facer, esta hipótese é confirmada por un antigo empregado de Apple. (Unha das cousas que non me gusta en Mac. E, por exemplo, con AppImage non hai diferenza entre a aplicación e o paquete no que estaba. Arrastra a icona á papeleira = iso é todo. Fácil!)

En haiku, tamén hai unha división entre apps/ и packages/, polo que dubido que isto o deixase máis claro aos usuarios. Pero que pasa se arrastras unha aplicación desde apps/ Engadir á cesta:

Isto é o que ocorre cando tentas eliminar unha aplicación tomada dun ficheiro .hpkg

Tecnicamente é correcto (despois de todo, a aplicación está aloxada nun sistema de ficheiros de só lectura), pero non é especialmente útil para o usuario.

Solución rápida: suxire usar GUI para eliminar .hpkg

Só por diversión, tentei duplicar a aplicación premendo Alt+D. Recibín a mensaxe "Non se poden mover ou copiar obxectos nun volume de só lectura". E todo porque /system (ademais /system/packages и /system/settings) é o punto de montaxe de packagefs (lembra como aparece na saída df?). Desafortunadamente, a saída do comando mount non aclara a situación (como se dixo nun dos artigos anteriores), mountvolume non mostra o que está a buscar (aparentemente paquetes montados a través de bucle .hpkg non se consideran "volumes"), e tamén esquecín os comandos alternativos.

Ninguén gañou nesta categoría excepto AppImage (pero esta, para ser completamente honesto, é unha opinión tendenciosa). Non obstante, pódese imaxinar que despois de axustar, a experiencia do usuario en Haiku será mellor que en Mac.

Nota: cómpre descubrir o que é un "volume" en relación cunha "sección". Isto probablemente sexa semellante á relación de "cartafol" con "directorio": a maioría dos directorios aparecen como cartafoles no xestor de ficheiros, pero non todos (paquetes tratados como ficheiros, por exemplo). Este tipo de exhibición convérteme nun nerd oficial?

Copiando o contido dun paquete a outro sistema

En Mac, arrastro estúpidamente o paquete .app, e como as dependencias están dentro do paquete, móvense xuntas.

En haiku, arrastro a aplicación, pero as dependencias non se procesan en absoluto.

Solución rápida: suxerimos que arrastre todo o paquete `.hpkg, xunto con calquera dependencia, se é o caso.

O Mac gaña claramente nesta categoría. Polo menos para min, amante do seu paradigma. Debería copialo en Haiku .hpkg en lugar dunha aplicación, pero o sistema non me ofrece isto...

Descarga un paquete con todas as súas dependencias

Non todas as máquinas están conectadas á rede todo o tempo. Pola contra, algunhas máquinas (si, estou mirando para ti, Windows, Mac e Linux modernos) esquécense disto. É importante para min que poida ir, por exemplo, a un cibercafé, descargar software nunha unidade extraíble, inserir esta unidade no meu ordenador de casa e estar seguro de que todo funcionará [tipo arriscado, facendo isto en Windows... - aprox. tradutor].

Como resultado, adoito acabar con dependencias non satisfeitas de Windows e Linux un pouco máis do habitual.

En Mac adoita ser un ficheiro, todo o que tes que facer é descargar .dmg. Na maioría das veces, non ten outras dependencias que as proporcionadas polo propio MacOS por defecto. Unha excepción son as aplicacións complexas que requiren un ambiente de execución axeitado, por exemplo, Java.

En haiku descargar paquete .hpkg pois, por exemplo, a mesma aplicación en java pode non ser suficiente, xa que Java pode estar ou non presente na máquina de destino. Hai algún xeito de descargar todas as dependencias dun determinado paquete .hpkg, ademais dos que están instalados por defecto en Haiku e, polo tanto, deberían estar en todos os sistemas Haiku?

O Mac gaña esta categoría por unha pequena marxe.

Comentarios Sr. waddlesplash:

Escribir un programa para recoller todas as dependencias dunha aplicación como un conxunto de paquetes .hpkg para alguén familiarizado co funcionamento interno do Haiku, uns 15 minutos son suficientes. Engadir apoio para isto non é tan difícil se hai unha necesidade real. Pero para min esta é unha situación rara.

Contemos a respiración ata o próximo artigo desta serie.

Mover paquetes a un lugar separado

Como escribín anteriormente, quero colocar os meus paquetes .hpkg (ben, ou parte deles) a un lugar especial, separado da colocación habitual no volume de arranque (partición raíz). No caso habitual (non tan teórico), a razón é que constantemente quedo sen espazo libre nos meus discos (integrados), por moi grandes que sexan. E normalmente conecto unidades externas ou recursos compartidos de rede onde se atopan as miñas aplicacións.

En Mac Só estou movendo paquetes .app a unha unidade extraíble ou directorio de rede no Finder, e iso é todo. Aínda podo facer dobre clic para abrir a aplicación como faría normalmente desde o volume de arranque. Só!

En haiku, como me dixeron, isto pódese conseguir movendo o meu .hpkg paquetes a unha unidade extraíble ou directorio de rede, pero entón cómpre empregar algúns comandos non documentados na consola para montalos no sistema. Non sei como facelo usando só a GUI.

O Mac gaña nesta categoría.

Segundo o sr. waddlesplash:

Esta é unha optimización baseada no uso normal. Se hai demanda de máis dun usuario, implementarémolo. En calquera caso, existe a posibilidade de implementación por terceiros.

Falaremos disto no seguinte artigo.

Falando de directorios de rede, sería xenial (supoño que as festas LAN) contaran con aplicacións sinxelas e descubertas para toda a rede (como Zeroconf) que se poidan copiar no ordenador local ou executarse directamente desde a rede local. Por suposto, os desenvolvedores teñen a opción de desactivarse mediante app_flags.

Informe final sobre a integración do sistema hpkg coa GUI

Creo que, sobre todo, pola novidade relativa da integración .hpkg a GUI aínda deixa moito que desexar. De todos os xeitos, hai algunhas cousas que se poderían mellorar en canto a UX...

Unha cousa máis: Kernel Debug Land

Sería xenial poder introducir comandos durante o pánico do núcleo, por exemplo syslog | grep usb. Ben, en Haiku é posible grazas a Kernel Debug Land. Como podes ver esta maxia en acción se todo funciona como debería sen entrar en pánico do núcleo? Fácil premendo Alt+PrintScn+D (mnemotécnica de depuración). Lembro inmediatamente Clave do programador, o que permitiu aos desenvolvedores de Macintosh orixinais entrar no depurador (se se instalou algún, claro).

Conclusión

Estou comezando a entender que a sofisticación do sistema Haiku vén do feito de que o traballo é realizado por un pequeno equipo cun foco claro no ambiente de traballo, con todas as capas do sistema accesibles.
Un forte contraste co mundo de Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, onde todo se rompe en pequenos anacos ata tal punto que a abstracción aséntase na abstracción e conduce con muletas.
Tamén houbo unha comprensión de como o sistema .hpkg combina as mellores prácticas dos xestores de paquetes tradicionais, Snappy, Flatpak, AppImage, incluso btrfs, e combínaas co enfoque "só funciona" de Mac.

Era coma se algo "cambiase" na miña cabeza, e entendín como era o sistema .hpkg sabe rodar, só con mirala. Pero non son eu, senón a beleza e a sinxeleza do sistema. Gran parte disto está inspirado no espírito do Mac orixinal.

Si, a navegación no navegador pode ser entrecortada e funcionar como un caracol, pode faltar aplicacións (non Gtk, Electron; os desenvolvedores concluíron que non van ben coa sofisticación), o vídeo e a aceleración 3D poden estar completamente ausentes, pero aínda así. gústalle este sistema. Despois de todo, estas cousas pódense corrixir e aparecerán tarde ou cedo. É só cuestión de tempo e quizais un pequeno ollo vermello.

Non podo ofrecer axuda, pero creo que comezará a partir de agora ano de Haiku no escritorio.

Problemas aleatorios

Quizais xa hai solicitudes, ou debería abrilas?

BeScreenCapture debería poder exportar a GIF como Peek. Isto pódese facer usando ffmpeg, xa dispoñible para Haiku. Solicitude.
O software de captura de pantalla non logra capturar unha xanela modal, senón que captura toda a pantalla
Non podes recortar capturas de pantalla usando a ferramenta de recorte de WonderBrush e despois gardar o resultado nun ficheiro
Non me gusta especialmente o cursor da man en Haiku, pero creo que ten que ver coa cálida sensación nostálxica. Isto é especialmente molesto cando se usa a ferramenta de recorte en Krita, xa que provoca un recorte inexacto (consulte as capturas de pantalla dos diálogos modais neste artigo). Un cursor en cruz sería marabilloso. Solicitude.

Probao vostede mesmo! Despois de todo, o proxecto Haiku ofrece imaxes para o arranque desde DVD ou USB, xeradas diario. Para instalala, só tes que descargar a imaxe e escribira nunha unidade flash usando Etcher

Tes algunha dúbida? Convidámoste ao rusofalante canle de telegrama.

Visión xeral do erro: Como dispararse no pé en C e C++. Colección de receitas Haiku OS

De autor tradución: este é o sexto artigo da serie sobre o haiku.

Lista de artigos: Primeira O segundo Terceiro Cuarto Quinto

Fonte: www.habr.com

O meu sexto día con Haiku: baixo o capó de recursos, iconas e paquetes