Moi non plus je ne suis pas un grand technicien mais voila
ce que je pense avoir compris.
E17 ne supportera jamais le fake transparency parce que raster pense que c'est
un horrible hack du aux manques qu'avait Xfree dans le passé.
C'est pour cela que si on lance un terminal transparent sur E17 il ne marchera pas.
Cependant, il est possible de contourner le problème en utilisant Esetroot ou autre.
Elapse utilise le fake transparency via une lib autour de Evas
que Raster ne cautionne mais alors pas du tout :)
En ce qui concerne la vrai transparence, E17 la supporte dans certain cas. Il faut
voir le fond d'écran de e17 comme un immense canevas (heu je suis pas technicien hein !! :) ).
Tout ce qu'affiche E17 __Autour__ des fenetres partage ce canevas.
Ce qui permet la vrai transparence.
Donc, entre les modules(indicateurbatterie,pager), il y de la transparence.
Grace à cela, par exemple, le module particulier qui permet les ombres autour des fenètre "ombre" aussi les autres module modules. Mais il ne peut pas "ombrer" ce qu'il y a à l'intérieur des autres fenètres car ça n'a rien à voir avec
E17. Ca à plutot à voir avec X11.
A propos de X11, voila ce que j'ai compris. Les EFL, ce sont des bibliothèques
graphiques, rien de plus!!! Ca permet d'afficher des images, des rectangles,
du texte, de faire bouger tout cela d'une façon "programer friendly".
Pour afficher tout cela à l'écran, il faut bien utiliser quelque chose. C'est pour cela
que Evas (la lib à la base de tout) dispose de plusieurs Backend :
-Software X11
-Gl X11
-Frame Buffer
-DirectFB
-Et, et, je vous le donne en mille : Cairo !!
Maintenant, il se trouve que Raster et ses amis codent
un WM avec tout cela. Tout de suite, se posent la question de supporter composite.
Composite fonctionne avec Render. Pour que E17 supporte Composite, il suffit
d'ajouter un backend Render et quelques autres chose. Mais Render, c'est
abominablement lent chez la plupart, et ça ne fonctionne bien (et parfois de façon instable)
que sur une minorité de carte. Donc Raster ne s'occupera pas de Render tant
que la situation n'aura pas changé(ou qu'un dieu de la programmation matrise le travail de raster et implémente Render).
Voila ce que j'ai compris :). Les EFL et E17 sont __au dessus__ de tout ce qui
concerne les serveurs graphique, ça les utilise c'est tout !!
Raster c'est rendu compte que le software Render était trop lent, c'est pourquoi
il s'est arrangé pour avoir un backend X11 Software performant.
De ce fait, il ne peut pas faire de vrai transparence mais la façon dont fonctionne E17 permet d'en avoir,un peu.
Ce n'est pas parfait mais ça à le mérite de fonctionner partout d'une façon performante.
Maintenant, il y a le backend GL. Le gros problème de GL(selon Raster) c'est
que c'est très instable. Pour afficher une fenètre en plein écran(jeu) ça va mais
pour le reste, c'est très dur de faire quelque chose de stable pour un WM.
Donc pas de Gl pour E17. Cependant, on peut bidouiller dans le code de E17
pour utiliser GL. Une ligne à changer. Ca passe bien pour le fond d'écran et
ca permet d'avoir un background avec plein d'animation sans trop bouffer
le CPU.
Conclusion :
-Raster veut faire des lib graphique, pas des serveurs graphique
-Il veut que ça soit performant. Alors il fait avec ce qu'il a. Aujourd'hui
Evas X11_soft est ce qui se fait de plus rapide.
-Le projet Enlightenment, c'est 4 ou 5 personnes qui codent __pendant leur temps libre. Donc çe ne va pas à la vitesse de la lumière alors quand on
demande des features encore instables, utilisables sur une minorité de machines,
la réponse est : on n'est pas beaucoup, il nous faut des priorités : stabilité, performance.
J'ai du mal à comprendre toute cette excitation autour de la vrai transparnce
alors qu'il ne s'agit que d'une implémentation d'une feature de X. Elle n'est
pas faite dans E17 et Raster le revendique. Elle est faite par Kwo pour e16,
il le revendique.
Il y a de la vrai transparence entre tous les objets gérés par le WM e17 et Raster le revendique. Point barre.
Il a n'a pas recemment revendiqué le fait qu'il avait fait avec les EFL le travail
qui revient à un serveur graphique! Les EFL Ne peuvent pas faire de la vrai
transparence !! Il peut y avoir de la transparence A l'INTERIEUR d'un appli EFL
donné, mas pas de transparence entre les applis !!! C'est le role du serveur !!!
Il a seulement dit : "eh les gars! vous etes
en train d'imaginer le bureau idéal. C'est pas pour vous déranger mais on fait
déja la majorité de ce que vous imaginez la! Bon ok, on a pas tout (transp, pager en live) parce que Render est très lent pour l'instant mais c'est déja pas mal non ?"
[^] # Re: linux vers mac os x
Posté par lamar . En réponse au journal Tiger vient de sortir. Évalué à 5.
ce que je pense avoir compris.
E17 ne supportera jamais le fake transparency parce que raster pense que c'est
un horrible hack du aux manques qu'avait Xfree dans le passé.
C'est pour cela que si on lance un terminal transparent sur E17 il ne marchera pas.
Cependant, il est possible de contourner le problème en utilisant Esetroot ou autre.
Elapse utilise le fake transparency via une lib autour de Evas
que Raster ne cautionne mais alors pas du tout :)
En ce qui concerne la vrai transparence, E17 la supporte dans certain cas. Il faut
voir le fond d'écran de e17 comme un immense canevas (heu je suis pas technicien hein !! :) ).
Tout ce qu'affiche E17 __Autour__ des fenetres partage ce canevas.
Ce qui permet la vrai transparence.
Donc, entre les modules(indicateurbatterie,pager), il y de la transparence.
Grace à cela, par exemple, le module particulier qui permet les ombres autour des fenètre "ombre" aussi les autres module modules. Mais il ne peut pas "ombrer" ce qu'il y a à l'intérieur des autres fenètres car ça n'a rien à voir avec
E17. Ca à plutot à voir avec X11.
A propos de X11, voila ce que j'ai compris. Les EFL, ce sont des bibliothèques
graphiques, rien de plus!!! Ca permet d'afficher des images, des rectangles,
du texte, de faire bouger tout cela d'une façon "programer friendly".
Pour afficher tout cela à l'écran, il faut bien utiliser quelque chose. C'est pour cela
que Evas (la lib à la base de tout) dispose de plusieurs Backend :
-Software X11
-Gl X11
-Frame Buffer
-DirectFB
-Et, et, je vous le donne en mille : Cairo !!
Maintenant, il se trouve que Raster et ses amis codent
un WM avec tout cela. Tout de suite, se posent la question de supporter composite.
Composite fonctionne avec Render. Pour que E17 supporte Composite, il suffit
d'ajouter un backend Render et quelques autres chose. Mais Render, c'est
abominablement lent chez la plupart, et ça ne fonctionne bien (et parfois de façon instable)
que sur une minorité de carte. Donc Raster ne s'occupera pas de Render tant
que la situation n'aura pas changé(ou qu'un dieu de la programmation matrise le travail de raster et implémente Render).
Voila ce que j'ai compris :). Les EFL et E17 sont __au dessus__ de tout ce qui
concerne les serveurs graphique, ça les utilise c'est tout !!
Raster c'est rendu compte que le software Render était trop lent, c'est pourquoi
il s'est arrangé pour avoir un backend X11 Software performant.
De ce fait, il ne peut pas faire de vrai transparence mais la façon dont fonctionne E17 permet d'en avoir,un peu.
Ce n'est pas parfait mais ça à le mérite de fonctionner partout d'une façon performante.
Maintenant, il y a le backend GL. Le gros problème de GL(selon Raster) c'est
que c'est très instable. Pour afficher une fenètre en plein écran(jeu) ça va mais
pour le reste, c'est très dur de faire quelque chose de stable pour un WM.
Donc pas de Gl pour E17. Cependant, on peut bidouiller dans le code de E17
pour utiliser GL. Une ligne à changer. Ca passe bien pour le fond d'écran et
ca permet d'avoir un background avec plein d'animation sans trop bouffer
le CPU.
Conclusion :
-Raster veut faire des lib graphique, pas des serveurs graphique
-Il veut que ça soit performant. Alors il fait avec ce qu'il a. Aujourd'hui
Evas X11_soft est ce qui se fait de plus rapide.
-Le projet Enlightenment, c'est 4 ou 5 personnes qui codent __pendant leur temps libre. Donc çe ne va pas à la vitesse de la lumière alors quand on
demande des features encore instables, utilisables sur une minorité de machines,
la réponse est : on n'est pas beaucoup, il nous faut des priorités : stabilité, performance.
J'ai du mal à comprendre toute cette excitation autour de la vrai transparnce
alors qu'il ne s'agit que d'une implémentation d'une feature de X. Elle n'est
pas faite dans E17 et Raster le revendique. Elle est faite par Kwo pour e16,
il le revendique.
Il y a de la vrai transparence entre tous les objets gérés par le WM e17 et Raster le revendique. Point barre.
Il a n'a pas recemment revendiqué le fait qu'il avait fait avec les EFL le travail
qui revient à un serveur graphique! Les EFL Ne peuvent pas faire de la vrai
transparence !! Il peut y avoir de la transparence A l'INTERIEUR d'un appli EFL
donné, mas pas de transparence entre les applis !!! C'est le role du serveur !!!
Il a seulement dit : "eh les gars! vous etes
en train d'imaginer le bureau idéal. C'est pas pour vous déranger mais on fait
déja la majorité de ce que vous imaginez la! Bon ok, on a pas tout (transp, pager en live) parce que Render est très lent pour l'instant mais c'est déja pas mal non ?"