Gerer une selection d'objets

Version imprimable

Bonjour,

Je developpe actuellement un petit système d'interface graphique.

Ces interfaces peuvent être construites avec des composants : des boutons, des labels, des listes....

Maintenant, j'aimerais pouvoir gerer une selection d'objets : ajouter un objet à la selection, retirer un objet à la selection.

Pratiquement tous les objets seront selectionnable.

J'ai donc pensé à faire une classe "Gestionnaire de selection", qui s'occuperait de garder en mémoire la liste des objets selectionnés, et une interface "selectionnable" qui détermine qu'un objet est selectionnable.

J'ai donc un truc du genre :
Code:

1 2 3 4 5 6 7 8 9 class cGestionnaireSelection { private: std::vector<iSelectionnable*> m_vecteurObjets; public: int ajouterObjet(iSelectionnable* pObjet); int retirerObjet(iSelectionnable* pObjet); }
Seulement, voila mon probleme :

Certains objets sont selectionnables ensemble (plusieurs boutons, plusieurs labels ou plusieurs boutons ET plusieurs labels) alors que d'autres ne le sont pas (des boutons et des listes, c'est pas possible)

Donc, comment puis-je determiner si on a le droit ou pas d'ajouter un objet à la selection ?

Existe-t-il des méthodes pour ça (je pense à QT, Swing ou autre, ce genre de truc doit y être traité, non ?)

Merci !

19/12/2007, 19h31
zais_ethael

Heu, as-tu déja pu, avec une programme quelconque utilisant n'importe quelle api, sélectionner plusieurs composants à la fois? Moi jamais.
Il y a bien les listes, tableaux, arbres,... où on sélectionne plusieurs propositions à la fois, mais ça n'a rien à voir avec la conception du système, c'est juste géré par certains composants chacun à leur sauce.
19/12/2007, 20h20
NiamorH

Oui si tu parle de la notion de sélection au sens de "focus", je n'ai pas en tête non plus un exemple ou l'on puisse sélectionner plusieurs controls.
19/12/2007, 20h26
Davidbrcz

Je n'ai pas non plus en tête mais ac peut être assez utile.
Mais si ce n'est pas courant, je pense que c'est une bonné idée mais il faudrai resteindre cette possibilité a des widgets de même type.

Edit: Après réflexion,seul les bouttons semble être intéréssant à implémenter pour ce genre de chose.
20/12/2007, 09h10
buzzkaido

Les boutons et autre, c'est pour donner des exemples parlant à tout le monde.

Dans mon interface, on manipule des objets métiers.

Et que ce soit des boutons ou n'importe quoi d'autre, ça reste des objets, non ? Donc le principe est le même, non ?

Et puis, pensez à une interface faite pour construire.... des interfaces (un éditeur d'IHM, par exemple, quoi) !!!

On peut selectionner plusieurs boutons, plusieurs labels et autre... pour les déplacer, les grouper, les effacer....

Si on en selectionne un seul à la fois, on peut le renommer ou autre....

Donc on selectionne un ou plusieurs objets de même type ou pas et en fonction de ce que contient la selection, on peut faire certaines actions dessus.

En tout cas, je ne parle pas de focus. Ca, je le gère déjà et c'est beaucoup plus simple, puisque là, on ne donne le focus qu'à un seul composant à la fois.

Voilà.
20/12/2007, 10h08
zais_ethael

Dans ce cas...
Si on part du principe qu'on ne peut ajouter qu'un seul objet à la fois à la sélection, tu peux prévoir une méthode style bool selectionable::canAddToSelection(cGestionnaireSelection). En gros ça revient à demander à chaque objet si il veut bien être ajouté à la sélection, en se servant des critères qui lui plaisent pour faire ce choix (certains objets renverront toujours true, ou toujours false, ou auront un comportement plus tordu).
20/12/2007, 10h30
buzzkaido

Ah, effectivement, j'avais pour l'instant implémenté ça dans le gestionnaire de selection, mais c'est franchement pas pratique....

Déléguer ça au composant lui-même me parait un bien meilleure idée !

Par contre, un autre soucis : il faudrait que je construise un panneau de propriétés en fonction de ce que contient la sélection....

J'ai pensé à deriver cGestionnaireSelection en plusieurs classes spécialisées :

- cGestionnaireSelectionBouton
- cGestionnaireSelectionPlusieursBoutons
- cGestionnaireSelectionLabel
- cGestionnaireSelectionPlusieursLabel
- cGestionnaireSelectionLabelsEtBoutons
....

Et en fonction de ce que l'on ajoute à la selection, le gestionnaire est transformé pour fournir :
- le panneau de propriétés spécifique
- les méthodes spécifiques (copier/coller...)

Mais ça ne me parait pas pratique du tout (ça fait beaucoup de classes...)

Vous auriez des pistes pour ce genre de trucs ?

Merci !
20/12/2007, 15h21
Davidbrcz

Adaptateur ? Décorateur ?
20/12/2007, 20h51
zais_ethael

En java, toutes les propriétés de tous les composants sont détectées par réflexion, tous les gui builders fonctionnent comme ça.
Malheureusement en C++ ce n'est pas utilisable :(, mais il y a peut-être moyen de s'inspirer un peu histoire de réduire le code à taper au maximum. Ce que je pourrais imaginer c'est une classe par composant du genre XXXPropertyHandler (tous les property handlers héritent d'une même interface) qui soit capable de fournir une liste des propriétés (liste codée en dur) avec leur type (string, entier, ect,...bien évidemment, il faut se limiter à un nombre restreint de types), il sera aussi capable de paramétrer ces types (setString(composant,propertyname,string), setInt(composant,propertyname,int),...).
Ca fera toujours beaucoup de classes à taper, avec beaucoup de switchs, mais l'avantage c'est que l'aspect graphique de ton gui builder (ta liste de propriétés) ne devra être tapé qu'une seule fois (avec un affichage de tous les types à gérer), les property handlers par contre ne gèreront rien de graphique et leur code sera très systématique, donc très clair.
21/12/2007, 09h06
buzzkaido

Davidbrcz :

Décorateur, je vois pas trop comment l'utiliser dans ce cas...
Adaptateur, je connais pas, faut que je creuse...

zais_ethael :

Tu pourrais preciser un peu ce qu'est la reflexion en Java ?
Sinon, ce que tu proposes me parait une bonne idée !

Sinon, il reste la possibilité de créer une base de réflexion à la compilation. Et si ça se trouve, il est peut-être même possible de le faire en une fois avec quelques macros et templates, du genre:
Code:

1 2 3 4 5 6 //Dans la classe #define MEMBER(type, name) type name; \ ReflectionEntry< type > reflect_ ## name; //Dans la liste d'initialisation du constructeur #define INIT_MEMBER(name, val) name(val), reflect_ ## name(#name, &name)

21/12/2007, 11h53
zais_ethael

Citation:

Envoyé par buzzkaido

Tu pourrais preciser un peu ce qu'est la reflexion en Java ?

Ca consiste à apprendre au runtime les méthodes proposées par un objet, dans ce cas on s'interresse uniquement aux propriétés, représentées par des méthodes suivant une norme de nommage précise appelées accesseurs (getxxx, setxxx).
Imagine qu'on ait un composant fenêtre, le gui builder va identifier au runtime les propriétés, comme "title" qui est un string, "height" et "width" qui sont des unsigned int, ect... il peut détecter leur existence, récupérer leur valeur et en donner une nouvelle. C'est donc largement plus simple puisqu'il suffit de prévoir des boites de dialogue pour chaque type de base, après on code un petit système qui va rechercher toutes les propriétés d'un composant et les afficher dans une grille. Il y a même des gui builders où on peut ajouter des composants personnalisés à la volée, sans avoir besoin de coder quoi que ce soit pour expliquer au gui builder comment s'en servir.
21/12/2007, 13h31
buzzkaido
Ok !

Effectivement, c'est pas mal, comme principe...

Et la solution de Medinoc me parait bien adaptée...

Je vais essayer d'implementer ça comme ça :

Un interface cObjetAvecProprietes qui contient un vecteur de cProprietes.

Une classe mere cProprietes qui contient la valeur et un ID (ID_NOM, ID_LARGEUR, ID_HAUTEUR...).

Chaque objet selectionnable implemente cObjetAvecProprietes.

Toutes les proprietes editables de chaque objet selectionnable derivent de cProprietes (cProprietesInt, cProprietesString...) et ne sont pas des variables membres mais des entrées dans le vecteur.

Quand on selectionne plusieurs objets, on parcourt la liste des proprietes de chacun, et on propose d'editer toutes les proprietes qu'ils ont en commun (si ils ont tous une propriete avec comme ID la valeur ID_LARGEUR, on peut editer toutes les valeurs à la fois)

Comme ça, en plus je peux mettre un flag dans cPropriete pour dire si elle est editable même quand plusieurs objets sont selectionnés.

Du coup, par exemple, le nom est commun à plein de composants, mais n'est pas editable dans le cadre d'une selection multiple....

Ca me parait pas mal...

Et effectivement, avec un systeme de macro comme le dit Médinoc, ça peut grandement simplifier l'ecriture du code....
Code:

1 2 //Dans la définition de la classe #define MEMBER(type, name, ID, multiEdit) m_vecteurProprietes.push_back(new cPropriete##type(ID, name, multiEdit) );