Menu à tiroir: Ouverture et fermeture

[boubouk50]

Bonjour à tous,

je crée ce post pour trouver et définir une façon simple et efficace de gérer les menus à tiroirs.

Je ne sais pas réellement comment m'y prendre pour réaliser des menus à tiroir, c'est à dire, des menus qui ouvrent d'autres sous-menus, et comment gérer la navigation dans ceux-ci.
Je parle ici d'UI depuis l'interface, pas depuis le code avec OnGui ().
Image démonstrative:



L'idée est donc de trouver un moyen de gérer le menu correctement pour les cas suivants:
- Cliquer sur Menu ouvre (ou ferme) les sous-menus. Cliquer sur un sous-menu ouvre (ou ferme) ses sous-menu (facile)
- Cliquer sur Menu (alors que des sous-menus (et sous-sous-menus, etc) sont ouverts) ferme tous les sous-menus. Cliquer de nouveau sur Menu ouvre les sous-menus uniquement.
- Cliquer sur un sous-menu alors qu'un autre est ouvert ferme le précédent et ouvre le nouveau.
- Cliquer en dehors d'un menu ferme tous les sous-menus et le menu.

On a donc la notion d'ouverture et de fermeture de menu (simple) ainsi que la gestion du clic. Je souhaiterai donc savoir comment gérer ces événements de façon intelligente pour ne pas avoir à tout mapper à la main.

L'idée de matérialiser le menu automatiquement en code via des tableaux (recréer la hiérarchie automatiquement) pour gérer les différents niveaux me semble pas trop mal. Mais il faut aussi gérer l'événement de clic externe au menu. Donc qui gère, le clic ou le menu.

Si vous avez la solution ou juste des idées (voire le terme exact de ce système en anglais ou français), elles sont la bienvenue. Ainsi, toute personne ici pourra utiliser un système efficace de menu à tiroir.

Je précise, je souhaiterai que ce système soit multiplateforme, c'est à dire utiliser les clics et pas les highlights pour l'ouverture, puisqu'il n'y a pas de survol avec les touchs.

[boubouk50]

Admettons la classe suivante:

Code : Tout sélectionner

public class Menu : MenuSystem  //Définir MenuSystem avec toutes les fonctions associées à la navigation
{
	public Menu parent;
	public Menu[] submenus;
	public bool isOpen;
}

Le menu top n'aura pas de parent. (unique)
les sous-menus intermédiaires auront tous les champs remplis
les sous-menu finaux auront que le champ parent de rempli.

Ainsi, on peut aisément situer chaque élément dans la hiérarchie et donc agir sur ceux désirés -> même niveau, niveaux inférieurs, top.

Le script sera affecté à chaque gameObject qui gère la hiérarchie du menu (pour éviter que tous les enfants soient pris en compte, on peut avoir des GO Text ou Image qui ne sont là que pour le graphisme) et par le biais de GetComponentsInChildren () ou GetComponentInParent () reconstruire la hiérarchie via code.

[Iwa]

Est-ce que tu génères ton menu à la volée ou pas du tout? Sinon cette idée là tient la route, c'est une bonne façon de faire je pense

[boubouk50]

Non, le menu est créé dans l'éditeur, c'est le comportement qui est généré au démarrage.

[boubouk50]

Bon, ça pose de petits problèmes avec la conception des menus...
Le fait est que les nœuds hiérarchiques ne sont pas forcément les nœuds d'interaction. On a vite fait d'ajouter des Panels/Images/etc pour créer un menu évolué (un ou plusieurs fond, un sous-bouton). De ce fait un bouton pour ouvrir un menu n'est pas forcément le nœud de menu, ce peut être son enfant (ou petit-enfant). Il faut donc gérer cela et dissocier le nœud hiérarchique du nœud interactif (si on peut dire) ou bien se contraindre à ce que ces nœuds ne fassent qu'un dans la conception.

Du coup, je pensais faire un truc simple, mais je me rend compte que pour que ce soit vraiment efficace, il faudrait tout gérer par script, la construction en Editor et le système en InGame... Mais là, autant faire un asset évolué, moi qui voulais juste gérer le système inGame facilement...

[Alesk]

J'ai déjà bossé sur des trucs comme ça.

Il est utile de mémoriser dans une variable statique le dernier menu qui a été cliqué, ainsi au clic suivant (sur un menu ou totalement en dehors) tu sais lequel doit être fermé.

Tu peux aussi te faire une fonction récursive pour identifier les ancêtres d'un menu en particulier (en concaténant par exemple leurs identifiants uniques dans une string), ainsi tu sauras si tu te trouves dans une même branche ou non.

Normalement ces deux outils te permettent de t'en sortir sur la logique de tous les comportements dont tu as besoin.

[boubouk50]

Il est utile de mémoriser dans une variable statique le dernier menu qui a été cliqué, ainsi au clic suivant (sur un menu ou totalement en dehors) tu sais lequel doit être fermé.

Je pensais gérer ça avec l'EventSystem, mais je ne vois pas LastPointEnter... Comme quoi les infos dans l'Inspector ne sont pas forcément accessible. Par contre, là où c'est plus délicat, c'est de gérer les multiples cas. Pas seulement fermer le dernier volet ouvert, mais toute la hiérarchie si ce qui a été cliqué ne figure pas sur la liste du menu (clic ailleurs ou autre menu). Evidemment, tout s'enregistre et se teste, mais ça reste du fait main complet j'ai l'impression.

Tu peux aussi te faire une fonction récursive pour identifier les ancêtres d'un menu en particulier (en concaténant par exemple leurs identifiants uniques dans une string), ainsi tu sauras si tu te trouves dans une même branche ou non.

La récursivité, c'est vers quoi je me dirigeais. Pour les UniqueIDs, j'avais pas pensé à cette solution, j'étais plutôt parti pour recréer l'arbre hiérarchique. J'explorerais. Merci.

[Alesk]

Je pensais gérer ça avec l'EventSystem, mais je ne vois pas LastPointEnter... Comme quoi les infos dans l'Inspector ne sont pas forcément accessible. Par contre, là où c'est plus délicat, c'est de gérer les multiples cas. Pas seulement fermer le dernier volet ouvert, mais toute la hiérarchie si ce qui a été cliqué ne figure pas sur la liste du menu (clic ailleurs ou autre menu). Evidemment, tout s'enregistre et se teste, mais ça reste du fait main complet j'ai l'impression.

En comparant le chemin hierarchique (la liste d'IDs concaténés) du menu cliqué et de celui cliqué juste avant, tu peux facilement régler ce cas.