Discussion :

[koala01]

Cette histoire de [signal][event][callback] (choisissez l'option que vous voulez, de toutes façon ce sont des notions différentes mais dans notre cas l'objectif est le même) n'est en effet pas si simple. Techniquement il n'y a rien de compliqué, je pense qu'on peut même s'en sortir avec boost::function (avec une map de boost::fonction par exemple si on veut plusieurs observeurs), mais c'est au niveau de la conception qu'il ne faut pas se planter.

Je crois que la meilleure solution dépends de ce que l'on veut faire, et qu'une fois qu'on aura bien déterminé ce que l'on veut faire, le choix nous paraitra évident.

Je suis globalement d'accord avec toi, si ce n'est que...

A titre tout à fait personnel, j'exècre les callbacks

Et, quelque part, faut il rappeler que la politique du projet est, malgré tout, d'utiliser au mieux les méthodes "modernes" disponibles

De ce point de vue, boost.signals2 fournit (c'est du moins mon ressenti) une alternative valable et efficace à tout ce que l'on pourrait faire avec les callbacks qui, de mon avis (mais on peut en discuter, hein ) s'apparente à une manière de faire totalement préhistorique (re ).

Je proposerais donc de prendre le problème "par l'autre bout", pour ne pas dire "le prendre à l'envers" et que l'on essaye de réfléchir à la possibilité de faire en utilisant en priorité boost.signals, quitte à faire "marche arrière" et à revenir à des possibilités plus traditionnelles (callbacks) si l'on se rend compte que l'approche "moderne" pose plus de problèmes qu'elle n'apporte de réponses.

Je ne dis pas qu'il faut abandonner de manière systématique les callbacks, mais je souhaiterais que leur utilisation soit restreinte au stricte minimum et au plus près des fonctions dépendante du système (en gros, qu'il n'y ait pas de callbacks au-delà de la façade que nous devrons mettre en oeuvre pour faire cohabiter les différents systèmes).

Quelques remarques d'ordre général sur le problème:

En fait, au niveau le plus abstrait, ce qu'il nous faut c'est que nos contrôles soient observables (DP observer), et que les observeurs puissent être implémentés par l'utilisateur. Il y a différentes techniques pour implémenter un observer (callback, signal/slot, événement), chacune ayant ses avantages et ses inconvénients. Par exemple, avec un système d'événement avec une FIFO de gestion de ces events, l'avantage est la souplesse et la facilité pour implémenter des animations. L'inconvénient c'est que c'est plus complexe à mettre en place (et donc à maintenir etc.).

Quelque part, si par la complexité de mise en place et de maintenance qu'implique signals2, on arrive à faciliter la vie de l'utilisateur, je vote sans réflexion pour la souplesse

Je pense qu'il faut commencer par répondre à des questions du style:
- Comment gérer les animations (par exemple une liste déroulante - combo - qui s'ouvre). Répondre à cette question nécessite répondre à la questions suivante:
- Va-t-on avoir besoin d'une boucle principale? Personnellement, je ne vois pas comment s'en passer.

Au niveau de l'application (TApplication et ses spécialisations ) on ne pourra pas éviter une boucle, cela me semble évident.

Mais bon, nous pourrions très bien nous en sortir avec quelque chose proche de

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class TApplication
{
    public:
        int run()
        {
            continue_=true;
            while(continue_)
            {
                /*...*/
            }
            return returnCode_;
        }
        void onStopRequest(int returnCode=0)
        {
            continue_=0;
            returnCode_=returnCode;
        }
    private:
        int returnCode_; // la valeur de retour
        bool continue_; // pour savoir si on retourne dans la boucle
};

Ha, et une précision: les événements de l'OS on ne peut pas s'en passer. C'est eux qui nous disent ce qu'il se passe (clic souris, touche clavier, etc.)

On ne peut pas s'en passer, mais l'idéal est de les "enrober" de manière à ce qu'ils soient "formatés" pour l'utilisation une fois qu'ils ont passé le "barrage" de la façade

[r0d]

Ok, ton point de vue me convient
Je ne connais pas boost.signal, je vais aller y jeter un coup d'oeil tout de suite pour m'assurer que c'est bien ce que je crois.
Une classe Application me semble une bonne idée, effectivement. Mais quelle sera l'interface publique de TApplication? En fait ce que je me demande c'est si c'est cette classe qui va gérer (dans le sens de "posséder": être responsable du cycle de vie) la(les?) fenêtre(s?) et les contrôles?

Et heu... pourquoi avez-vous choisi le T en préfixe (TMyClass)? C'est que ça me rappelle de mauvais souvenirs de la VCL (je déteste les IDE de Borland - je ne dis pas qu'ils sont mauvais, juste que je ne les aime pas)

[koala01]

Ok, ton point de vue me convient
Je ne connais pas boost.signal, je vais aller y jeter un coup d'oeil tout de suite pour m'assurer que c'est bien ce que je crois.

Si j'en ai moi-même bien compris le fonctionnement, ce sera le cas

Sois seulement attentif au fait qu'il y a deux boost.signals: la première version est non threadsafe, la seconde (boost.signals2) étant l'évolution thread safe de la première

Je préconise d'utiliser cette dernière

Une classe Application me semble une bonne idée, effectivement. Mais quelle sera l'interface publique de TApplication? En fait ce que je me demande c'est si c'est cette classe qui va gérer (dans le sens de "posséder": être responsable du cycle de vie) la(les?) fenêtre(s?) et les contrôles?

En gros, les (seules ) fonctions qu'elle exposerait serait... int run() et sa surcharge int run(int argc, char* argv[]) (boost.options inside ) et un signal onQuitQuery (ou similaire) permettant de mettre fin à la boucle.

Son (ses) princial / principaux membres "visuel(s)" serai(en)t... une TMainWindow ou ses spécialisations / dérivées.

Il serait éventuellement possible de spécialiser / dériver TApplication de manière à y rajouter des objets "externes" (ex: des infos de connexion à une base de données , infos de thread principal ), à moins que l'on ne considère plus opportun de les placer dans la fenêtre principale (c'est le genre de chose qui mérite réflexion )

Ce serait plutôt la fenêtre principale qui aurait la responsabilité de la durée de vie des autres éléments visuels

Je ne fais ici que tracer un tableau rapide de ce que je voudrais, en réfléchissant "à voix haute", car rien n'a encore été décidé sur ce point

Si donc vous avez des remarques à faire sur le sujet, n'hésitez pas (mais créez peut être une autre discussion, pour éviter de surcharger celle-ci )

Et heu... pourquoi avez-vous choisi le T en préfixe (TMyClass)? C'est que ça me rappelle de mauvais souvenirs de la VCL (je déteste les IDE de Borland - je ne dis pas qu'ils sont mauvais, juste que je ne les aime pas)

Pour respecter les règles de codage, et plus particulièrement les conventions de nommages

Plus sérieusement, le fait est qu'une très grosse partie du travail va consister en la définition d'une série de modèles de classes, de politiques et de traits associés...

Une personne ayant un bagage raisonnable en C++ sera donc sans doute très attiré par le fait de pouvoir effectuer un "fine tuning" des différentes classes, en mettant (pourquoi pas ) ses propres politiques / traits au points, ou en choisissant ceux et celles qui lui conviennent le mieux parmi l'existant.

Par contre, le pauvre Jean (dans mon scénario N°1) sera tout à fait largué si on lui met une bibliothèque qui fonctionne uniquement à coup de spécialisations de template entre les pattes.

L'idée sera donc de fournir une sélection utile et variée de tyedef sympa lui permettant... de travailler correctement.

Ces typedef n'auront plus le préfixe T, et il sera donc "facile" de lui dire "attention, les classes préfixées, c'est "touche pas à ca p'tit con" "

[yan]

la première version est non threadsafe, la seconde (boost.signals2) étant l'évolution thread safe de la première

Attention à ce que l'on entend par là.

"attention, les classes préfixées, c'est "touche pas à ca p'tit con" "

c'est pas

casse toi pauv' con

ou

fait pas le malin

?

[koala01]

Peut-être

En tout cas, c'est un drapeau de danger à agiter devant n'importe quel zoulou qui n'est pas habitué à manipuler les templates

[koala01]

Attention à ce que l'on entend par là.

Je vais donc préciser: c'est la version qui est susceptible d'être thread safe (qui dispose en tout cas de tout ce qu'il faut pour l'être en cas de besoin)

[r0d]

Ha ok, T c'est pour Template. Bien

Son (ses) princial / principaux membres "visuel(s)" serai(en)t... une TMainWindow ou ses spécialisations / dérivées.

Mouaich. Agrégation quand tu nous tiens... je n'aime pas trop cette idée de TApplication qui possède une TMainWindow (je pense d'ailleurs qu'il n'en faudrait pas qu'une), qui elle-même possède des contrôles. C'est rigide et ça peut poser des problèmes de maintenance.

Mais d'un autre côté je ne sais pas trop comment faire autrement.
Peut-être une factory qui nous permet de créer des fenêtres "à la volée", et après l'utilisateur gère lui même ses fenêtres... je sais pas...

edit: en fait la question est: "a-t-on besoin d'un lien fort entre la classe TApplication et les fenêtres?"

[koala01]

Ha ok, T c'est pour Template. Bien

C'est... logique

Mouaich. Agrégation quand tu nous tiens... je n'aime pas trop cette idée de TApplication qui possède une TMainWindow (je pense d'ailleurs qu'il n'en faudrait pas qu'une), qui elle-même possède des contrôles. C'est rigide et ça peut poser des problèmes de maintenance.

Cela peut poser des problèmes de maintenance, mais d'un autre coté, si, justement, il y a plusieurs fenêtre pouvant être considérées comme principales, il sera sans doute plus facile de faire dériver une classe Application pour y rajouter les fenêtres supplémentaires que de devoir commencer à gérer une collection de fenêtre à la main (d'autant plus que, les template aidant, nous risquons de ne pas avoir de base commune utile)

En plus, cela permet de distinguer clairement les responsabilités: les éléments visuels (fenêtre en tête) sont dédiés à... la gestion des éléments visuels (ou de l'aspect "vue" du MVC) et l'application est dédiée à la gestion de "ce qui vient en plus" de l'aspect purement visuel.

Mais d'un autre côté je ne sais pas trop comment faire autrement.

moi non plus

Peut-être une factory qui nous permet de créer des fenêtres "à la volée", et après l'utilisateur gère lui même ses fenêtres... je sais pas...

Cela pourrait parfaitement être une des politiques mises en oeuvre, par exemple, lorsque nous nous attèlerons à l'évolution prévue qui consiste à permettre les déclarative ui

edit: en fait la question est: "a-t-on besoin d'un lien fort entre la classe TApplication et les fenêtres?"

Ma réponse est relativement simple: le lien doit être le plus faible possible, en dehors du fait que l'arrêt de l'application doit signifier... la destruction de la fenêtre

C'est pour cela que j'envisage les classes Application et MainWindow (ou similaire) sous la forme de modèles et que je souhaite séparer clairement les deux

Il ne faut pas oublier qu'à terme, tu aura des fenêtres 2D ou 3D, des applications multi-threadées ou non, qu'il sera souhaitable d'avoir plusieurs "fenêtres principales", ou d'avoir une fenêtre principale "éclatée", un peu à la manière de ce que fait the Gimp, que l'application devra pouvoir gérer des timers ou des connexions divers et variés ou que sais-je.

Seule une séparation claire de l'application en elle-même par rapport à la (les) fenêtre(s) principale(s) nous permettra une telle souplesse dans l'utilisation

[r0d]

Ok. Bon on peut partir là-dessus pour l'instant, et si on parvient à ce que le lien entre l'application et les fenêtres reste ténu, ce sera simple de les séparer si besoin est.


"And now something diferent"

Un des objectifs de cette lib est d'être utilisable facilement par des débutants, mais de permettre également de faire des choses très complexes. En lisant la discussion d'à côté, il m'est apparu tout de suite l'idée de faire deux couches: une couche très modulaire, avec des templates dans tous les sens, et une couche au-dessus qui spécialisera celle-ci. C'est par exemple ce que fait la STL avec la classe string qui spécialise basic_string avec les politiques et allocateur qui va bien. Voyez-vous ce que je veux dire? (l'idée étant de ne pas faire des parties distinctes selon l'utilisateur cible, mais juste des couches superposées).

[koala01]

C'est en tout cas ainsi que j'envisage les choses...

nous avons une couche extrêmement flexible, à base de template, que peuvent utiliser les programmeurs "pointus" et, au dessus, une couche basée sur la spécialisation à coup de typedef, commençant au niveau de "Point2D" et s'étendant jusqu'à "ApplicationMultiThread" qui permet d'utiliser Button, Menu, MenuItems, etc, et qui est accessible "à tous"