E17 ne supportera jamais le fake transparency ?
Hem hem ! http://pinaraf.robertlan.eu.org/opacity.png(...) : capture d'écran d'une appli d'E17, elapse, lancée sur mon KDE (ma session E17 merdouille)
Je peux te faire la même avec erss (leur lecteur de flux RSS), et tant d'autres.
C'est ça la fake transparency ! Ils ne peuvent pas avoir de vraie transparence, point barre. Sauf si ils ne la font que dans la fenêtre d'une appli, en l'occurence le bureau dans ses démos (le bureau est une fenêtre, oui oui... Enfin, utilisable tout comme quoi)
Mais si c'est de la vraie transparence ça, alors ça aussi ça en est ? http://sharewebnom.sourceforge.net/notes/test.html(...) (ne marche que sur un navigateur utilisant Gecko, car il y a du XUL/XBL dedans...)
Et je trouve le comportement de Raster complètement anormal vis à vis de Render : oui render est lent, mais plutôt que de rester dans son coin coder son truc pour lui tout seul pourquoi n'aide-t-il pas à l'amélioration des perfs ? Mais non, c'est mieux de laisser le boulot aux autres voyons (merci à Zack Rusin pour son boulot : http://www.kdedevelopers.org/node/view/978(...) Ça au moins ça aide tout le monde, et pas 5 applis sur toutes celles disponibles !)
Pour Gl : c'est stable chez moi, et chez beaucoup de gens vu le peu de problèmes à ce propos sur les forums... en tout cas, j'ai jamais eu de crash à cause de Gl, mes applis 3D marchent aussi bien en fenêtré qu'en plein écran...
Et pour info, E17 n'est pas encore sorti, l'API non stabilisée, aucune doc claire ne semble disponible. Mais les gens de fd.o devraient se précipiter dessus, l'utiliser, et passer au final plus de temps à utiliser les EFL qu'à utiliser les libs existantes ? Hé, l'affichage vectoriel sera dans gtk 2.8 en utilisant cairo, raster veut quand même pas qu'ils utilisent soudainement son toolkit en cassant toute forme de compatibilité avec les applis existantes, et sans être sûr que ça marchera encore dans 3 mois ? Pensez à mono et wine pour les windows.forms : l'instabilité de l'API de wine a poussé les devs de mono à tout recoder. Ils ont donc perdu du temps à cause de wine...
[^] # Re: linux vers mac os x
Posté par Pinaraf . En réponse au journal Tiger vient de sortir. Évalué à 1.
Hem hem !
http://pinaraf.robertlan.eu.org/opacity.png(...) : capture d'écran d'une appli d'E17, elapse, lancée sur mon KDE (ma session E17 merdouille)
Je peux te faire la même avec erss (leur lecteur de flux RSS), et tant d'autres.
C'est ça la fake transparency ! Ils ne peuvent pas avoir de vraie transparence, point barre. Sauf si ils ne la font que dans la fenêtre d'une appli, en l'occurence le bureau dans ses démos (le bureau est une fenêtre, oui oui... Enfin, utilisable tout comme quoi)
Mais si c'est de la vraie transparence ça, alors ça aussi ça en est ? http://sharewebnom.sourceforge.net/notes/test.html(...) (ne marche que sur un navigateur utilisant Gecko, car il y a du XUL/XBL dedans...)
Et je trouve le comportement de Raster complètement anormal vis à vis de Render : oui render est lent, mais plutôt que de rester dans son coin coder son truc pour lui tout seul pourquoi n'aide-t-il pas à l'amélioration des perfs ? Mais non, c'est mieux de laisser le boulot aux autres voyons (merci à Zack Rusin pour son boulot : http://www.kdedevelopers.org/node/view/978(...) Ça au moins ça aide tout le monde, et pas 5 applis sur toutes celles disponibles !)
Pour Gl : c'est stable chez moi, et chez beaucoup de gens vu le peu de problèmes à ce propos sur les forums... en tout cas, j'ai jamais eu de crash à cause de Gl, mes applis 3D marchent aussi bien en fenêtré qu'en plein écran...
Et pour info, E17 n'est pas encore sorti, l'API non stabilisée, aucune doc claire ne semble disponible. Mais les gens de fd.o devraient se précipiter dessus, l'utiliser, et passer au final plus de temps à utiliser les EFL qu'à utiliser les libs existantes ? Hé, l'affichage vectoriel sera dans gtk 2.8 en utilisant cairo, raster veut quand même pas qu'ils utilisent soudainement son toolkit en cassant toute forme de compatibilité avec les applis existantes, et sans être sûr que ça marchera encore dans 3 mois ? Pensez à mono et wine pour les windows.forms : l'instabilité de l'API de wine a poussé les devs de mono à tout recoder. Ils ont donc perdu du temps à cause de wine...