les EFL se posent en effet comme une alternative a QT et Gtk+
et ce n'est pas en contradiction avec le fait que e17 ne concourt pas dans la meme arène que Gnome ou KDE
EFL, QT ou Gtk+ : ensemble de bibliothèques gérant en gros les main loop, la partie graphique et des fonctionalités diverses et variées (base de données, toolkits, configuration, etc...)
KDE et Gnome : environement de bureau (dont la partie développement) comprenant entre autre un gestionnaire de fenêtre (kwin pour KDE et metacity pour Gnome, par défaut, il me semble), qui utilisent respectivement QT et Gtk+
E17 : gestionnaire de fenêtre avec gestionnaire de fichier integré utilisant les EFL.
En aucun cas E17 sera un environnement de bureau comme Gnome ou KDE
Concernant les gestionnaire de fenêtres, ton argument se tient avec tous les autres gestionnaire de fenetre qui ont aussi existe (tu peux donc remonter au debut des annees 90 avec twm, fvwm, etc...). raster n'était pas satisfait de ce qui se faisait, donc il a voulu coder son propre gestionnaire de fenêtres. Exactement comme tous les autres développeurs de gestionnaires de fenêtres.
CLFSWM, je ne connais pas, par contre je connais le developpeur d'awesome et donc la conception de ce WM. C'est une gestionnaire de fenêtre classique ayant le tiling comme fonctionnalité très spécifique.
e17 est plus configurable que les autres gestionnaires de fenetres dans certains domaines (genre, e17 peut avoir un fond de bureau animé. Tu pourrais me répondre que ce n'est pas une fonctionalité que tu aimes, possible, mais il *peut* le faire, ou alors gestionnaire de fichier intégré) et aussi je pense moins dans d'autres (pas de tabbing ou de tiling, par exemple).
Au niveau legèreté, sans problème. Rien que pour la partie graphique, en ressource mémoire, e17 (via son plugin illume) tourne sur un Tréo disposant de 32 Mo de mémoire, avec tous les effets grahiques du thème par défaut. Ok, ça ne sera pas rapide mais c'est largement mieux que tout le reste, à qualité d'effets équivalente, et puis le Tréo n'est pas un foudre de guerre. C'est un exemple certes un peu extrême, mais question footprint d'un gestionnaire de fenêtre ayant beaucoup d'effets graphiques, c'est un bon exemple.
Pour les performances, on peut continuer avec un exemple d'une boite qui utilise les EFL sur des set top box (le dev n'a pas voulu que je publie le nom). Qt n'a même pas réussi à compiler (C++...), Gdk était très très lent. Il n'y avait que Evas (la bibliothèque gérant la partie graphique des EFL) qui a pu tourner lentement. Et il y avait (et il y a encore) des optimisations à faire. Maintenant, après avoir optimisé Evas, ses applis tournent à 25 fps sur du 200 MHz et il est très satisfait. La encore c'est un exemple un peu extrême.
Ces 2 exemples montre quand même que les EFL, au niveau footprint et perf, on est loin devant Qt ou Gtk.
La vie n'est pas si rose, néanmoins: manque de développeurs, les bibliothèques sont loins d'être aussi fournies que celles de Gtk+ ou Qt (plus de développeurs et beaucoup travaillant à temps plein sur ces bibliothèques, soutiens financiers important, etc...). Des changements de design, pour des raisons plus ou moins contestables (certains d'entre vous en ont parlé. Oui il y a eu des changements dans la roadmap, mais vous en ignorez les raisons, et ne mettez en avant que les conséquences de ces changements)
Dans le logiciel libre, il y a d'autres arguments à prendre en considération que le pur fait de développer. Les contraintes pécuniaires, par exemple, où raster devait bosser chez VA à faire toute la journée a faire des scripts python pour l'installation de distribution linux à grande échelle, ne lui laissant que très peu de temps pour développer e17. Il faut bien manger. Tous les développeurs qui ne sont pas payés pour bosser sur leur passe-temps favori sont forcément moins productifs que ceux qui sont effectivement payés pour cela.
Alors, voilà, je développe sur ce projet, sur mon temps libre. J'apprécie beaucoup. Les personnes sont sympa, les bibliothèques ont un énorme potentiel (Qt l'a compris: si vous voyez la bibliothèque Qedje de Qt et que vous etes impressionnés par ses performances, c'est qu'elle est basée sur la bibliothèque Edje des EFL. Les mecs de QT ont aussi changé leur fusil d'épaule pour leur toolkit : plutôt qu'une fenêtre X pour chaque widget dans une fenêtre, ils ont adopté le schéma d'Evas (une autre EFL, comme mentionné ci-dessus), cad un canevas gérant les widget pour une seul fenêtre), ce qui a supprimé le tearing lors d'un redimensionnement des fenêtres.
C'est mon point de vue et j'ai essayé de faire un peu de publicité à ce projet via ce site (que sont les dépêches, sinon de la publicité ?)
[^] # Re: Ayé, c'est au point?
Posté par Anonyme . En réponse à la dépêche Enlightenment - Google Summer of Code. Évalué à 10.
et ce n'est pas en contradiction avec le fait que e17 ne concourt pas dans la meme arène que Gnome ou KDE
EFL, QT ou Gtk+ : ensemble de bibliothèques gérant en gros les main loop, la partie graphique et des fonctionalités diverses et variées (base de données, toolkits, configuration, etc...)
KDE et Gnome : environement de bureau (dont la partie développement) comprenant entre autre un gestionnaire de fenêtre (kwin pour KDE et metacity pour Gnome, par défaut, il me semble), qui utilisent respectivement QT et Gtk+
E17 : gestionnaire de fenêtre avec gestionnaire de fichier integré utilisant les EFL.
En aucun cas E17 sera un environnement de bureau comme Gnome ou KDE
Concernant les gestionnaire de fenêtres, ton argument se tient avec tous les autres gestionnaire de fenetre qui ont aussi existe (tu peux donc remonter au debut des annees 90 avec twm, fvwm, etc...). raster n'était pas satisfait de ce qui se faisait, donc il a voulu coder son propre gestionnaire de fenêtres. Exactement comme tous les autres développeurs de gestionnaires de fenêtres.
CLFSWM, je ne connais pas, par contre je connais le developpeur d'awesome et donc la conception de ce WM. C'est une gestionnaire de fenêtre classique ayant le tiling comme fonctionnalité très spécifique.
e17 est plus configurable que les autres gestionnaires de fenetres dans certains domaines (genre, e17 peut avoir un fond de bureau animé. Tu pourrais me répondre que ce n'est pas une fonctionalité que tu aimes, possible, mais il *peut* le faire, ou alors gestionnaire de fichier intégré) et aussi je pense moins dans d'autres (pas de tabbing ou de tiling, par exemple).
Au niveau legèreté, sans problème. Rien que pour la partie graphique, en ressource mémoire, e17 (via son plugin illume) tourne sur un Tréo disposant de 32 Mo de mémoire, avec tous les effets grahiques du thème par défaut. Ok, ça ne sera pas rapide mais c'est largement mieux que tout le reste, à qualité d'effets équivalente, et puis le Tréo n'est pas un foudre de guerre. C'est un exemple certes un peu extrême, mais question footprint d'un gestionnaire de fenêtre ayant beaucoup d'effets graphiques, c'est un bon exemple.
Pour les performances, on peut continuer avec un exemple d'une boite qui utilise les EFL sur des set top box (le dev n'a pas voulu que je publie le nom). Qt n'a même pas réussi à compiler (C++...), Gdk était très très lent. Il n'y avait que Evas (la bibliothèque gérant la partie graphique des EFL) qui a pu tourner lentement. Et il y avait (et il y a encore) des optimisations à faire. Maintenant, après avoir optimisé Evas, ses applis tournent à 25 fps sur du 200 MHz et il est très satisfait. La encore c'est un exemple un peu extrême.
Ces 2 exemples montre quand même que les EFL, au niveau footprint et perf, on est loin devant Qt ou Gtk.
La vie n'est pas si rose, néanmoins: manque de développeurs, les bibliothèques sont loins d'être aussi fournies que celles de Gtk+ ou Qt (plus de développeurs et beaucoup travaillant à temps plein sur ces bibliothèques, soutiens financiers important, etc...). Des changements de design, pour des raisons plus ou moins contestables (certains d'entre vous en ont parlé. Oui il y a eu des changements dans la roadmap, mais vous en ignorez les raisons, et ne mettez en avant que les conséquences de ces changements)
Dans le logiciel libre, il y a d'autres arguments à prendre en considération que le pur fait de développer. Les contraintes pécuniaires, par exemple, où raster devait bosser chez VA à faire toute la journée a faire des scripts python pour l'installation de distribution linux à grande échelle, ne lui laissant que très peu de temps pour développer e17. Il faut bien manger. Tous les développeurs qui ne sont pas payés pour bosser sur leur passe-temps favori sont forcément moins productifs que ceux qui sont effectivement payés pour cela.
Alors, voilà, je développe sur ce projet, sur mon temps libre. J'apprécie beaucoup. Les personnes sont sympa, les bibliothèques ont un énorme potentiel (Qt l'a compris: si vous voyez la bibliothèque Qedje de Qt et que vous etes impressionnés par ses performances, c'est qu'elle est basée sur la bibliothèque Edje des EFL. Les mecs de QT ont aussi changé leur fusil d'épaule pour leur toolkit : plutôt qu'une fenêtre X pour chaque widget dans une fenêtre, ils ont adopté le schéma d'Evas (une autre EFL, comme mentionné ci-dessus), cad un canevas gérant les widget pour une seul fenêtre), ce qui a supprimé le tearing lors d'un redimensionnement des fenêtres.
C'est mon point de vue et j'ai essayé de faire un peu de publicité à ce projet via ce site (que sont les dépêches, sinon de la publicité ?)