Je te conseille :
http://www.gtkmm.org/
Je rebondis car le choix d'une API graphique est typiquement une de
mes préoccupations du moment. Je ne trouves rien qui me conviennes.
Enfin si, mais BeOS est mort, et Haiku n'est pas encore exploitable. Et
puis ce ne serait pas portable...
Existe-t-il un API graphique permettant le genre de chose suivantes :
class MyWindow : public gapi::Windows
{
virtual void onclose() ;
}
Et que onclose soit la méthode appelée lorsque la fenêtre est fermée,
et ne pas avoir à utiliser une syntaxe lourdingue, à savoir connecter la
fonction à un événement. En C je comprends qu'il n'y ait pas le choix,
mais en C++, on a quand même une syntaxe permettant de faire facilement
de l'orienté objet.
[SNIP]
Est-ce moi qui ait une vision biaisée en raison de la Be API, ou
est-ce que cette habitude de connecter est la bonne ?
Je te conseille :
http://www.gtkmm.org/
Je rebondis car le choix d'une API graphique est typiquement une de
mes préoccupations du moment. Je ne trouves rien qui me conviennes.
Enfin si, mais BeOS est mort, et Haiku n'est pas encore exploitable. Et
puis ce ne serait pas portable...
Existe-t-il un API graphique permettant le genre de chose suivantes :
class MyWindow : public gapi::Windows
{
virtual void onclose() ;
}
Et que onclose soit la méthode appelée lorsque la fenêtre est fermée,
et ne pas avoir à utiliser une syntaxe lourdingue, à savoir connecter la
fonction à un événement. En C je comprends qu'il n'y ait pas le choix,
mais en C++, on a quand même une syntaxe permettant de faire facilement
de l'orienté objet.
[SNIP]
Est-ce moi qui ait une vision biaisée en raison de la Be API, ou
est-ce que cette habitude de connecter est la bonne ?
Je te conseille :
http://www.gtkmm.org/
Je rebondis car le choix d'une API graphique est typiquement une de
mes préoccupations du moment. Je ne trouves rien qui me conviennes.
Enfin si, mais BeOS est mort, et Haiku n'est pas encore exploitable. Et
puis ce ne serait pas portable...
Existe-t-il un API graphique permettant le genre de chose suivantes :
class MyWindow : public gapi::Windows
{
virtual void onclose() ;
}
Et que onclose soit la méthode appelée lorsque la fenêtre est fermée,
et ne pas avoir à utiliser une syntaxe lourdingue, à savoir connecter la
fonction à un événement. En C je comprends qu'il n'y ait pas le choix,
mais en C++, on a quand même une syntaxe permettant de faire facilement
de l'orienté objet.
[SNIP]
Est-ce moi qui ait une vision biaisée en raison de la Be API, ou
est-ce que cette habitude de connecter est la bonne ?
L'argument est plus celui qu'explique James, si une fenêtre
possède 20 boutons, chacun associé à une action différente,
il est plus simple d'écrire 20 fonctions que 20 classes
différentes.
L'argument est plus celui qu'explique James, si une fenêtre
possède 20 boutons, chacun associé à une action différente,
il est plus simple d'écrire 20 fonctions que 20 classes
différentes.
L'argument est plus celui qu'explique James, si une fenêtre
possède 20 boutons, chacun associé à une action différente,
il est plus simple d'écrire 20 fonctions que 20 classes
différentes.
On Fri, 25 Jan 2008 11:27:48 +0100, Sylvain Togni <"sylvain.togni at
visionobjects.com">:L'argument est plus celui qu'explique James, si une fenêtre
possède 20 boutons, chacun associé à une action différente,
il est plus simple d'écrire 20 fonctions que 20 classes
différentes.
Note que le cas des boutons est justement géré différemment du reste
par Windows lui-même :
- Un message "normal" (par exemple, déplacement de la souris)
est envoyé au bouton lui-même (en fait, via l'héritage fenêtre ->
bouton).
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Du coup, dans un système basé sur les fonctions virtuelles, c'est
probablement une fonction de la fenêtre parent qui serait appelée lors
d'un clic sur le bouton.
On Fri, 25 Jan 2008 11:27:48 +0100, Sylvain Togni <"sylvain.togni at
visionobjects.com">:
L'argument est plus celui qu'explique James, si une fenêtre
possède 20 boutons, chacun associé à une action différente,
il est plus simple d'écrire 20 fonctions que 20 classes
différentes.
Note que le cas des boutons est justement géré différemment du reste
par Windows lui-même :
- Un message "normal" (par exemple, déplacement de la souris)
est envoyé au bouton lui-même (en fait, via l'héritage fenêtre ->
bouton).
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Du coup, dans un système basé sur les fonctions virtuelles, c'est
probablement une fonction de la fenêtre parent qui serait appelée lors
d'un clic sur le bouton.
On Fri, 25 Jan 2008 11:27:48 +0100, Sylvain Togni <"sylvain.togni at
visionobjects.com">:L'argument est plus celui qu'explique James, si une fenêtre
possède 20 boutons, chacun associé à une action différente,
il est plus simple d'écrire 20 fonctions que 20 classes
différentes.
Note que le cas des boutons est justement géré différemment du reste
par Windows lui-même :
- Un message "normal" (par exemple, déplacement de la souris)
est envoyé au bouton lui-même (en fait, via l'héritage fenêtre ->
bouton).
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Du coup, dans un système basé sur les fonctions virtuelles, c'est
probablement une fonction de la fenêtre parent qui serait appelée lors
d'un clic sur le bouton.
Note que le cas des boutons est justement géré différemment du reste
par Windows lui-même :
- Un message "normal" (par exemple, déplacement de la souris)
est envoyé au bouton lui-même (en fait, via l'héritage fenêtre ->
bouton).
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Du coup, dans un système basé sur les fonctions virtuelles, c'est
probablement une fonction de la fenêtre parent qui serait appelée lors
d'un clic sur le bouton.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
Note que le cas des boutons est justement géré différemment du reste
par Windows lui-même :
- Un message "normal" (par exemple, déplacement de la souris)
est envoyé au bouton lui-même (en fait, via l'héritage fenêtre ->
bouton).
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Du coup, dans un système basé sur les fonctions virtuelles, c'est
probablement une fonction de la fenêtre parent qui serait appelée lors
d'un clic sur le bouton.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
Note que le cas des boutons est justement géré différemment du reste
par Windows lui-même :
- Un message "normal" (par exemple, déplacement de la souris)
est envoyé au bouton lui-même (en fait, via l'héritage fenêtre ->
bouton).
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Du coup, dans un système basé sur les fonctions virtuelles, c'est
probablement une fonction de la fenêtre parent qui serait appelée lors
d'un clic sur le bouton.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
Ben non, c'est toujours un method template, il me semble, dans lequelle on
appellerait la fonction de la classe de base avant la fonction de la classe
dérivée pour finir par envoyer le wm_command.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
Ben non, c'est toujours un method template, il me semble, dans lequelle on
appellerait la fonction de la classe de base avant la fonction de la classe
dérivée pour finir par envoyer le wm_command.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
Ben non, c'est toujours un method template, il me semble, dans lequelle on
appellerait la fonction de la classe de base avant la fonction de la classe
dérivée pour finir par envoyer le wm_command.
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
James Kanze wrote on 26/01/2008 11:49:- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
subjectif tout ça ...
certes (dans ce schéma) les N boutons d'un container exigeront
N case d'un switch dans la procédure (virtuelle) "onCommand"
de ce container et certes, si 'on' n'aime pas les switchs,
cela peut être lourd.
James Kanze wrote on 26/01/2008 11:49:
- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
subjectif tout ça ...
certes (dans ce schéma) les N boutons d'un container exigeront
N case d'un switch dans la procédure (virtuelle) "onCommand"
de ce container et certes, si 'on' n'aime pas les switchs,
cela peut être lourd.
James Kanze wrote on 26/01/2008 11:49:- Quand l'utilisateur clique sur le bouton, Windows envoie un
message WM_COMMAND à la fenêtre parent du bouton (i.e. celle qui le
contient), avec l'identifiant du bouton en paramètre.
Ce qui veut dire qu'il faut un switch ou une serie d'if pour les
départager ? Pas très sioux, à mon avis.
subjectif tout ça ...
certes (dans ce schéma) les N boutons d'un container exigeront
N case d'un switch dans la procédure (virtuelle) "onCommand"
de ce container et certes, si 'on' n'aime pas les switchs,
cela peut être lourd.
certes (dans ce schéma) les N boutons d'un container exigeront
N case d'un switch dans la procédure (virtuelle) "onCommand"
de ce container et certes, si 'on' n'aime pas les switchs,
cela peut être lourd.
Ça dépend. J'utilise volentiers des switch pour décoder des
entrées. Ici, en revanche, il me semble effectivement mal
placé. Au niveau plus bas, le système a déjà dû mappé la
position du curseur à l'évenemment. Alors, autant que faire,
pourquoi pas directement à un pointeur à un objet, plutôt qu'à
un enum ou quelque chose.
En fait, d'autres solutions sont possible aussi. Donc, par
exemple, chaque bouton est unique -- il a une étiquette
différente, un icon différent, etc. La solution de Swing (qui me
semble convenir assez ici, au moins dans certains cas), c'est
que la classe JButton lit ces informations de l'Action qui lui
est attachée. On régroupe donc tout qui varie selon le bouton.
certes (dans ce schéma) les N boutons d'un container exigeront
N case d'un switch dans la procédure (virtuelle) "onCommand"
de ce container et certes, si 'on' n'aime pas les switchs,
cela peut être lourd.
Ça dépend. J'utilise volentiers des switch pour décoder des
entrées. Ici, en revanche, il me semble effectivement mal
placé. Au niveau plus bas, le système a déjà dû mappé la
position du curseur à l'évenemment. Alors, autant que faire,
pourquoi pas directement à un pointeur à un objet, plutôt qu'à
un enum ou quelque chose.
En fait, d'autres solutions sont possible aussi. Donc, par
exemple, chaque bouton est unique -- il a une étiquette
différente, un icon différent, etc. La solution de Swing (qui me
semble convenir assez ici, au moins dans certains cas), c'est
que la classe JButton lit ces informations de l'Action qui lui
est attachée. On régroupe donc tout qui varie selon le bouton.
certes (dans ce schéma) les N boutons d'un container exigeront
N case d'un switch dans la procédure (virtuelle) "onCommand"
de ce container et certes, si 'on' n'aime pas les switchs,
cela peut être lourd.
Ça dépend. J'utilise volentiers des switch pour décoder des
entrées. Ici, en revanche, il me semble effectivement mal
placé. Au niveau plus bas, le système a déjà dû mappé la
position du curseur à l'évenemment. Alors, autant que faire,
pourquoi pas directement à un pointeur à un objet, plutôt qu'à
un enum ou quelque chose.
En fait, d'autres solutions sont possible aussi. Donc, par
exemple, chaque bouton est unique -- il a une étiquette
différente, un icon différent, etc. La solution de Swing (qui me
semble convenir assez ici, au moins dans certains cas), c'est
que la classe JButton lit ces informations de l'Action qui lui
est attachée. On régroupe donc tout qui varie selon le bouton.
