à propos des GUI écrites en C !

Bonjour et bienvenue,

Tu mélanges plusieurs choses. Il y a d'abord le langage C, qui est très répandu parce qu'il a de l'âge, parce son histoire est intimement liée à celle d'Unix, et parce que son fonctionnement est très proche du fonctionnement réel d'un micro-processeur. Donc si les bibliothèques que tu cites sont écrites en C, c'est surtout dû à l'état de l'art et pas au fait que le C soit plus adapté qu'un autre langage à la gestion de fenêtres en particulier. Il y ensuite, et seulement après, les gestionnaires de fenêtres proprement dits.

Citation:

… je connais peu le C (débutant) mais assez pour savoir qu'il n'y à aucun header nu fonction qui "dessine" sur l'écran pour construire une fenêtre et tout.

Il est difficile de comprendre où tu veux en venir sans avoir une idée des langages que tu connais déjà mais, si c'est bien ce à quoi je pense, il y a effectivement des langages qui définissent des primitives graphiques en standard, tel que le BASIC ou on trouvait au moins les équivalents de LINE, PLOT, BOX… à charge ensuite à l'implémentation du langage de mettre tout cela en œuvre sur la machine cible.

En C, rien de tout cela, pour la simple raison qu'il n'y a AUCUNE directive pré-codée dans le langage C. Simplement quelques mots-clés et des descripteurs de structures tels que boucles et autre. Cela dit, il y a une « bibliothèque standard » qui renferme le minimum syndicale qu'une plate-forme de développement C doit proposer, mais il s'agit bien d'une bibliothèque, et pas d'instructions codées en dur dans le compilateur.

Ceci est dû au fait que l'effet de ces instructions est dépendant de la machine : s'il n'y a pas de moniteur ni de carte graphique sur ton PC, des instructions telles que LINE, PLOT ou BOX n'ont aucune raison d'être et ne peuvent être accomplies. Cela peut même être le cas pour banal « printf » (qui est pourtant la première fonction que l'on apprend en C) si tu programmes un micro-contrôleur, par exemple.

Ensuite, pour faire apparaître quelque chose à l'écran au plus bas niveau du fonctionnement de ta machine (par exemple, en assembleur sur PC, sans utiliser d'appel système ni d'interruptions B.I.O.S. ou D.O.S.) on écrit dans la mémoire vidéo, tout simplement. L'automate de la carte graphique lit cette zone en parallèle, en permanence, et convertit chaque bit en pixel. Le problème est que, d'une part, tu ne pratiquement plus le faire directement de nos jours à cause du mode protégé et parce que, d'autre part, il y a des centaines de cartes graphiques différentes et des dizaines de mode d'affichage possibles.

Pour faire le lien entre tout ça : faire un appel à « créer une fenêtre » est donc une succession d'étapes pas forcément très compliquées mais qu'il faut respecter : il y a d'un côté la « création logique » de la fenêtre, c'est-à-dire ses attributs, son titre, sa taille, sa position, etc. qui sont conservés par le gestionnaire sur une sorte de carte « d'identité » de la fenêtre, et d'un autre côté le « rendu » proprement dit, à l'écran, de la fenêtre qui n'intervient qu'en dernier lieu. Il se peut même qu'il n'ait pas lieu du tout si ta fenêtre est en mode « réduit » ou si elle se trouve en dehors de l'écran, tout simplement.

Les routines de rendu se trouvent donc dans la bibliothèque de gestion des fenêtres mais font quasiment toujours appel à d'autres routines qui font abstraction du hardware et présentent la mémoire graphique comme uniforme. Ce sont ces routines qui, ensuite, traduisent ce qui a été « dessiné » en quelque chose qui va sortir de la même façon sur la carte graphique que tu utilises.