Enlightenment - Google Summer of Code

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
16
25
mar.
2009
Serveurs d’affichage
Enlightenment est un gestionnaire de fenêtres extrêmement configurable et peu gourmand en ressources. Il est basé sur un ensemble de bibliothèques nommées EFL (Enlightenment Foundation Libraries), qui elles-mêmes peuvent être utilisées à part pour créer tout type d'applications.

Pour la deuxième année consécutive, le projet Enlightenment est accepté au Google Summer of Code, permettant à des étudiants de travailler (travail rémunéré par Google) sur Enlightenment et les EFL durant l'été, avec certains de ses développeurs (quelques uns étant même français) Enlightenment est un gestionnaire de fenêtres extrêmement configurable et peu gourmand en ressources malgré les effets graphiques proposés. Ceci est certainement l'aspect le plus connu du projet Enlightenment dans sa version 17. Son développement a été très lent pour plusieurs raisons: peu de développeurs, et la création d'un ensemble de bibliothèques nommées EFL (Enlightenment Foundation Libraries), qui prirent énormément de temps, sur lesquelles se base Enlightenment, et qui elles-mêmes peuvent être utilisées à part pour créer tout type d'applications.

Les EFL sont écrites dans le langage C et ont été conçues pour être très performantes, en termes de rapidité et de gestion de ressources. Ceci permet de répondre aux deux objectifs principaux de Enlightenment: la performance et la capacité de faire fonctionner le projet sur tous type de matériels (même les plus faibles en capacité, comme le Tréo). Les bibliothèques ont ainsi été portées sur Windows (XP et CE) et Mac OS X ainsi que sur des appareils mobiles tels que des téléphones (utilisant OpenMoko, par exemple) ou encore dans le domaine de la domotique. Elles peuvent utiliser des systèmes graphiques tels que Xlib, XCB, OpenGL, Xrender, GDI, DirectDraw, Direct3D, Quartz, SDL, DirectFB ou le FrameBuffer entre autres. En particulier, un grand travail a été fait du côté des interfaces graphiques afin qu'elles soient adaptées à une utilisation tactile sans stylet.

Quelques distributions utilisent Enlightenment exclusivement, comme Elive (distribution et Live CD) ou OpenGEU.

À ce jour les bibliothèques ainsi que le gestionnaire de fenêtres sont dans un état avancé, proche d'une première release qui arrivera au cours de l'année (voir cette page web pour l'avancement). Ceci n'empêche pas de trouver énormément de points à améliorer ou à ajouter dans les bibliothèques pour les releases futures (ajout du streaming dans les thèmes (pour les vidéos), utilisation de Lua comme langage de script, etc...).

Le point faible de Enlightenment reste à ce jour le manque d'applications permettant d'obtenir un environnement complètement en EFL (éditeur de texte, messagerie, gestionnaire d'emails ...), mais ceci a également l'avantage de permettre à tout le monde de contribuer quelque soit son niveau (code, interfaces graphiques, ...).

L'avancement des bibliothèques a permis aux EFL d'entrer dans le monde « professionnel » avec le soutien d'entreprises telles que Calaos dans le secteur de la domotique, Samsung, Indt (filière brésilienne de Nokia) dans le domaine de la téléphonie mobile, Profusion pour les set top box, ainsi que d'autres compagnies.

Pour la deuxième année consécutive, le projet est accepté au Google Summer of Code, qui est, en paraphrasant la nouvelle de "SIP Communicator", "un événement organisé chaque été par Google, qui se propose de rétribuer des étudiants de tous les pays pour leur travail sur un projet libre durant leurs vacances d'été".

Donc, si des étudiants sont intéressés dans le développement et dans ce projet (Enlightenment et les EFL), ils peuvent regarder les idées proposées ou en proposer de nouvelles et nous contacter. L'inscription au Summer of Code prend fin le 3 avril 2009.

Aller plus loin

  • # Nombre de Journaux

    Posté par  . Évalué à 1.

    Vu le nombre de projets inscrits au GSOC ( http://socghop.appspot.com/program/accepted_orgs/google/gsoc(...) ) il va falloir changer les serveurs :)
    ( http://linuxfr.org/2009/03/23/25208.html )

    Au fait saviez vous que KDE se présentait aussi ?
    Ah et saviez vous que OpenSsh aussi ?
    Ah ...

    Non sérieusement ...

    • [^] # Re: Nombre de Journaux

      Posté par  (site web personnel) . Évalué à 10.

      Il faudrait plutôt parler des projets qui n'ont pas été acceptés ! Exemple : Hurd, roooh (alors que MINIX3 a été accepté, il y a du favoritisme !).

      Sinon, je trouve qu'il y a énormément de communication AVANT (le recrutement des étudiants), par contre, très peu sur les retombées réelles des GSoC. Est-ce que tous les projets ont donné du code ? Est-ce que le code a été intégré upstream ? Est-ce que les étudiants sont restés attachés au projet ? etc. Bon, j'ai peut-être loupé un super compte rendu des années précédentes ?

      • [^] # Re: Nombre de Journaux

        Posté par  (site web personnel) . Évalué à 8.

        Concernant le résultats des GSoC, ça dépend beaucoup des projets je pense. Je peux te répondre pour NetBSD (j'ai pas vérifié les chiffres exactes). Globalement, 1 GSoC sur 2 ne commence pas vraiment (soit que l'étudiant ne joue pas le jeu, soit qu'il a des vrais problèmes (ça arrive), soit au final il a vraiment pas le background technique). Dans les projets restants, je dirai que la moitié arrive à terme, et les autres sont souvent laissés dans un état mi-terminé (et en général oublié). Les gens menant leur projet à terme, on leur propose en général d'intégrer l'équipe pour l'intégrer à NetBSD, à défault il est intégré par un développeur actuel).

        Conclusion : ça amène un peu de sang frais (pas énormement non plus, vu que certains SoC sont fait par des étudiants déjà dans l'équipe de développement), disons 1 ou 2 personnes, mais y'a pas mal de pertes.

        A noter que les procédures de sélections sont maintenant beaucoup plus restrictives. Les premières années, c'était assez cool au niveau préparation pré-SoC, maintenant, on essaye de sélectionner des "dossiers sérieux", cad qui ont une chance d'aboutir (même si ce n'est pas une science exacte).

        NetBSD reste un projet avec des SoC plutôt très technique aussi, certains projets proposent des SoC plus "simple" (ça reste une impression), ça ne se généralise peut-être pas facilement (certains SoC de FreeBSD sont très dur, tandis que d'autres semblent assez faciles, mais je pense qu'ils ont a peu prêt autant de déchets que nous)).

        • [^] # Re: Nombre de Journaux

          Posté par  (site web personnel) . Évalué à 3.

          Pour KDE c'est à peu près pareil.
          Assez peu de nouvel étudiants restent, mais tout de même certains.

          À noter aussi que grâce aux 500$ par étudiant donnés à l'organisation, Google est le plus gros sponsor financier de KDE.

        • [^] # Re: Nombre de Journaux

          Posté par  . Évalué à 4.

          Un example intérressant est celui de MusicBrainz avec un des étudiants employé à temps partiel à la suite de son summer of code. Je crois qu'il n'avait pas encore fini et que ce n'est pas encore visible mais tout son travail représente une grande partie de la prochaine version. (je ne suis pas sur que tous les autres aient été intégré mais MB n'est pas forcément un gros projet (coté code, car coté données c'est autre chose) avec beaucoup de développeurs.
          Cf http://blog.musicbrainz.org/?p=346 pour l'annonce de son embauche...

    • [^] # Re: Nombre de Journaux

      Posté par  . Évalué à 9.

      Sauf que e17 a grandement besoin de devellopeur contrairement a des projets comme KDE. On a bien déjà eu des dépêches sur des projets qsui ne faisait que demander des contributeurs ...
      On en profite également pour expliquer un peu ce qu'est réellement e17, pour beaucoup c'est juste un wm, mais le wm n'est qu'une partie dans ce qu'on appelle aujourd'hui E17.
      Et on annonce l'arrivé prochaine d'une release, ce qui n'est pas rien pour ce projet quand même :D

      • [^] # Re: Nombre de Journaux

        Posté par  . Évalué à 0.

        "Et on annonce l'arrivé prochaine d'une release, ce qui n'est pas rien pour ce projet quand même"

        Ah ah ah, ca fait juste 6 ans qu'on lis ca non ? Release utilisée par qui ? Quelles applications utilisent les EFL ? Pour moi E est une grosse perte d'energie qui par son mode de developpement est complétement passé a coté du succés qu'il aurait pu avoir il y a 10 ans. Pour situer la chose, E17 est en dev depuis 9 ans !!! Pourquoi ? Parce que son créateur a tendance après quelques années de dev de se dire que le design utilisé pourrait etre mieux et qu'il vaut mieux faire une grosse réécriture de l'ensemble de libs ! Ces délais ont fait que E a loupé le coche pour le desktop linux mais également dans l'embarqué.

        Alors désolé, moi je suis plus pour affecter des dev a KDE ou on voit un vrai efforts et des objectifs pour faire un desktop utilisable que dans E.

        • [^] # Re: Nombre de Journaux

          Posté par  . Évalué à 5.

          Un exemple d'utilisation des EFL: http://calaos.fr/joomla/index.php?option=com_content&tas(...)

          Pour la roadmap de e17 qui finira sur la release: http://trac.enlightenment.org/e/wiki/Release

        • [^] # Re: Nombre de Journaux

          Posté par  (site web personnel) . Évalué à 10.

          Alors désolé, moi je suis plus pour affecter des dev a KDE ou on voit un vrai efforts et des objectifs pour faire un desktop utilisable que dans E.
          Puis je me permettre de rappeler une chose, il s'agit de LL, pas d'une entreprise affectant des ressources à tel ou tel projet, donc les devs pour ceux qui ne sont pas payés pour pour, c-a-d un très grosse partie, s'autoaffecte et ne t'attende pas toi pour être affecté à tel ou tel projet.

          Nan mais quel arrogance, de te positionner à la place des devs. c'est quand même hallucinant de plus en plus de gens sont là "mais c'est quoi ton projet de merde, il faudrait affecter toutes les ressources ici ou là etc".
          Avoir ton existance sur le pourquoi un projet marche ou pas et la faire partager oui, mais savoir mieux qu'un dev (libre de ses choix et de ses projets) ce qu'il doit faire et sur quoi il devrait bosser n'importe quoi.

        • [^] # Re: Nombre de Journaux

          Posté par  (Mastodon) . Évalué à 4.

          Ah ah ah, ca fait juste 6 ans qu'on lis ca non ? Release utilisée par qui ?

          Alors désolé, moi je suis plus pour affecter des dev a KDE ou on voit un vrai efforts et des objectifs pour faire un desktop utilisable que dans E.

          C'est pas la peine d'essayer de cacher ton ignorance et on étroitesse d'esprit par de l'arrogance.

          -pas besoin de release officielle pour utiliser enlightenment DR17
          -les version de dev sont utilisé par de nombreuses personnes et suffisemment fiable (je l'utilise par exemple au bureau, alors que le moindre bug ou crash me feraient vraiment chier dans ce contexte)
          -kde 4.0 et 4.1 ont beau avoir de jolis numéro de release, ce sont des bouses infâmes et instables comparés à une version de developpement de E17. KDE 4.0 est totalement impropre à l'utilisation.

          bref numéro de versions, releases officielle, toussa >/dev/null. ça ne sert à rien.

          • [^] # Re: Nombre de Journaux

            Posté par  . Évalué à 8.

            Pour moi l'arrogance c'est la maniere dont E est géré. Malgré les commentaires ci-dessus la verité est bien que la release est promise depuis des années. Je sais bien que E17 est stable à l'utilisation, la n'est pas le probleme, les APIs sont restées stables depuis qu'on nous promet la release ? Est-ce que quelqu'un qui a choisit les EFL vers 2005 parce que "la release va bientot arriver" (donc les APIs resteront stabilisées) est heureux d'avoir fais ce choix ?

            Chaque developpeur fais ce qu'il veut, aucun problème, le GSoC choisit arbitrairement de financer tels ou tels projets, j'ai aussi le droit de donner mon avis non ?

            • [^] # Re: Nombre de Journaux

              Posté par  . Évalué à 4.

              Depuis 2006, date a laquelle j'ai rejoind le projet, je n'ai jamais entendu parle de release, et encore moins de planning de release, sauf depuis environ 6 mois. En cherchant un peu dans google, je n'ai rien trouve qui parle d'une release avant 2006. Juste un article de 2005 sur le sujet ( http://www.linux.com/feature/44018 ), et il est clair en le lisant qu'aucune release n'etait prevu dans les mois/annees a venir.

            • [^] # Re: Nombre de Journaux

              Posté par  (Mastodon) . Évalué à -3.

              qui a besoin d'une release pour l'utiliser ? personne. Alors pourquoi faire ?

              • [^] # Re: Nombre de Journaux

                Posté par  . Évalué à 5.

                Les entreprises qui veulent utiliser des librairies dont l'API est fixe, peut-être ?

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Nombre de Journaux

                  Posté par  . Évalué à 3.

                  bof, dans l'entreprise ou je travail on a fixé les sources que l'on utilise, ca revient au même qu'une release. Ce n'est pas parce qu'une release est faite que les API ne vont plus changer (après faut pas tout changer non plus, mais depuis 2 ans que je suis sur e et les API n'ont pas tant changer que ca à part le passage a eina).

          • [^] # Re: Nombre de Journaux

            Posté par  . Évalué à 2.

            "C'est pas la peine d'essayer de cacher ton ignorance et on étroitesse d'esprit par de l'arrogance."

            Moi au moins je n'ai insulte personne dans mes posts.

          • [^] # Re: Nombre de Journaux

            Posté par  . Évalué à 4.

            Bonjour,

            J'ai eu une expérience assez malheureuse d'e17 avec la version intégrée à YellowDogLinux 6 : e17 plantait assez fréquemment dès que je configurais quelquechose ou ajoutais une applet.

            Existe-t-il un liveCD/distribution/dépot Debian particulièrement recommandable pour découvrir e17 ?

            BeOS le faisait il y a 20 ans !

            • [^] # Re: Nombre de Journaux

              Posté par  . Évalué à 4.

              Des paquets pour Lenny et Sid : http://sidux.com/PNphpBB2-viewtopic-t-14545.html
              Des distributions toutes prêtes (c'est dans la dépêche) :
              - OpenGEU http://opengeu.intilinux.com/Home.html
              - Elive http://www.elivecd.org/

              Amuse-toi bien :)

        • [^] # Re: Nombre de Journaux

          Posté par  . Évalué à 5.

          Ben justement, dans l'embarqué, E est déjà utilisé.
          Une (très) rapide recherche me donne ces liens[1][2].
          Le premier concerne l'OpenMoko, et le deuxième une tablette pour de la domotique


          1 http://mobileblog.canalblog.com/archives/2007/12/08/7168086.(...)
          2 http://calaos.fr/joomla/index.php?option=com_content&tas(...)

          • [^] # Re: Nombre de Journaux

            Posté par  . Évalué à 4.

            Personnellement sur le Neo freerunner je le trouve pas super utilisable/beau/réactif ... Au point que j'ai commencer à réécrire mon propre gestionnaire en Qt4 ...
            Bref les reproches qui sont fait à un kde4.0, 4.1 avec Qt4.4 sur un n810 moi je les fais pour e17 sur le freerunner ...

            Sinon, il y a aussi une énorme différence entre un kde 4.0 avec Qt4.4 et kde 4.2 / svn avec Qt 4.5 ...

            • [^] # Re: Nombre de Journaux

              Posté par  . Évalué à 0.

              oauis enfin le freerunner a des pbs au niveau du matériel en ce qui concerne l'affichage. Tu aura les même problemes en QT.

              • [^] # Re: Nombre de Journaux

                Posté par  . Évalué à 2.

                Heu j'ai écrit des applications en Qt sur le freerunner et je n'ai aucun problème d'affichage tant qu'on n'utilise pas la transparence à outrance ou le scrolling ça passe sans problème.
                Son problème est que le driver graphique est tout pourri et que le processeur n'a pas, je crois, d'unité de calcul en virgule flottante donc faut faire avec ...

                • [^] # Re: Nombre de Journaux

                  Posté par  . Évalué à 1.

                  bah voila, ton interface en QT est simple, statique alors que illumine y a quelques trucs en plus quand même. Disons que illumine n'est pas adapté a openmoko si tu veut, mais honnetement openmoko n'est pasa dapté a grande chose pour le moment.

                  • [^] # Re: Nombre de Journaux

                    Posté par  . Évalué à 2.

                    D'abord c'est illume, pas illumine. Ensuite ça n'est que le gestionnaire de fenêtres, et ça ne présage en rien des toolkits des applications utilisées dessus. Par exemple, la fameuse ASU faisait tourner une suite d'applications téléphonesques en Qt(Core) avec Illume comme WM.

                • [^] # Re: Nombre de Journaux

                  Posté par  . Évalué à 3.

                  Si c'etait juste ca. Tu pouvais editer le fichier de theme et faire une version sans animation, transparence, scrolling. Si tu as un lien sur une video de ton wm sur l'openmoko, j'aimerais bien voir parcontre.

    • [^] # Re: Nombre de Journaux

      Posté par  (site web personnel) . Évalué à 5.

      Je suis bien d'accord.
      Tous les projet qui participent au summer of code méritent autant de publicité.

      Je pense qu'il aurais fallut faire une dépêche globale pour le Google Summer of Code.

      • [^] # Re: Nombre de Journaux

        Posté par  (site web personnel) . Évalué à 4.

        Je pense qu'il aurais fallut faire une dépêche globale pour le Google Summer of Code.

        ah, cool ;-) elle est prête ? tu la soumets quand ? ;-)
        Si tu passes sur le salon Solutions GNU/Linux, il y aura peut-être un atelier rédaction de dépêches, n'hésite pas à venir faire un tour.
        Ou si tu veux la rédiger à plusieurs, il y a http://demoll.tuxfamily.org/linuxfr/NewsLinuxFr qui est disponible pour s'y mettre.

        Les rédacteurs ce sont avant tout les participants au site, ça peut évoluer et y avoir une équipe de rédaction, ça va sans doute viendre, mais pour l'instant c'est encore comme ça :D
        En l'état, les deux dépêches étaient acceptables et ont - à raison - été acceptées, libre à tout un chacun de soumettre une sélection des projets du GSoc avec arguments factuels et pas trop de trolls et elle sera sans doute acceptée.

        • [^] # Re: Nombre de Journaux

          Posté par  (site web personnel) . Évalué à 2.

          Je m'attendais à cette réponse. (j'aivais originelement mis une note dans mon commentaire mais je l'avais enlevé)

          Non, je ne ferais pas de dépêche (et puis Solution Linux c'est trop loin et pas intéressant)

          Je sais que les rédacteurs sont les participants du site et je les en remercie, eux, les relecteurs, les modérateurs, et tout ceux qui font que le site fonctionne.
          (mais pas pour cette dépêche précise :-))

          • [^] # Re: Nombre de Journaux

            Posté par  (site web personnel) . Évalué à 1.

            (mais pas pour cette dépêche précise :-))

            t'inquiète, comme ton ulcère nous intéresse, il y en a une nouvelle dans les tuyaux :p

  • # Ayé, c'est au point?

    Posté par  . Évalué à 3.

    La dernière fois que j'ai testé Enlightenment, c'était:
    - E16 trop vieux,
    - E17 trop buggé.

    Enlightenment est un bon symbole du logiciel libre: plein de bonnes idées, d'excellentes idées, mais un développement trop "fougueux" pour pouvoir dire "Ayé, y'a une version utilisable."

    Même sans être un débutant total, je trouve que les bugs du genre "La touche du clavier X ne répond plus quand on charge le plugin Y" ça le fait moyen.
    Dommage, parce qu'E17 est vraiment sympa.

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Ayé, c'est au point?

      Posté par  (site web personnel) . Évalué à -1.

      C'est bizarre c'est ce que je me suis dit de KDE, il y a 6 mois... Comme quoi les choses avancent avec de la patience.

      • [^] # Re: Ayé, c'est au point?

        Posté par  . Évalué à -2.

        Kde c'est quand même le projet qui est (a était) en béta pendant 1 avec des versions dites stables >.<

        • [^] # Re: Ayé, c'est au point?

          Posté par  . Évalué à 2.

          Tu peux faire un effort sur l'orthographe et la grammaire, ou bien tu postes tellement vite qu'elles sont court-circuitées? Parce que là, ça pique les yeux.

        • [^] # Re: Ayé, c'est au point?

          Posté par  . Évalué à 1.

          en même temps, Enlightenment est en bêta depuis... ? On en est à peine à la version 0.17, et encore, la 0.16 est plus stable !

          :-)

    • [^] # Re: Ayé, c'est au point?

      Posté par  . Évalué à 6.

      ça doit faire un sacré bout de temps que tu ne l'as pas essayé

      sans vouloir faire dans le trollesque de bas niveau, je tourne avec depuis au moins trois ans, si ce n'est plus
      je l'ai gardé car il est configurable comme je l'entends, et j'ai beau avoir cherché chez les (gros) autres, je n'ai pas trouvé mieux ailleurs
      évidemment il n'est pas parfait, évidemment il lui arrive de planter, c'est notre lot commun à tous je pense, mais il est, à mon avis, de ces logiciels qui donnent envie de passer aux logiciels libres, beau, léger, configurable et maniable à souhait

      tu devrais retenter l'aventure, la compilation est rapide avec une machine moderne < de 3 ans
      et le jeu peut en valoir la chandelle

      • [^] # Re: Ayé, c'est au point?

        Posté par  . Évalué à 6.

        J'en profite pour poster ici quelques liens indispensables :
        Pour compiler, installer ou/et mettre à jour E17, un script vraiment facile à utiliser, même pour un ignare comme moi :
        http://omicron.homeip.net/projects/?style_changed=Underwater(...)

        Pour suivre le projet en temps réel :
        http://trac.enlightenment.org/e/browser/trunk?order=date&(...)
        http://sourceforge.net/mailarchive/forum.php?forum_name=enli(...)

        Pour info :
        - sur ma machine, E17 consomme 16 M en mémoire.
        - depuis 3 ans, je me sers de E17 pour travailler, 2 sessions X ouvertes en même temps.
        - jusqu'à présent, question rapidité, aucun équivalent de E17.

        "L'art est fait pour troubler. La science rassure" (Braque)

        • [^] # Re: Ayé, c'est au point?

          Posté par  (site web personnel) . Évalué à 6.

          Moi je me demandes, 16Mo, ok c'est cool. Mais d'un autre coté, si dès que je lance une appli, je suis obligé de charger d'autres libs (gtk/qt), qu'est ce que j'y gagne ?

          Tu as quoi comme applis ouvertes avec 16Mo ?

          • [^] # Re: Ayé, c'est au point?

            Posté par  . Évalué à -3.

            "Tu as quoi comme applis ouvertes avec 16Mo ?"

            J'ai bien écrit "E17 consomme 16 M en mémoire"
            Les 16 M concernent donc uniquement E17.
            La faible utilisation mémoire n'est pas le point le plus intéressant.

            "qu'est ce que j'y gagne"
            Tu gagnes la rapidité, surtout quant tu as pas mal d'applis lancées en même temps.
            C'est le plus intéressant, selon moi.

            "L'art est fait pour troubler. La science rassure" (Braque)

            • [^] # Re: Ayé, c'est au point?

              Posté par  (site web personnel) . Évalué à 9.

              Hum je sais pas, je peux aussi utiliser fluxbox pour ça qui est également très paramétrable et léger.

              C'est vrai que y a pas de super effets de la morts dès que tu passes au dessus de la moindre ligne du menu, mais comme je supporte déjà pas d'avoir un curseur clignotant, je crois pas que ce soit pour moi.

              Donc bon, E17 consomme pas grand chose, mais il fourni pas grand chose non plus. Si demain les EFL sont utilisés pour un bureau complet de l'acabit de gnome/kde+bureautique, le tout dans moins de 32Mo, je l'adopte direct.

              Je peux me tromper, mais pour l'instant E17 c'est juste un gestionnaire de fenêtre dont la majeur différence semble être l'esthétisme.

              En dehors des effets, quels sont ces différences par rapport à fluxbox par exemple ?

              • [^] # Re: Ayé, c'est au point?

                Posté par  . Évalué à -1.

                Rien à voir avec fluxbox.
                E17 est un environnement de bureau complet.

                "L'art est fait pour troubler. La science rassure" (Braque)

                • [^] # Re: Ayé, c'est au point?

                  Posté par  (site web personnel) . Évalué à 9.

                  Tu es sûr ? Bon je me suis trompé alors.

                  Mais est-ce qu'il y a un client mail utilisant EFL ?
                  Il y a un client de messagerie utilisant EFL ?
                  Il y a une suite bureautique utilisant EFL ?
                  Il y a un gestionnaire de fichier (genre nautilus/konquereror) ?

                  Il me semble qu'il y a un «eterm» au moins.

                  En gros ma question c'est qu'est ce que E17 fournie d'autre qu'un gestionnaire de fenêtre ?

                  • [^] # Re: Ayé, c'est au point?

                    Posté par  . Évalué à 1.

                    Comme dit dans la news, ca manque vraiment d'application mais c'est parce que ca manque de devs. Les outils pour créer des applis sont là.

                    • [^] # Re: Ayé, c'est au point?

                      Posté par  (site web personnel) . Évalué à 5.

                      Donc si je comprends bien, les EFLs se posent comme alternative a Qt/GTK ? Pourtant sur le site on peu lire sur E17 : «It will not compete with GNOME or KDE, but be a completely new way of visualizing your desktop, based around the EFL which was built from the ground up for this task».

                      J'ai du mal à voir ce que ça à de complètement nouveau. Autant des projets comme CLFSWM[1] ou awesome[2] sortent vraiment de ce qui fait ailleurs autant E17 m'a l'air d'être un gestionnaire de fenêtre tout à fait classique.

                      Maintenant la question que je me pose est si refaire un environnement de bureau complet avec les EFL produira quelque chose de vraiment plus léger et donc que ça présente un plus réel en terme de performances/empreinte mémoire ou si au final ce serait juste une usine à gaz de plus.

                      [1] https://linuxfr.org/2008/09/25/24529.html
                      [2] https://linuxfr.org/2008/09/19/24506.html

                      • [^] # Re: Ayé, c'est au point?

                        Posté par  . Évalué à 1.

                        E17 une approche très différente de gnome et KDE (et GTK et QT). Par exemple les bibliothèques sont les même pour les applications PC et mobile (notamment par ex le toolkits de widgets).

                        E17 s'est formé autour du design, ainsi Edje a était créé et tout l'affichage repose sur cette bibliotheque. Regarde par exemple les vidéos de Calaos (d'autres ici: http://watchwolf.fr/public/Calaos/). Essaye de faire ca sur une machine de 64mo de ram et avec un proc qui ne chauffe pas (ventilo éteint les 3/4 du temps). Le tout entièrement personnalisable par le designer: il peut se contenter de remplacer les images mais peut également réécrire toute l'interface et par exemple changer la position d'une liste ou d'un bouton, ajouter des animations ...


                        Comme dit dans la news E17 ce n'est pas juste un Wm ou un toolkits de widgets, c'est vraiment penser différemment de GTK et QT.

                        Après oui E17 ce veut etre un gestionnaire de bureau complet, mais comme deja dit ca manque de dev, aujourd'hui il y a des devs qui sont sur 3 projets en même temps alors forcement cela conduit a l'abandon/non amélioration de certaines applications ou libs.

                        • [^] # Re: Ayé, c'est au point?

                          Posté par  (site web personnel) . Évalué à 2.

                          Ok donc c'est très jolie, très configurable et ça mange pas trop de ressources.

                          Je me demande donc où est le problème avec ELF. Est-ce la minutie apporté à la conception qui rendent les contributions difficiles ?

                          En gros qu'elles sont les facteurs bloquant aux contributions si cette boite à outil explose vraiment la concurrence à tous points de vue ?

                          • [^] # Re: Ayé, c'est au point?

                            Posté par  . Évalué à 5.

                            Le reproche le plus important qu'on puisse faire, c'est le manque de release. Disons que en soit Enlightenment ce doit d'etre impeccable lors de sa sortie, ce qui a fait durer toute release intermediaire. Et pourtant les snapshot/tarball sont surement du meme niveau de finition que les releases de certains autres toolkit.

                            Le deuxieme point, la license. Elle etait exclusivement BSD jusqu'a recemment, et pour un certain nombre de societe ca pose probleme de contribuer. Ce fut un troll de longue dure entre QT/GPL et GTK/LGPL. La licence LGPL ayant favorise le support par de nombreux contributeurs industriel de GTK (Toolkit de choix de l'embarque pour cette raison). Quand a QT, c'est une lib bien propre avec un bon support commercial, et donc une quantite de dev impressionnante derriere.

                            Enfin, la majorite des dev jusqu'a maintenant, ne s'est absolument pas soucie de faire de la pub ou de communique sur les avancements du projet. Compare a KDE ou GNOME qui ont vraiment bien encre une communication importante dans leurs devs. Les EFL a cote, ca se limite au log svn... a la limite irc.

                            Et bien entendu de maniere mecanique ca manque de doc. Meme si il suffit de se pointer sur irc ou d'envoyer un mail sur la ml pour avoir sa reponse, ca n'est clairement pas ca.

                            En fait pour faire simple, la mentalite des devs joue beaucoup, mais cela evolue petit a petit.

                      • [^] # Re: Ayé, c'est au point?

                        Posté par  . Évalué à 10.

                        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  . Évalué à 0.

                          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

                          C'est rigolo mais il y a 10 ans de cela wmaker + mplayer me permettait de mettre en fond de bureau un film. D'ailleurs je crois pas que cela fonctionne encore cela enfin bon il y a 10 ans il été possible d'avoir un fond animé. Mais bon cela est aussi possible avec screenlet (donc compiz) et un des ses plugins.

                          Personnellement je n'ai rien contre e17, j'ai essayé plusieurs fois, pour avoir un bureau qui soit un peu plus joli et qui bouffe pas trop de mémoire et bon cela crashait beaucoup trop pour être utilisable et comme dit plus haut cela fait trop longtemps que l'on nous bassine avec. Un peu comme hurd ou duke nukem cela fait sourire.

                          • [^] # Re: Ayé, c'est au point?

                            Posté par  . Évalué à 2.

                            beaucoup de personnes utilise e17 depuis des années, même dans des entreprise on en voit, alors dire que ca crash trop ...

                            En ce qui concerne les fonds d'écran animé, on ne parle pas de vidéo mais d'animation ce qui est différent. On peut même y gérer l'événementiel et ainsi activer une anim lorsque la souris passe dans une zone, on peut également exécuter des application lors d'une clic dans une zone (et en même temps avec une anim genre les classiques boutons par ex).

                            En faite tous les widgets et autres apps sont faites avec la même méthode que celle pour faire des fonds d'écran.

                            Ca va un peu plus loin que de la vidéo (qui n'est pas encore possible dans e17 d'ailleurs car le support de la vidéo n'est pas présent dans edje/eet pour le moment).

                            • [^] # Re: Ayé, c'est au point?

                              Posté par  . Évalué à -1.

                              dans mon utilisation cela planté, les plantages étaient d'ailleurs souvent différents suivant le thème utilisé, mais cela date d'il y a plus d'un an donc cela a peut être changé mais moi aussi j'ai changé ainsi que ma machine du coup les gestionnaires un peu plus lourd ne m'embettent pas tant que cela.

                              • [^] # Re: Ayé, c'est au point?

                                Posté par  (site web personnel) . Évalué à 2.

                                tu as peut-être utilisé une version binaire moisie ou s'appuyant sur des binaires moisis, genre <troll mode="vendredi">quand je vois iceape sous debian je comprend mieux pourquoi Moz ne veut pas qu'on utilise leur nom pour les versions modifiées à l'arrache</troll>.
                                Pour ma part je n'ai eu que quelques rares plantages en plusieurs mois d'utilisation en 2006 environ sur une FC4. Pour reprendre mon exemple, rien de comparable avec les crash quotidiens de mon iceape actuel sous lenny.

                  • [^] # Re: Ayé, c'est au point?

                    Posté par  (site web personnel) . Évalué à 4.

                    De mémoire il y a bien plus qu'un gestionnaire de fenêtre mais la stabilité de ces applications n'est pas encore là. Du moins d'après mes derniers tests.

                    Amns2 va posséder une interface utilisant les EFL.
                    Il y a un gestionnaire de fichier intégré mais certe pas du niveau de konqueror/nautilus.

                    Bref ca se contruit et E17 a pour vocation d'être plus qu'un gestionnaire de fenêtre, sinon quel intérêt de développer un nouveau toolkit.

                  • [^] # Re: Ayé, c'est au point?

                    Posté par  . Évalué à 1.

                    Tu peux utiliser les applis que tu veux avec E17 très peu gourmand en mémoire et cpu.
                    Le gestionnaire de fichiers est en chantier. Pour le moment je me sers de MC, Thunar ou Konqueror.

                    En vrac :
                    http://www0.get-e.org/Resources/Applications/
                    http://wiki.enlightenment.org/index.php/E17_User_Guide
                    http://xsm.alphagemini.org/E17/repository/
                    http://fr.enlightenment.org/article-de-presentation/les-appl(...)
                    http://blog.calaos.fr/index.php/2008/12/10/26--efl-applicati(...)

                    "L'art est fait pour troubler. La science rassure" (Braque)

              • [^] # Re: Ayé, c'est au point?

                Posté par  (Mastodon) . Évalué à 3.

                Moi j'ai une killer feature que je n'ai retrouvée nulle part. Une gestion indépendante des bureaux virtuels en multi-screen : je peux changer d'écran virtuel sur mon écran physique de droite sans que ça me switche celui de gauche. C'est hyper pratique, je ne peux m'en passer.

              • [^] # Re: Ayé, c'est au point?

                Posté par  . Évalué à 6.

                Alors E17, c'est le gestionnaire de fenetre et le filemanager.

                Les features :
                - Demarrage instantane (tu peux desactiver le splash screen qui ne sert a rien).
                - Politique modulaire de placement des fenetres (Actuellement disponible: Desktop classique, Fullscreen pour telephone/tablette, ou un mode tiling).
                - Systeme modulaire de plugin pour rajouter des fonctionnalites dans les shelf, la root window ou dans les menus (Plugin reseau, heure, temperature, systray, mail, calendrier, meteo, ...).
                - Grande efficacite dans la manipulation des fenetres (Tu peux comparer les perf de ton window manager avec : http://www.rasterman.com/files/wm_torture-0.1.tar.gz)
                - Gestionnaire de fichiers integre et efficace (Actuellement en grosse phase de finition, mais ca commence a ressembler a quelque chose de credible).

                Pour ce qui est des applis pur EFL, il y en a effectivement assez peu aujourd'hui. Les applis qui existe aujourd'hui, sont principalement des media player (enna, canola, rage), ou des applis de presentation.

                Mais etant donnee le peu de dev actuel sur le sujet, il faut rester un peu concentre. Le principal objectif, c'est de faire une appli, e17, qui montre tout ce qui est possible de faire avec les EFL et de faire une release d'ici a la fin de l'annee pour faire grandir la communaute de dev.

                Par contre, si tu veux ecrire un client Mail, IM ou un navigateur Web avec toutes les bibliotheques, n'est pas une tache complexe pour arriver a un resultat satisfaisant. C'est meme un tres bon moyen de s'entrainer pour comprendre le fonctionnement des EFL.

                • [^] # Re: Ayé, c'est au point?

                  Posté par  (site web personnel) . Évalué à 3.

                  - Demarrage instantane
                  Ok E17 et les libs autour sont super chiadées, mais s'il faut 8 ans pour y arriver, je sais pas si c'est vraiment efficace comme méthode... Je préfère avoir des applications moins optimisées mais qui existent et fonctionnent.

                  A mon avis il y a un juste milieu entre l'efficacité du programme (i.e ces performances) et la rapidité de développement pour obtenir ce même programme.

                  Qu'elle est donc le degré de rapidité/facilité de dev d'une application classique avec les EFL ? par rapport à C/GTK, C++/Qt, Python/Qt, Java/SWING, .NET/WinForms... ? (grosso modo hein, c'est le genre de truc hyper subjectif)

                  Personnellement je développe en C++/Qt qui me semble être un juste milieu entre performances du programme et sa rapidité de développement.

                  • [^] # Re: Ayé, c'est au point?

                    Posté par  . Évalué à -1.

                    Ok E17 et les libs autour sont super chiadées, mais s'il faut 8 ans pour y arriver, je sais pas si c'est vraiment efficace comme méthode... Je préfère avoir des applications moins optimisées mais qui existent et fonctionnent.

                    Surtout que ces bonnes perfs sont peut-être plutôt obtenues grâce à la modernité du matériel que...

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Ayé, c'est au point?

                      Posté par  . Évalué à 5.

                      et non, elles ne sont pas obtenues que par la modernité du matériel. On a fait un test, il y a quelques années avec plusieurs gestionnaire de fenetres. Pour comparer uniqement e17 avec les 2 plus utilisés que sont metacity et kwin, e17 était devant (initialisation, mappage de fenêtres et un autre test que j'ai oublié).

                      Quant nous faisons des tests, nous les faisons sur une même machine...

                      De plus j'ai fait un post où je parle de tests de qt, gtk et evas sur une set top box à 200 MHz. Qt(opia) n'a meme pas compilé (à cause du C++, en fait), gdk était trop lent, et Evas (une des EFL) était la seule à pouvoir faire des animations potables (et après des optimisations, ça tournait à 25 fps, sur un 200 MHz)

                      Je me demande à quoi sert ton commentaire, sinon pour faire un troll. Renseigne-toi un minimum, c'est la moindre des choses, plutôt que d'émettre une affirmation (malgré ton "peut-être") sans fondement.

                      • [^] # Re: Ayé, c'est au point?

                        Posté par  . Évalué à 0.

                        Gagné, c'était un troll ;-)

                        (j'admets que celui-ci était facile)

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Ayé, c'est au point?

                    Posté par  . Évalué à 3.

                    E17, c'est la premiere appli developpe. C'est aussi avec elle que le design des EFL a evolue. MAIS il ne faut pas prendre ca comme etant le temps de developpement necessaire pour une appli base sur les EFL. D'ailleur l'objectif, c'est de permettre a tout le monde de developper rapidement des applis tres efficace sans avoir a se soucier des problemes de perfs qui sont gere par le design des EFL et leur fonctionnement interne.

                    Tu peux essayer un peu de developper avec elementary/edje, tu verras qu'il est possible de rapidement developper de petites applis qui marchent et qui sont optimise par nature (Elementary ne fait pas partie de la release). Les binding en Python existant pour elementary, ca ne doit pas etre bien complique de dev avec ce langage de script.

                    L'idee qui se cache derriere le couple elementary/edje, c'est de pouvoir developper une appli rapidement sur pc et qu'elle tourne au theme pres sur un notebook, un telephone, une set top box.

                • [^] # Re: Ayé, c'est au point?

                  Posté par  . Évalué à 1.

                  < Alors E17, c'est le gestionnaire de fenetre et le filemanager

                  C'est quand même plus que cela, avec des modules bien pratiques: contrôle système, barre des tâches, calendrier, screenshot, alarme, batterie, temperature, notif mail, cpu, mélangeur son, diaporama, visualiseur de disques, moniteur réseau,etc.....

                  "L'art est fait pour troubler. La science rassure" (Braque)

      • [^] # Re: Ayé, c'est au point?

        Posté par  . Évalué à 5.

        compilation rapide sur une machine de moins de 3 ans? Mhh, mon eeePC 701 a moins de trois ans, ça devrait être rapide ^^

        Je ré-essaierai.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # EFL Bindings? Documentation ?

    Posté par  . Évalué à 3.

    Bonjour,

    Quelles sont les langages qui peuvent être utilisé avec EFL? Quelles sont les bindings existants ?
    Est-il par exemple possible à l'heure actuelle d'utiliser un langage comme ruby, python ou perl pour créer ses applications EFL?

    Existe-t-il de la documentation ou des tutoriaux pour apprendre les bases de EFL ?

    D'avance merci à ceux qui me répondront,

    Gawan

  • # Différence Ewl/Etk

    Posté par  (site web personnel) . Évalué à 3.

    J'ai jeté un petit coup d'oeil à l'API et j'ai un peu de mal à comprendre la différence entre Ewl et Etk, j'ai l'impression que les deux sont des toolkits à la Qt ou GTK mais du coup je ne comprend pas l'intérêt pour Enlightenment d'en avoir deux. Quelqu'un peut éclaircir ma lanterne ?

    Un détail qui m'interpelle un peu aussi: les methodes de l'API ont leur verbe à la fin, c'est un peu bizarre vu que Qt/GTK/Java/.Net font le contraire. Example:
    etk_label_alignment_set
    gtk_misc_set_alignment

    • [^] # Re: Différence Ewl/Etk

      Posté par  . Évalué à 5.

      Etk c'est mort, c'est juste gardé dans un état compilable pour le moment.

      pour l'API je dirait que ca part du plus global au plus prévis:
      lib_objectDeLaLib_actionSurObjet

    • [^] # Re: Différence Ewl/Etk

      Posté par  . Évalué à 2.

      Pour faire simple ewl et etk sont construit sur la meme logique que la partie toolkit graphique/widget de QT et GTK. En tant que tel, ils retirent beaucoup de fonctionnalite et de capacite des bibliotheques se trouvant en dessous. C'est le resultat d'un certain nombre d'essai et d'erreur qui ont amene a l'existence de ces deux projets.

      Mais comme au lieu de rajouter plus de puissance, fonctionnalite, capacite, ils en retirent, ces deux toolkits ne semblent pas etre l'avenir de la partie widget des EFL. Le travail le plus prometteur est actuellement dans Elementary et Guarana qui s'integre nettement mieux dans le design des EFL.

      Par contre, il faut bien noter qu'a leur actuel aucun de ces toolkit de widget ne fait partie de la release a venir. C'est encore un domaine trop jeune et qui bouge trop vite pour cela.

      Le fait de mettre le verbe a la fin, ca a un cote pratique en C, le get et le set ont des noms tres semblable et il est tres facile de rechercher simultanement tous les points d'utilisations. Mais bon, c'est plus une convention de projet qu'autre chose.

      • [^] # Re: Différence Ewl/Etk

        Posté par  . Évalué à 2.

        Cela veut dire qu'il faut adapter/recoder des applications de base régulièrement ?

        Envoyé depuis mon lapin.

        • [^] # Re: Différence Ewl/Etk

          Posté par  . Évalué à 3.

          En fait, il faut voir que avec les EFL, la majorite des applications n'ont pas besoin d'utiliser un toolkit de widget.

          Pour faire simple, les EFL, c'est un canvas (Evas) qui fournit des primitives de base (image, texte, rectangle, ...) qui recoit des events (Ecore). Sur cette base a ete construite une bibliotheque d'animation (Edje) qui sert de base pour construire toute l'interface de E17.

          C'est sur ces bases qu'on ete construit 3 toolkits, dans l'ordre chronologique Ewl, ETK et Elementary. Les deux premiers ont ete completement concu comme un toolkit de widget a la QT ou GTK. Le probleme, c'est qu'il cache le canvas et cela rend par design difficile d'utiliser les widget dans Edje ou dans d'autres objets. Cela limite les possibilites et l'interet des EFL. L'approche de Elementary est completement differente et vise a fournir une suite d'objet comme Edje.

          EWL, ETK et Elementary sont en soit des essais, experimentation pour essayer de fournir quelque chose de puissant, de facile a utiliser et qui ne demande pas beaucoup de dev pour arriver a un resultat. Mais actuellement la plus part des applis ont redevelopper leur propre jeux de widget, car ecrire un widget avec les EFL est quelque chose de plutot simple. Ca n'est pas semblable aux autres toolkit.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.