Intro Editorial A Propos Sommaire Quizz Musiques Pub Archives
Obligement


Labo : Feelin par Olivier Laviale



Qu'est-ce que Feelin ?

Feelin est un nouveau système orienté objet pour l'AmigaOS. Il fournit deux choses : une petite bibliothèque partagée rapide et puissante (le coeur du système objet), qui offre tout ce qu'il faut pour créer un environnement objet complet ; et un système extensible pour créer et gérer des interfaces graphiques. Pour le moment, Feelin est codé pour Amiga 68k mais il fonctionne apparemment sous OS4.

Un puissant système objet

Feelin a été créé parce qu'il n'y avait, et n'y a toujours pas d'ailleurs, de système objet performant, utile et utilisable sur AmigaOS. Le seul disponible est BOOPSI, et il est sérieusement limité (il est âgé faut dire :-). Les fonctionnalités GUI sont apparues par la suite ; dans un premier temps comme test, ensuite comme un amusement personnel. Il faut dire qu'à part MUI, les systèmes graphiques sur Amiga ne sont pas très attractifs. Mais MUI n'est pas un système objet, et sans BOOPSI, pas de MUI. De plus, si on veut étendre MUI, il faut demander la permission à une sorte d'autorité pour avoir un numéro d'enregistrement, pour pouvoir l'utiliser comme base de sa nouvelle classe.

Evolution : attributs et méthodes dynamiques

Feelin propose un système libre (dans tous les sens du terme, pas seulement celui de licence), où chacun pourrait ajouter des fonctionnalités sans se dire "Faut pas que j'utilise les numéros entre 0xFF004444 et 0xFF00FFFF parce qu'il sont utilisés par Brenda pour sa classe page blanche". La gestion des classes de Feelin est bien plus puissante. L'utilisation d'IDs dynamiques a été un premier pas dans cette direction. Fini les numéros statiques pour identifier les attributs et les méthodes. Feelin utilise des chaînes de caractères formatées comme "FA_String_Contents".

Le système de gestion non centralisé des IDs est appelé dynamique (dynamic en Anglais :-). Ainsi, si la classe "String" définit l'attribut "Contents", cet attribut sera publiquement connu comme "FA_String_Contents". C'est une évolution majeure et un travail de longue halaine. Il n'utilise pas plus de mémoire et il est extrêmement rapide (vous ne verrez absolument pas la différence). Il existe évidement des fonctions pour résoudre des tables dynamiques, et des fonctions de remplacement pour NextTagItem(), FindTagItem() et GetTagData().

Pour des raisons stratégiques d'évolution, les classes sont très opaques. Aucune méthode ou structure magique n'est utilisée. Chaque classe peut-être réécrite par n'importe qui sans qu'il y ai le moindre problème (faut pas faire n'importe quoi non plus :-). Par exemple, la partie publique de FC_Area ne peut être obtenue qu'en utilisant l'attribut FA_AreaData, car la classe FC_Object (base de la plupart des classes) est totalement opaque.

Gestion mémoire

Feelin dispose aussi d'un système de gestion de mémoire à toute épreuve. Des piscines (pools) et des flaques (puddles) sont utilisées pour contenir de petits blocs. Les blocs de mémoire alloués sont alignés sur 32 bits. Là où la fonction FreePooled() de EXEC requiert le pointeur de la piscine dans laquelle un bloc à été alloué, le bloc et sa taille ; Feelin ne requiert que le bloc : F_Dispose(bloc). Les blocs libérés sont remplis avec 0xABADFOOD (ce qui peut être utile pour un développeur). De plus, il est impossible de libérer un bloc qui n'existe pas. Dans tous les cas, si une erreur survient, un message sera envoyé sur le log.

Grâce à un sémaphore embarqué, les piscines de Feelin peuvent facilement être partagées entre plusieurs applications (ou tâches). Elles peuvent également être nommées, et comme Feelin trace chaque allocation de mémoire, vous pouvez savoir exactement la mémoire consommée par telle ou telle piscine. Des outils sont inclus pour le listage et le dump (la sauvegarde sur disque des blocs d'une piscine).

Malgré toutes ces charmantes fonctionnalités, le système de gestion mémoire de Feelin est encore plus rapide que celui d'EXEC (2 à 4 fois plus rapide sur un A1200/68030 à 29 MHz).

Sécurités

L'invocation de méthodes sur les objets est sans risques. Pour chaque invocation, Feelin vérifie que l'objet sur lequel est invoquée la méthode est bel et bien un objet. Si l'objet n'existe pas, un message est inscrit au journal pour informer le développeur. Par exemple l'invocation F_Do((FObject)(13),FM_Dispose) ; ne plantera pas bêtement votre ordinateur, mais produira un message d'erreur. Ce système anti-crash est extrêmement rapide et très utile, parce qu'un système qui plante sans raison apparente est la chose la plus frustrante sur Terre (après les gens qui parlent au cinéma :-).

Rapport d'erreur

Comme mentionné plus haut, Feelin propose un système de rapport d'erreur. Feelin trace toutes les invocations et la fonction F_LogA(), utilisée pour inscrire les messages, ajoute des informations cruciales telles que la classe, l'objet et la méthode qui ont causé l'erreur. Par exemple : Text{101EA608} @ Area.Connect() - a bug ??. Et puisque chaque message est accompagné d'un niveau d'erreur, l'utilisateur final peut choisir à quel niveau il désire être informé.

Le niveau d'erreur ainsi que la sortie d'erreur peuvent être modifiés très facilement par l'intermédiaire des variables système Feelin/LIB_ERRORLEVEL et Feelin/LIB_CONSOLE.

De nombreuses fonctions

La bibliothèque feelin.library offre également de nombreuses fonctions pour gérer des listes à double lien (différentes de celles d'EXEC) ; des fonctions de Hachage ; tout un appareil pour créer et gérer des serveurs et bien d'autres encore.

Une interface graphique évoluée

Reposant sur ce puissant système objet, Feelin propose une interface graphique orientée objet. Cette interface, bien que complète et puissante, n'est qu'une vitrine pour Feelin. L'application du système objet va au-delà de l'aspect graphique. Le système objet proposé par Feelin peut aussi bien être utilisé pour toute autre chose (des éléments système, gestion sonore).

Feelin
Feelin

Un système de préférence indépendant

L'interface graphique de Feelin est extrêmement configurable. Chaque pixel de l'application peut être choisi par l'utilisateur (et pas le développeur). Comme Feelin utilise des IDs dynamiques, le système de préférence utilise lui aussi des chaînes de caractères au lieu de numéros pour référencer les items qu'il stocke. Un système de collision est utilisé pour gagner un maximum de place et augmenter les performances. Cette gestion, comme les IDs dynamiques est prête pour le futur.

Des classes évoluées

Les bordures de la fenêtre peuvent être configurées. On peut enfin se débarrasser du vieux look d'Intuition sans utiliser de patch. Pour l'instant un seul décorateur est disponible (Shade), mais d'autres peuvent être écrits très facilement en se basant sur le source de Shade.

Les balises HTML sont reconnues et peuvent être utilisées pour formater le texte. De nombreuses sont déjà supportées, et pas que les plus simples. Le texte peut être aligné à gauche, à droite, centré ou justifié grâce à la balise "align". Les styles gras, italique et souligné sont supportés. Différentes polices peuvent être utilisées pour différencier des portions de texte, leur taille et leur couleur est facilement définissable grâce à la balise "font". Des lignes horizontales très configurables peuvent également être utilisées pour séparer le texte (hr). Les lignes peuvent être différemment espacées par la balise "spacing". Des images peuvent être incorporées au texte (img). Quatre pinceaux configurables peuvent être utilisés pour produire de nombreux effets sur le texte, et bien d'autres encore.

De nombreux héritages

Chaque application, chaque fenêtre, chaque groupe, chaque bouton peut avoir sa propre palette. L'héritage dans l'interface graphique est très important. Vous pouvez par exemple obtenir des objets de plus en plus sombre (ou de plus en plus clair) en fonction de leur profondeur dans l'arbre de l'application très facilement. L'héritage s'applique aux polices, aux palettes ainsi qu'aux images de fonds. A noter que l'interface s'adapte d'elle-même en fonction des modifications.

De nombreuses possibilités

Avec plus de 40 frames, vous avez un grand choix pour configurer vos objets (la frame normale et la frame sélectionnée sont configurables indépendamment). La gestion abstraite des images vous laisse aussi un très grand choix. Vous pouvez même utiliser une fonction pour dessiner vos fonds.

Conclusion

Feelin est sans doute le système objet le plus évolué disponible sur AmigaOS. Il est encore jeune par rapport à MUI, il manque encore quelques classes, la classe FC_Liste n'est pas encore totalement satisfaisante. Feelin est le fruit d'un développement solitaire sur le tas. MUI est un standard très établit et même si Feelin est bien meilleur au niveau implémentation (ce serait ridicule de comparer BOOPSI et le système objet de Feelin), il aura du mal à s'imposer face à MUI, ou même cette horreur de Reaction. Les changements font peur aux gens, après tout 90% d'entre eux utilisent Windows et Internet Explorer, non ?