Pourquoi se borner aux deux seules solutions :
- soit on continue dans la voie actuelle (protocole X bas niveau + toolkits (GTK/QT) gourmands)
- soit on recommence tout à zéro (Fresco/Y)
=> On pourrait très bien imaginer d'étendre le protocole X (de même qu'il existe plein d'autres extensions comme Render, etc...) avec des appels de haut niveau (à la GTK) pour gérer le rendu du toolkit côté serveur ! (et si ça a du succès QT et GTK pourraient en partie être réécrits pour n'être que des "wrappers" autour de cette extension).
Il me semble que ce genre de solution résoudrait le problème sans casser la compatibilité ou tout recommencer à 0 puisque les deux "modes" seraient possibles. (dites moi si je me trompe)
Autre chose tant que j'y suis : je trouve que ça pourrait être pas mal si on séparait aussi (côté serveur) nettement la partie "driver graphique" de la partie "serveur", de manière à avoir une bibliothèque "à la SDL" qui parle directement au hardware sans avoir à se taper des couches intermédiaires (comme X, puisque actuellement il me semble que SDL est au dessus de X et non en dessous, le contraire serait plus logique non ?), ça serait pratique pour les jeux et ça rendrait le serveur X plus modulaire.
(je sais, SDL existe au dessus du framebuffer mais dans ce cas on pert tous les bénéfices des drivers graphiques accélérés de X, idem dans le cas de DirectFB où les drivers sont réécrits en partants de 0).
Bon, je sais, << les "y'a qu'à" et les "faut qu'on" sont les prédateurs de l'homo bénévolus >>, mais vu l'ampleur c'est pas vraiment le genre de truc qu'on peut expérimenter tout seul dans son coin... ;)
[^] # Re: Y.org
Posté par karteum59 (site web personnel) . En réponse à la dépêche XFree86 a de moins en moins la côte. Évalué à 1.
- soit on continue dans la voie actuelle (protocole X bas niveau + toolkits (GTK/QT) gourmands)
- soit on recommence tout à zéro (Fresco/Y)
=> On pourrait très bien imaginer d'étendre le protocole X (de même qu'il existe plein d'autres extensions comme Render, etc...) avec des appels de haut niveau (à la GTK) pour gérer le rendu du toolkit côté serveur ! (et si ça a du succès QT et GTK pourraient en partie être réécrits pour n'être que des "wrappers" autour de cette extension).
Il me semble que ce genre de solution résoudrait le problème sans casser la compatibilité ou tout recommencer à 0 puisque les deux "modes" seraient possibles. (dites moi si je me trompe)
Autre chose tant que j'y suis : je trouve que ça pourrait être pas mal si on séparait aussi (côté serveur) nettement la partie "driver graphique" de la partie "serveur", de manière à avoir une bibliothèque "à la SDL" qui parle directement au hardware sans avoir à se taper des couches intermédiaires (comme X, puisque actuellement il me semble que SDL est au dessus de X et non en dessous, le contraire serait plus logique non ?), ça serait pratique pour les jeux et ça rendrait le serveur X plus modulaire.
(je sais, SDL existe au dessus du framebuffer mais dans ce cas on pert tous les bénéfices des drivers graphiques accélérés de X, idem dans le cas de DirectFB où les drivers sont réécrits en partants de 0).
Bon, je sais, << les "y'a qu'à" et les "faut qu'on" sont les prédateurs de l'homo bénévolus >>, mais vu l'ampleur c'est pas vraiment le genre de truc qu'on peut expérimenter tout seul dans son coin... ;)