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).
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 ?
|
|