Hello,
le sel et l'amer du pb des menus, c'est qu'ils doivent être extensibles
alors que les besoins des utilisateurs sont très très différent.
IL faut que les plugins puissent ajouter des entrées où ils veulent
et sans que ça foute tout en l'air.
Or avec l'existant, les chercheurs en affordance n'ont pas encore trouvés
comment satisfaire tout le monde.
Si j'ai bien compris le code actuel va vers un menu de base fixe,
rigide, fondation immuable et solide devant assurer pour les pluggins
les constructions les plus folles et les combinaisons les plus libres.
Hmmm... même dans le bâtiment, c'est pas évident.
J'ai lu dire aussi que le positionnement était géré par des entiers :
ordres/positionnements dans la hiérarchie parcourue des menus.
On peut alors imaginer que le menu "fondation"
soit lui-même généré par de tels ordres d'insertion,
en telle position sur l'existant (vide au début).
ça peut introduire une souplesse pour des besoins particuliers.
Si c'est bien le cas, c'est peut être ça qu'il faut changer :
car ça semble bien limité pour décrire quelquechose d'aussi mouvant
- et d'aussi sémantique - qu'une arborescence de menus ...
Que veut dire "à la 5ème place" quand on ne sait pas
combien d'entrées intermédiaires ont été ajoutées depuis le socle fondation ?
Peut être vous avez trouvé une astuce, mais
il me semble alors que dire "je veux que cette entrée ci C soit placée
juste après cette entrée là L" serait une manière de faire
qui mappe mieux le besoin.
En remplacement avec un positionnement par ordre de position,
on peut en fait imaginer un langage de description des menus
qui s'appuie sur des notions "topologiques" de proximité :
après/avant telle entrée / début/fin de tel menu, ...
Par ailleurs comment se référer à une option/à un menu ?
L'id et le n° d'ordre ne veulent "rien dire" dans un menu dynamique...
Avec l'internationalisation, on ne peut pas prendre le titre.
Par ailleurs, certaines fonctions peuvent être implémentées par différents plugins
peut être de manière différentes.
Ce dont un plugin a besoin pour positionner une option,
c'est de se repérer sur les "fonctions" remplies par les options existantes.
Aux titres et aux ids des options, il semble nécessaire alors d'associer
comme un motclé qui témoignerait du signifiant.
Il y aurait une bibliothèque standard de tels tags signifiants,
extensibles au besoin, et qui servirait de référence pour positionner
de nouvelles entrées.
Sur cette base, il peut y avoir un ensemble d'instructions basiques
pour permettre à un plug de dire qu'il veut
"introduire une entrée de signifiant-type 'yop'
après l'entrée de signifiant 'iX',
ou sinon avant 'Yg' (en l'absence de X),
ou sinon à la fin de eM".
<code>new 'yop', après 'iX', avant 'Yg', fin 'eM'</code>
plutôt que "menu Configuration, position 5".
Instructions à définir pour que couvrir largement les besoins.
Un peu sonné après une nuit blanche,
JLuc