Bonjour à tous,
je développe une api pour des tracer des graphes, j'aurais besoin d'un petit
coup de main. Voici le problème :
j'ai une classe Graphe qui hérite de JComponent et qui reçoit les évènements
souris. Cette classe Graphe contient plusieurs objet, sous-graphes, barre
d'outils perso etc... Ce ne sont pas des JComponents pour des raisons
d'optimisation.
Je me pose la question suivante :
-est-il judicieux de rerouter les évènements souris de la classe Graphe vers
les différentes classes contenues, en trouvant l'objet par l'appel
isInxxxBounds(e.getPoint) pour chaque objet contenus dans le graphe par
exemple ?
(le e.getPoint est récupéré de l'évènement click de la souris)
Cela me permet de ne quasiment rien gérer niveau évènement dans ma classe
Graphe, mais plutôt dans les classes contenues.
Si ça vous parait judicieux, comment le mettre en oeuvre ?
Sinon, quelle serait l'autre solution ?
Bonjour à tous,
je développe une api pour des tracer des graphes, j'aurais besoin d'un petit
coup de main. Voici le problème :
j'ai une classe Graphe qui hérite de JComponent et qui reçoit les évènements
souris. Cette classe Graphe contient plusieurs objet, sous-graphes, barre
d'outils perso etc... Ce ne sont pas des JComponents pour des raisons
d'optimisation.
Je me pose la question suivante :
-est-il judicieux de rerouter les évènements souris de la classe Graphe vers
les différentes classes contenues, en trouvant l'objet par l'appel
isInxxxBounds(e.getPoint) pour chaque objet contenus dans le graphe par
exemple ?
(le e.getPoint est récupéré de l'évènement click de la souris)
Cela me permet de ne quasiment rien gérer niveau évènement dans ma classe
Graphe, mais plutôt dans les classes contenues.
Si ça vous parait judicieux, comment le mettre en oeuvre ?
Sinon, quelle serait l'autre solution ?
Bonjour à tous,
je développe une api pour des tracer des graphes, j'aurais besoin d'un petit
coup de main. Voici le problème :
j'ai une classe Graphe qui hérite de JComponent et qui reçoit les évènements
souris. Cette classe Graphe contient plusieurs objet, sous-graphes, barre
d'outils perso etc... Ce ne sont pas des JComponents pour des raisons
d'optimisation.
Je me pose la question suivante :
-est-il judicieux de rerouter les évènements souris de la classe Graphe vers
les différentes classes contenues, en trouvant l'objet par l'appel
isInxxxBounds(e.getPoint) pour chaque objet contenus dans le graphe par
exemple ?
(le e.getPoint est récupéré de l'évènement click de la souris)
Cela me permet de ne quasiment rien gérer niveau évènement dans ma classe
Graphe, mais plutôt dans les classes contenues.
Si ça vous parait judicieux, comment le mettre en oeuvre ?
Sinon, quelle serait l'autre solution ?
Bonjour à tous,
je développe une api pour des tracer des graphes, j'aurais besoin d'un
petit
coup de main. Voici le problème :
j'ai une classe Graphe qui hérite de JComponent et qui reçoit les
évènements
souris. Cette classe Graphe contient plusieurs objet, sous-graphes,
barre
d'outils perso etc... Ce ne sont pas des JComponents pour des raisons
d'optimisation.
Je me pose la question suivante :
-est-il judicieux de rerouter les évènements souris de la classe Graphe
vers
les différentes classes contenues, en trouvant l'objet par l'appel
isInxxxBounds(e.getPoint) pour chaque objet contenus dans le graphe par
exemple ?
(le e.getPoint est récupéré de l'évènement click de la souris)
Cela me permet de ne quasiment rien gérer niveau évènement dans ma
classe
Graphe, mais plutôt dans les classes contenues.
Si ça vous parait judicieux, comment le mettre en oeuvre ?
Sinon, quelle serait l'autre solution ?
N'est-il pas possible que tes classes (sous-graphes, barre d'outils,
...) étendent eux-même MouseAdapter ou implémentent MouseListener par
exemple (ou ActionListener en fonction du contexte). Comme ça, il
récupèrent directement les événements souris qui leur sont propres.
Miguel
Bonjour à tous,
je développe une api pour des tracer des graphes, j'aurais besoin d'un
petit
coup de main. Voici le problème :
j'ai une classe Graphe qui hérite de JComponent et qui reçoit les
évènements
souris. Cette classe Graphe contient plusieurs objet, sous-graphes,
barre
d'outils perso etc... Ce ne sont pas des JComponents pour des raisons
d'optimisation.
Je me pose la question suivante :
-est-il judicieux de rerouter les évènements souris de la classe Graphe
vers
les différentes classes contenues, en trouvant l'objet par l'appel
isInxxxBounds(e.getPoint) pour chaque objet contenus dans le graphe par
exemple ?
(le e.getPoint est récupéré de l'évènement click de la souris)
Cela me permet de ne quasiment rien gérer niveau évènement dans ma
classe
Graphe, mais plutôt dans les classes contenues.
Si ça vous parait judicieux, comment le mettre en oeuvre ?
Sinon, quelle serait l'autre solution ?
N'est-il pas possible que tes classes (sous-graphes, barre d'outils,
...) étendent eux-même MouseAdapter ou implémentent MouseListener par
exemple (ou ActionListener en fonction du contexte). Comme ça, il
récupèrent directement les événements souris qui leur sont propres.
Miguel
Bonjour à tous,
je développe une api pour des tracer des graphes, j'aurais besoin d'un
petit
coup de main. Voici le problème :
j'ai une classe Graphe qui hérite de JComponent et qui reçoit les
évènements
souris. Cette classe Graphe contient plusieurs objet, sous-graphes,
barre
d'outils perso etc... Ce ne sont pas des JComponents pour des raisons
d'optimisation.
Je me pose la question suivante :
-est-il judicieux de rerouter les évènements souris de la classe Graphe
vers
les différentes classes contenues, en trouvant l'objet par l'appel
isInxxxBounds(e.getPoint) pour chaque objet contenus dans le graphe par
exemple ?
(le e.getPoint est récupéré de l'évènement click de la souris)
Cela me permet de ne quasiment rien gérer niveau évènement dans ma
classe
Graphe, mais plutôt dans les classes contenues.
Si ça vous parait judicieux, comment le mettre en oeuvre ?
Sinon, quelle serait l'autre solution ?
N'est-il pas possible que tes classes (sous-graphes, barre d'outils,
...) étendent eux-même MouseAdapter ou implémentent MouseListener par
exemple (ou ActionListener en fonction du contexte). Comme ça, il
récupèrent directement les événements souris qui leur sont propres.
Miguel
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait correct
comme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait correct
comme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait correct
comme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait
correct
comme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Ce que je ne comprends pas, c'est que tes classes représentent des vues
(barre d'outils, sous-graphes, etc.) Donc les objets de ces classes
visualisent quelque chose. A partir de là, je ne vois pas trop pourquoi
ils ne sont pas des JComponent ... surtout par rapport à ton histoire de
performance. La classe abstraite JComponent implémente tous les
mécanismes d'affichage (double buffering, ...) et s'intégre parfaitement
dans l'environnement SWING (look&feel, évenements, ...).
Ce n'est surement pas lui qui va te gréver en perf.
Dans ton architecture, l'objet de classe Graphe (qui est un JComponent),
qui semble jouer le rôle de contrôleur, devrait demander à chacun des
vues le constituant de s'afficher eux-même. Si jamais, un évenement
d'une de ses vues l'intéresse, il peut s'enregistrer alors comme
listener.
Sinon, si tu ne veux absolument pas étendre JComponent pour tes classes,
alors fais en sorte que les objets de celles-ci soient des listener de
ton objet de la classe Graphe. Ils recoivent alors directement les
évenements utilisateur de ce dernier et peuvent vérifier si cet
évenement les concerne. Le pb est qu'ils devront gérer leur propre
affichage (lorsqu'une fenêtre les cache puis ne les cache plus, ...).
Et quand tu vas commencer à gérer ces pbs, je ne suis pas sûr que ton
implémentation sera plus performant que celle de la classe JComponent.
Miguel
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait
correct
comme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Ce que je ne comprends pas, c'est que tes classes représentent des vues
(barre d'outils, sous-graphes, etc.) Donc les objets de ces classes
visualisent quelque chose. A partir de là, je ne vois pas trop pourquoi
ils ne sont pas des JComponent ... surtout par rapport à ton histoire de
performance. La classe abstraite JComponent implémente tous les
mécanismes d'affichage (double buffering, ...) et s'intégre parfaitement
dans l'environnement SWING (look&feel, évenements, ...).
Ce n'est surement pas lui qui va te gréver en perf.
Dans ton architecture, l'objet de classe Graphe (qui est un JComponent),
qui semble jouer le rôle de contrôleur, devrait demander à chacun des
vues le constituant de s'afficher eux-même. Si jamais, un évenement
d'une de ses vues l'intéresse, il peut s'enregistrer alors comme
listener.
Sinon, si tu ne veux absolument pas étendre JComponent pour tes classes,
alors fais en sorte que les objets de celles-ci soient des listener de
ton objet de la classe Graphe. Ils recoivent alors directement les
évenements utilisateur de ce dernier et peuvent vérifier si cet
évenement les concerne. Le pb est qu'ils devront gérer leur propre
affichage (lorsqu'une fenêtre les cache puis ne les cache plus, ...).
Et quand tu vas commencer à gérer ces pbs, je ne suis pas sûr que ton
implémentation sera plus performant que celle de la classe JComponent.
Miguel
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait
correct
comme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Ce que je ne comprends pas, c'est que tes classes représentent des vues
(barre d'outils, sous-graphes, etc.) Donc les objets de ces classes
visualisent quelque chose. A partir de là, je ne vois pas trop pourquoi
ils ne sont pas des JComponent ... surtout par rapport à ton histoire de
performance. La classe abstraite JComponent implémente tous les
mécanismes d'affichage (double buffering, ...) et s'intégre parfaitement
dans l'environnement SWING (look&feel, évenements, ...).
Ce n'est surement pas lui qui va te gréver en perf.
Dans ton architecture, l'objet de classe Graphe (qui est un JComponent),
qui semble jouer le rôle de contrôleur, devrait demander à chacun des
vues le constituant de s'afficher eux-même. Si jamais, un évenement
d'une de ses vues l'intéresse, il peut s'enregistrer alors comme
listener.
Sinon, si tu ne veux absolument pas étendre JComponent pour tes classes,
alors fais en sorte que les objets de celles-ci soient des listener de
ton objet de la classe Graphe. Ils recoivent alors directement les
évenements utilisateur de ce dernier et peuvent vérifier si cet
évenement les concerne. Le pb est qu'ils devront gérer leur propre
affichage (lorsqu'une fenêtre les cache puis ne les cache plus, ...).
Et quand tu vas commencer à gérer ces pbs, je ne suis pas sûr que ton
implémentation sera plus performant que celle de la classe JComponent.
Miguel
"Miguel Moquillon" a écrit dans le message
de news:40d7ee28$0$294$
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le
seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait
correctcomme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Ce que je ne comprends pas, c'est que tes classes représentent des vues
(barre d'outils, sous-graphes, etc.) Donc les objets de ces classes
visualisent quelque chose. A partir de là, je ne vois pas trop pourquoi
ils ne sont pas des JComponent ... surtout par rapport à ton histoire de
performance. La classe abstraite JComponent implémente tous les
mécanismes d'affichage (double buffering, ...) et s'intégre parfaitement
dans l'environnement SWING (look&feel, évenements, ...).
Ce n'est surement pas lui qui va te gréver en perf.
Dans ton architecture, l'objet de classe Graphe (qui est un JComponent),
qui semble jouer le rôle de contrôleur, devrait demander à chacun des
vues le constituant de s'afficher eux-même. Si jamais, un évenement
d'une de ses vues l'intéresse, il peut s'enregistrer alors comme
listener.
Sinon, si tu ne veux absolument pas étendre JComponent pour tes classes,
alors fais en sorte que les objets de celles-ci soient des listener de
ton objet de la classe Graphe. Ils recoivent alors directement les
évenements utilisateur de ce dernier et peuvent vérifier si cet
évenement les concerne. Le pb est qu'ils devront gérer leur propre
affichage (lorsqu'une fenêtre les cache puis ne les cache plus, ...).
Et quand tu vas commencer à gérer ces pbs, je ne suis pas sûr que ton
implémentation sera plus performant que celle de la classe JComponent.
Miguel
oui, c'est vrai que ça fait pas mal de problèmes à régler, mais la classe
JComponent me parait très lourde. J'ai notamment besoin de pouvoir gérer
les repaint de manière très fine, encore pour des raisons d'optimisation,
tu
penses que c'est possible avec un JComponent ? Par exemple, lorsque le
chart
est scrollé, ne redessiner que la partie qui apparait, décaler la partie
qui
reste visible et effacer le reste... Je me complique peut-être beaucoup la
vie, mais ces classes devront être téléchargées par un réseau lent et
tourner sur des machines peut-être peu rapides, et j'ai un peu peur, en
mettant des JComponent partout, que ça pénalise bcp les perfs. Qu'en
penses-tu ?
merci pour tous ces éléments.
noe
"Miguel Moquillon" <miguel.moquillon@silicomp.com> a écrit dans le message
de news:40d7ee28$0$294$626a14ce@news.free.fr...
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le
seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait
correct
comme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Ce que je ne comprends pas, c'est que tes classes représentent des vues
(barre d'outils, sous-graphes, etc.) Donc les objets de ces classes
visualisent quelque chose. A partir de là, je ne vois pas trop pourquoi
ils ne sont pas des JComponent ... surtout par rapport à ton histoire de
performance. La classe abstraite JComponent implémente tous les
mécanismes d'affichage (double buffering, ...) et s'intégre parfaitement
dans l'environnement SWING (look&feel, évenements, ...).
Ce n'est surement pas lui qui va te gréver en perf.
Dans ton architecture, l'objet de classe Graphe (qui est un JComponent),
qui semble jouer le rôle de contrôleur, devrait demander à chacun des
vues le constituant de s'afficher eux-même. Si jamais, un évenement
d'une de ses vues l'intéresse, il peut s'enregistrer alors comme
listener.
Sinon, si tu ne veux absolument pas étendre JComponent pour tes classes,
alors fais en sorte que les objets de celles-ci soient des listener de
ton objet de la classe Graphe. Ils recoivent alors directement les
évenements utilisateur de ce dernier et peuvent vérifier si cet
évenement les concerne. Le pb est qu'ils devront gérer leur propre
affichage (lorsqu'une fenêtre les cache puis ne les cache plus, ...).
Et quand tu vas commencer à gérer ces pbs, je ne suis pas sûr que ton
implémentation sera plus performant que celle de la classe JComponent.
Miguel
oui, c'est vrai que ça fait pas mal de problèmes à régler, mais la classe
JComponent me parait très lourde. J'ai notamment besoin de pouvoir gérer
les repaint de manière très fine, encore pour des raisons d'optimisation,
tu
penses que c'est possible avec un JComponent ? Par exemple, lorsque le
chart
est scrollé, ne redessiner que la partie qui apparait, décaler la partie
qui
reste visible et effacer le reste... Je me complique peut-être beaucoup la
vie, mais ces classes devront être téléchargées par un réseau lent et
tourner sur des machines peut-être peu rapides, et j'ai un peu peur, en
mettant des JComponent partout, que ça pénalise bcp les perfs. Qu'en
penses-tu ?
merci pour tous ces éléments.
noe
"Miguel Moquillon" a écrit dans le message
de news:40d7ee28$0$294$
Voilà, le pb c'est que ce ne sont pas des JComponent, pour des raisons
d'efficacité en fait.
C'est pour ça que je suis obligé, je crois, de devoir passer par le
seul
JComponent de toute l'API, à savoir, la classe Graphe. Ca te parait
correctcomme architecture ?
Le pb d'en faire des JComponent, c'est que l'API va utiliser bcp de
ressources, et ça je peux pas me permettre...
Ce que je ne comprends pas, c'est que tes classes représentent des vues
(barre d'outils, sous-graphes, etc.) Donc les objets de ces classes
visualisent quelque chose. A partir de là, je ne vois pas trop pourquoi
ils ne sont pas des JComponent ... surtout par rapport à ton histoire de
performance. La classe abstraite JComponent implémente tous les
mécanismes d'affichage (double buffering, ...) et s'intégre parfaitement
dans l'environnement SWING (look&feel, évenements, ...).
Ce n'est surement pas lui qui va te gréver en perf.
Dans ton architecture, l'objet de classe Graphe (qui est un JComponent),
qui semble jouer le rôle de contrôleur, devrait demander à chacun des
vues le constituant de s'afficher eux-même. Si jamais, un évenement
d'une de ses vues l'intéresse, il peut s'enregistrer alors comme
listener.
Sinon, si tu ne veux absolument pas étendre JComponent pour tes classes,
alors fais en sorte que les objets de celles-ci soient des listener de
ton objet de la classe Graphe. Ils recoivent alors directement les
évenements utilisateur de ce dernier et peuvent vérifier si cet
évenement les concerne. Le pb est qu'ils devront gérer leur propre
affichage (lorsqu'une fenêtre les cache puis ne les cache plus, ...).
Et quand tu vas commencer à gérer ces pbs, je ne suis pas sûr que ton
implémentation sera plus performant que celle de la classe JComponent.
Miguel
oui, c'est vrai que ça fait pas mal de problèmes à régler, mais la classe
JComponent me parait très lourde. J'ai notamment besoin de pouvoir gérer
les repaint de manière très fine, encore pour des raisons d'optimisation,
tu
penses que c'est possible avec un JComponent ? Par exemple, lorsque le
chart
est scrollé, ne redessiner que la partie qui apparait, décaler la partie
qui
reste visible et effacer le reste... Je me complique peut-être beaucoup la
vie, mais ces classes devront être téléchargées par un réseau lent et
tourner sur des machines peut-être peu rapides, et j'ai un peu peur, en
mettant des JComponent partout, que ça pénalise bcp les perfs. Qu'en
penses-tu ?
merci pour tous ces éléments.
noe
