À l'automne de cette année, après 6 ans de développement, la première version bêta de "R1 / beta1" du système d'exploitation
Haiku est sortie. Je suis depuis longtemps ce projet intéressant qui vise à recréer et à développer le système
BeOS qui existait en 1994-2000. Par conséquent, dès que j'ai vu des nouvelles sur la sortie de la version bêta de Haiku sur les sites de nouvelles informatiques, j'ai immédiatement décidé de voir ce qui était ajouté à cette version tant attendue. Après avoir installé le système dans la machine virtuelle
VirtualBox et un peu de familiarisation avec ses fonctionnalités de base, j'ai pensé qu'il serait bien d'aider la communauté OpenSource, qui développe ce système d'exploitation, un peu aujourd'hui. J'ai décidé de commencer par ce que j'ai acquis un peu d'expérience: le portage de certains projets de jeux.
Le bureau du système d'exploitation Haiku.Plus tard, j'ai essayé d'affiner certaines applications et bibliothèques existantes. C'est ma petite activité dans divers référentiels open source à laquelle cet article sera consacré. Dans ce document, je décrirai constamment les problèmes que j'ai rencontrés et parlerai des méthodes pour les résoudre. J'ai essayé d'envoyer la plupart des correctifs qui ont été faits au cours de ce travail à des projets existants en
amont afin de leur fournir un support Haiku et d'intéresser leurs développeurs à l'existence de systèmes d'exploitation alternatifs.
Le système d'exploitation Haiku utilise un
noyau hybride , qui est une implémentation de l'architecture micro-noyau avec la capacité de charger dynamiquement les modules nécessaires. Il est basé sur la fourche du noyau
NewOS , qui a été développé par un ancien ingénieur de
Be Inc. , Par Travis Geiselbrecht. Aujourd'hui, ce développeur travaille chez Google sur un noyau appelé
Zircon pour le nouveau système d'exploitation
Google Fuchsia , mais c'est une autre histoire. Ainsi, puisque les développeurs de Haiku déclarent la compatibilité binaire avec BeOS, ils sont obligés de prendre en charge non pas deux branches architecturales familières, mais trois: x86_64, x86 et x86_gcc2. Cette dernière architecture est une charge de compatibilité avec le compilateur de l'ancienne version de
GCC 2.95. C'est grâce à elle qu'il est possible d'exécuter des applications écrites pour le système d'exploitation BeOS d'origine. Malheureusement, en raison de cette charge de compatibilité, les développeurs Haiku ne peuvent pas utiliser les fonctionnalités modernes du langage de programmation C ++ dans les API système. Cependant, ils préparent des images d'installation pour seulement deux architectures: x86_64 et x86. Le fait est que la distribution Haiku pour x86 est hybride: malgré le fait que tous les composants du système sont construits sous x86_gcc2 pour la compatibilité binaire, l'utilisateur a la possibilité d'installer ou de construire des applications modernes conçues avec des compilateurs modernes et une architecture x86 . La distribution Haiku pour l'architecture x86_64 est entièrement 64 bits et n'a pas la possibilité d'exécuter des applications BeOS et Haiku 32 bits. Cependant, il existe une compatibilité au niveau de l'API, donc si vous avez le code source de l'application sous BeOS ou Haiku x86, vous pouvez facilement le compiler sous Haiku x86_64 et tout devrait fonctionner. Une image du système d'exploitation pour l'architecture x86_64 est recommandée pour l'installation sur du matériel réel si vous n'avez pas besoin de prise en charge pour des applications BeOS spécifiques ou des applications Haiku 32 bits.
Il convient de noter que ce système d'exploitation prend en charge partiellement le standard
POSIX . Cette fondation s'apparente à des systèmes de type UNIX et facilite le portage de leurs logiciels. Le langage de programmation principal est le C ++, il est activement utilisé, car les API publiques de Haiku poursuivent principalement un paradigme de programmation orienté objet. Néanmoins, personne n'interdit l'utilisation du langage de programmation C, mais dans la plupart des cas, vous devrez écrire les couches de compatibilité correspondantes. L'interface logicielle du système d'exploitation est regroupée dans des cadres système distincts qui sont responsables d'une opportunité particulière, par exemple, pour une interface ou un support réseau. C'est un peu comme ce qui est disponible sur
macOS ou dans le
framework Qt . Il convient de noter que ce système d'exploitation est mono-utilisateur, bien que certains développements dans le sens de fournir un mode de travail multi-utilisateurs pour les développeurs de Haiku soient disponibles.
Je ne peux que partager avec les lecteurs de cet article l'expérience positive de l'utilisation du système avancé de gestion des fenêtres d'application disponible dans Haiku. À mon avis, c'est l'un des plus pratiques et à sa manière est la marque de fabrique de cet OS.
Gestion avancée des fenêtres dans le système d'exploitation Haiku: prise en charge du pavage et des onglets.Les fenêtres peuvent être attachées ensemble dans des onglets, comme cela se fait dans les navigateurs modernes, attachées les unes aux autres et redimensionnées de manière pratique.
Mosaïque simple , transfert des contextes de certaines applications d'une fenêtre à une autre et
réplicants pris en charge. Vous pouvez en savoir plus sur toutes les fonctionnalités du système de fenêtres locales dans la
documentation officielle , là toutes les touches de raccourci nécessaires y sont décrites.
Je n'écrirai pas dans cet article un aperçu complet de toutes les fonctionnalités et capacités de Haiku, car ceux qui s'y intéressent pourront facilement trouver eux-mêmes les informations nécessaires sur Internet.
Contenu:
1. Packages et référentiels dans Haiku2. Premières étapes: Porter l'aventure d'affection de l'armure adamante3. Modification du port NXEngine existant (Cave Story)4. Portage du jeu Gish5. Le projet BeGameLauncher, qui vous permet de créer rapidement des lanceurs de jeux6. Portage de Xash3D: jeu de demi-vie légendaire et modules complémentaires officiels7. Portage des deux parties du jeu Serious Sam: The First Encounter et The Second Encounter8. Portage du jeu Vangers9. Implémentation de dialogues dans la bibliothèque SDL2 pour Haiku10. Portage de ma fourchette de Cool Reader11. Finalisation du programme KeymapSwitcher12. Conclusion1. Packages et référentiels dans Haiku
Par rapport au BeOS d'origine, une innovation importante est apparue dans Haiku: un système de gestion de paquets qui comprend divers outils pour obtenir et installer des logiciels à partir de diverses sources. Ces sources peuvent être les référentiels officiels
Haiku et
HaikuPorts , des référentiels non officiels et des packages HPKG simplement séparés et spécialement préparés. De telles capacités d'installation et de mise à jour de logiciels sont connues depuis longtemps dans le monde des systèmes d'exploitation de type Unix, mais maintenant toute leur puissance et leur commodité ont atteint Haiku, ce qui ne peut que plaire aux utilisateurs ordinaires de ce système d'exploitation. Grâce à l'infrastructure construite autour du gestionnaire de packages, tout développeur peut désormais facilement porter une nouvelle application open source ou la modifier, puis ajouter les résultats de son travail au référentiel de port du logiciel HaikuPorts, après quoi ils seront disponibles pour tous les utilisateurs de Haiku. En conséquence, l'écosystème résultant ressemble à celui des systèmes d'exploitation macOS avec leur
Homebrew , FreeBSD avec leurs
ports , Windows avec
MSYS2 ou Arch Linux avec son
AUR .
Un outil de construction de packages et de logiciels de portage, appelé
HaikuPorter , est fourni séparément du système d'exploitation et est installé à l'aide d'un petit
manuel situé dans le référentiel sur GitHub. Après avoir installé cet utilitaire à partir du même GitHub, l'arborescence de recette entière est téléchargée, sur laquelle le développeur travaille. La recette est un script Shell standard avec des instructions sur lesquelles HaikuPorter collectera le package HPKG requis. Il est à noter que l'outil lui-même est écrit dans le
langage de programmation
Python 2, interagit étroitement avec le système de gestion de packages existant et utilise l'outil standard
Git en interne pour corriger les modifications du code source du logiciel et générer un ensemble de correctifs. Grâce à cette pile technologique, faire des recettes pour créer des packages HPKG et des correctifs logiciels sous forme de fichiers de patchs est très pratique et simple. Dans la plupart des cas, je n'ai dû utiliser que trois commandes lorsque je travaillais avec HaikuPorter:
alias hp="haikuporter -S -j4 --get-dependencies --no-source-packages" hp libsdl2 hp libsdl2 -c hp libsdl2 -e
La première commande collecte simplement le package sélectionné, la deuxième commande efface le répertoire de construction et la troisième crée ou met à jour un ensemble de correctifs en fonction de vos modifications enregistrées dans le référentiel Git du répertoire de travail via les validations.
Ainsi, afin de publier un package dans le référentiel HaikuPorts et de le mettre à la disposition de tous les utilisateurs Haiku, le développeur doit installer HaikuPorter, développer l'arborescence de recettes, collecter le package HPKG localement et le tester, puis valider à sa fourchette de l'arbre de recettes. puis faites une
requête Pull sur GitHub. Les développeurs de Haiku devraient considérer le travail publié, après quoi ils décident de fusionner vos modifications dans le référentiel ou de les envoyer pour révision. Si les modifications sont acceptées, le même HaikuPorter installé sur le serveur de génération collectera à distance le package et le publiera automatiquement dans le référentiel.
Un programme spécial
HaikuDepot a été ajouté à la version bêta de «R1 / beta1» du système d'exploitation Haiku, qui permet de travailler avec des packages et des référentiels via une interface utilisateur graphique, plutôt que via des commandes de console dans le terminal.
Le programme HaikuDepot fonctionnant sur le système d'exploitation Haiku.Grâce à cet outil, les utilisateurs inexpérimentés et novices de Haiku peuvent facilement gérer leur base de packages. Il convient de noter que cette application n'est pas seulement un shell GUI sur le gestionnaire de packages existant, mais qu'elle implémente également des fonctionnalités supplémentaires. Par exemple, les utilisateurs autorisés peuvent évaluer et rédiger des avis sur les packages disponibles pour l'installation. De plus, HaikuDepot dispose d'un site
Web spécial
Haiku Depot qui vous permet de visualiser les modifications des packages sur Internet ou de télécharger des packages HPKG individuels.
<< Passer au contenu2. Premières étapes: Porter l'aventure d'affection de l'armure adamante
Après avoir pris connaissance des fonctionnalités du système d'exploitation dans la machine virtuelle VirtualBox, j'ai décidé d'évaluer la bibliothèque SDL2 et de porter le jeu
Adamant Armor Affection Adventure sur Haiku, que j'ai écrit plus tôt sur le transfert vers la plate-forme Android. La construction du programme n'a nécessité aucune modification du code source, j'ai juste installé tous les outils nécessaires, les bibliothèques, leurs fichiers d'en-tête à partir du référentiel et effectué les opérations suivantes:
cmake -DCMAKE_BUILD_TYPE=Release -DGLES=off -DANDROID=off -DCMAKE_C_FLAGS="-D__linux__" -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp cmake --build . = off -DCMAKE_C_FLAGS = "- D__linux__" -DSDL2_INCLUDE_DIR = `finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR =` finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp cmake -DCMAKE_BUILD_TYPE=Release -DGLES=off -DANDROID=off -DCMAKE_C_FLAGS="-D__linux__" -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` -DSDL2_MIXER_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` ../aaaa/src/main/cpp cmake --build .
Puisque Haiku a POSIX, les définitions -D__linux__ ou
-D__unix__ résolvent de nombreux problèmes associés à la définition d'une plate-forme. Cependant, il convient de noter qu'il est préférable d'abandonner leur utilisation et d'implémenter la prise en charge de Haiku dans le code source du projet s'il existe des problèmes de construction similaires. L'appel de l'
utilitaire système
finddir avec un argument spécifique vous permet d'obtenir le chemin d'accès correct aux fichiers d'en-tête pour diverses architectures.
Donc, en exécutant les commandes ci-dessus, j'ai compilé un fichier exécutable qui fonctionnait parfaitement et le jeu fonctionnait parfaitement. Je pensais que ce serait cool de préparer un package HPKG autosuffisant avec le jeu et pour cela, je suis allé profondément dans Internet à la recherche des informations dont j'avais besoin. Ensuite, je ne connaissais pas d'outils pratiques pour le portage de logiciels, tels que HaikuPorter, dont j'ai parlé dans la section ci-dessus, donc pour atteindre mon objectif, j'ai décidé de tricher et de démonter un paquet système pour voir comment il est organisé à l'intérieur et faire par analogie.
Sur Internet, j'ai trouvé les
informations souhaitées, après quoi j'ai déballé un package système aléatoire à l'aide de l'archiveur
Expander intégré au gestionnaire de fichiers local, trouvé le fichier
.PackageInfo , l'
ai édité et, conformément à la structure de mon application, j'ai remplacé les fichiers. Ensuite, je viens d'exécuter les commandes pour créer le package HPKG et l'installer sur le système:
package create -C AAAA/ aaaa.pkg pkgman install aaaa.pkg
Malheureusement, le lancement du jeu à partir du menu "Applications" n'a pas réussi. En exécutant l'exécutable dans le terminal, j'ai reçu une erreur disant qu'il était impossible de trouver les fichiers de données nécessaires pour exécuter et exécuter l'application. Dans ce cas, si dans le terminal allez dans le répertoire du package d'application, alors tout a bien commencé. Cela m'a conduit à l'idée que lors du démarrage du jeu à partir du menu, vous devez effectuer une modification forcée dans le répertoire de l'application. Cela peut se faire soit avec un script Shell, soit en changeant la source du jeu. J'ai choisi la deuxième option et ajouté quelque chose de similaire à ce code:
#ifdef __HAIKU__
Au tout début de la fonction de démarrage
main () , qui a complètement résolu ce problème et le paquet s'est avéré être réalisable. Dans les commentaires sur les nouvelles de la sortie de la version bêta de Haiku sur
Linux.org.ru, j'ai laissé tomber le lien vers mon package assemblé et demandé à quelqu'un de m'envoyer dans certaines communautés d'utilisateurs actifs de ce système d'exploitation, puis je me suis couché.
Port de jeu d'Adamant Armor Affection Adventure fonctionnant sur Haiku.Le matin, une personne utilisant le surnom de
3dEyes m'a écrit un e-mail. Comme il s'est avéré plus tard,
Gerasim Troeglazov , l'un des développeurs Haiku actifs et auteur du port de framework Qt pour ce système d'exploitation, se cachait derrière ce nom. Il m'a montré le référentiel HaikuPorts et m'a expliqué comment utiliser l'utilitaire HaikuPorter. En outre, il a écrit une recette pour la construction du package HPKG pour Adamant Armor Affection Adventure et l'a ajouté à HaikuDepot.
Après avoir analysé toutes les modifications apportées par ce développeur, j'ai remarqué qu'il y avait des inconvénients dans mon package assemblé manuellement, par exemple, les paramètres n'étaient pas enregistrés, car les répertoires montés des packages installés n'avaient pas de capacités d'écriture. Ce problème d'écriture des paramètres ou des sauvegardes dans son package a été élégamment résolu à l'aide de liens symboliques dans un répertoire spécial accessible pour l'enregistrement et destiné à la sauvegarde des données utilisateur. Mon colis n'avait pas non plus sa propre icône d'origine.
De plus, j'ai appris que Haiku n'a pas d'accélération matérielle des graphiques 3D, et le même OpenGL est rendu par programme en utilisant la puissance du processeur. Pour les applications graphiques lourdes, cela n'est bien sûr pas bon, mais pour les jeux plus anciens, c'est plus que suffisant. J'ai même décidé de vérifier spécifiquement le package du jeu et d'installer Haiku sur mon ancien ordinateur portable, c'est-à-dire sur du vrai matériel. À ma grande surprise, l'image d'Adamant Armor Affection Adventure a rendu si vite que s'ils ne m'avaient pas parlé du manque d'accélération matérielle, je n'aurais pas remarqué que le rendu est fait par mon processeur.
Source du projet: https://github.com/EXL/AdamantArmorAffectionAdventureJ'ai reporté la création manuelle des packages HPKG jusqu'à des temps meilleurs et suis complètement passé à l'utilisation de l'outil HaikuPorter et à l'écriture de recettes. Mais parfois, il existe des situations où une reconstruction manuelle du package est nécessaire. Par exemple, si HaikuPorter définit la version de nuit de Haiku dans le fichier
.PackageInfo trop haut et que le package doit être testé sur la version
finale du système d'exploitation. Il convient de noter que c'est grâce à la réactivité et à l'expérience de Gerasim que j'ai pu comprendre les nombreuses subtilités de la création de packages pour le système d'exploitation Haiku et continuer mon travail.
<< Passer au contenu3. Modification du port NXEngine existant (Cave Story)
J'ai été incroyablement surpris de trouver une recette dans le référentiel HaikuPorts qui faisait référence à ma fourchette du moteur
NXEngine pour le jeu Cave Story , que j'avais
analysé sur mon
blog depuis très longtemps. La recette et les patchs ont été préparés par un développeur nommé
Zoltán Mizsei , utilisant le surnom
extrowerk et un mainteneur actif de nombreux packages pour Haiku.
Une analyse superficielle, l'installation du package et le lancement de l'application ont révélé les mêmes problèmes que ceux décrits dans la section précédente de cet article: la sauvegarde du jeu n'a pas fonctionné, les paramètres n'ont pas été enregistrés non plus, et le package n'avait pas l'icône d'origine. J'ai décidé de corriger ces lacunes et j'ai commencé à travailler sur le patch, en intégrant d'abord toutes les idées de l'extrowerk. J'ai écrit le
Makefile original pour le système d'exploitation Haiku et corrigé l'écriture et la sauvegarde de diverses données utilisateur.
Port du jeu Cave Story basé sur le moteur NXEngine, lancé dans le système d'exploitation Haiku.Depuis que le jeu a assumé les versions russe et anglaise avec un ensemble différent de fichiers exécutables et de fichiers de données, j'ai décidé de créer un package commun qui combine deux versions à la fois et sélectionne automatiquement la bonne en fonction de la langue du système choisie par l'utilisateur. Cela a été implémenté par le script Shell le plus simple:
Ce script est lancé lorsqu'un élément de jeu est sélectionné dans le menu "Applications" et détermine les paramètres régionaux actuels du système. Dans le cas où l'utilisateur a choisi le russe comme langue système, la version russe du jeu démarrera, et dans tous les autres cas, la version anglaise.
Mais avec la création de l'icône originale de l'application j'ai dû bricoler assez. Le fait est que dans le système d'exploitation Haiku, seules les icônes vectorielles du format
HVIF spécial sont
autorisées , qui sont définies comme des attributs du
système de fichiers
Be File System . Dans la documentation officielle, il y a deux grands manuels sur la création de vos propres icônes pour les applications: le
premier manuel décrit le style de dessin et de conception, et le
deuxième manuel explique en détail comment utiliser le programme système
Icon-O-Matic pour créer des icônes.
Icon-O-Matic vous permet d'importer les fichiers SVG les plus simples et d'exporter l'icône résultante dans le format nécessaire pour HaikuPorter, appelé HVIF RDef et représentant le même HVIF, mais converti en vue texte. Les fichiers RDef peuvent contenir non seulement des images, mais également des informations supplémentaires, par exemple la version de l'application et sa description. À certains égards, ces fichiers ressemblent aux fichiers RES utilisés dans Windows. Les commandes suivantes de la recette compilent les fichiers RDef et définissent le résultat sur des attributs spéciaux:
rc nxengine-launcher.rdef resattr -o "$appsDir/NXEngine/Cave Story" nxengine-launcher.rsrc addResourcesToBinaries $sourceDir/build/nxengine-rus.rdef "$appsDir/NXEngine/RUS/Cave Story"
De plus, la fonction
addResourcesToBinaries est définie dans les recettes, ce qui permet d'automatiser ce travail. Il y a un problème, mais très grave, avec Icon-O-Matic: les fichiers SVG que l'éditeur de vecteurs
Inkscape populaire enregistre ne s'ouvrent pas ou sont importés sans prendre en charge certaines fonctionnalités nécessaires, par exemple les dégradés. Par conséquent, une quête d'aventure avec la conversion d'images raster en images vectorielles grâce à l'utilisation de divers convertisseurs en ligne et hors ligne payants et gratuits, puis en ouvrant les fichiers SVG résultants dans Icon-O-Matic, j'ai échoué lamentablement. Plus tard, j'ai résolu le problème de l'ouverture des fichiers SVG et trouvé une solution de contournement, mais j'écrirai à ce sujet ci-dessous. En attendant, j'ai décidé de profiter des fonctionnalités standard d'Icon-O-Matic et de dessiner l'icône moi-même. Après une demi-heure de copie papier des pixels, j'ai obtenu l'art suivant:
Le programme Icon-O-Matic standard dans le système d'exploitation Haiku.Oui, j'ai utilisé un éditeur de vecteur pour créer une image dans le genre Pixel Art. Dans mon point de vue amateur d'un homme qui connaît mal l'art, cela s'est plutôt bien passé. J'ai enregistré cette icône dans le format requis, préparé toutes les modifications, mis à jour la recette et tout envoyé au référentiel HaikuPorts.
Code source du projet: https://github.com/EXL/NXEngineJ'ai envoyé les packages résultants juste au cas où et sur le site de fans du jeu
Cave Story (Doukutsu Monogatari) , dont l'administration a ajouté le système d'exploitation Haiku à la section de téléchargement.
<< Passer au contenu4. Portage du jeu Gish
Le prochain projet que j'ai décidé de transférer vers Haiku était le jeu
Gish , que j'avais précédemment porté sur Android. Le référentiel HaikuPorts avait une recette pour une implémentation gratuite inachevée d'un jeu appelé
Freegish , j'ai donc décidé d'y ajouter le jeu original également, mais sans fichiers de données, car contrairement au moteur, ils sont livrés séparément et ne sont pas du tout gratuits.
Port de jeu Gish fonctionnant sur le système d'exploitation Haiku.Je n'ai eu aucun problème particulier avec le portage de ce jeu. Le fichier exécutable a été compilé immédiatement après l'exécution des commandes de génération suivantes:
cmake gish/src/main/cpp/ \ -DGLES=0 \ -DANDROID=0 \ -DSDL2_INCLUDE_DIR=`finddir B_SYSTEM_HEADERS_DIRECTORY` \ -DCMAKE_C_FLAGS="`sdl2-config --cflags` -D__linux__" \ -DCMAKE_BUILD_TYPE=Release cmake --build .
Ensuite, j'ai implémenté la possibilité de lancer le jeu à partir du menu "Applications" et fourni un support pour l'enregistrement des données utilisateur dans un répertoire accessible pour l'enregistrement et destiné à cela:
char* getHaikuSettingsPath() { char path[PATH_MAX]; find_directory(B_USER_SETTINGS_DIRECTORY, -1, false, path, sizeof(path)); strcat(path, "/Gish/"); return strdup(path); }
La fonction
getHaikuSettingsPath () utilisant la fonction
find_directory () de l'API Haiku forme le chemin complet vers le répertoire dont j'ai besoin.
Code source du projet: https://github.com/EXL/GishIl restait à résoudre la question suivante: comment l'utilisateur devrait-il choisir le répertoire avec les fichiers originaux du jeu Gish? Vous pouvez essayer de résoudre le problème en utilisant des scripts Shell et l'utilitaire de système d'
alerte , mais j'ai décidé d'aborder ce problème de manière plus approfondie et d'implémenter un lanceur GUI pratique à l'aide de l'API Haiku et du cadre du
kit d'interface .
<< Passer au contenu5. Le projet BeGameLauncher, qui vous permet de créer rapidement des lanceurs de jeux
Il a été décidé d'écrire mon projet BeGameLauncher en C ++ de l'ancien standard de 1998, en utilisant les outils natifs du système d'exploitation pour créer des applications avec une interface utilisateur graphique. Étant donné que les noms de nombreux programmes pour Haiku et BeOS commencent par le préfixe «Be», j'ai également décidé de choisir un tel nom pour le projet. J'ai décidé de commencer par me familiariser avec le framework Interface Kit, qui fait partie de l'API Haiku. En plus de la documentation assez détaillée sur le site officiel de Haiku, j'ai trouvé deux excellents cours de
DarkWyrm qui permettent à un développeur novice de comprendre rapidement comment certaines classes système fonctionnent. Le premier cours s'intitule
Apprendre à programmer avec Haiku et au tout début couvre les bases du langage de programmation C ++, qui seront très utiles pour les débutants. Le deuxième cours est appelé
Programmation avec Haiku et est destiné à ceux qui sont déjà familiers avec C ++ et ont des connaissances de base de ce langage. Les deux cours parlent des aspects les plus divers de l'API Haiku et seront donc très utiles à quiconque souhaite commencer à créer des applications pour ce système d'exploitation.
Après avoir lu cet excellent matériel en diagonale, j'ai fait une impression générale de l'API Haiku et j'ai commencé à réfléchir à mes prochaines étapes. J'avais déjà une certaine expérience dans le développement d'applications d'application en utilisant le framework Qt, qui est également écrit dans le langage de programmation C ++ et utilise le paradigme de programmation orienté objet. Ainsi, l'API Haiku est très similaire à celle-ci, à l'exception de l'absence d'un système de signal et de slots, donc je vais souvent faire des parallèles et des comparaisons avec Qt. En outre, il convient de noter l'utilisation du principe de
programmation piloté par les
événements , qui est courant dans l'API Haiku, qui permet à diverses entités d'interagir les unes avec les autres par la transmission d'événements ou de messages. Un analogue de la classe
QEvent est ici la classe
BMessage , autour de laquelle se construit le système d'interaction des objets. Une instance de la classe
BMessage obtient généralement un numéro unique qui vous permet d'identifier l'expéditeur et son action dans un filtre d'événement commun.
Pour mon projet, j'ai dû choisir les classes API Haiku appropriées qui me permettraient d'implémenter les fonctionnalités prévues. Premièrement, pour lancer une application externe, il était nécessaire de trouver un analogue de la classe
QProcess ou de la fonction
POSVE execve () , qui, soit dit en passant, fonctionne également très bien dans le système d'exploitation Haiku, cependant, j'ai décidé que l'utilisation d'outils natifs serait préférable, mais juste au cas où l'affaire laissait la possibilité de lancer des applications via la fonction POSIX. La classe de communication interprocessus
BRoster était idéale à cet effet. Il a trouvé une méthode
Launch () appropriée qui vous permet de spécifier le chemin d'accès au fichier exécutable et de lui passer des arguments. Étant donné que le lanceur devrait être en mesure d'enregistrer certains paramètres, par exemple, un répertoire sélectionné par l'utilisateur avec des fichiers de données de jeu, j'avais besoin d'une classe qui fait tout cela. Dans Qt, une telle classe est appelée
QSettings , et dans l'API Haiku, comme Gerasim me l'a
demandé , il y a une classe
BMessage que je
connais déjà, qui a une fonctionnalité très utile. Le fait est que les informations de cette classe peuvent être facilement sérialisées et, par exemple, enregistrées sur disque. C'est très pratique et souvent utilisé pour enregistrer des données utilisateur dans des programmes, c'est pourquoi j'ai choisi cette classe pour enregistrer les paramètres dans mon projet pour implémenter des lanceurs.
Malheureusement, l'API Haiku n'a pas trouvé d'analogue de la classe QDebug , donc je viens de m'envoyer la sortie de débogage pendant le développement à stderr en utilisant la fonction fprintf () du langage de programmation C standard:
J'ai enveloppé cette fonction dans une entité BeDebug () qui me convient , qui, selon la norme de langue sélectionnée, est soit une macro, soit également une fonction. Cela a été fait du fait que C ++ 98 ne prend pas en charge les macros avec un nombre variable d'arguments.Qt Framework possède également une classe QMessageBox utile à travers laquelle vous pouvez créer une boîte de dialogue modale avec toutes les informations auxquelles l'utilisateur doit prêter attention, par exemple, une erreur ou un avertissement. L'API Haiku possède une classe BAlert à cet effet .dont l'implémentation est quelque peu différente de ce qui est disponible dans Qt. Par exemple, un objet de cette classe doit être créé sur le tas, et non sur la pile, car après une action utilisateur, il doit se supprimer. Quant aux autres classes de l'interface graphique, ici je n'ai eu absolument aucune difficulté et j'ai trouvé tout ce dont j'avais besoin sans aucun problème.Maintenant, j'aurais dû penser à l'architecture simple du projet. J'ai décidé de me concentrer sur la création d'une bibliothèque statique, dans laquelle il y aurait deux classes conçues pour en hériter leurs propres classes dérivées. La première classe et la plus importante, BeLauncherBase, est responsable de la création de la fenêtre principale du lanceur, du transfert de tous les paramètres utilisateur et offre la possibilité d'ajouter vos propres éléments GUI. La deuxième classe, BeAboutWindow , est simplement responsable de l'ouverture de la boîte de dialogue "A propos du programme ..." avec des informations qui sont affichées dans une fenêtre séparée. Ainsi, un programmeur doit faire deux étapes simples pour créer son lanceur, par exemple, pour jouer à Gish: class GishAboutWindow : public BeAboutWindow { ... }; class GishLauncher : public BeLauncherBase { ... }; int main(void) { BeApp *beApp = new BeApp(SIGNATURE); GishLauncher *gishLauncher = new GishLauncher(BeUtils::GetPathToHomeDir()); beApp->SetMainWindow(gishLauncher); beApp->Run(); delete beApp; beApp = NULL; return 0; }
Premièrement, créez une fonction de démarrage appropriée main () , et deuxièmement, héritez simplement des deux classes ci-dessus et implémentez-y les méthodes nécessaires. Après cela, nous compilons le fichier C ++ résultant avec un lien vers ma bibliothèque statique et notre lanceur pour le jeu Gish est prêt.Dialogue "A propos du programme ..." dans le lanceur du port du jeu Gish.Ensuite, j'ai réfléchi à la façon de transférer les paramètres de mon lanceur vers le moteur lui-même ou vers le fichier exécutable du jeu. Je n'ai vu que deux façons de résoudre ce problème. La première façon était de changer les variables d'environnement. En pratique, après avoir cliqué sur le bouton "Exécuter", le lanceur met simplement tous les paramètres dans des variables d'environnement en appelant la fonction setenv () , et le moteur de jeu lit ensuite ces paramètres en utilisant la fonction getenv () , qui semble assez simple. Le seul problème qui pourrait survenir ici était dans la classe BRoster et sa méthode Launch (): Je ne savais pas si l'application lancée à l'aide de cette classe héritera de toutes les variables d'environnement qui ont été définies dans le lanceur. Après une petite expérience, l'héritage des variables d'environnement a été confirmé, et j'ai complètement implémenté cette méthode dans mon projet. La deuxième façon de résoudre le problème était de définir des paramètres de ligne de commande spéciaux. En pratique, le lanceur place simplement tous les paramètres dans les arguments appropriés et appelle l'exécutable de l'application avec eux. Mais le moteur de jeu devait déjà les traiter indépendamment, ce qui a créé quelques difficultés. Par exemple, si le jeu ne supposait pas la possibilité de spécifier le chemin d'accès aux fichiers du jeu via les paramètres de ligne de commande, il était alors nécessaire de modifier l'analyseur d'arguments dans le moteur lui-même. Malgré ces problèmes,J'ai mis en œuvre ce mode d'interaction et, par conséquent, j'ai eu une excellente occasion de tout combiner ensemble. Cela m'a permis de créer une chaîne pour spécifier les arguments utilisateur dans certains lanceurs.Lorsque tout a été conçu, j'ai décidé de choisir un système d'assemblage pour mon projet. Seules deux options ont été envisagées: Makefile "on steroids" et CMake . Dans le premier cas, les développeurs du système d'exploitation Haiku ont préparé un package de moteur de makefile pratique dans lequel ils ont collecté toutes les fonctionnalités nécessaires auxquelles un développeur aurait été confronté en commençant à écrire une application sur l'API Haiku, par exemple, la génération de traduction automatique et la compilation des ressources d'application. Mais je ne fais pas partie de ceux qui recherchent des moyens faciles, j'ai donc choisi CMake et y ai transféré une partie du travail du package makefile-engine. En conséquence, vous pouvez regarder le script d'assemblage monstrueux résultant dans le référentiel du projet, un lien vers lequel je laisserai ci-dessous.Capture d'écran du lanceur de port de jeu Gish pour Haiku.Je voudrais écrire quelques mots sur la localisation des applications. Dans le framework Qt, il existe une fonction wrapper tr () pratique pour cela , deux utilitaires auxiliaires lrelease et lupdate , qui sont impliqués dans la génération de fichiers de traduction. Le cadre inclut même un programme spécial Qt Linguist avec une interface utilisateur graphique pratique conçue pour les traducteurs. Dans l'API Haiku, les outils de localisation d'application sont moins pratiques et plus archaïques. Il est proposé d'encapsuler les lignes à traduire dans une macro spéciale B_TRANSLATE () et d'ajouter la définition B_TRANSLATION_CONTEXT au fichier source, qui sépare un groupe de chaînes traduisibles d'un autre. Après cela, une chose très étrange doit être faite: définir le préprocesseur du compilateur avec l'indicateur -DB_COLLECTING_CATKEYS sur absolument tous les fichiers source du projet, faire de la magie avec l'utilitaire grep et enfin obtenir un énorme fichier PRE. C'est avec ce fichier que l'utilitaire collectcatkeys fonctionnera , qui créera déjà des fichiers CATKEYS de traducteur lisibles par l'homme et faciles à modifier. Après avoir localisé les chaînes, vous devez utiliser l'utilitaire linkcatkeys, qui ajoute des traductions aux ressources du fichier exécutable. Ainsi, lors du choix d'une langue système spécifique, l'application affiche les lignes traduites. Étrange, la documentation de l'API Haiku sur la localisation des applications contient très peu d'informations. Cependant, sur le site officiel, j'ai trouvé un excellent article Localiser une application , qui détaille de nombreux aspects de la traduction d'applications pour ce système d'exploitation. Si je comprends bien, le BeOS d'origine n'avait pas le framework Locale Kit et il a été ajouté uniquement à Haiku.Ma prochaine étape a été de choisir un environnement pour développer des applications dans le langage de programmation C ++. En raison du fait que le framework Qt a été porté sur Haiku, des IDE tels que Qt Creator et disponibles dans le référentiel HaikuPortsKDevelop . De plus, il existe un port JVM , qui vous permet d'utiliser des IDE écrits dans le langage de programmation Java, par exemple, NetBeans ou IntelliJ IDEA . J'ai opté pour l'environnement de développement Qt Creator, d'autant plus que dans ses dernières versions, il existe une analyse de haute qualité du code à l'aide de l'analyseur LibClang , qui fonctionne beaucoup plus précisément et plus rapidement que l'analyseur standard.L'environnement de développement intégré Qt Creator fonctionnant sur le système d'exploitation Haiku.En termes d'IDE bien connus et multiplateformes à Haiku, tout va bien. Mais qu'en est-il des solutions exclusives? Je ne peux que mentionner un projet très intéressant, parrainé par DarkWyrm et qui soutient actuellement Adam Fowler , il s'appelle Paladin . Ce programme rend l'éditeur de texte Pe disponible dans la distribution du système d'exploitation presque un véritable IDE.Paladin IDE pour Haiku installé à partir du référentiel HaikuPorts.En utilisant le carrelage intégré dans le système de fenêtres Haiku, vous pouvez attacher la fenêtre Paladin sur le côté de l'éditeur Pe et ajouter un terminal. Toujours dans le référentiel HaikuPorts, il existe un éditeur de texte Koder pratique qui ressemble au populaire programme Notepad ++ pour Windows et est également basé sur l'expérience du projet Scintilla . Pour mon application, j'ai créé un fichier PLD de projet et maintenant tout développeur qui utilise l'IDE Paladin peut facilement ouvrir mon projet dans ce programme.Lorsque l'environnement de développement Qt Creator a été configuré et prêt à fonctionner, j'ai commencé à réaliser toutes les fonctionnalités prévues. Le premier problème que j'ai rencontré était lié aux contrôles de mise à l'échelle lors du changement de la taille de la police système. Initialement, dans BeOS, tout le code de placement des éléments GUI était défini explicitement en coordonnées. C'était très gênant, bavard et a créé un énorme tas de problèmes, par exemple, avec le même changement de taille de police, toute la forme de l'application a été dispersée et est devenue inutilisable. Heureusement, Haiku a essayé de résoudre ce problème et a ajouté l' API Layout , qui fait partie du cadre du kit d'interface.Grâce à l'utilisation de l'API Layout, les lanceurs répondent correctement à la modification de la taille de la police système dans Haiku.Cette innovation a complètement résolu mon problème avec les commandes de positionnement et j'ai réécrit l'application en utilisant l'API Layout, ce qui a considérablement réduit la longueur du code à certains endroits. Sur le site officiel de Haiku, j'ai trouvé une série d'articles intéressants Laying It All Out , qui expliquent simplement les raisons pour lesquelles cette interface logicielle a été créée et montre des exemples de son utilisation.Un autre problème a été identifié par Gerasim lorsqu'il a essayé d'utiliser ma bibliothèque pour créer un lanceur pour le jeu qu'il a porté. Le fait était que je me suis souvent tourné vers le code source du système d'exploitation Haiku lui-même pour implémenter diverses fonctionnalités. En particulier, j'ai trouvé un exemple d'utilisation de la méthode Launch () sur un objet de la classe BRoster . Le problème s'est manifesté par le fait que cet exemple était incorrect et que le moteur de jeu porté par Gerasim n'a pas pu analyser correctement les arguments définis par le lanceur. Après avoir étudié le code source de Haiku plus en profondeur, j'ai réussi à découvrir que le premier argument, qui devrait contenir le chemin d'accès complet au fichier exécutable, n'a pas besoin d'être défini explicitement dans le cas de la méthode Launch () , car il sera défini automatiquement.
La documentation de la méthode Launch () ne dit pas que le premier argument n'est pas requis, c'est probablement pourquoi le développeur a mal écrit ce code. J'ai corrigé cette erreur dans mon projet et le problème de Gerasim a été résolu par lui-même. Mais qu'en est-il de cette petite erreur dans le système d'exploitation Haiku lui-même? J'ai décidé de la réparer aussi. Heureusement, cela s'est avéré très facile à faire! Vous devez vous connecter en utilisant GitHub à la ressource Gerrit de Haiku Code Review , ajouter votre clé SSH publique, bifurquer le code source de Haiku, créer un commit commit et envoyer le patch résultant à Code review à des développeurs privilégiés: git clone ssh://EXL@git.haiku-os.org/haiku --depth=1 -b master && cd haiku git commit git push origin master:refs/for/master
Si vous devez mettre à jour des correctifs qui ont déjà été envoyés, avant d'envoyer des modifications ou de nouvelles validations, assurez-vous d'ajouter l'ID que le service Haiku Code Review nous a donné à la fin du message de validation. Une fois le correctif envoyé, les développeurs de Haiku doivent l'approuver, le rejeter ou le soumettre pour révision. Dans mon cas, la correction a été acceptée immédiatement et ce petit défaut est désormais corrigé partout. Si vous devez tester vos correctifs avant de les envoyer au référentiel, vous pouvez essayer de compiler une application distincte à l'aide de l'utilitaire jam , qui est un fork du système de génération Perforce Jam et qui est utilisé pour créer la base de code entière du système d'exploitation Haiku. Le référentiel de code source a le fichier ReadMe.Compiling.md, qui vous aidera à gérer toutes les astuces de compilation.Lors de la finalisation de mon projet, j'ai trouvé la raison pour laquelle le programme Icon-O-Matic n'ouvre pas les fichiers SVG créés à l'aide de l'éditeur vectoriel Inkscape. Le fait est que Icon-O-Matic n'est pas en mesure de traiter l'attribut viewBox , cependant, si vous trouvez un fichier SVG simple sans cet attribut, modifiez-le avec Inkscape et enregistrez-le en tant que fichier SVG ordinaire , il s'ouvrira dans Icon-O -Matic. Par conséquent, j'ai mis dans mon référentiel un fichier SVG spécialement préparé qui peut être édité et qui s'ouvrira dans Icon-O-Matic sans aucun problème. De plus, j'ai ajouté une petite instruction au fichier Lisez-moi du projet sur la façon de créer des icônes pour mes lanceurs à l'aide d'Inkscape.J'ai décidé de vérifier le code de mon projet avec une variété d'analyseurs statiques, mais ils n'ont trouvé aucun problème sérieux. Mais j'ai trouvé plus tard un problème qu'ils n'ont pas pu détecter. Le fait que la méthode statique GetBitmap () classe BTranslationUtils pourrait retourner NULL:
Et dans la méthode Draw () , j'ai oublié par inadvertance de vérifier la validité du champ de la classe fBitmap . Par conséquent, l'application devait se planter si elle ne trouvait pas une certaine image, mais selon le plan, elle devait dessiner un carré rouge à la place. J'ai raconté cette histoire au fait que les analyseurs statiques sont loin d'être une panacée et qu'il faut de toute façon être attentif lorsque l'on travaille avec du code dans le langage de programmation C ++.Le code source du projet BeGameLauncher et toutes mes meilleures pratiques sont téléchargés dans le référentiel sur GitHub. J'espère que ce programme sera utile à quelqu'un et pourra être une sorte de tutoriel comme une simple application pour Haiku:Code source du projet: https://github.com/EXL/BeGameLauncherUn petit conseil pour ceux qui utiliseront mon lanceur dans leurs recettes pour le référentiel HaikuPorts. Si vous souhaitez masquer l'exécutable du jeu de la liste des applications Haiku que certains programmes lisent et ne laisser que le lanceur, vous pouvez utiliser l'astuce suivante: settype -t application/x-vnd.Be-elfexecutable $appsDir/Gish/engine/Gish rc $portDir/additional-files/gish.rdef -o gish.rsrc resattr -o $appsDir/Gish/engine/Gish gish.rsrc
Cela exclura la possibilité d'exécuter des fichiers exécutables sans paramètres transmis par le lanceur à partir de divers programmes tels que QuickLaunch , qui sont engagés dans le lancement rapide d'applications. Dans ce cas, votre icône d'origine sur le fichier exécutable sera enregistrée.<< Passer au contenu6. Portage de Xash3D: jeu de demi-vie légendaire et modules complémentaires officiels
Le projet Xash3D est une implémentation gratuite du moteur GoldSrc, qui est utilisé dans le jeu Half-Life et dans ses add-ons officiels. Derrière le développement de Xash3D se trouve le programmeur domestique Oncle Misha , qui coordonne toujours son développement et son amélioration. Un peu plus tard, d'autres développeurs ont rejoint le projet qui ont créé un fork de FWGS Xash3D , avec la prise en charge d'un grand nombre de systèmes d'exploitation non Windows. Aujourd'hui, les programmeurs clés du projet FWGS Xash3D sont mittorn et a1batross ( libpony ), la dernière personne était un participant actif au forum MotoFan.Ru, autrefois populaire .que j'administre toujours pendant mon temps libre.Je me suis demandé: pourquoi ne pas porter ce moteur sur Haiku, ajoutant la prise en charge d'un système d'exploitation aussi intéressant au projet Xash3D, et donner aux utilisateurs de Haiku la possibilité de jouer au légendaire Half-Life, un jeu de tous les temps? Le problème est resté limité - il a été nécessaire de commencer immédiatement les travaux de portage et, en cas de succès, de publier les résultats de ces travaux.Après avoir passé plusieurs heures à étudier la structure du projet et les parties du code qui sont responsables de la prise en charge de diverses plates-formes, j'ai commencé à apporter des modifications au moteur Xash3D pour prendre en charge le système d'exploitation Haiku. À l'ancienne, j'ai défini le compilateur -D__linux__et a essayé de construire un exécutable et un tas de bibliothèques. Étonnamment, les choses se sont déroulées assez rapidement et le soir, après avoir transmis les fichiers de données du jeu, j'ai réussi à lancer Half-Life et à prendre le train jusqu'à la gare principale de Black Mesa.Processus de portage du moteur Xash3D vers Haiku dans l'IDE Qt Creator.Étant donné que le projet utilise la bibliothèque SDL2 multiplateforme, le portage du moteur est grandement simplifié, car vous n'avez pas besoin d'écrire de morceaux de code qui dépendent de la plate-forme, par exemple: sortie de son, création d'une fenêtre avec un contexte OpenGL ou gestion des événements d'entrée. Tout cela a déjà été implémenté dans la bibliothèque SDL2 et est prêt à l'emploi. Un petit problème est survenu avec la prise en charge du réseau, car Haiku a une bibliothèque distincte qui implémente la pile réseau, elle devait donc être liée au moteur.Le projet de création de lanceurs, sur lequel j'ai écrit un peu plus haut, m'a été très utile. En utilisant l'héritage des classes C ++, j'ai sérieusement étendu ses fonctionnalités et implémenté la possibilité de sélectionner divers ajouts au jeu:Capture d'écran du lanceur de port du moteur Xash3D pour Haiku.L'idée était la suivante: définir trois variables d'environnement qui vous permettraient de configurer de manière flexible le moteur de jeu pour lancer un module complémentaire spécifique. Dans ce cas, il serait utile de laisser l'utilisateur jouer avec les différents arguments du fichier exécutable et de laisser la possibilité de lancement portable du moteur lorsqu'il se trouve juste dans le répertoire contenant les fichiers de données requis. Ainsi, la première variable d'environnement XASH3D_BASEDIR est responsable du répertoire avec les fichiers de jeu que l'utilisateur sélectionne dans le lanceur. La deuxième variable XASH3D_GAME est responsable de l'ajout que l'utilisateur a sélectionné pour le lancement dans le lanceur. Et voici la troisième variable XASH3D_MIRRORDIR, utile uniquement aux utilisateurs avancés. Il vous permet de mettre en miroir le répertoire système Xash3D sur n'importe quel espace disque accessible en écriture pour l'utilisateur. Ainsi, une personne qui souhaite publier son jeu complémentaire sur le moteur Xash3D sous Haiku a juste besoin de collecter plusieurs bibliothèques dynamiques pour différentes architectures à partir du code source de son projet:• ./cl_dlls/libclient-haiku.so• ./dlls/libserver-haiku .so• ./cl_dlls/libclient-haiku64.so• ./dlls/libserver-haiku64.soEt puis placez-les dans les répertoires appropriés de votre module complémentaire. Pour mon port Xash3D, j'ai décidé de précompiler des bibliothèques de modules complémentaires populaires pour le jeu Half-Life, à savoir Blue Shift et Opposing Force, qui permet aux utilisateurs de télécharger simplement leurs fichiers de données, de sélectionner un répertoire et de démarrer le jeu sans aucune compilation de bibliothèque.Dans le processus de portage du moteur Xash3D, j'ai rencontré des problèmes amusants. Il s'avère que pour déterminer la longueur du message d'aide pour les arguments du fichier exécutable qui est généré lorsque le paramètre --help est passé , le moteur a utilisé la taille prédéfinie de la constante MAX_SYSPATH , qui est un alias d'une autre constante MAX_PATH , dont la valeur est déjà extraite de l'API Haiku. Donc, pendant longtemps, je n'ai pas pu comprendre pourquoi ce certificat est délivré incomplet et coupé à l'endroit le plus intéressant. Au début, j'ai péché que d'une manière étrange au flux de sortie d'erreur standardstderr a connecté la mise en mémoire tampon et a même essayé de la désactiver de force. Après un certain temps, je me suis souvenu que j'étais surpris par la très petite taille de la constante MAX_PATH dans le système d'exploitation Haiku. Cette constante suppose une taille de chemin de seulement 1024 octets. Ma conjecture a payé, dès que j'ai augmenté la taille du message à 4096 octets standard, le problème a été résolu. La conclusion suivante doit être tirée de cette histoire amusante: vous ne devez pas utiliser la constante MAX_PATH dans des tableaux de caractères qui ne sont en aucun cas associés à des chemins de fichier.Un collage de captures d'écran du jeu Half-Life, ainsi que ses ajouts officiels Blue Shift et Opposing Force, lancés à l'aide du moteur Xash3D dans le système d'exploitation Haiku (aperçu, augmentation par référence ).Un autre problème était le plantage lors de l'utilisation des fonctionnalités du moteur lui-même pour sélectionner le module complémentaire pour le jeu. Il s'est avéré que lorsque la définition XASH_INTERNAL_GAMELIBS a été définie, la bibliothèque cliente a été chargée non pas une, mais deux fois. Ce qui entraînait un problème similaire. Comme m'a expliqué a1batross , cela a été fait afin qu'il soit possible de lier statiquement la bibliothèque OpenVGUI à la bibliothèque cliente. Dans mon port Xash3D sur Haiku, cette bibliothèque n'est pas utilisée en aucune façon, j'ai donc juste évité d'utiliser la valeur par défautXASH_INTERNAL_GAMELIBS et a signalé ce bogue aux développeurs du moteur.Puis je suis tombé sur l'impossibilité d'ouvrir le navigateur WebPositive intégré à Haiku en cliquant sur les liens à l'intérieur d'un jeu fonctionnant sous Xash3D. Le problème était vraiment étrange, car lorsque le moteur a été démarré à partir du terminal, le navigateur s'est ouvert, mais lorsqu'il a commencé à utiliser le lanceur, il a refusé de le faire. Après avoir étudié un peu le code, j'ai trouvé l'appel execve () , que j'ai essayé de remplacer par system () , après quoi le navigateur a commencé à s'ouvrir sans aucun problème.Lorsqu'une erreur se produit, le moteur Xash3D utilise activement les appels de fonction SDL_ShowSimpleMessageBox () et SDL_ShowMessageBox (), seul le port de bibliothèque SDL2 actuel pour Haiku ne prend pas en charge la création de ces boîtes de dialogue. Notre version de la bibliothèque n'a tout simplement pas cette fonctionnalité. Mais je vais parler de résoudre ce problème ci-dessous.Le port du moteur Xash3D, publié dans le référentiel Haiku Depot.Il convient également de noter qu'avant mon transfert du moteur Xash3D vers Haiku, Gerasim Troeglazov a implémenté une capture de curseur de souris en SDL2; Avant cela, jouer à des jeux 3D était presque impossible. Un peu plus tard, il a corrigé un bug délicat, dans lequel le mouvement du joueur dans l'espace était progressivement ralenti, et le jeu commençait à ralentir terriblement. Il s'avère que le fait était que par défaut les événements du curseur de la souris étaient transmis avec toute son histoire de mouvement autour de l'écran. En conséquence, cette histoire s'est rapidement gonflée pendant le jeu et tout a commencé à ralentir considérablement. La désactivation de cette fonctionnalité dans le port Haiku SDL2 a résolu ce problème et vous pouvez maintenant jouer à Half-Life sans aucun problème. Cependant, le manque d'accélération 3D sur du matériel faible se fait sentir. Et si le jeu fonctionne décemment dans la fenêtre et ne ralentit pas du tout, alors en mode plein écran, le FPS est considérablement réduit.Mais ici, cela n'aidera qu'à ajouter une accélération matérielle au pilote vidéo pour au moins les GPU intégrés aux processeurs Intel populaires.Code source du projet: https://github.com/FWGS/xash3dJ'ai envoyé toutes les modifications du code source aux développeurs du projet FWGS Xash3D qui les ont acceptés dans le référentiel, et les packages avec ce moteur sont depuis longtemps disponibles dans HaikuPorts et dans le programme HaikuDepot pour tout utilisateur de Haiku .<< Passer au contenu7. Portage des deux parties du jeu Serious Sam: The First Encounter et The Second Encounter
Récemment, les développeurs de Croteam ont publié le code source de Serious Engine , qui est utilisé dans les jeux de la série Serious Sam: The First Encounter et The Second Encounter . J'ai décidé de le porter sur le système d'exploitation Haiku, j'ai téléchargé le code source et j'ai commencé à travailler.Capture d'écran du lanceur de port Serious Engine pour Haiku.L'assemblage du fichier exécutable après les modifications a été effectué sans aucun problème, mais il n'a pas été si facile de démarrer le jeu en raison du fait que des erreurs ont été versées dans les boîtes de dialogue SDL2, qui ne sont pas implémentées dans la version de cette bibliothèque pour Haiku. Par conséquent, j'ai dû prendre le stderr , le flux de sortie d'erreur standard éprouvé dans le temps, et trier lentement les problèmes, qui se sont révélés être principalement en l'absence des fichiers de données de jeu requis.Capture d'écran du jeu Serious Sam: The Second Encounter lancé à l'aide du port Serious Engine pour le système d'exploitation Haiku.Après avoir décomposé les fichiers téléchargés dans les répertoires requis, j'ai pu exécuter la deuxième partie de ce merveilleux jeu sans aucun problème et j'ai même parcouru un peu la belle jungle. Malgré le manque d'accélération 3D, le processeur dessine les charmes graphiques du jeu si vous l'exécutez dans une fenêtre, et non en mode plein écran. Ce moteur fonctionne, bien sûr, avec des FPS beaucoup plus faibles que le moteur Xash3D, dont j'ai écrit ci-dessus, mais les graphismes ici sont plus modernes et meilleurs. Après des manipulations mineures, il a été possible de lancer la première partie du jeu, qui nécessite un fichier exécutable différent et un ensemble différent de bibliothèques dynamiques. Étonnamment, elle a gagné un peu plus vite, apparemment les graphismes ne sont pas si exigeants. En gravissant les paramètres du moteur, j'ai trouvé un grand nombre de paramètres graphiques qui peuvent réduire considérablement la charge sur le processeur,ce qui s’est avéré très utile dans le cas de Haiku.
void CUnixDynamicLoader::DoOpen(const char *lib) {
Une petite astuce qui a remplacé le chemin complet de la bibliothèque requise dans la fonction s'est avérée être une solution complètement fonctionnelle. Et puisque la bibliothèque en son absence est recherchée plusieurs fois par le moteur, pour l'avenir j'ai laissé la possibilité de charger la prochaine version majeure. J'espère qu'ils n'y cassent pas l'API.Le problème suivant que j'ai rencontré était l'incapacité de déterminer la fréquence du processeur sur l'architecture x86, bien que tout fonctionnait bien sur x86_64. Lors de l'exécution sur x86, le moteur a demandé de définir une variable d'environnement avec le nom SERIOUS_MHZet définir la fréquence appropriée, ce qui m'a beaucoup surpris. J'ai essayé de le faire et le jeu a vraiment commencé, mais pour une raison quelconque, cela a fonctionné trop lentement. En gravissant le code source du jeu, pendant longtemps, je n'ai pas pu trouver la source du problème et j'ai même écrit un morceau de code qui utilise l'API Haiku pour obtenir la fréquence de processeur correcte et la remplacer dans le moteur de jeu, voici à quoi cela ressemblait: #include <kernel/OS.h> #include <stdio.h> ... uint64 cpuFreq = 0; uint32 count = 0; get_cpu_topology_info(NULL, &count); if (count != 0) { cpu_topology_node_info *topology = new cpu_topology_node_info[count]; get_cpu_topology_info(topology, &count); for (uint32 i = 0; i < count; ++i) { if(topology[i].type == B_TOPOLOGY_CORE) { cpuFreq = topology[i].data.core.default_frequency; } } delete[] topology; } fprintf(stderr, "%llu\n", cpuFreq);
Mais cela n'a pas aidé. Ensuite, j'ai vérifié les journaux du moteur sur x86_64 et j'ai vu que la fréquence du processeur est généralement déterminée à 1 MHz, mais tout fonctionne bien. En continuant à examiner le code plus loin, je suis tombé sur un déni de la définition de __GNU_INLINE_X86_32__ , qui est automatiquement exposé lorsque l'application est construite pour l'architecture x86, mais pas pour x86_64. En dessous de cette définition, l'indicateur qui utilisait les minuteries SDL2 était caché, au lieu d'obtenir la fréquence du processeur en utilisant diverses magies comme l'assembleur en ligne et l'instruction rdtsc ou en lisant le fichier / proc / cpuinfo , j'ai donc activé cet indicateur et pour x86, ce qui a résolu mon problème.Le dernier défaut était lié à ma négligence. J'ai raté dans le dossier d'assemblageCMakeLists.txt définissant le drapeau -march = native , qui indique littéralement au compilateur: lors de la génération de blocs de code machine, utilisez toutes les instructions sophistiquées et modernes disponibles sur le processeur de votre ordinateur. if(NOT PANDORA AND NOT HAIKU) message("Warning: arch-native will be used!") add_compile_options(-march=native) endif() if(HAIKU) if(CMAKE_SIZEOF_VOID_P EQUAL 4)
Pour cette raison, les packages dans le référentiel se sont réunis exclusivement sous le serveur de génération le plus puissant et ont refusé de s'exécuter sur les ordinateurs des mortels ordinaires, jurant les mauvaises instructions et les mauvais codes d'opération. La désactivation de cet indicateur et l'ajout manuel de la prise en charge des instructions MMX, SSE et SSE2 ont non seulement résolu ce problème, mais nous ont également permis de compiler un énorme groupe d'assembleurs en ligne dans ce projet, qui est tombé après la suppression de cet indicateur.À mon grand regret, les développeurs de Croteam n'acceptent aucun correctif dans le référentiel du moteur, j'ai donc bifurqué et y mettre tout mon travail:Code source du projet: https://github.com/EXLMOTODEV/Serious-EngineDes packages prêts à installer pour le lancement de jeux Serious Sam sont déjà disponibles dans le référentiel HaikuPorts. N'oubliez pas de télécharger les fichiers de données du jeu.<< Passer au contenu8. Portage du jeu Vangers
Franchement, jusqu'à récemment, je n'étais pas du tout familier avec ce jeu, qui dans les années 90 lointaines a été réalisé par le studio de développement national KD Lab. Mais les participants à la conférence de Telegram IM , consacrée à discuter du système d'exploitation Haiku, m'ont demandé de porter Vangerov et m'ont donné un lien vers le référentiel GitHub , dans lequel se trouvaient les sources de ce jeu.Capture d'écran du lanceur de port de jeu Vanger pour Haiku.Après avoir introduit le code source dans Haiku, j'ai essayé de le compiler et j'ai réussi sans aucun problème particulier. J'ai dû bricoler un peu avec le manque de certains fichiers d'en-tête et avec les chemins vers les bibliothèques FFmpeg qui sont utilisées par le moteur de ce jeu. J'ai immédiatement commencé à préparer le code source pour l'empaquetage, j'ai donc ajouté la variable d'environnement VANGERS_DATA et déplacé le journal du moteur dans le répertoire utilisateur accessible en écriture.Processus de portage d'un jeu Vanger vers Haiku dans l'IDE Qt Creator.J'ai commencé le jeu lui-même et après un moment j'ai apprécié toute l'atmosphère que les gars de KD Lab ont réussi à créer. Après un certain temps, j'ai commencé à porter légèrement le Nimbus à l'incubateur et le flegme à Podish, après quoi j'ai même réussi à amener l'Elik au troisième. Ayant suffisamment joué, j'ai commencé à préparer un lanceur pour ce jeu basé sur ma bibliothèque, sur laquelle j'ai écrit ci-dessus.Un port de jeu pour Vanger fonctionnant sur le système d'exploitation Haiku.Le premier problème que j'ai rencontré était que les fichiers de données de jeu, qui pouvaient être obtenus officiellement en utilisant les services de distribution numérique GOG.com et Steam , ne voulaient pas fonctionner avec le moteur. J'ai dû contacter une personne qui utilise le surnom de stalkerg et qui portait Wanger sur Linux. Il m'a dit quels fichiers remplacer, pour que tout commence et commence à fonctionner. J'ai suivi ses recommandations et obtenu ce dont j'avais besoin.Comme dans le cas du port NXEngine (Cave Story), dont j'ai parlé ci-dessus, les versions russe et anglaise diffèrent dans différents fichiers exécutables, mais le répertoire avec les fichiers de données est courant, les différences ne concernent que les scripts. À la pointe de stalkerg, j'ai essayé de compiler le moteur de jeu avec l'option -DBINARY_SCRIPT = Off , qui a activé la compilation dynamique de ces scripts au moment de l'exécution, s'ils se trouvent dans le répertoire du fichier de données de jeu. Tout cela m'a permis de créer un lanceur, dans lequel il est possible de changer de langue. L'idée est la suivante: le répertoire du jeu est pré-vérifié, et s'il n'a pas les scripts nécessaires, ils sont copiés à partir des entrailles du package, après quoi le fichier exécutable de la version russe ou anglaise est déjà en cours d'exécution.Le port de jeu de Vanger, publié dans le référentiel Haiku Depot.Lors du portage de Wanger, j'ai utilisé une fonctionnalité intéressante liée aux bibliothèques partagées que j'aime à propos de Haiku. Le moteur de jeu dépend de la bibliothèque dynamique libclunk.so , qui est responsable de la génération de sons binauraux en temps réel. Et si sous Linux, je dois me casser les doigts, en remplaçant le chemin vers cette bibliothèque dans la variable d'environnement LD_LIBRARY_PATH , afin que ce qui était dans cette variable avant cela soit également enregistré, alors dans Haiku, cela se fait de manière pratique, comme dans Windows. Il suffit de mettre la bibliothèque partagée à côté du fichier exécutable et elle sera récupérée, à la seule différence que dans le cas de Haiku, la bibliothèque doit être placée dans le répertoire ./lib/, ce qui, à mon avis, peut considérablement économiser du temps et des nerfs. Par conséquent, j'ai décidé de ne pas considérer la compilation statique de cette bibliothèque.Code source du projet: https://github.com/KranX/Vangers Lesdéveloppeurs de Wanger ont accepté mes modifications de leur moteur de jeu, et des packages prêts à installer sont disponibles en téléchargement à partir du référentiel HaikuPorts ou du programme HaikuDepot, malgré le récent fakap dans l'infrastructure du référentiel qui s'est produit après Mise à jour de la distribution Fedora Linux vers la nouvelle version.<< Passer au contenu9. Implémentation de dialogues dans la bibliothèque SDL2 pour Haiku
Lors du portage des moteurs Xash3D et Serious Engine, dont j'ai parlé ci-dessus, je suis tombé sur un port local de la bibliothèque SDL2 où il y avait un manque total d'implémentation des dialogues. Les dialogues sont appelés par deux fonctions SDL_ShowSimpleMessageBox () et SDL_ShowMessageBox () , qui permettent d'informer l'utilisateur de toute information importante, par exemple, sur une erreur. L'implémentation de ces boîtes de dialogue est disponible sur de nombreuses plates-formes et systèmes d'exploitation: Windows, macOS, iOS, X11 et Android, mais pour une raison quelconque, il manque à Haiku. J'ai décidé de corriger cette omission et d'ajouter cette fonctionnalité au port de bibliothèque SDL2.Dans l'API Haiku, ou plutôt dans le framework Interface Kit, il y a une merveilleuse classe BAlertce qui est idéal pour mettre en œuvre de tels dialogues. J'ai décidé de le choisir comme base. La seule chose qui m'a dérangé, c'est que je n'étais pas sûr que plus de trois boutons puissent être placés dans la boîte de dialogue que BAlert construit . Je me suis également souvenu des fonctionnalités de gestion de la mémoire de cette classe dont j'ai parlé ci-dessus: ses objets ne peuvent être créés que sur le tas et ne peuvent pas être créés sur la pile, car après avoir appelé la méthode Go () et l'action utilisateur suivante, il se supprime. Après avoir mené quelques expériences, j'ai dissipé tous mes doutes, hérités de cette classe et commencé à écrire une implémentation.Implémentation de dialogues dans la bibliothèque SDL2 pour le système d'exploitation Haiku.La première difficulté que j'ai rencontrée a été que lors de l'utilisation d'un objet de la classe BAlert ou de ses descendants, il était nécessaire de créer une instance de la classe système BApplication , apparemment afin d'enregistrer l'application dans app_server pour pouvoir interagir avec elle. J'ai créé une instance de cette classe, mais lors de l'appel de la boîte de dialogue BAlert à partir d'un autre processus ou de la fenêtre créée, j'ai eu une autre erreur liée au fait que l'application ne peut pas avoir deux objets de la classe BApplication , heureusement j'ai trouvé une solution à ce problème. L'API Haiku a un pointeur global sur l'instance actuelle de la classeBApplication , appelée be_app , son homologue dans le cadre Qt est une macro qApp spéciale , qui définit également un pointeur vers l'objet d'application actuel. Donc, il suffit de simplement vérifier le pointeur be_app pour NULL, et si la vérification réussit, créez l'objet requis. Ainsi, tous ces problèmes ont été résolus.Il convient de noter que la bibliothèque SDL2 est écrite dans le langage de programmation C et que l'API Haiku, comme vous le savez, utilise le langage de programmation C ++. Pour cette raison, certaines parties du code doivent être recouvertes de conventions de liaison externes "C" afin qu'il n'y ait aucun problème avec la résolution de caractères lors de la liaison. De plus, au lieu denew , vous devez utiliser le nouvel opérateur (std :: nothrow) pour pouvoir vérifier la mémoire allouée pour NULL, au lieu de lever des exceptions, dont le traitement que SDL2, bien sûr, ne prend pas en charge.Le reste n'a rien de compliqué. Nous écrivons plusieurs fonctions qui convertissent les entités et les représentations SDL2 de manière à ce qu'elles soient compatibles avec l'API Haiku et vérifions qu'elles fonctionnent correctement. Pour diverses vérifications, j'ai élargi le petit test., que j'ai régulièrement exécuté sur différents systèmes d'exploitation, analysé les résultats et évalué mon travail. En fin de compte, je me suis tellement emporté que j'ai même pris en charge la personnalisation, comme la définition de différentes couleurs pour les boutons et l'arrière-plan de la boîte de dialogue. Ceci est pris en charge dans l'API de la bibliothèque SDL2, mais au départ, je n'avais pas prévu de mettre en œuvre de telles choses.Si le programmeur décide de cracher une très, très longue ligne dans cette boîte de dialogue, l' objet de classe BTextView , qui est utilisé à l'intérieur de l' objet de classe BAlert , doit appeler la méthode SetWordWrap () avec l'argument truepour frapper un tel programmeur dans ses bras et faire tenir le dialogue à l'écran. Il semblerait qu'il n'y ait rien de plus simple: nous vérifions la longueur de la chaîne en utilisant la fonction strlen () et faisons ce qu'il faut. Le seul problème est que SDL2 fonctionne également avec UTF-8, ce qui signifie que la fonction strlen () renverra le nombre d'octets, pas le nombre de caractères. L'API Haiku et la classe de chaîne BString viennent à la rescousse , qui a la méthode CountChars () , qui vous permet de trouver la longueur de la chaîne en caractères, pas en octets: bool CheckLongLines(const char *aMessage) { int final = 0;
Cette fonction vérifie le texte du message pour les lignes de plus de 120 caractères et, le cas échéant, renvoie true. Quant à UTF-8, il y avait encore un moment tel que dans certaines polices système Haiku, il n'y avait pas de support pour les caractères chinois. Par conséquent, par exemple, vous ne pouvez pas définir d’inscription chinoise dans le titre de la fenêtre. Mais le texte en russe est installé sans problème.Lors de la préparation du package, j'ai rencontré une erreur de génération pour l'architecture x86_gcc2, qui est activée dans la recette de la bibliothèque SDL2. Il s'est avéré que le plus ancien compilateur GCC 2.95 ne pouvait pas deviner que le code commenté était équivalent à celui ci-dessous: rgb_color ConvertColorType(const SDL_MessageBoxColor *aColor) const {
Par conséquent, j'ai dû réécrire ce fragment dans l'ancien style et toujours supprimer l'initialisation de certaines constantes de la classe directement dans leurs déclarations, l'ancien compilateur n'aimait pas cela non plus.J'ai envoyé des correctifs pour l'implémentation des boîtes de dialogue SDL2 au référentiel HaikuPorts, donc maintenant les moteurs Xash3D et Serious Engine peuvent correctement envoyer toutes les informations à l'utilisateur, par exemple, sur les erreurs. Mais je n'ai pas encore contacté les développeurs SDL2, mais ce serait bien de transférer tous les correctifs du référentiel HaikuPorts vers la bibliothèque SDL2 en amont. Bien que le travail de portage de nos correctifs soit devenu un peu plus compliqué en raison du récent changement de nom des préfixes de fonction de BE_ * en HAIKU_ * , ce n'est pas un problème si sérieux.<< Passer au contenu10. Portage de ma fourchette de Cool Reader
Je développe depuis longtemps une fourchette du programme Cool Reader , qui a été écrit par Vadim Lopatin ( Buggins ), l'article correspondant à ce sujet est disponible sur mon site Web. Dans les commentaires de cet article, les lecteurs de mon blog se désabonnent constamment, qui veulent voir une nouvelle fonctionnalité dans leur application préférée pour lire des livres électroniques, ou veulent corriger des erreurs et des lacunes dans les fonctions de programme déjà implémentées.Ma fourchette de Cool Reader fonctionnant sur Haiku.Dans le référentiel HaikuPorts, j'ai trouvé une recette pour construire le programme Cool Reader original, cependant, en raison de certains changements constants qui se produisent avec la ressource SourceForge , cette recette s'est avérée inopérante, car le code source de l'application est devenu indisponible pour le téléchargement. J'ai ensuite décidé de transférer ma fourchette vers le référentiel HaikuPorts, en tant que nouvelle version de Cool Reader. J'ai mis tous les correctifs de Gerasim sur le code, corrigé quelques lacunes dans la recette et basé sur lui, j'ai créé un nouveau package qui est déjà disponible pour tous les utilisateurs de Haiku. Vous pouvez trouver le code source de ma fourchette Cool Reader dans ce référentiel GitHub:Code source du projet: https://github.com/EXLMOTODEV/coolreaderLe seul problème que j'ai rencontré était les inexactitudes dans le transfert des correctifs de Gerasim. En plus de la définition de __HAIKU__ , ailleurs dans le système de construction, la définition de _LINUX a également été définie et, puisque dans la plupart des cas, le dernier dans la liste de code source était le premier, la compilation conditionnelle m'a laissé tomber. Conformément aux règles de priorité du préprocesseur, pour Haiku exactement ces morceaux de code ont été compilés qui ont été encadrés par la définition de _LINUX , bien que j'avais besoin de quelque chose de complètement différent. Mais malgré cela, le programme a démarré et a fonctionné, mais il n'a enregistré ses paramètres que là où il était nécessaire. J'ai correctement priorisé, reconstruit le package et le problème a été complètement résolu.<< Passer au contenu11. Finalisation du programme KeymapSwitcher
Récemment, de nombreux systèmes d'exploitation populaires sont passés à un nouveau raccourci clavier Meta / Opt / Cmd / Win + Space pour changer de disposition de clavier. Cela m'a semblé très pratique car je n'ai plus besoin de changer quoi que ce soit et de le configurer. Vous vous asseyez sur n'importe quel ordinateur exécutant macOS, Windows ou Linux avec le shell GNOME 3 et cette combinaison pratique de changement de langue d'entrée fonctionne juste partout. Même le système d'exploitation mobile Android a son analogue. En général, je suis passé à ce raccourci clavier il y a longtemps et je m'y suis beaucoup habitué.À mon grand regret, KeymapSwitcher, fourni avec Haiku, ne m'a pas permis de définir une combinaison de touches aussi pratique pour changer de disposition, c'est pourquoi je me sentais constamment incommode lorsque je travaillais avec du texte dans ce système d'exploitation. Par conséquent, j'ai décidé de modifier un peu cette application et j'ai commencé à rechercher son code source. Il s'est avéré que ce programme, bien qu'inclus dans la distribution Haiku, est fourni séparément du code source du système d'exploitation lui-même. De plus, l'application est disponible dans le référentiel HaikuPorts et elle est également mise à jour via celui-ci. Comme j'ai été informé, KeymapSwitcher n'était pas inclus dans Haiku, car il est prévu de mettre en œuvre une API spéciale pour changer les dispositions de clavier et un jour, la nécessité de ce programme disparaîtra complètement.KeymapSwitcher sur Haiku avec un raccourci clavier populaire pour changer la disposition du clavier.Malgré le fait que j'ai été effrayé par la complexité du code KeymapSwitcher, j'ai rapidement trouvé la bonne place grâce aux commentaires et introduit un petit patch dans le code du programme, ce qui a grandement facilité la saisie de tous les textes en haïku. Le seul défaut mineur que je n'ai pas pu surmonter est que la touche Opt doit être relâchée pour changer de langue. Autrement dit, maintenez Optet un espace pour basculer entre les langues sélectionnées ne fonctionnera pas. Mais cela n'interfère absolument pas avec le changement de langue pendant la frappe, j'ai donc envoyé le correctif au référentiel du programme et mis à jour le package d'application dans HaikuPorts, après quoi la nouvelle version de KeymapSwitcher est devenue disponible pour l'installation pour tous les utilisateurs de Haiku.Code source du projet: https://github.com/HaikuArchives/KeymapSwitcherJ'espère que je ne suis pas le seul utilisateur de ce raccourci clavier à changer de disposition de clavier.<< Passer au contenu12. Conclusion
L'étude de l'API Haiku, ainsi que la résolution de divers problèmes exotiques qui sont survenus à la suite du portage de nouvelles applications et de la mise à jour des applications existantes pour ce système d'exploitation, m'ont apporté beaucoup d'expérience et de plaisir. J'ai pu promouvoir les correctifs de support Haiku dans le référentiel de code source de certains grands projets et j'ai rencontré de nouvelles personnes intéressantes qui étaient en quelque sorte liées à ce beau système d'exploitation.Diverses applications fonctionnant sur le système d'exploitation Haiku.J'espère sincèrement qu'à l'avenir, tous les problèmes d'aujourd'hui comme le manque d'accélération matérielle 3D et les navigateurs populaires, ainsi que la mauvaise prise en charge du matériel moderne, seront résolus avec succès et Haiku recevra un afflux de sang neuf de développeurs et d'utilisateurs qui apprécieront ses capacités uniques et sa conception originale . Heureusement, le développement est loin d'être arrêté et aujourd'hui sur le forum local de ce système d'exploitation, des sujets d'actualité sur l'accélération 3D et le portage de la bibliothèque GTK + 3 sont évoqués , et la possibilité de porter le composant QtWebEngine est discutée dans les référentiels HaikuPorts. Le port GTK + 3 peut impliquer la possibilité de lancer et de travailler les navigateurs populaires Firefox et Chromium, et QtWebEngine permettra d'utiliser le moteur Blink dans les navigateurs modernes basés sur le framework Qt, comme Otter Browser ou Falkon .Déjà maintenant, je peux recommander ce système d'exploitation à ceux qui ont des ordinateurs portables ou des netbooks anciens et faibles, par exemple, au lieu de la distribution Lubuntu ou de Windows XP. Vous serez étonné de sa rapidité et de sa réactivité. Oui, vous devrez vous limiter un peu à la visualisation de certains sites en raison d'anciens navigateurs et d'un tas de problèmes qui leur sont associés, mais pour la plupart des cas sur l'ancien matériel, cette limitation n'a aucune importance.Tous mes ports et améliorations ont déjà été publiés et sont disponibles pour l'installation pour tous les utilisateurs de Haiku. Toutes les modifications apportées au code source sont disponibles dans les référentiels respectifs sous leurs licences d'origine. Dans ce travail, j'ai utilisé une énorme quantité de matériaux, dont je soulignerai les principaux dans les liens utiles ci-dessous. Un grand merci à stackoverflow.com et google.com pour leur présence.1. Le site officiel du système d'exploitation Haiku .2. Le forum officiel du système d'exploitation Haiku .3. Documentation officielle pour les utilisateurs de Haiku .4. Documentation officielle pour les développeurs Haiku .5. Description des fonctionnalités de l'interface utilisateur graphique Haiku .6. Recommandations pour la création d'icônes pour les applications Haiku .7. Description du programme Icon-O-Matic et conseils d'utilisation .8. Description du format des icônes vectorielles HVIF .9. La documentation officielle du cadre du kit d'interface .10. La documentation officielle pour le framework Locale Kit .11. Article sur les aspects de localisation des applications pour Haiku .12. La documentation officielle de l'API Layout .13. Une série d'articles décrivant l'implémentation de l'API Layout dans Haiku .14. Dépôt GitHub du code source du système d'exploitation Haiku .15. Dépôt GitHub de l'arbre de recette HaikuPorts .16. La version Internet du référentiel de packages HPKG prêts à l'emploi Haiku Depot Web .17. Un article intéressant "Haiku: lampe geek-OS" sur le blog du développeur INSTEAD, Peter Kosykh .18. The Haiku: Immersion article sur le blog des développeurs d'INSTEAD, Pyotr Kosykh .19. Le cours de programmation des leçons "Apprendre à programmer avec Haiku" de DarkWyrm .20. Le cours de programmation des leçons "Programmation avec Haiku" de DarkWyrm .21. Publication «Y a-t-il de la vie sur Haiku?» sur la ressource Linux.org.ru, de moi .22. Conférence en télégramme IM, consacrée à la discussion du système d'exploitation Haiku .Félicitations à tous les utilisateurs de la ressourcehabr Bonne année et leur souhaite de joyeuses fêtes de Noël! Bonne chance à vous tous dans la nouvelle année 2019!<< Passer au contenu