Journal Apercu Enlightenment v17

Posté par  (site web personnel) .
Étiquettes :
0
6
sept.
2006
Voila l'environnement de bureau développé par Rasterman et ses compères avance a grand pas aujourd'hui (certains diront qu'il était temps).

Donc comme je surveille son avancée et que Raster nous a mis une nouvelle vidéo présentant e17 je partage celle ci :

http://www.rasterman.com/files/e17_movie-05.avi

Hum je n'ai pas testé récemment mais même non finalisé j'ai trouvé E17 stable et utilisable quotidiennement.

Voila il manque encore une flopée d'appli pour avoir un bureau 100% EFL (enlightenment foundation library) mais le gestionnaire de fenêtre rempli correctement son rôle surtout comparé a ce que l'on peut trouver ailleurs.

On l'a attendu mais je pense que ça valait le coup !!

  • # Plussagement

    Posté par  . Évalué à 2.

    Que oui, ça vaut le coup.

    On ne répétera jamais assez combien les EFL sont bien fichue. Bien avant XGL, AIGLX, Compiz et tout les méchants hacks des codeurs X, les EFL était optimisé pour l'OpenGl et portait les ombres, les menus animées et la belle transparence.

    Les EFL forment peut-être la plus puissante API graphique qui existe sous Linux et un toolkit de devellopement d'application plus qu'admirable de part son architecture novatrices. Un fois qu'on a codé avec les EFL, revenir vers GTK ou QT est un vrai enfer.

    Il est dommage qu'elles ne soient que très peu utilisé pour l'instant, peut-être du fait qu'elles soient toujours en devellopement.

    Ceci dit outre le fait que Rasterman et de manière général les devellopeurs de E17 aient une qualité de graphiste qui les met en égales avec MacOSX. E17, c'est beau. E17, c'est bien. E17, mangez en.

    • [^] # Re: Plussagement

      Posté par  . Évalué à 10.

      Bien avant XGL, AIGLX, Compiz et tout les méchants hacks des codeurs X, les EFL était optimisé pour l'OpenGl et portait les ombres, les menus animées et la belle transparence.
      Dis tu t'es renseigné un peu ?
      Dire que le travail des développeurs de X c'est des hacks, c'est n'avoir rien compris au problème.
      Les "ombres" dans E17, autour des fenêtres par exemple, c'est l'exemple parfait de la méthode "hack". Ces ombres sont dessinnées sur le bureau. Deux fenêtres se superposant n'auront pas d'ombres "d'une fenêtre à l'autre" (comme dit quelqu'un qui m'a posé la question... j'espère que sa formulation est claire, la mienne ne l'était pas).
      La belle transparence, c'est aussi la même chose. Si tu déplaces un xterm sous un élément transparent dans E17, l'élément transparent n'affichera pas la fenêtre xterm. Ho si, il peut c'est vrai... la bonne vieille méthode des hacks avec les captures d'écran, super optimale. Essaye avec un contenu qui bouge comme une vidéo c'est mieux.
      La seule méthode valable pour faire de la vraie transparence et des vraies ombres, elle passe par une extension dans X. Il n'y a pas d'autre solution. Il est irréaliste d'avoir chaque élément transparent du bureau qui fasse des captures d'écran de ce qu'il se passe derrière lui toutes les x millisecondes. Il doit être notifié des modifications, et modifier son affichage en fonction de ces modifications.

      • [^] # Re: Plussagement

        Posté par  . Évalué à -8.

        Du calme. C'est une façon de parler. Tu monte sur des grands cheveaux sans raisons préalable. Ou tu tente de troller.

        De même, tu tente de faire croire que X est propre et bien architecturé, ce qui est bien evidemment faux. Les EFL, si. Entre quelque chose d'aussi gros et inélégant que XGL et quelque chose d'aussi bien fait, tentant par une architecture optimale de pallier aux problèmes même de X, le Hack n'est pas les EFL. Le Hack, c'est X, désolé de te le dire.

        Surtout que les EFL ont été réalisé pour pouvoir être porté sur d'autre back-end de fenêtrage. Et qu'ils impliquent OpenGL bien avant XGL.

        • [^] # Re: Plussagement

          Posté par  . Évalué à 10.

          De même, tu tente de faire croire que X est propre et bien architecturé, ce qui est bien evidemment faux. Les EFL, si.
          Démonstration ?

          Tu confonds allègrement Xgl et X. C'est un piège facile qui s'est propagé avec le marketing de Novell.
          Il est tout à fait possible de réaliser un composite manager utilisant l'openGl sans passer par la bidouille qu'est Xglx. Oui Xglx est une bidouille, je le sais et tout le monde devrait le savoir. Mais Xegl n'est pas une bidouille, et X.org avec aiglx non plus.
          Pour info, un Composite manager utilisant l'OpenGL ça existe depuis au moins juin 2004, bien avant qu'on parle de Xgl. Et il gérait la vraie transparence, bien avant qu'on en parle dans E17 (vu qu'on n'en parle pas).

          Au fait, les EFL c'est avant tout du rendu logiciel optimisé plutôt que du rendu OpenGL parce que Rasterman trouve l'OpenGL trop instable, ce en quoi il n'a pas forcément tord hélas...

          • [^] # Re: Plussagement

            Posté par  . Évalué à -10.

            Tu a une opinion toute faite sur les EFL que je n'essaierait pas de contredire pour rien au monde. Dort en paix ce soir, tu n'apprendra rien de plus que ce que tu ne veux comprendre. Sans vouloir te contredire, bien sûr.

            X n'a rien a voir avec Xegl, on est d'accord. Ce qui n'enléve rien a la pertinence de mes propos sur l'architecture des EFL.

            • [^] # Re: Plussagement

              Posté par  . Évalué à 8.

              Tu n'as pas sorti le moindre argument. On met régulièrement le doigt sur la langue de bois des politiciens, mais apparemment celle de certains ici est bien chargée aussi.

          • [^] # Re: Plussagement

            Posté par  . Évalué à 8.

            Je ne peux rien dire concernant les EFL, ne les ayant jamais utilisées.

            En ce qui concerne Xgl, AIGLX et consorts, il n'y a pas lieu d'en faire un fromage et de dire que l'un est une bidouille tandis que l'autre l'est moins.

            Xglx n'est pas une bidouille, c'est juste une des solutions les plus directes au problème, même si elle ne permet pas de répondre aux objectifs à long terme. Est-ce que tu dirais qu'Xnest est une méchante bidouille ? Sans doute pas, parce que ça marche, et pouvoir faire tourner un deuxième serveur X à l'intérieur d'un premier est très utile pour le développement de certaines choses (en ce qui me concerne, je joue avec kicker ainsi). Xglx, c'est exactement ça, mais en puisant dans les ressources d'OpenGL en plus. Partant de là, il est possible de faire en sorte que ce serveur X basé sur OpenGL prenne tout l'écran, et c'est comme ça qu'il est utilisé en pratique dans les distributions.

            Astucieux, moi je trouve ça astucieux.

            AIGLX prend une approche différente, qui a ces avantages indéniables, mais aussi ces inconvénients. Impossible de faire tourner un Xnest avec AIGLX activé. Ou plutôt si, c'est possible, mais l'extension Composite n'est alors pas activée pour des raisons techniques qui m'échappent, donc compiz et metacity accompagné de son compositeur n'y fonctionneront pas...

            À mon avis, Xglx a le mérite d'avoir accéléré le développement des gestionnaires de fenêtres avec compositeurs. C'est une bonne chose.

            Quant à l'architecture du serveur X, je trouve bien ambitieux de vouloir la critiquer avant de réellement la connaître. Le serveur X est construit de manière modulaire (indépendamment de la façon dont il est distribué) autour de ses extensions, ce qui me semble plutôt une architecture évolutive. Les aspects du serveur X encore en retrait vont sans doute s'améliorer dans l'avenir, parce exemple la gestion dynamique des périphériques d'entrée, etc. Enfin, comparer l'architecture des EFL et du serveur X n'a pas beaucoup de sens, ce serait comparer la structure d'un moteur et de la voiture qui le porte. Comparer les EFL et Qt ou GTK a beaucoup plus de sens.

            • [^] # Re: Plussagement

              Posté par  . Évalué à 3.

              Xglx a un autre intérêt que tu ne mentionnes pas : il permet de tester la viabilité d'un serveur X qui fasse tout son rendu par l'OpenGL, et comme il partagera du code avec un éventuel Xegl, cela facilitera le développement de ce dernier. (Je suis assez pessimiste sur la possibilité de survie d'Xegl... Mais ce n'est pas le sujet).

            • [^] # Re: Plussagement

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

              Impossible de faire tourner un Xnest avec AIGLX activé.
              XGL est précisement un Xnest qui fournit GLX_EXT_texture_from_pixmap à partir de l'accélération OpenGL sous-jacente. Et ton cas (jouer avec le développement X) est précisement la raison qui a fait naitre XGLx dans le projet XGL.
              Là ou ça devient du marketing sale, c'est que Novell l'a présenté comme le futur de X à des utilisateurs médusés.

              À mon avis, Xglx a le mérite d'avoir accéléré le développement des gestionnaires de fenêtres avec compositeurs. C'est une bonne chose.
              Ça aussi a crée un fort engouement pour des technologies immatures et mal comprises (avec des reflexions du type "même si compiz sert à rien, l'affichage de firefox iras plus vite").

              De toutes manière, le problème est pas l'existence d'XGLx. C'est effectivement un outil utile pour les gens qui, comme toi, ont besoin d'un serveur X à l'intérieur d'un autre serveur.
              Le problème c'est plutôt le buzz associé qui noie la reflexion dans un torrent de captures d'écrans.

              • [^] # Re: Plussagement

                Posté par  . Évalué à 2.

                XGL est précisement un Xnest qui fournit GLX_EXT_texture_from_pixmap à partir de l'accélération OpenGL sous-jacente.

                On est d'accord.

                Novell l'a présenté comme le futur de X à des utilisateurs médusés.

                Eh oui, le marketing... Bon, il y a une part de vrai quand même, les compositeurs basés sur OpenGL sont sans doute l'avenir même si les EFL arrivent à faire une quantité raisonnable d'effets en software. Xgl(x), lui, n'est qu'une partie de la pyramide. Et puis, dans tous les cas, (1) ça marche même si c'est suboptimal, (2) il n'y a vraiment pas de raison que ce soit plus instable qu'une autre implémentation, (3) c'est suffisant pour que compiz et compagnie nous montrent des choses au mieux jolies, au pire impressionnantes.

                Ça aussi a crée un fort engouement pour des technologies immatures et mal comprises (avec des reflexions du type "même si compiz sert à rien, l'affichage de firefox iras plus vite").

                Tiens, c'est intéressant. Pour avoir joué un peu avec Xgl et compiz, je confirme que ça n'accélère pas firefox, sans doute parce que la couche de composition rajoute quand même une bonne quantité de travail en plus au serveur (et ma carte graphique n'est plus toute jeune). Par contre, en théorie, ce n'est pas impossible. L'idée de Xgl, c'est de baser toutes les opérations graphiques sur OpenGL. Aiglx, lui, se contente de fournir un moyen de faire de la composition avec OpenGL, mais les autres opérations restent gérées par les habituels XAA, ou EXA quand ça marche. C'est d'ailleurs pour cela qu'a été introduite très récemment [1] une troisième architecture appelée "glucose" pour combler cette différence. La solution qui se dessine à l'horizon est donc un serveur X doté d'Aiglx pour la composition, et de "glucose" pour l'accélération des opérations graphiques habituelles.

                [1] http://lists.freedesktop.org/archives/xorg/2006-August/01752(...)

          • [^] # Re: Plussagement

            Posté par  . Évalué à 4.

            > OpenGL trop instable

            Tu peux m'en dire plus, je suis surpris par cette phrase :-\
            En quoi OpenGL est instable ?

            • [^] # Re: Plussagement

              Posté par  . Évalué à 1.

              Tu peux m'en dire plus, je suis surpris par cette phrase :-\
              En quoi OpenGL est instable ?

              Je pense qu il voulait parler du backend opengl et pas d opengl en lui meme :)

              • [^] # Re: Plussagement

                Posté par  . Évalué à 2.

                Houla, je suis encore plus perdu :-)
                Tu entends quoi par "backend opengl", les libs/headers systèmes ou bien les implémentations hardwares ?

            • [^] # Re: Plussagement

              Posté par  . Évalué à 4.

              Demande à Rasterman. Pour ma part, je pense qu'il parle du fait qu'il faille généralement des pilotes propriétaires, qui ont des problèmes de stabilité. Les pilotes libres en ont aussi d'ailleurs, il suffit de regarder un peu les mailing lists dri-devel.
              Mais bon, je ne m'avancerai pas plus.

    • [^] # Re: Plussagement

      Posté par  . Évalué à 3.

      élégant, surprenant, reposant, innovant, mais gardant malgré tout certains repères traditionnels (impression de macosx en plus sobre, d'amiga là-dedans, sans y voir toutefois de plagiat), je trouve E17 absolument sublime et unique. En plus il tourne vraiment très bien sur de petites configs, et reste très réactif.

      Ce bureau, c'est une oeuvre d'art.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Plussagement

        Posté par  . Évalué à -2.

        on s'en fout de qui est mieux, ça restera trop lent avec nos pilotes opensources incomplets :p

        • [^] # Re: Plussagement

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

          justement E17 reste tres rapide meme en mode software donc non accéléré.

          • [^] # Re: Plussagement

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

            À dire vrai y a que là qu'il pourait avoir un interêt (et encore)
            Sauf que pas de pot les pilotes opensources risquent d'être d'ici un an, pour ATI et nVidia au moins aussi performant, si ce n'est plus que leur équivalent proprio..... (Pour les ATI c'est déjà pas loin)

      • [^] # Re: Plussagement

        Posté par  . Évalué à 3.

        Macosx en plus en sobre? tu trouves? ça surjoue au niveau des effets je trouve

        Le look est plutôt vieillot, oui ce n'est qu'un thème, mais il a encore ce côté wm d'il y a 6ans, parcontre les fonds d'écrans sont sublimes, bref un ptit coup d'harmonisation et ça devrait le faire.

        j'attends qu'il tande vers un desktop pour l'utiliser.

    • [^] # Re: Plussagement

      Posté par  . Évalué à 4.

      Pour contenter tout le monde, il y a un module e17 en développement pour permettre de tirer profit d'XGL ("expose", alt-tab avec miniatures, fenêtres en "gélatine") sous e17. Une vidéo peut être trouvée ici: http://www.tzi.de/~jeff/elbang-scale.mpg

      C'est basé sur le code de compiz, le développement vient tout juste de commencer et aucun code n'a encore été publié mais ça permet de voir ce qu'il sera possible de faire. Un gros avantage c'est que tout le code se trouve dans un module, et donc aucune modification d'e17 n'est nécessaire: ceux qui ne veulement pas de XGL (comme Rasterman) n'ont donc juste à ne pas installer/activer le module.
      Il y a également un module pour l'extension "Composite" d'X qui est déjà disponible sur le CVS d'e17 (e_modules/bling). Ce module est stable (si on considère que Composite est stable...) et permet de d'avoir de "vraies" ombres projetées, de rendre les fenêtres qui n'ont pas le focus transparentes, ...

    • [^] # Re: Plussagement

      Posté par  . Évalué à 1.

      Ben... EFL j'avais vaguement regardé il y a quelques temps, et justement je n'avais pas été super convaincu par rapport à gtk+, dont je ne suis pas 100% satisfait.

      Je n'avais peut-être pas vu les bons exemples? On peut avoir des liens?

      Snark

      • [^] # Re: Plussagement

        Posté par  . Évalué à 3.

        Tu ne peux pas vraiment comparer les EFL avec Gtk. Les EFL sont un ensemble de librairies sur lesquelles se base e17. Elles sont composées principalement de:
        - Evas qui est une librairie graphique très rapide qui permet d'afficher des primitives (rectangles, images, dégradés, textes, ...). Evas est comparable à Gdk
        - Ecore qui est une librarie fourre-tout qui offre pas mal d'outils aux développeurs pour créer des fenêtres, créer des timers, gérer les évenements, etc. Ecore peut être comparer (et encore...) à la GLib
        - Edje qui se base sur Evas et sur Ecore et qui permet de charger des animations au format .edj et qui offre un moyen très puissant pour rendre les applications thémables. Tous les effets d'e17 sont fait grâce à Edje. Edje n'a pas d'alternative parmi les librairies Gnome/KDE. Edje se "rapproche" plutôt de Flash.

        E17 est donc basé sur ces trois librairies.
        Maintenant, Gtk peut être comparer à Etk (que je développe :) ). Etk est un toolkit graphique qui se base également sur Evas/Ecore/Edje et qui offre toute sorte de widgets (bouttons, menus, listes...) aux programmeurs. Etk à une API très proche de celle de GTK (c'était un des premiers buts d'Etk, maintenant c'est un peu moins vrai). Etk est encore au stade de développement, mais quelques applications l'utilisent déjà.
        Voici quelques screenshots:
        http://mtreny.free.fr/emphasis_detour.jpg
        http://mtreny.free.fr/escape.jpg
        http://mtreny.free.fr/etk/etk_apps.png

        • [^] # Re: Plussagement

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

          En parlant des applications e17 utilisant ETK ou EFL, se serait intéressant de tenir un listing de ces dernières et de leur status de développement ALPHA, BETA, ..., STABLE, ainsi que de leur utilisabilité : inutilisable/instable/.../utilisable/stable

          J'ai bien trouvé ça http://www.get-e.org/Resources/Applications/ mais escape n'y est par exemple.

          Autre question exhibit peut choisir entre ewl et etk c'est quoi la différence entre ces deux toolkits ?

          • [^] # Re: Plussagement

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

            je suis pas sur du tout mais je pense que c'est juste un changement de nom a confirmer :/

            • [^] # Re: Plussagement

              Posté par  . Évalué à 1.

              Non, Ewl et Etk n'ont rien à voir. J'ai commencé à écrire Etk il y a un an environ parce que je n'étais pas satisfait d'Ewl et parce je n'étais pas d'accord avec la politique de développement d'Ewl.
              Pour ce qui est d'exhibit, il est entièrement écrit avec Etk, il n'y a pas de frontend Ewl disponible. Seul entropy permet de choisir entre ces deux toolkits.

  • # moi...

    Posté par  . Évalué à -4.

    ...il était temps...

  • # Joli

    Posté par  . Évalué à 3.

    Mais le petit truc lumieux et qui bon "blob" c'est un peu lassant à force, je pense... (Un peu comme XGL d'ailleur)
    Par contre, il doit consommer beaucoup plus de processeur O_o

    • [^] # Re: Joli

      Posté par  . Évalué à 1.

      Plus rapide que fluxbox, mon petit. Enfin, selon certains et des très sérieus tests de Rasterman.

      Sans tomber aussi bas - je sens déjà venir les défenseurs de Fluxbox - E est très optimisé et très rapide, entre autre grace a une bonne architecture et des idée toute aussi bonne : comme le fait de devoir compiler ses fond d'écrans (au début, il est vrai, ça surprend). Les EFL ont été conçu pour l'embarqué, c'est dire.

      • [^] # Re: Joli

        Posté par  . Évalué à 7.

        Enfin, selon certains et des très sérieus tests de Rasterman.
        Tests sérieux... Tu parles de son test avec son "wm torture" ?
        Je l'ai testé. KWin 3.4 (je crois) contre Looking Glass l'été dernier. Sensiblement, l'utilisateur peut dire que Looking Glass consomme plus et est plus lourd que KWin. (Je l'affirme même... Il est particulièrement ardu de bosser sur ses performances. Bref passons).
        Or avec le wm torture, Looking Glass est plus rapide que KWin. En effet, KWin dessine les fenêtres avant de les fermer alors que Looking Glass ne le fait pas... Les résultats sont donc faux, et je suis sûr que tous les résultats donnés par Rasterman ne prennent pas en compte ce paramètre.

        De plus il n'a jamais présenté ça comme un benchmark (heureusement d'ailleurs)

        • [^] # Re: Joli

          Posté par  . Évalué à -8.

          Tu a été frustré par les EFL dans ta petite enfance ? Tu a toujours voulu faire quelque chose de ce niveau là sans y parvenir, ou bien ?

          Ton attitude est un manque sérieux d'éducation, avec toute mes escuses possible pour cette vérité.Je ne sais pas si tu n'a jamais essayé Enlightenment, mais tout ceux qui l'ont fait le disent : C'est extremement leger, bien plus que XGL, par exemple, auquel je met dans le même panier parce que ces deux technologie utilise OpenGL pour faire divers truc animé. EFL, ça roxe. Qu'on ne puisse pas en parler en publique, c'est que tout simplement la cabale censure dans notre dos.

          Non a la cabale. Oui a la vérité ! Pour un monde libre ! Toujours !

          • [^] # Re: Joli

            Posté par  . Évalué à 3.

            Tu cliques sur Répondre pour dire un texte qui ne répond pas à mon commentaire. Quel est l'intérêt ?
            De plus, relis moi : je n'apprécie guère Xgl. Ha oui, et aussi : les EFL c'est pas forcément de l'OpenGL parce que Rasterman préfère l'éviter. Mais c'est vrai, je connais pas.
            J'attends de voir un Alt+Tab dans E17 qui affiche des miniatures mises à jour en live de fenêtres, incluant dans le tas une petite vidéo (dans un lecteur quelconque, qu'il s'agisse de Xine ou Mplayer, utilisant XVideo de préférence)

      • [^] # Re: Joli

        Posté par  . Évalué à 6.

        E est très optimisé et très rapide, entre autre grace a une bonne architecture et des idée toute aussi bonne


        Pouquoi dis tu cela...?
        Comment peut tu dire qu'un soft est mieux architecturé que d'autre...?

        Ce n'est pas une attaque personnel, mais je te vois dire plusieur fois que E17/EFL
        est mieux architecturé que X, que ceci ou cela, mais tu à "lu" les codes de Xgl, ou même Xorg...?

        Tu dis que certaine chose sont des hacks, mais tu sais comment cela fonctionne...?

        Tu a des diagrammes de l'archi de Xgl, ou du fonctionnement EFL...?

        Tu dis que E est optimisé et rapide, mais optimisé pourquoi...?
        Xorg est mal fait...? Xgl...?

        Je ne suis pas asser bon pour comprendre comment on peut dire que Xorg
        est mal architecturé...
        Sur quoi te base tu pour dire ça...?

        Desolé pour toute ces questions...! :)

      • [^] # Re: Joli

        Posté par  . Évalué à 3.

        <troll de compet>
        comme le fait de devoir compiler ses fond d'écrans

        Chouette on va nous aussi avoir droit aux failles de securité sur les skins, y'avait pas de raisons que seul wmp beneficie de cette feature.

        </troll de compet>

        Ceci dit, je n'ai jamais essayé e17, je crois que je vais tenter vu que beaucoup de gens en disent du bien.

  • # p2p, tu me tient ... et je te soutiens :)

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

    http://www.rasterman.com/files/e17_movie-05.avi

    ed2k://|file|e17_movie-05.avi|37049214|10CADD0ED9088FB1DBAD7958915D5492|/

    PS: pourquoi le ed2k:// ne dievient-il pas ici un lien comme le http:// ?

Suivre le flux des commentaires

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