Discussion :

[Klaim]

Salut à tous!

Je viens seulement de découvrir le forum du projet et j'ai juste parcouru rapidement pour l'instant (il se fait tard...) aussi peut être que ma question aura été traitée auparavant.

Où est donc la notion de découpage en "input_lib -> Farfelue -> output_lib" ?

Il me semblait que l'idée avait été retenue et j'ai l'impression, après avoir parcouru le forum et quelques tickets que la séparation n'est pas du tout évidente.

Par exemple, pour moi parler de pixels, de rectangles et de souris me parrait pour le moins inadequate, sauf si on les places dans des contextes de bibliothèques d'entrées et de sorties autour de Farfelue... non?

En proposant une séparation en 3 parties lors de la discussion, je voyais la biliothèque centrale plus comme un moyen de décrire un comportement abstrait qu'un portement physique concernant une interface, et que le comportement physique (input/output) serait défini donc à part et clairement spécialisé, mais suivant les interfaces de la bibliothèque centrale abstraite.

On peut abstraire les concepts d'interfaces jusqu'à omettre les notions d'espace et de rendu dés le moment ou on s'en tiens au comportement. L'aspects et les entrées sont toujours spécifiques alors autant séparer le code lié a l'aspect et les entrées du code décrivant le comportement non-aspects de de l'interface.

Je vais essayer (si je trouve le temps la semaine prochaine) de monter un exemple de ce a quoi je pensais, parceque je sens que je sui sloin d'être clair. ^^;

[minnesota]

Salut,

Par exemple, pour moi parler de pixels, de rectangles et de souris me parrait pour le moins inadequate, sauf si on les places dans des contextes de bibliothèques d'entrées et de sorties autour de Farfelue... non?

Non, en fait tout est intégré dans Farfelue, il y a le kernel qui représente la base et les moteurs de rendu et de saisis qui sont l'extension du kernel. Par exemple, le rectangle est une notion concrète qui a des propriétés et que l'on peut définir ou conceptualisée aisément dans le kernel, mais sa représentation au sein du système d'exploitation sera confiée au moteur, c'est-à-dire l'API de l'OS. Mais tout ça c'est dans Farfelue. Il n'est a priori pas question d'encapsuler l'API de l'OS dans une Lib intermédiaire pour l'encapsuler de nouveau dans Farfelue. C'est juste que si la partie kernel est bien délimitée, la partie OS le sera aussi. Mais pour être sûr, il faudra attendre confirmation.

Cela dit, j'attends avec impatience ton exemple.

[Klaim]

Salut,



Non, en fait tout est intégré dans Farfelue, il y a le kernel qui représente la base et les moteurs de rendu et de saisis qui sont l'extension du kernel. Par exemple, le rectangle est une notion concrète qui a des propriétés et que l'on peut définir ou conceptualisée aisément dans le kernel, mais sa représentation au sein du système d'exploitation sera confiée au moteur, c'est-à-dire l'API de l'OS. Mais tout ça c'est dans Farfelue. Il n'est a priori pas question d'encapsuler l'API de l'OS dans une Lib intermédiaire pour l'encapsuler de nouveau dans Farfelue. C'est juste que si la partie kernel est bien délimitée, la partie OS le sera aussi. Mais pour être sûr, il faudra attendre confirmation.

Justement il me semble que ça ça a déjà été fait et ça me semble impossible d'avoir quelquechose d'assez générique si il n'y a pas une séparation quelque part.

Cela dit, j'attends avec impatience ton exemple.

J'essaye de faire un exemple court dans la semaine.

[koala01]

Salut,

Je présumes que tu fais référence, entre autres, à l'un de diagrammes de classes dans lequel il y en a une (TMouseListener) qui présente explicitement un interface à base de onMouseXXX...

J'avoue avoir complètement "zappé" le problème que tu remet en évidence ici au moment de créer ce diagramme de classes ... Ce qui est un comble lorsque l'on sait que j'étais le plus gros promoteur de cette approche qui consiste à considérer un "système de pointage" générique

Il faudrait donc renommer la classe pour la faire correspondre d'avantage à cette approche (quelque chose comme TPointingInputListener ), la modifier pour qu'elle soit spécialisable sur base du système de pointage, et renommer les fonctions de son interface en conséquence (onPointingXXX)...

Rien de plus facile Je le fais de suite

Je placerai les fichiers de bouml sur le svn tout de suite après

[Klaim]

Je pensais effectivement a quelque chose comme ça, mais pas seulement.

Pour moi, l'interface de farfelue devrait dépendre du "type" d'input et d'output qu'on veut utiliser, sans préciser exactement l'implémentation, du moins pas dans le code définissant le comportement.

Je pensais a quelque chose de l'ordre 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
22
23
24
25
26
 
// ici on définit le type d'interface de code dont on a besoin, 
// pas la lib utilisée derrière mais juste si c'est de la 2D, 
// si on a besoin de précision niveau inputs, etc, 
// histoire que le code de comportement puisse exploiter 
// ces données sans avoir quelles sont les libs utilisées derrière.
typedef Farfelue::Interface< Farfelue::Input_MouseKeyboard , Farfelue::OutPut_2DFlatScreen > Interface; // classique : clavier + souris pour manipuler une interface 2D 
 
//ensuite on définit les modules d'entrée et de sortie, 
// dll ou autre, peu importe c'est du détail d'implémentation
Interface::input_system( "OIS" ); // on utilise la bibliothèque OIS pour acquérir clavier et souris, ça aurait pu être Win32 ou X, ou autre chose
Interface::output_system( "Win32" ); // on utilise Win32 pour l'affichage, ça aurait pu être OpenGL ou DirectX ou autre
 
Interface ma_fenetre("ma_fenetre"); // une fenetre
Interface mon_boutton("mon_boutton");// un boutton
// etc
 
/////////////////////////////////////////////////////////////////////////
// si on voulait utiliser des systemes différentes, par exemple sur un iPad :
typedef Farfelue::Interface< Farfelue::Input_MultiPoint , Farfelue::OutPut_2DFlatScreen > Interface; // multipointeurs + affichage 2D
 
// on encore, une interface custom pour un jeu vidéo par exemple
typedef Farfelue::Interface< Farfelue::Input_MouseKeyboard , Farfelue::OutPut_3DSolidSpace > Interface; // on veut manipuler l'interface avec l'équivalent d'un clavier/souris mais l'interface elle même sera représentée par des blocs dans un espace 3D...
 
// variante exemple
typedef Farfelue::Interface< Farfelue::Input_MultiTouch , Farfelue::OutPut_3DFlatSpace > Interface; // on veut manipuler l'interface avec du multi-pointeur mais l'interface elle même sera représentée par des espaces 2D dans un espace 3D...

Il est un peu tard alors c'est un peu n'importe quoi comme exemple mais en tout cas ça serait une meilleur séparation je pense :

(module lib d'input) => [partie "en dur"] (interface d'input) => (code comportement) => (interface output) [/partie "en dur"] => (module lib d'output)

On est obligé d'avoir du code utilisateur qui prenne en compte le type d'entrées, d'espace et de rendu de l'interface. En revanche on doit pouvoir permettre de changer l'implémentation de ce rendu et l'acquisition de ces inputs sans changer le code utilisateur.

Oulàlà il se fait tard...

[minnesota]

Merci Klaim.

C'est vrai que ton exemple est très parlant, parce qu'en effet, je ne voyais pas une séparation aussi radicale.

Mon avis :

C'est excellent, pas facile pour moi, et dans l'absolut, mais néanmoins excellent. En tout cas, je suis vraiment content de savoir que tu participes au projet et j'en connais d'autre qui seront aux anges de le savoir aussi, surtout avec des interventions de ce genre.

Ce topique risque d'être très intéressant pour Farfelue.
J n'ai pas le niveau pour en débattre plus profondément. Cela dit, je sais reconnaitre un code quand il est beau.

[Klaim]

N'allons pas trop vite

Non seulement mon expérience sur le sujet est très limitée et donc certainement quelque peu idéaliste; mais en plus je ne vais pas pouvoir participer activement au projet avant un (long moment)

Mais j'espère que (si je me suis fait comprendre sur le fond) vous explorerez cette idée voir si c'est réellement utile.

edit> D'ailleurs, dans mon exemple (qui est fait vraiment a l'arrache...) il faudrait remplacer Mouse par Pointer et Keyboard par quelque chose de plus abstrait disant qu'il y a des "bouttons physiques", soit avec 2 etats (pressé, lachés) soit avec de l'analogique... enfin bref c'est pas aussi abstrait qu'il faudrait quoi.

[minnesota]

Je vois ce que tu veux dire bien qu’à titre personnel je ne vois pas d'inconvénient à utiliser un keyboard ou keypad, mais c'est aussi parce que je n'ai ni le recule ni l'expérience nécessaire.

En attendant l'intervention de nos amis,
promets-moi quand même que tu passeras "aux moins" assez souvent.

[Klaim]

Oui je suit de loin ^^;