Discussion :

[Ti-R]

J'ai un ami qui y a passé 1 an là-dessus Mais il a finit son projet de GUI "graphique".

J'y suis depuis 5 ans sur le mien, et j'ai toujours pas fini

Cela dépend jusqu'ou tu veux aller ?

Le dernier objet que j'ai écrit (et pas fini), est une sorte d'éditeur de texte simplifié, qui prend en compte des images et du texte avec des fonts différentes et des couleurs de font différentes...

Je n’ai pas encore implémenté la sélection du texte à l'intérieur de l'objet... Cela prend pas mal de temps si on veut bien faire les choses, en gérant le scrolling ou autre...

Vous êtes combien sur le projet ?

[Ange_de_coren]

En ce qui me concerne je suis pour le moment seul sur le projet, mais j'ai vraiment envi de savoir faire une GUI et une correcte.

Comme je le dissais dans les post précédent je compte en faire une pour OpenScenGraph qui comporte déjà pas mal d'option (un loader d'image et d'objet 3D) et l'utilisation des TTF. Bref de quoi simplifier le travail !!!

Sinon tu penses que c'est bon ce que j'ai dit pour le moment ?

[Sixissor]

la classe Widget étant l'élément de base où vont découler tous nos éléments (classe abstraite).

Cette classe possède 3 membres : x,y,z (coordonnée spaciale) pour situer un objet graphique. Le choix de coordonnée spaciale reside dans le fait que je veux réaliser une GUI 3D. Le problème reste à définir à quoi correspond ce point : le centre de l'objet, ou le coin supérieur gauche (insertion d'un booléan pour préciser ?).
Ensuite création d'une fonction virtuelle permettant d'afficher le widget.

Doit-on rajouter autre chose ? (boolean de visibilité, ... )

Déjà une GUI 2D c'est pas évident alors va pas compliquer les choses dès le début ^^
Il semblerait plus évident que ta coordonnée (x,y) (en global) correspondant au point (0,0) (en local) de ta fenêtre se situe en haut à gauche (ou bas à gauche selon les préférences). Il te faudrait en plus des attributs de largeur et de hauteur de fenêtre.
Un booléen de visibilité ne me semble pas très utile dans le sens où tu va pas t'amuser à cacher tes fenêtres... Par contre si tu veux implémenter plusieurs fenêtres, il te faudra prévoir le cas des fenêtres mères et filles, etc. Et extensible aux objets simples (boutons, etc.).
En gros voilà le problème: tu as 2 boutons superposés. Tu cliques dessus: seulement celui d'au-dessus devra avoir reçu l'événement "click" par exemple => gestion du focus.

Sinon, pour ton architecture, n'hésites surtout pas à t'inspirer des modèles déjà existants et regarde comment on fait dans C++ builder, Visual, etc.
On réinvente pas la roue

Comme je le dissais dans les post précédent je compte en faire une pour OpenScenGraph qui comporte déjà pas mal d'option (un loader d'image et d'objet 3D) et l'utilisation des TTF. Bref de quoi simplifier le travail !!!

Loader d'image => t'en trouves partout.
Loader d'Objets 3D => t'en trouves assez facilement aussi (OBJ et ASE abondent, sinon y'a lib3ds pour les modèles 3ds... Animation et tout La classe)
TTF => Windows gère ça très bien aussi.

[Ti-R]

Un booléen de visibilité ne me semble pas très utile dans le sens où tu va pas t'amuser à cacher tes fenêtres...

Cela peut toujours servir, j'en ai un je crois...

Pour faire apparaître/disparaitre certain éléments, on peut en ajouter un pour désactiver l'objet aussi.

Des trucs pas faciles à faire sont:
Copier-coller du contenu depuis ton GUI vers un OS (Au départ je voulais un GUI cross-Platform, mais déjà avec un OS, cela demande énormément de travail)
Car faut sélectionner des bouts de textes et les envoyer dans l'os (la partie facile c'est la communication mais bon faut se contraindre à trouver/écrire les bonnes fonctions)

Ensuite il y a plein de raccourci, comme "ctrl+tab", ou comme "ctrl+la molette", je n'y suis pas encore, parce qu’il faut tout coder, tout, tout, tout...

Mon GUI est loin d'être parfais, et à évolué au fil du temps, j'en suis à la troisième version majeur (+ une version en C).

Faut des bases solides, je suis d'accord, mais même si cela semble parfais dans ta tête et sur le papier, il y a toujours un moment donnée ou on arrive dans un cas ou, soit faut "patcher", soit dans le pire des cas réécrire une grosse partie....

Ma première version était une version 2D pure dans OpenGL (manipulation dans le buffer)
La seconde une GUI simple pour entrer du texte dans un editbox, et 2 types de boutons.
La version 3, écrite en C est une version 2 amélioré
La version 4 est une version C++ basé sur la 3 et la 2 qui gère scrollbar, fenêtres, fichiers de configurations, lecture de vidéo, images, images animées etc…

Je suis sur que je pourrais tout remettre à plat et refaire une version 5, qui ne serait pas parfaite non plus.

Si tu souhaites vraiment une GUI complète multi-platform, va falloir réserver pas mal de temps. A mon avis, tu devrais essayer de concevoir une gui de Base avec possibilité d’ajouts d’éléments, et vraiment te concentrer sur le moteur que sur les divers éléments à ajouter ensuite.

Ce n’est que mon point de vu.

[ash.ice.loky]

Si tu souhaites vraiment une GUI complète multi-platform, va falloir réserver pas mal de temps. A mon avis, tu devrais essayer de concevoir une gui de Base avec possibilité d’ajouts d’éléments, et vraiment te concentrer sur le moteur que sur les divers éléments à ajouter ensuite.

Il me semble que tu as bien resumé la situation.

Faire une bonne archi et agrementé ta GUI ensuite plutot que de faire X compos ...

Dans l'odre je ferais un truc comme ca :
- type d'archi et decoupage souhaité (en gros comment l'utilisateur (programmeur) de ma lib pourras utiliser la GUI), ce qui permet de voir les interaction entre les composants.
- La techno utilisé (Opengl, D3D, SDL, ...)
- Un type de base FENETRE (le pere de l'appli)
- Integration d'un bouton, image, text (ca suffit pour couvrir 90% des problemes que tu va rencontré, un truc bete mais affiché du texte sous SDL pure rapidement est quasiment infaisable donc exit l'editeur de texte avec cette techno)

[Ange_de_coren]

- Un type de base FENETRE (le pere de l'appli)

j'aimerai avec quelques informations sur cette partie. Qu'est-que ça doit faire exactement ?
Je pense qu'elle doit contenir un lien vers des fenetres (ou des widgets plus généralement), elle peut mémoriser le nom de l'application, dimension de la fenetre principale , ... (tout ça est fait sous opengl donc je sais pas si c'est vraiment nécessaire de refaire cette partie).

Je commence à voir un peu plus clair dans l'architecture général d'un GUI mais il me reste cette question pour le moment.

De plus, j'ai réfléchis à l'architecture de mémorisation des fenetres pour une application suivant une forme d'arbre(voir de graphe).

On part de la racine (fenetre principale) les fils sont des widgets (des fenetres par exemple)et on descend dans l'arbre avec d'autres widgets.
Ainsi pour afficher une fenetre il suffit de choisir un noeud fil de la racine.

Si vous pouvez commenter mes réflexions. N'hésitez pas à proposer des solutions.

Merki !

[ash.ice.loky]

Le systeme d'arbre, pourquoi pas mais les feuilles ne seront pas des widgets mais des conteneurs.

sinon tu ne pourras activer qu'un widget, or si tu as 3 boutons il faut les afficher tous les 3.

Le plus difficile est l'odre d'affichage.
Ta structure de données doit te permettre d'afficher rapidement tous les widgets non masqué par un autre.

l'idee est peut-etre d'avoir une sorte de map de vector

map <PROFONDEUR , VECTOR<widget> , TRIER>

faut y penser

[Invité]

Bonjour,

Je suis en train de commencer un systeme de widgets en OpenGL, donc un truc similaire.

Mon systeme, conçu sur le papier uniquement pour le moment, est comme ceci :

Mes widgets ressemblent à ceci :

Code :

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

1
2
3
4
5
6
7
8
 
struct Widget {
   int x, y;
   int w, h;
   renderer renderer;
   Child_list *child_list;
   parent *parent;
};

Un widget est associé à un unique renderer, qui est en fait une texture (recalculée ou non)

Et sur le principe, du moins pour le dessin, cela suffit.

La liste des enfants est ordonnée de maniere à ce que les widgets puissent etre systematiquement dessinés dans le bon ordre. (donc, dans l'ordre d'apparition, et on deplace ceux qui ont eu un raise au fur et à mesure)

Mes renderer sont au nombre de 3 pour le moment, un renderer blanck (qui sert dans le cas ou l'on veux faire des conteneurs), un renderer image, et un renderer texte.

par exemple, pour faire une fenetre de dialogue, on va avoir un truc de ce genre la :

Code :

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
 
Widget dialogue;
Widget bouton_ok;
Widget label_ok;
Widget label_dialogue;
 
dialogue.renderer = image_de_fond;
bouton_ok.renderer = image_de_fond;
label_ok.renderer = TextRenderer( "Ok" );
label_dialogue = TextRenderer( "Message du dialogue" );
 
AddChild( bouton_ok, label_ok );
AddChild( dialogue, bouton_ok );
AddChild( dialogue, label_dialogue );
 
bouton_ok.x = emplacement_x;
bouton_ok.y = emplacement_y;
/* etc... pour les coordonnée */
 
/* Et pour afficher */
AddChild( root, dialogue );

Ensuite, il suffit de coder des widgets un peu plus évolués, c'est à dire des combinaison des premiers, pour simplifier la tache.

La, on a un truc modulaire, à peu pres utilisable.

Et pour les évènnement, en fait, c'est assez simple, on parcoure ce même arbre en cherchant uqi a le focus, et quel sont les callbacks associés.

[Ange_de_coren]

Je suis en train de commencer un systeme de widgets en OpenGL, donc un truc similaire.

Si ça t'interresse on peut essayer de développer une architecture d'un GUI en confrontant nos idées sur ce forum. Ca te permettra de faire avancer ton projet et je pourrai faire une doc avec une expérience concrète.

Bref pour le moment je suis d'accord avec ton idée (bien pensé le coup du renderer ça évite de faire plein d'objet pour mettre du texte, des images , ...)

[Invité]

Si ça t'interresse on peut essayer de développer une architecture d'un GUI en confrontant nos idées sur ce forum. Ca te permettra de faire avancer ton projet et je pourrai faire une doc avec une expérience concrète.

Bref pour le moment je suis d'accord avec ton idée (bien pensé le coup du renderer ça évite de faire plein d'objet pour mettre du texte, des images , ...)

J'ai a peu pres tout dit, le reste n'est que détails, plus ou moins important, mais cela ne reste que des details... Sauf pour la gestion d'evenement, mais je n'ai que de vagues idées pour le moment.

Au niveau codage, je suis en train de faire la gestion de texte, il me reste donc encore pas mal de choses à faire avant de pouvoir reellement commencer mon Gui.

[ash.ice.loky]

Au niveau codage, je suis en train de faire la gestion de texte, il me reste donc encore pas mal de choses à faire avant de pouvoir reellement commencer mon Gui.

c'est tres interressant !! je me suis toujours pris la tete avec l'affichage de textes d'une facon parametrable avec SDL+OpenGL

je suis assez interressé si tu sort un truc potable

[Invité]

c'est tres interressant !! je me suis toujours pris la tete avec l'affichage de textes d'une facon parametrable avec SDL+OpenGL

je suis assez interressé si tu sort un truc potable

Ici cela reste assez simple, mais je ferai surement un topic d'aide à ce propos, freetype est assez complexe à utiliser.

Tout ce que je peux en dire pour le moment, c'est que je fait du rendu de texte à la volée et à partir de glyph pre-rendus pour les choses simples (compteur de fps par exemple) dans des textures.

[Ti-R]

Je viens de passer tout mon dimanche sur wglUseFontBitmaps, et un problème de contexte suivant le chemin d'appel de la fonction....

La fonction renvoie "false" et GetLastError(), ne renvoie rien.. Ce qui est TRES frustrant.

[EDIT]
A noté que j'ai déjà un contexte pour ma fenêtre, que les fonts fonctionnent sur plein de projet avec ma lib, et que cela posait problème que dans un cas précis..., lors d'appuie d'une touche.
[/EDIT]

[ash.ice.loky]

je me suis cassé les dents plus d'une fois sur les fonts avec openGL
via SDLcom/