Suivez-nous sur Mastodon
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Point de vue : Nouvelles classes BOOPSI pour ReAction - régler la radio
(Article écrit par Daniel Jedlicka et extrait de Rear Window - juin 2026)
|
|
Régler la radio
Les programmeurs d'interfaces graphiques (GUI) sur Amiga savent que les boutons radio ont tué MX_KIND, le gadget
vedette mutuellement exclusif, il y a bien longtemps. Cela ne veut pas dire que
l'ancien gadget MX_KIND de
GadTools ne
méritait pas sa place dans l'histoire. C'était un excellent ajout à la boîte à outils GUI du système, car il apportait un
contrôle véritablement utile et pratique : un groupe de boutons étiquetés et mutuellement exclusifs, où la
sélection d'une option désélectionnait automatiquement les autres. Pour les fenêtres de préférences, les
sélectionneurs de mode et toutes sortes de requêtes, c'était exactement ce que le médecin avait prescrit :
En fait, Installer simule le gadget, mais vous voyez l'idée
Cependant, dès que la boîte à outils ReAction
a introduit le radiobutton.gadget, le MX_KIND a été battu à
plate couture. Non pas tant parce que la nouveauté était un contrôle radicalement différent - sur le principe,
il faisait à peu près le même travail que le MX - mais parce qu'il appartenait à un cadre de développement d'interfaces
graphiques beaucoup plus sophistiqué. Il pouvait s'intégrer dans des mises en page automatiques, respecter
les polices choisies par l'utilisateur, se redimensionner plus gracieusement, coopérer avec d'autres objets
BOOPSI et, globalement, se comporter comme un élément d'une interface plus moderne. Le MX_KIND nous avait
donné le contrôle ; le radiobutton.gadget nous a donné ce contrôle dans un monde qui avait évolué.
Vingt ans plus tard, dans le cadre de mes aventures BOOPSI sur AmigaOS 4, il m'a semblé qu'il était grand
temps de se brancher à nouveau sur le sujet et de revoir ce que ce gadget offre réellement. L'idée de base
a parfaitement bien vieilli, mais les boîtes à outils
pour interfaces graphiques sur d'autres plates-formes ne sont pas restées
immobiles, et les boutons radio ont discrètement adopté quelques raffinements utiles en chemin. Certains
des défauts de notre propre implémentation avaient déjà été remarqués, la tâche consistait donc moins à
découvrir des failles cachées qu'à leur accorder enfin l'attention qu'ils méritaient : qu'est-ce qui semble
inutilement limité aujourd'hui, et qu'est-ce qui pourrait être amélioré pour aligner davantage le gadget sur
les attentes modernes.
Une amélioration évidente consistait à permettre la sélection de chaque bouton radio en cliquant sur son
étiquette textuelle, et pas seulement sur le bouton lui-même. De nos jours, c'est tout simplement ainsi que
les contrôles de boutons radio sont censés se comporter ; on a à peine l'impression qu'il s'agit d'une fonctionnalité.
Le gadget MX_KIND d'origine ne réagissait qu'aux clics sur les boutons physiques, et le radiobutton.gadget avait
hérité de la même limitation. C'était non seulement un peu inconfortable en pratique, mais aussi incohérent avec
le propre checkbox.gadget de ReAction, qui gérait déjà les clics sur les étiquettes depuis un bon moment. Et
enfin, il y avait la question de se maintenir au niveau de la branche AmigaOS 3.x, où ce comportement avait été
implémenté il y a près de six ans.
Dans cette optique, emprunter du code à la branche soeur semblait être la chose évidente à faire. Mais encore
une fois, on m'a rappelé que ce n'est presque jamais aussi simple.
BOOPSI
a évolué différemment dans les deux
branches d'AmigaOS au fil des ans, et bien que nous essayions de préserver la compatibilité au niveau de l'API,
le code source sous-jacent peut raconter une histoire très différente. De légères différences d'API se sont
également glissées : chaque branche a accumulé tel ou tel marqueur ("tag") ou comportement qui n'existe pas
dans l'autre.
Ainsi, copier et coller du code fonctionne rarement sans effort supplémentaire. Lorsque j'ai emprunté le code
d'AmigaOS 3.x pour les clics sur les étiquettes, les tests ont révélé qu'il ne fonctionnait pas bien lorsque
l'étiquette était placée à gauche du bouton. Non pas parce que le code était bâclé, mais parce que le radiobutton.gadget
d'AmigaOS 3.x ne place jamais les étiquettes que sur la droite. Leur code n'a jamais eu à gérer une autre
disposition ; une simplification que notre version ne peut pas se permettre.
Des étiquettes à gauche. Parce qu'on le peut !
Une autre fonctionnalité qui demandait pratiquement à être implémentée était la disposition horizontale pour
le groupe de boutons radio. Non seulement c'est désormais une pratique courante dans les boîtes à outils
d'interfaces graphiques sur d'autres plates-formes, mais la demande pour cela attendait également dans le
gestionnaire de bogues d'AmigaOS 4 depuis 2016. Après tant d'années, ne pas l'avoir devenait à la fois embarrassant
et un peu difficile à défendre.
Et, comme d'habitude, l'implémentation s'est transformée en une nouvelle descente dans le terrier du lapin.
J'ai vite réalisé que la conception verticale d'origine du gadget était très profondément ancrée dans le code.
La mise en page, le rendu et la gestion des saisies reposaient tous sur des hypothèses qui ne pouvaient tout
simplement pas survivre à une orientation alternative. Pire encore, chacune de ces zones faisait ses propres
calculs, ce qui invitait les éléments à se désynchroniser.
Mes six mois d'expérience de travail sur AmigaOS 4 m'ont appris qu'être trop respectueux envers le code source
d'origine apporte parfois plus de problèmes que de bénéfices. Le plus souvent, vous vous retrouvez à contourner
des décisions de conception qui n'ont pas résisté à l'épreuve du temps, ajoutant encore une autre couche à un
système kafkaïen de rouages internes que vous ne comprenez qu'en partie, parce que personne n'a eu la décence de
laisser suffisamment de commentaires derrière lui. Par conséquent, vous traitez le composant comme un colis fragile,
en enveloppant soigneusement vos modifications autour de lui et en espérant que l'ensemble ne s'effondrera pas.
Je pense que cette approche de "relique sacrée" est l'une des raisons pour lesquelles le sous-système BOOPSI
d'AmigaOS 4 a connu si peu d'améliorations réelles au fil des ans. Par conséquent, je me sens de plus en plus
enclin à être un peu irrévérencieux et à infliger aux classes un traitement froid et sans sentimentalisme.
Avec radiobutton.gadget, j'ai décidé que greffer l'orientation horizontale sur le code de mise en page existant
revenait à jeter de l'huile sur le feu. Le code était déjà trop complexe, et le gadget avait de fait trois
systèmes de mise en page distincts et implicites : la méthode "domain" estimait les tailles et les positions,
la méthode "render" les recalculait, et les méthodes d'entrée ("input") et de test de collision ("hit-test")
les recalculaient encore une fois. Ma première tentative d'orientation horizontale a immédiatement mis le
problème en évidence. Chacun de ces endroits avait encodé des hypothèses légèrement différentes, de sorte que
la nouvelle mise en page n'a pas seulement brisé l'ancienne logique - elle l'a brisée de plusieurs manières
différentes à la fois.
Tout ce que je peux dire, c'est que le flux est beaucoup plus propre maintenant : les données géométriques sont
calculées en un seul endroit et utilisées partout. Dès que cela a été fait, amener le gadget à organiser les
boutons horizontalement est devenu presque trivial.
Enfin
Et comme un joyeux "effet secondaire", la sélection en cliquant sur les étiquettes placées à gauche a commencé
à fonctionner immédiatement, sans aucun changement de code !
En y pensant maintenant, ma motivation initiale pour la réécriture - l'orientation horizontale -
semble presque secondaire. Le vrai gain a été le remaniement lui-même : se débarrasser des duplications
douteuses, supprimer plusieurs idées concurrentes de l'endroit où les choses devaient se trouver, et rendre
la classe à nouveau maintenable.
Ce qui ressemble à un assez bon plan général pour mes futures aventures BOOPSI, n'est-ce pas ?
|
