Suivez-nous sur X
|
|
|
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 : Rave et gadget ToolBar, la synergie des projets
(Article écrit par Daniel Jedlicka et extrait de Rear Window - janvier 2021)
|
|
Note : traduction par David Brunet.
En décrivant mes activités de programmation dans le précédent
billet de mon blog, j'ai également mentionné que j'étais impliqué dans le projet
Amiga Developer depuis un certain temps. Après la publication de ce
billet, quelques personnes m'ont demandé si cela signifiait que j'allais moins m'investir dans cette équipe
maintenant que je développe mes propres logiciels. La réponse est non, pas vraiment. En fait, il y a une
bonne synergie entre Rear Window et le travail que je fais pour Amiga Developer, et les deux efforts ont
bénéficié l'un de l'autre.
Je suis certainement partial en raison de mes intérêts personnels, mais je dirai que l'une des meilleures
choses que l'initiative Amiga Developer a produite sont les classes de
l'Enhancer
Software Core : une collection gratuite étendant la boîte à outils pour l'interface standard d'AmigaOS 4. En effet,
la principale raison pour laquelle j'aime promouvoir Enhancer Software Core est qu'il apporte de
nouvelles possibilités à la programmation de l'interface graphique Amiga. Ainsi, lorsque j'ai commencé
à travailler sur mon éditeur audio Rave, je savais que je voulais utiliser les nouvelles classes en plus
des classes traditionnelles. Ce que je ne savais pas, c'est que Rave allait bientôt devenir un important
banc d'essai, une épreuve du feu dans laquelle les classes d'Enhancer Software Core devraient faire leurs preuves.
Quelle que soit la rigueur de sa conception, un composant logiciel ne révèle sa vraie nature que lorsqu'il
est utilisé dans un logiciel réel. J'entends par là non seulement que l'utilisation réelle expose les bogues
et les inconvénients qui sont passés inaperçus au stade de la conception, mais aussi les tests bêta.
L'utilisation réelle d'un logiciel a également tendance à jeter une nouvelle lumière sur la façon dont
le composant pourrait fonctionner et sur les fonctionnalités qui pourraient manquer. Je me hasarderai à
dire que beaucoup de gadgets d'AmigaOS ont vu le jour parce qu'un développeur travaillant sur un logiciel
particulier avait besoin d'une fonctionnalité particulière. Ou est-ce une pure coïncidence que la boîte à
outils de l'interface graphique ait reçu des mises à jour majeures alors que Simon Archer, l'un des principaux
développeurs d'AmigaOS 4, travaillait sur son environnement de développement
CodeBench ? Je ne le pense pas.
Et ce n'est qu'un exemple parmi d'autres.
Ayant accès au dépôt de code source d'Amiga Developer, j'ai eu la chance, comme Simon Archer, de pouvoir
façonner les classes que j'avais décidées d'utiliser dans mon logiciel. En fait, toutes les mises à jour
récentes que j'ai faites au gadget Select (écrit à l'origine par Massimo Tantignone) et au gadget InfoData
(Mark Ritter) ont été motivées par quelque chose qui a surgi pendant que je travaillais sur Rave. Et il ne
sera pas surprenant que mon éditeur audio soit aussi directement responsable de la toute nouvelle addition
à Enhancer Software Core : la classe de gadget ToolBar, que j'ai récemment couverte pour le
blog d'Amiga Developer.
Voici comment tout cela est arrivé...
J'ai l'habitude de commencer mes projets en concevant l'interface graphique. Bien qu'au final, elle ne
ressemble que très peu à la version originale, je préfère procéder de cette manière car le fait de voir
quelque chose de tangible sur l'écran stimule ma créativité (cela me donne aussi un sentiment d'accomplissement,
malgré le fait que le programme ne fait encore rien). J'étais donc en train de concevoir une première
barre d'outils pour Rave lorsque j'ai réalisé une fois de plus à quel point je déteste le gadget SpeedBar
standard, car il est très long à mettre en place. Dans un acte de bravade, j'ai décidé de mettre le
travail de côté et d'écrire une classe de gadgets de barre d'outils personnalisée : une classe qui serait
basique dans ses fonctionnalités mais extrêmement facile à mettre en place. Je me suis dit que peu de
programmes utilisent leur barre d'outils pour autre chose que déclencher une action, alors pourquoi ne
pas se concentrer sur la fonction principale ? Le travail s'est avéré relativement rapide, et il serait
resté une affaire sans lendemain (et je n'aurais pas à en parler dans un article) si je n'avais pas fait
une erreur classique : j'ai partagé mon travail avec d'autres.
D'une certaine manière, je me suis tiré une balle dans le pied en proposant le gadget ToolBar comme
contribution au lot Enhancer Software. Je me suis laissé aller à la sémantique, sans me rendre compte
que si quelque chose est appelé "Enhancer", les gens s'attendent invariablement à ce qu'il ait plus de
fonctionnalités. Or, ma classe de gadget n'avait pas plus de fonctionnalités que la SpeedBar, elle
représentait simplement une alternative plus simple - ce qui n'a apparemment pas été perçu comme une
valeur ajoutée. Les réactions qui ont suivi allaient de l'indifférence au mépris pur et simple, et ce fut
une leçon douloureuse à apprendre. Un collègue développeur a gentiment envoyé une liste de fonctionnalités
que ma classe devait absolument avoir avant qu'il ne prenne la peine de l'utiliser ; l'esprit d'équipe n'est-il
pas formidable ? Mais nous, les programmeurs Amiga, sommes réputés pour notre résistance (en plus du fait
que nous pouvons cuisiner un curry décent, ce qui nous rend très demandés dans les bureaux d'enregistrement),
alors je n'ai pas abandonné aussi facilement et j'ai continué à travailler sur la classe parallèlement au
projet Rave. Cette décision s'est avérée très judicieuse, car le gadget ToolBar a évolué au fur et à mesure
de l'évolution du programme, en réponse à mes besoins croissants. Ainsi, une fonctionnalité a conduit à une
autre jusqu'à ce qu'un beau jour (ouf !) j'ai finalement estimé que ma chère petite création ne pouvait plus
être blâmée pour ne pas avoir suffisamment amélioré Enhancer Software.
Mon écran Workbench montrant diverses configurations du gadget ToolBar
Un bref coup d'oeil à la capture d'écran ci-dessus peut suggérer qu'il y a peu de différence visuelle entre
la ToolBar et l'ancienne SpeedBar. Oui, lorsque le gadget ToolBar a vu sa première version publique, quelques
utilisateurs ont semblé déçus que les deux classes n'aient pas l'air différentes. Cependant, en y regardant
de plus près, vous remarquerez certains détails qui vont au-delà de l'apparence par défaut et qui laissent
entrevoir la configurabilité avancée de la barre d'outils. En particulier, la nouvelle classe présente un
mode sans bordure, ce qui lui confère un aspect plus moderne et permet de réduire l'encombrement dans les
interfaces graphiques encombrées. Il existe également des améliorations plus modestes et moins visibles,
comme la gestion de plusieurs jeux d'images (et la possibilité de passer facilement de l'un à l'autre),
le remplissage intérieur réglable des boutons de la barre d'outils ou le style configurable des barres de séparation.
Une fonctionnalité dont je suis vraiment fier d'avoir implémenté est la gestion des débordements.
De quoi s'agit-il ? Eh bien, certaines barres d'outils peuvent être assez longues et prendre beaucoup de
place dans la fenêtre du programme, ce qui peut compliquer l'utilisation (surtout lorsque la surface de
l'écran est limitée). C'est pourquoi les classes de barres d'outils sont généralement conçues comme des
éléments d'interface graphique "repliables", pour permettre de réduire la fenêtre à une taille plus petite.
Lorsque la fenêtre devient trop petite pour contenir tous les membres de la barre d'outils, on obtient une
situation appelée débordement. La façon dont cette situation est gérée dépend de la classe en question.
Par exemple, le gadget SpeedBar utilise un mécanisme de défilement qui est déclenché en maintenant la
touche "Shift" enfoncée et en déplaçant la souris vers la gauche/droite (ou vers le haut/bas si le gadget
est orienté verticalement). J'ai toujours trouvé ce comportement plutôt bizarre et peu intuitif, et j'ai
donc préféré une solution plus intelligente. Comme le montre l'image ci-dessous, le gadget ToolBar réagit
au débordement en affichant un bouton de sélection sur la droite. En cliquant sur le sélectionneur, vous
invoquez un menu contextuel dont les éléments individuels correspondent aux membres de la barre d'outils
qui sont actuellement hors de vue. Ainsi, même dans une fenêtre de taille minimale, l'accès aux fonctions
du programme est vraiment rapide et facile (les éventuels récalcitrants seront heureux d'apprendre que la
gestion du débordement est facultative, donc si vous préférez avoir une barre d'outils "statique" toujours
affichée en entier, il vous suffit de ne pas activer cette fonctionnalité).
Débordement du gadget ToolBar dans MultiEdit
Après avoir finalement publié la mise à jour du gadget ToolBar en octobre 2020, j'ai pensé laisser les
classes d'Enhancer Software au repos pendant un certain temps et me concentrer pleinement sur mon éditeur
audio, mais comme tout programmeur expérimenté le sait - l'homme propose, le logiciel dispose. Peu après
m'être attelé à la tâche, le travail sur Rave m'a donné une autre idée. Contrairement à ce qui se passe
dans d'autres sphères de l'activité humaine, les idées dans le domaine de la programmation peuvent être
vraiment dangereuses, car elles conduisent souvent à une dérive des fonctionnalités et, finalement, à des
projets qui ne sont jamais terminés. Les grandes entreprises de logiciels engagent même des chasseurs
professionnels pour repérer les programmeurs ayant des idées et les abattre sur place. Mais en tant qu'humble
indépendant, je n'avais pas à m'inquiéter, et comme la période de Noël me promettait un peu plus de temps
libre, j'ai décidé d'essayer une fois de plus le gadget ToolBar. Alors, de quoi s'agit-il ?
Eh bien, la barre d'outils du programme principal de Rave contient une section avec des boutons qui
contrôlent le zoom de l'affichage de la forme d'onde. À l'origine, le niveau de zoom actuel était indiqué
dans la barre d'état en bas de l'interface graphique, ce qui était correct mais ne semblait pas correct.
Du point de vue de la conception de l'interface utilisateur, je pense que si un élément de l'interface
graphique contrôle une valeur particulière, la valeur doit de préférence être affichée à proximité de
l'élément de contrôle, afin d'avoir une correspondance visuelle claire entre eux. J'ai donc commencé à
réfléchir : et si la valeur du niveau de zoom était affichée dans la même section de la barre d'outils,
c'est-à-dire à côté des boutons de zoom, plutôt que quelque part loin en dessous dans la barre d'état ?
Bien sûr, le gadget ToolBar n'était pas exactement adapté : vous pouviez créer un bouton de texte uniquement,
vous pouviez même modifier le texte à la volée, mais il avait toujours l'apparence et le comportement d'un
bouton. Ce qu'il me fallait, c'était un nouveau type de membre de barre d'outils, une zone d'affichage en
lecture seule rationalisée pour un contenu textuel dynamique. Heureusement, la conception interne du
gadget me permet d'ajouter à peu près n'importe quoi (du moment qu'il s'agit d'un objet BOOPSI), si bien
qu'avant que la nouvelle année ne sonne, le type de membre Textbox était prêt et opérationnel. Voici à quoi
il ressemble dans la version de développement actuelle de Rave.
Rave - notez la section zoom dans la barre d'outils qui montre maintenant le niveau de zoom
Pour faire bonne figure, j'ai également ajouté la gestion des couleurs et des styles de texte, car il
était clair pour moi que quelqu'un demanderait ces fonctionnalités tôt ou tard. Maintenant que j'y pense,
j'ai dû faire du gadget ToolBar l'une des classes les plus polyvalentes et les plus configurables de
l'ensemble des éléments BOOPSI d'AmigaOS 4. Pourquoi est-ce que je me sens soudainement si fatigué ?
Bon, ça devient long (et tard), alors il est temps de conclure. Un vieux proverbe slave dit que l'on
ne peut pas s'asseoir sur deux chaises en même temps. Et il y a une bonne part de vérité dans ce proverbe :
travailler sur deux projets simultanés signifie souvent que l'un d'eux vous privera de votre temps et de
votre attention. D'un autre côté, les projets peuvent aussi s'inspirer mutuellement, se développer ensemble
et produire un effet de synergie entre eux. Cela a très bien fonctionné pour moi : les classes pour
Enhancer Software et l'éditeur audio Rave ont tous deux grandement bénéficié de cette synergie. Je suis sûr
qu'il y en aura d'autres à l'avenir. Et je serai là pour vous le dire, alors gardez un oeil sur mon site
Rear Window.
|
