Tout d'abord je te remercie beaucoup pour ta réflexion, je comprend mieux !
Envoyé par
liberforce
stBox
Pourquoi tu as des champs id et name séparés, alors que tu indiques que le nom est obligatoirement unique ? Un identifiant, c'est quelque chose d'unique qui identifie un objet, alors pourquoi avoir deux identifiants ? A la rigueur, j'aurais pu comprendre si ID avait été du type
GQuark pour faire des comparaisons/recherches rapides, mais là ils sont du même type...
En fait, j'ai besoin des deux, il peut exister deux box ayant le même nom mais pas la même id, qui du coup permettra de les différencier.
Envoyé par
liberforce
Pour les champs pIN et pOUT: une GList ne me parait pas être une bonne idée pour stocker des éléments si tu connais leur nombre et que tu dois les parcourir fréquemment (pour retracer tes lignes par exemple). Je m'orienterai plutôt vers du
GPtrArray pour stocker les structures d'entrée/sortie.
Ah, voilà quelque chose de nouveau que j'apprend ! Ne connaissant pas encore tout de GTK (et du C en général), je ne voyais pas d'autres solutions qu'une GList ou une GHashTable ! Je ne connaissais pas les GPtrArray. J'ai quelques questions dessus : il y a-t-il besoin de gérer le transtypage comme pour les GList ou c'est inutile ?
Je m'explique : exemple pour récupérer le nom d'un pad dans le tableau d'indice i
(gchar *)((stBox *)g_ptr_array_index (IDPatches, i))->Name
ou
g_ptr_array_index (IDPatches, i)->Name ?
Sinon, à vrai dire, je me rend compte aussi je ne sais pas pourquoi je suis parti avec deux structures différentes pour les petits connecteurs...
Envoyé par
liberforce
stIN/stOUT
Comme je te l'ai dit, tes deux structures sont actuellement identiques... Une entrée et une sortie, c'est la même chose. Ce sont juste deux "Pads" que l'on peut connecter. C'est le conteneur, ton stBox, qui donne la direction de la connexion entrée -> sortie. Tu n'as donc besoin que d'une seule structure, appelons la "stPad" par exemple.
Je pencherai tout de même plus pour 2 structures au total : 1 pour les box et une pour les petits connecteurs, car j'ai bien peur qu'on ne s'y retrouve plus dans mon code.
Envoyé par
liberforce
Ensuite, tu as un champ BoxParent qui identifie le conteneur qui contient le Pad. Bon, déjà, on peut utiliser juste "parent" pour le décrire. Un objet évite en général de faire des suppositions sur ce qui le contient, parce qu'il sait ce que lui utilise, mais qu'il n'a pas à savoir qui l'utilise. En revanche, si son parent est toujours un stBox, alors autant l'indiquer via son type, et prendre un pointeur vers une stBox.
OK.
Envoyé par
liberforce
Pour le nom, c'est ok.
Pour l'id, ton but était de le propager pour que tous les pads connectés entre eux aient le même id. Mais quel est l'intérêt ? Cela te permet de savoir simplement si deux pads sont connectés entre eux, mais tu ne peux pas savoir directement à quels pads est connecté un pad. Le mieux je pense donc de conserver dans chaque pad à quels autres pads il est connecté. On a donc la encore un tableau de pads.
Effectivement, c'est mieux.
Envoyé par
liberforce
Pour X et Y, je ne sais pas à quoi ils servent, je ne peux donc pas me prononcer sur leur utilité. Je me demande juste pourquoi il s'agit de pointeurs.
En fait, j'en ai besoin pour savoir leurs positions pour dessiner les lignes de connexion. Mais je me pose la question, sachant que leur position est dépendante de celle du box parent et donc d'une formule simple, s'il vaut mieux stocker leurs valeurs courantes au sein de leur structure, ou alors de recalculer en fonction du x et y du box parent, sachant aussi qu'il va falloir gérer le redessinement lorsque l'utilisateur déplace une box.
P.S. : j'ai commencé à recoder, et finalement, c'est pas plus mal, ça permet d'améliorer voire rectifier certaines portions du code.
Partager