E17 est annoncé.

Posté par  . Modéré par patrick_g.
Étiquettes :
25
26
avr.
2009
Serveurs d’affichage
Vous avez peut-être déjà entendu parler de Enlightenment, qui était à la base un gestionnaire de fenêtres. Notez qu'il a (certes il y a fort longtemps maintenant) été le gestionnaire de fenêtres de GNOME. La version utilisée par GNOME était « E16 » ou, plus formellement, « Enlightenment DR16 ». Si vous téléchargez cette version, vous constaterez qu'elle est assez vieille.

En effet, le développement de e17 se déroulait uniquement sur le gestionnaire de version, et l'installation de celui-ci signifiait une compilation après un checkout — bien sûr, rien n'empêche les distributions de fournir des paquets binaires de e17, et quelques unes le font.

Mais pourquoi parler de ce gestionnaire de fenêtres — ou « desktop shell » — dont la sortie semble prévue entre celle de Debian Lenny et de Duke Nukem Forever ? Eh bien, les développeurs se sont risqués à annoncer une date de sortie. En fait, une page « release schedule » classique, allant jusqu'au lundi 14 septembre, date de sortie de la version Alpha. Selon le site, si tout se passe bien, la version finale sortira aux alentours de Noël. Wait and see. E17 est entré dans cet horaire le vendredi 17 — ou le jeudi 16, à 23:59... — « dernier » jour d'ajout de nouvelles fonctionnalités. Entre guillemets, car le lundi 20, le développement reprendra, jusqu'au 21 du mois suivant, etc.

Des paquets au format Debian seront générés chaque mois, jusqu'en août. Ce mois sera consacré au Google Summer of Code, et bien sûr au développement d'E.

Le « desktop shell » est un élément important d'e17, mais n'oublions pas les EFL, les bibliothèques écrites en C sur lesquelles reposent enlightenment. Voici les principales d'entre elles :
  • Eina, des structures comme les arrays, etc. ;
  • Eet, utilisé notamment pour les fichiers de configurations ;
  • Evas, qui sert à afficher du texte non crénelé ;
  • Ecore, gérant la boucle d'événements ;
  • E_Dbus, une implémentation de D-Bus ;
  • Efreet, pour assure la compatibilité avec le projet freedesktop ;
  • Embryo, pour interpréter le langage de script du même nom ;
  • Edje, servant à appliquer un thème sur les applications ;
  • Ewl et Etk, deux boîtes à outils légères, orientées objets — restant bien sûr codés en C.

Un point important d'E17, est qu'il est entièrement modulaire. Vous pouvez même désactiver les modules de configuration si cela vous chante — ce n'est toutefois pas conseillé...

Il vise à être très eye candy, sans être lourd. Il vous est donc possible d'activer toutes les fioritures que vous aimez, comme compiz — ecomorph — , ou encore un dock — itask-ng.

Néanmoins, il n'y a pas que des bureaux virtuels, un vieux Compiz patché, etc.
E17 s'offre le luxe d'innover, notamment par ses fonds d'écran. Les fonds d'écran sont des fichiers edje, scriptables avec embryo, vous pouvez donc vous amuser avec, par exemple, des fortunes sur votre bureau.

Au niveau des applications, cela reste moins riche que Gnome/GTK et KDE/Qt. Il n'y a pas de navigateur web, ni de client de messagerie instantanée, codés avec les EFL. Il y a toutefois un frontend à MPD — emphasis — , un jeu de cartes — elitaire — mais même le gestionnaire de fichiers est expérimental, d'où la presque-obligation de passer par d'autres applications pour avoir un système utilisable.

Les développeurs commencent néanmoins à « combler » les manques. Non pas qu'ils soient en train de développer un navigateur web, mais ils s'activent sur le développement du gestionnaire de fichier, et, par exemple, un module de systray s'est ajouté dans le serveur SVN il y a peu.

Aller plus loin

  • # E17 ... le gestionnaire préféré sur OpenMoko

    Posté par  . Évalué à 5.

    C'est cool, on va pouvoir faire ressembler les PC installés avec des distros classiques à un téléphone FreeRunner ;)
  • # Annonce d'une version alpha ?

    Posté par  . Évalué à 9.

    Un article pour une hypothétique date de sortie d'une version alpha pour dans plusieurs mois ?
    Zut, et moi qui hésitait à écrire un article pour la sortie (effective !) d'une alpha de k3b pour kde4 ...

    Certains diront que c'est déjà utilisable, mais si au moins on avait une idée du travail qu'il reste à accomplir jusqu'à l'alpha et la final, ça serait plus intéressant.

    Désolé pour la critique, je respecte toujours l'effort que font les personnes qui rédigent des articles.
    • [^] # Re: Annonce d'une version alpha ?

      Posté par  . Évalué à 9.

      Il faut tout de même garder à l'esprit qu'Enlightenment est ... Enlightenment !
      Son cycle de développement est très long, puisque la mise au point d'E17 a débuté en 2000.
      On peut donc comprendre qu'en soi l'annonce d'une alpha d'E17 soit un "évènement" pour le monde du libre.
      Bien plus que k3b qui sort des versions plus souvent...
      • [^] # Re: Annonce d'une version alpha ?

        Posté par  . Évalué à 3.

        Tiens ça me fait penser à ce que je me suis "amusé" à lire depuis 1h, à savoir des articles wikipedia concernant les Indicateur_economiques dont entre autres les indices de développement que sont le Produit_national_brut (PNB), l' Indice_de_developpement_humain (IDH), l' Indicateur_de_pauvrete (IPH) ou encore l' Indice_de_sante_sociale (ISS) qui ont confirmé à mes yeux la difficulté de choisir le bon indicateur pour évaluer les "choses".

        Alors à ton indicateur de "temps de développement" pour juger de la pertinence d'avoir un article sur E17 plutôt que sur k3b, j'oppose un indicateur disons de "temps d'attente global" correspondant au temps de développement multiplié par le nombre d'utilisateurs probables (aïe !) de l'application cible.

        Voilà, il n'y a plus qu'à écrire un article pour k3b maintenant.


        PS : Ce message n'est bien entendu qu'une boutade. ;)
        PS2 : La balise wikipedia ne semble pas acceptée les caractères non ASCII
        • [^] # Re: Annonce d'une version alpha ?

          Posté par  . Évalué à 1.

          PS2 : La balise wikipedia ne semble pas acceptée les caractères non ASCII

          Ton correcteur grammatical non plus, manifestement.
        • [^] # Re: Annonce d'une version alpha ?

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

          Et moi je propose de remplacer "nombre d'utilisateurs probables" par "nombre de vieux geek qui attendent des nouvelles". Et vu qu'E17 est devenu plus qu'une légende chez les vieux geeks ils gagne haut la main... (il partage la première place avec DukeNukem Forever)
          Bien sûr, si on prend en compte tous les ptit jeunes qui n'on pas connu la merveille qu'est E16 et donc n'attendent rien de E17...

          PS: Ce messae n'est bien entendu qu'une pause nostalgie ;-)
          • [^] # Re: Annonce d'une version alpha ?

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

            Je plussoie :-)

            J'ai utilisé E16 à son heure de gloire, puis je suis passé à quelque chose de bien plus classique (Gnome), faisant de temps en temps un bout de route avec des alternatives à construire (c.a.d. forger son bureau à partir de plusieurs logiciels dissociés) comme FluxBox en window manager par exemple.

            J'ai essayé E17 à un certain moment (il y a 1 ou 2 ans) et ce n'était vraiment pas stable. Je l'ai réessayé il y a quelques temps, et j'ai aimé, mais difficile de se faire facilement un desktop complet sans l'aide d'intégration de distributions (ça se démocratise, avec par exemple Elive ou OpenGeu). Du coup, je laisse tomber pour l'instant, mais ancien utilisateur d'E, je suis sûr que j'y reviendrai.

            Pour le temps de développement, la raison est simple : le développement prend beaucoup de temps car Rasterman est un perfectionniste et passe un temps considérable à optimiser, arranger, remodeler son code, jusqu'à arriver à une certaine maturité (l'annonce de la version 1 de EET a été le premier exemple).

            Du coup, je me suis retenté E16, et quoi qu'en dise l'article, bien qu'il ait vieilli, il est toujours aussi prenant, beau, et surtout léger. E16 était gourmand à l'époque, mais pour des machines de l'époque. Aujourd'hui, il se place plutôt dans la catégorie des légers (environ 8mo en RSS sur ma machine, en fournissant le pager, l'iconbox et le systray - via une iconbox dédiée). Et pourtant il est ... beau (le thème winter par défaut est simplement et assurément génial car simple et agréable à l'oeil).

            Il est possible de je reviennent définitivement à E16 si je trouve le courage de me remonter un desktop de A à Z, parce que les 20Mo RSS de gnome-panel, les 10 ou 15Mo par applet, le 15Mo pour metacity qui est pourtant simple, ça fini par m'énerver.

            Peut-être un jour E17, qui sait ...

            PS : au passage je fais de la pub pour urxvt, très fonctionnel et pourtant léger (surtout en mode daemon), rien à voir avec tous ces émulateurs de terminaux basés sur vte.
            • [^] # Re: Annonce d'une version alpha ?

              Posté par  . Évalué à 3.

              Comme toi j'ai commencé par e16. Mais j'ai rapidement basculé sur e17 il y a qq années, et je l'utilise quotidiennement depuis, sur portable, fixe et au boulot...

              C'est assez simple... je ne trouve rien qui fonctionne aussi bien.

              Alors par contre, il n'y a pas que Rasterman d'exigeant :) je dirais que c'est le cas de tous les dev e17... et du coup ça conduit à des versions svn cassées... entre deux modification d'API ou de libs.

              Mais, pour info, ce n'est pas une version stable, ni alpha... mais c'est 100 fois plus performant qu'un KDE4, et beaucoup plus stable qu'un gnome ou kde...


              La raison pour laquelle il n'y avait pas de systray jusqu'à il y a en gros 3 semaines, est expliquée ici : http://www.rasterman.com/index.php?page=News (ctrl +f :"I hate systray icons")

              Un exemple de ce qu'on peut faire avec les EFL : le selecteur de wallpaper : http://www.rasterman.com/files/wp2.avi

              ou illume : le module pour transformer E en un OS pour téléphone portable : http://www.rasterman.com/files/illume-01.ogg
              • [^] # Re: Annonce d'une version alpha ?

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

                La raison pour laquelle il n'y avait pas de systray jusqu'à il y a en gros 3 semaines, est expliquée ici : http://www.rasterman.com/index.php?page=News (ctrl +f :"I hate systray icons")

                En fait il y avait déjà eu un applet systray (peut être que le nom était itray), c'était bien avant que les shelves soient introduits dans e17, à l'époque les icônes étaient des .eap, il y avait des concepts et des applis qui ont disparus depuis… En fait à l'époque je compilais le cvs assez régulièrement, lors d'un checkout, le systray était arrivé, au checkout suivant il ne compilait pas, avec un commentaire de Rasterman disant que tant qu'il n'y avait pas de spécification freedesktop potable, et appliquée, il n'y aurait pas de systray dans e17. Un des exemples donnés étaient le fait que les icônes ont parfois un fond transparent, parfois un fond de la couleur du thème du toolkit de l'appli, parfois une couleur arbitraire, des icônes aliasées et d'autres non… bref un niveau d'exigence qui volait en sous-sol et qui mettait Rasterman en rogne !
                Si un systray doit aparaitre ce doit être par pragmatisme, parceque toujours valables sont les raisons qui ont fait se suicider le développement de l'applet dans le passé.

                Sinon, il y avait un systray dans engage, le dock qui poutrait des mamouths !

                Ah, nostalgie !

                ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: Annonce d'une version alpha ?

                Posté par  . Évalué à 2.

                Très impressionnantes les vidéos !!

                Dis donc, si on pouvait avoir plus d'applis en efl et se faire un bureau complet avec... Ouarf.
                • [^] # Re: Annonce d'une version alpha ?

                  Posté par  . Évalué à 1.

                  Vidéo d'un appli utilisant les EFL:

                  http://calaos.fr/pub/video/calaos_media_music.ogg
                  • [^] # Re: Annonce d'une version alpha ?

                    Posté par  . Évalué à 0.

                    et une vidéo du sélecteur de fond d'écran :

                    http://www.rasterman.com/files/wp2.avi

                    (oui, il est possible d'avoir un fond d'écran animé avec e17)
                    • [^] # Re: Annonce d'une version alpha ?

                      Posté par  . Évalué à 3.

                      cette vidéo n'est peut être pas la meilleure pub possible pour le fond d'écran animé
                      on voit que des qu'il active ce fond d'écran animé, le système se met à ramer comme une grosse bouse, n'arrivant plus à afficher environ qu'une seule image par seconde
                      • [^] # Re: Annonce d'une version alpha ?

                        Posté par  . Évalué à -2.

                        On voit que tu es un expert. Il y a un scrolling parallaxe sur 3 plans, avec un rafraîchissement de la totalité de l'écran tous les 1/25 de seconde, qui est assez gourmand. Donc oui, c'est normal que ça rame. Tout fond d'écran animé ramera, quel qu'il soit...
                        • [^] # Re: Annonce d'une version alpha ?

                          Posté par  . Évalué à 5.

                          Tout fond d'écran animé ramera, quel qu'il soit...

                          Pourquoi cette fonctionnalité serait proposée alors ? Au contraire, il y a des fonds d'écrans animés qui ne rament pas - j'en ai vu. Au passage, un scrolling sur 3 plans c'était peut-être impressionannt il y a dix ans, mais maintenant...

                          Ce qui m'a plus gêné dans cette vidéo c'est l'ergonomie. À chaque fois, l'utilisateur est obligé de redimensionner sa fenêtre. Et puis il faut deux clics pour changer le fond d'écran alors qu'un seul pourrait suffire. Si tout E17 est comme ça je risque de ne pas être un utilisateur ravi.
                          • [^] # Re: Annonce d'une version alpha ?

                            Posté par  . Évalué à 0.

                            bon, j'ai un peu exagéré quand j'ai dit que tout fond d'écran animé ramera. Ca dépend de la fréquence de rafraîchissement, de ce qui est modifié à l'écran. Mais pour l'exemple de la vidéo, rien que faire une modification de la totalité de l'écran 25 fois par seconde, c'est énorme (93 Mo/s en 1280x1024, qui est la résolution la plus utilisée, il me semble), sans compter toutes les calculs que le CPU fait pour faire les calculs (ici, pas d'accélération matérielle, tout est en soft).

                            tu as l'air de vouloir changer de fond d'écran toutes les minutes pour être à ce point tatillon sur un clic.
                            • [^] # Re: Annonce d'une version alpha ?

                              Posté par  . Évalué à 3.

                              Après e fond d'écran animé n'est as quelque chose qui a réellement était cherché. Un fond d'écran c'est un fichier edje, et un fichier peut contenir des animations et la gestion des evenements. Donc on peut faire des fonds d'écran animé. Ce n'est pas franchement LA feature de e17, c'est plus une feature collatérale.
                            • [^] # Re: Annonce d'une version alpha ?

                              Posté par  . Évalué à 1.

                              tu as l'air de vouloir changer de fond d'écran toutes les minutes pour être à ce point tatillon sur un clic.

                              Pour moi ce clic en trop est révélateur de l'ergonomie du bureau qui n'est probablement pas mieux que ses concurrents bien installés. Dommage, j'aurais bien aimé que ce soit beau et ergonomique (enfin, plus que les autres, je ne dis pas qu'il n'est pas utilisable).
                              • [^] # Re: Annonce d'une version alpha ?

                                Posté par  . Évalué à 3.

                                mais tu voudrais quoi ? que des que tu clique sur une image ça la sélectionne comme fond d'écran ?
                                Tu fait comment si finalement tu veut pas changer et garder l'ancienne image ? tu la recherche dans la liste pour la sélectionner ?
                                Si finalement tu ne veut appliquer la nouvelle image que pour ce bureau et non tous les bureaux ? Tu doit re-sélectionner l'ancienne image pour revenir en arrière puis ensuite sélectionner un bureau puis l'image ?

                                C'est un peu lourd comme méthode :/
                                Ici c'est clair: Tu sélectionne une image, si finalement tu la veut en fond d'écran tu doit clairement le valider. Au contraire niveau ergonomie au moins c'est clair pour l'utilisateur.
                                • [^] # Re: Annonce d'une version alpha ?

                                  Posté par  . Évalué à 1.

                                  Effectivement, j'aimerais bien que dès que l'on clique le nouveau fond d'écran soit appliqué. Et si l'on veut revenir en arrière ? On fait travailler sa mémoire visuelle et on clique sur l'ancienne image. Ainsi on épure l'interface et on est plus efficace les 98% des fois où on ne change pas d'avis. D'ailleurs je ne suis pas le seul à le penser... non, je ne vais pas citer l'OS à la pomme sinon je vais me faire jeter.

                                  Comme dit au dessus, c'est un détail sur une application que je n'utiliserais pas (j'ai du mal à supporter autre chose que le gris uniforme comme fond d'écran), mais je pense que tout le bureau est construit dans cette philosophie. Si je bascule sur E17 j'aimerais avoir un système plus beau, plus réactif et plus ergonomique ; je n'aurai que les deux premiers (de ce que j'ai vu).

                                  Si j'ai plus que trois lignes à écrire sur le sujet j'essayerai de rédiger un journal là-dessus. Un débat GUI vs GUI, ça changera du GUI vs CLI.
                                  • [^] # Re: Annonce d'une version alpha ?

                                    Posté par  . Évalué à 4.

                                    Sauf que tu n'es pas seul au monde, et que plusieurs personnes ne pensent pas du tout comme toi.
                                    A part Apple donc, sauf que Apple niveau ergonomie ne fait pas l'unanimité.
                                  • [^] # Re: Annonce d'une version alpha ?

                                    Posté par  . Évalué à 3.

                                    C'est la méthode apple qui fait ça pour la plupart de ces outils
                                    Pratique en effet, mais à mon gout plutot dangereu et antipratique (surtout si on veut faire plusieurs opérations longues, on doit les enchainer plutot que de les faire toute en un coup)
                        • [^] # Re: Annonce d'une version alpha ?

                          Posté par  . Évalué à 1.

                          pour info ce genre de scrollings, il me semble que ca marchait nickel sur Amiga, sans bouffer toutes les ressources. Ou encore, Mplayer est capable de m'afficher une vidéo en fond sans bouffer tout mon proc, pourtant ça doit être plus compliqué qu'un simple scroll, même sur 3 plans

                          donc ton assertion comme quoi c'est obligé de ramer est fausse (et la derniere fois que j'ai testé E17, cette fonction marchait mieux sur mon pc que la video en question)

                          euh je ne sais pas pourquoi ça rame (vieille vidéo, bug, manque d'opti, machine de merde ...), je n'accuse pas, je dis juste que ce n'est vraiment pas le bon lien pour faire de la pub pour cette fonction
                          • [^] # Re: Annonce d'une version alpha ?

                            Posté par  . Évalué à 5.

                            Afficher une vidéo et une suite d'image ce n'est pas tout à fait la même chose. Ton processeur a des optimisations pour la vidéos et la vidéo n'est qu'une suite d'image là ou edje calcul l'image résultat.

                            Toujours est il que oui ca rame, ce n'est peut être pas le bon exemple cette vidéo. Avoir un fond d'écran avec edje permet plus qu'une simple animation: il est possible de gérer les evenements souris et claviers et ainsi executer des animations au passage de la souris par exemple. Une animation n'est pas obligée d'occuper tous l'écran comme c'est le cas ici, une plus petite animation pour simuler un bouton par exemple, pour mettre une transition pendant le changement de la valeur de la t° du proc par exemple.

                            Sinon actuellement il y a un travail au niveau du cache du redimenssionnement des images qui est effectué, l'absence de se cache plombe les perfs lors d'animation utilisant des images dont la taille est modifiées par l'appli.

                            En ce qui concerne la taille de la fenetre, c'est possible de sauvegarder sa taille. Actuellement elle est petite parce que l'appli a était codé pour pouvoir tourner sur des petits écran (téléphone par ex).
                          • [^] # Re: Annonce d'une version alpha ?

                            Posté par  . Évalué à 2.

                            heuu l'Amiga 500 de l'époque a une résolution de 640x512 au max... De plus son co-processeur était optimisé pour l'affichage.

                            mplayer utilise l'accélération matérielle (via l'extension X Window Xv), et est de plus ultra-optimisé pour son unique boulot : l'affichage de vidéo. Or le fond d'écran animé n'est PAS une vidéo et a de plus beaucoup plus de contrainte que l'affichage d'une vidéo. Tu ne compares pas des fonctionnalités équivalentes (comme pour l'amiga, d'ailleurs : on ne fait pas juste un jeu). Enfin, l'utilisation de mplayer pour avoir un fond d'écran implique des contraintes pour faire des choses comme la transparence, transparence qui est faisable avec le fond de e17.

                            Concernant l'obligation de ramer, je viens de répondre, j'ai un peu exagéré. J'ai répondu juste avant. J'ai aussi oublié de préciser que mon commentaire était lié à ce type de fond d'écran (affichage de plusieurs plan, avec un taux de rafraichissement élevé)

                            Le fond d'écran qui est dans la vidéo a toujours ramé chez moi. Mais j'ai une machine pourrie. Raster a certainement un moniteur de folie avec une résolution en 1900x****, ce qui doit faire monter la bande passante à un trop gros niveau.
                            • [^] # Re: Annonce d'une version alpha ?

                              Posté par  . Évalué à 3.

                              J'ai aussi oublié de préciser que mon commentaire était lié à ce type de fond d'écran (affichage de plusieurs plan, avec un taux de rafraichissement élevé)

                              Ben justement, avec une architecture potable, c'est beaucoup beaucoup plus leger d'avoir simplement 3 plans ou plus qui bougent.

                              Une scene 3d tout ce qu'il y a de plus basique, 3 textures et hop c'est fini. J'ai fait un truc approchant pour Windows (2 textures avec un effet Ken Burns). Resultat: 2% CPU max pour un affichage sur 2 moniteurs en 1680x1050.

                              Par contre une video, ca demande beaucoup plus de bande passante justement puisque tu dois soit copier chaque frame decodee vers la RAM de la CG (d'ou utilisation de CPU en plus de la BP), ou bien copier les donnees vers la CG qui fait une partie du decodage (moins de CPU mais tjs pas mal de BP). Cela dit pour une video en 1280x1024 on reste dans les 10-15% de CPU. Par contre avec une carte AGP d'il y a 4-5 ans, ca va etre juste au niveau BP.

                              Donc si ca rame, c'est pas que c'est specialement complique ou demandeur en resources, c'est que c'est soit tres mal optimise, soit l'architecture retenue se prete tres mal a ce genre de choses.
                              • [^] # Re: Annonce d'une version alpha ?

                                Posté par  . Évalué à 3.

                                C'est juste que edje fait tout en software... Là où le travail, à l'heure actuelle, devrait être effectué en hardware.

                                Ça me fait justement penser que c'est là ce qui est malheureux avec E17, parce qu'on a justement besoin d'avoir ENFIN un toolkit pour faire des interfaces entièrement gérées matériellement (non je n'ai pas dit opengl, non je n'ai pas dit mac os, mais je l'ai fortement pensé).
                                Parce que tant qu'on en restera à l'architecture classique on pourra inventer tous les gestionnaires composites que l'on veut avec des effets de la mort qui tue nos interfaces se vautreront toujours lamentablement face à mac os et même windows parce que le simple redimensionnement de fenêtre qui lague et j'en passe des détails, ça fait carrément vieillot !

                                Bref tout ça pour dire que les EFL font un super boulot dans ce sens car elles ont finement travaillé ces détails 'oubliés' par les autres toolkit, des transitions, des redimensionnements, des animations possibles sur tout types d'objets, de manière fluide, belle et peu consommatrice ! Ça, c'est exceptionnel car c'est software, mais du coup, faut pas trop en attendre non plus. Un scroll 3 plan en full screen à 25 fps le tout avec un rendu calculé en software en temps réel, même pour un pentium récent, et même avec le niveau d'optimisation des efl, ça se remarque forcément par un lag bien appuyé !

                                Ce 'type' d'animation devrait être géré par la carte graphique (comme les videos en XV) un point c'est tout...
                                • [^] # Re: Annonce d'une version alpha ?

                                  Posté par  . Évalué à 6.

                                  Concernant l'accélération d'evas (la lib qui s'occupe de la partie graphique), il y a quelques petites choses à savoir, avant de dire que OpenGL, Xv etc... sont les techniques à utiliser.

                                  Sous Linux, il y a plusieurs moyens d'accélerer matériellement la partie graphique gérée par un serveur X (c'est-à-dire d'utiliser le GPU et non le CPU).

                                  Xv : extension X dédiée spécifiquement à la vidéo. On oublie, evas ne fait pas de la vidéo.

                                  Xrender : extension X dédiée au rendu dans un Pixmap X. Elle utilise les routines 3d pour l'accéleration du rendu (c'est comme ça que les drivers libres de xorg pour les ATI et pour Nvidia (avec leur driver s'appelant 'nouveau') font.

                                  OpenGL (et Direct3D pour la partie Windows XP) : on utilise les routines d'OpenGL pour afficher le contenu d'une fenêtre en faisant en sorte que le vertex (en fait les vertex vu qu'un vertex est un triangle et il faut 2 triangles pour faire le rectangle de la fenêtre) sur lequel on affiche le contenu de notre fenêtre soit parallèle a l'écran.

                                  Evas dispose de plusieurs moyen d'affichage, dont le software, XRender et OpenGL. Dans la pratique, le software sera plus performant pour certaines opérations car, durant une animation, il ne mettra à jour QUE la partie de la fenêtre qui a été modifiée

                                  A contrario, XRender et OpenGL doivent mettre à jour toute la fenêtre à chaque fois que l'affichage doit être fait. Ce qu'on gagne avec l'accélération matérielle, on le perd en mettant à jour toute la fenêtre.

                                  L'affirmation : on doit utiliser OpenGL ou une autre technique parce que c'est accéléré matériellement, n'est pas si évidente. Nous avons un benchmark pour évaluer les performances d'Evas et certains tests sont plus rapides en software, d'autres sont plus rapides avec OpenGL.

                                  "Ce 'type' d'animation devrait être géré par la carte graphique (comme les videos en XV) un point c'est tout... "

                                  Dans la mesure où je doute que tu saches comment est conçu e17 (surtout concernant la gestion du fond d'écran), je me permet de te répondre que, non, ce n'est pas possible. Ca implique de trop grosses contraintes sur la manière dont les autres fonctionnalités de e17 sont implémentées et on y perdrait plus qu'on y gagnerait.
                                  • [^] # Re: Annonce d'une version alpha ?

                                    Posté par  . Évalué à 2.

                                    Merci pour ces précisions.

                                    Cela dit, j'ai conscience que ce n'est pas possible pour E17. Mais quand on voit le résultat obtenu par les EFL (la beauté, la fluidité, l'optimisation) je pense pas qu'on puisse dire qu'un mauvais choix ait été fait sur cette gestion même si je ne connais effectivement pas comment ça marche dans le détail.

                                    Par contre, ça n'est clairement pas fait pour générer un fond d'écran animé à 25 fps. Ça me paraît juste logique, et d'ailleurs le résultat le prouve. Comme ça a été dit plus haut, une vidéo de démo d'e17 ne devrait simplement pas focaliser son attention sur ce gadget...
                                    • [^] # Re: Annonce d'une version alpha ?

                                      Posté par  . Évalué à 5.

                                      actuellement, toute animation qui a l'air d'être une vidéo est faite par edje avec plusieurs images (en général des png). C'est comme ça que l'animation de l'introduction de e17 est faite.

                                      Avec un ami, on compte ajouter le support de la vidéo dans edje (j'ai aussi écrit un petit codec qui travaille en ARGB (donc support de la transparence)). Ca pourra peut-être consommer moins de ressource, et l'animation prendra clairement moins de place sur le disque (j'ai 20% de gain avec mon codec, par rapport aux images png de l'intro)
                                      • [^] # Re: Annonce d'une version alpha ?

                                        Posté par  . Évalué à 2.

                                        Comme tu as l'air d'avoir le nez dans le code, tu vas peut-etre pouvoir me renseigner.

                                        Autant pour tout ce qui est animations de taille petite a moyenne, avoir une suite de pngs (ou un seul avec toutes les frames les unes a la suite des autres) fait parfaitement l'affaire - voire rend mieux qu'une video pixellisee; autant pour quelque chose comme le fond d'ecran (avec une resolution importante), j'ai du mal a voir ce qui a fait choisir ce genre d'architecture.

                                        En gros, c'est quoi les avantages d'avoir un rendu image et pas une scene OpenGL (afficher une suite d'image devient trivial et prend du coup que dalle en CPU) dans le cas de E17? J'imagine que vous devez avoir des contraintes autres, parce que vu la baisse de perf... Sur les videos d'il y a 1-2ans je me rappelle avoir remarque que les ombres etaient rendues directement sur le desktop (et pas proprement sur la/les fenetres suivantes dans le z-order). C'est seulement pour ca ou il y a autre chose?
                                  • [^] # Re: Annonce d'une version alpha ?

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

                                    OpenGL (et Direct3D pour la partie Windows XP) : on utilise les routines d'OpenGL pour afficher le contenu d'une fenêtre en faisant en sorte que le vertex (en fait les vertex vu qu'un vertex est un triangle et il faut 2 triangles pour faire le rectangle de la fenêtre) sur lequel on affiche le contenu de notre fenêtre soit parallèle a l'écran.

                                    Petite correction : un vertex c'est un sommet, donc il en faut trois pour former un triangle, quatre pour un rectangle.
        • [^] # Re: Annonce d'une version alpha ?

          Posté par  . Évalué à 3.

          Je pense que c'est un peu le contraire. Un projet qui a peut de visibilité doit avoir plus de publicité ici.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Annonce d'une version alpha ?

      Posté par  . Évalué à 4.

      si au moins on avait une idée du travail qu'il reste à accomplir jusqu'à l'alpha et la final

      Je ne vois pas vraiment ce qu'il y aurait à dire... Corriger les bugs « mystérieux » (Rien qu'aujourd'hui j'ai eu, disons, une dizaine de fois une fenêtre me demandant si je voulais bien redémarrer E — sans risque de pertes de données), au niveau des features, je ne vois pas grand chose, si ce n'est le navigateur de fichiers et le module systray.
      J'ai surtout du mal à trouver comment donner « une idée du travail qu'il reste à accomplir ».

      (Quant à la critique, il n'y a bien entendu pas de problèmes ;)
      • [^] # Re: Annonce d'une version alpha ?

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

        J'ai toujours trouvé E17 stable personnellement bien plus que d'autre environnement déclaré stable
        • [^] # Re: Annonce d'une version alpha ?

          Posté par  . Évalué à 2.

          Tu risques tout de même d'avoir des mésaventures si tu recompiles toi-même quand le code est « cassé » (Lors de ma première compilation, il y avait un problème avec eina, même si tout le code était compilé sans erreurs :).
          Après c'est sûr, la fenêtre blanche annonçant une erreur terrible fait peur une fois, mais après s'être rendu compte que l'on ne perdait pas le fichier que l'on était en train d'éditer, ça nous passe au dessus.

          Néanmoins, Je n'ai pas eu ce genre de bogue sous Openbox, etc.
      • [^] # Re: Annonce d'une version alpha ?

        Posté par  . Évalué à 2.

        Alors s'il ne reste effectivement qu'un travail de correction de bugs avant la sortie de E17, je vois deux questions :
        - Comment le temps de correction a t-il été évalué ? Arbitrairement ? En fonction des bugs connus restants ? (ce qui m'amène à la deuxième question)
        - Existe il un système de suivi de bugs (genre bugzilla ou autres ?) pour E17 où l'on peut voir les bugs Release Critical, ces fameux bugs qui repoussent de mois en mois la sortie d'une Debian Stable ou qui permettent encore de juger de l'état d'avancement du développement de Firefox 3.5 avant sa sortie prochaine ?

        Bon je pinaille, le titre de l'article m'a fait sourire indépendamment de son contenu, tu n'y es pour rien, c'est de ma faute. Toutes mes excuses pour mon mauvaise esprit à l'égard d'une prochaine sortie de Hur^W E17
  • # bibliothèques...

    Posté par  . Évalué à 5.

    Bon, mise à part que leur élaboration a pris des plombes, peut-on estimer qu'elles aient finalement atteint un niveau de maturité "parfait"? Et qu'on arrive enfin à battre Cocoa/Carbon/Quartz?

    On rigole de vista et ses lacunes élémentaires en matière de gestion de fichiers,
    E17 ne propose rien - depuis 6, 7 ans qu'il est developpé - et on fait passer la création de ce manque comme La "feature" qui va mobiliser 200 devs alors qu'ils ont accompli des choses beaucoup complexes et novateurs avec les biblio! Ce que je veux dire, c'est un gestionnaire de fichier ne devrait être qu'une formalité pour eux!

    Et en quoi E17 est un "desktop shell", mise à part que ça a été le premier environment à utiliser cette expression?
    • [^] # Re: bibliothèques...

      Posté par  . Évalué à 3.

      être bon pour développer une bibliotthèque ne veut pas dire être bon pour développer des applications.
    • [^] # Re: bibliothèques...

      Posté par  . Évalué à 6.

      Le développement de enlightenment ne se fait pas exactement comme celui de Gnome ou de KDE.
      Les principaux devs de e travaillent sur les bibliothèques et parfois sur des applis mobiles, les entreprises qui aujourd'hui utilisent les EFL c'est sur des environnement mobiles et tactiles.
      C'est pourquoi le dev d'appli "classique" n'avance pas.
  • # De l'orienté objet écrit en... C?

    Posté par  . Évalué à 1.

    deux boîtes à outils légères, orientées objets — restant bien sûr codés en C.

    Ah?
    • [^] # Re: De l'orienté objet écrit en... C?

      Posté par  . Évalué à 8.

      L'orienté objet est un concept, pas une technique ou un outil, tu fais deL'OO avec ce que tu veux, mais plus ou moins facilement.

      Vu que E vise la performance et l'embarqué, il est commun d'utiliser le C pour ça (après, si on peut pas faire mieux avec un langage OO est une autre discussion).
    • [^] # Re: De l'orienté objet écrit en... C?

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

      Bah bien sûr !
      Le concept d'objet est apparut avant... les langages objets !
      Et on en faisait en C il y a un bon moment déjà.
      Le principal outil C permettant de faire de l'orienté objet est le pointeur de fonctions, comme ça tu définis une structure (ton objet) avec des variables, et des méthodes (qui sont en fait des pointeurs sur des fonctions).
      C'est simple et efficace, mais comme un peu tout en C tu fais toute la mayonnaise à la main, à coups de malloc, etc.
      Le garbage collector il se fait à la main, et il faut être bien rigoureux, sinon ça segfaulte. Mais tout se fait pareil en C.

      Yth.
      • [^] # Re: De l'orienté objet écrit en... C?

        Posté par  . Évalué à 7.

        Il ne faut pas non plus éxagérer, faire de l'OO complet en C c'est très lourd, en générale ce qui est fait est de l'OO simplifié, c'est d'ailleurs le cas de EWL et de ETK. C'est surtout pour avoir un aspect héritage entre les widgets.

        les Evas_Smart_Object sont un peu plus complet niveau OO.
      • [^] # Re: De l'orienté objet écrit en... C?

        Posté par  . Évalué à 5.

        Le concept d'objet est apparut avant... les langages objets !

        Le concept Objet à été inventé sur papier d'abord et les premiers langages objets (Simula) sont plus ancien que le C.

        Pour info, le C c'est 1972, Smalltalk aussi. Simula c'est 1960 et quelque chose.
  • # Le point de vue du vieux geek

    Posté par  . Évalué à 10.

    Pour bien se rendre compte de ce que représente enlightenment pour un vieux geek, il faut se souvenir qu'il est apparu dans un monde ou le bureau sous GNU/Linux ressemblait à ça :

    http://stllinux.org/meeting_notes/1996/1219/dtwm.gif
    http://xwinman.org/screenshots/mwm-jmrutt.jpg
    http://xwinman.org/screenshots/fvwm95.gif

    Et que lui il apportait ça :

    http://xwinman.org/screenshots/enl-dfree.jpg


    Maintenant, attendre 8 ans pour avoir la nouvelle version, c'est peut-être un peu beaucoup, ça met la version 18 à peu près à l'époque de ma retraite.
    • [^] # Re: Le point de vue du vieux geek

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

      héhé, je trouve toujours aussi sympa les themes Propaganda du back-ground.
    • [^] # Re: Le point de vue du vieux geek

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

      mouai, y'avais pas que des trucs complètement moches non plus... ;)
      http://www.kde.org/screenshots/images/large/kde2final_1.jpg
      http://www.linuxplanet.com/graphics/screenshots/RpmDrake.png

      Bon par contre, j'ai pas retrouvé (pas cherché beaucoup non plus) de screenshot gnome)

      C'est ptetre pas hyper sexy mais quand même plus sympa que les trois premiers liens je trouve...
      • [^] # Re: Le point de vue du vieux geek

        Posté par  . Évalué à 3.

        Ouais, non... Je me souviens avoir vu tourner E sur une redhat chez un pote et c'est ce qui m'a mis à Linux parce que c'était trop beau, trop gratuit et que la mentalité libre qu'allait avec c'était trop bien.

        Et c'était une RH4.xx (je croyais 4.51mais on dirait que ça existait pas) offerte avec le magazine Login (je crois que ça s'appelait encore Dream) et j'ai installé un magnifique E avec un thème Alien et un autre rouillé... KDE était encore très immature de mémoire. Y'avait vraiment rien de bien folichon sorti de E...
    • [^] # Re: Le point de vue du vieux geek

      Posté par  . Évalué à 4.

      e18 aura un cycle de développement beaucoup plus court. Une des nombreuses raisons de la durée très longue de la sortie de e17 est l'écriture des EFL qu'il utilise (raster était quasiment seul pour les coder). Elles sont là et leur design nous convient. Donc pas besoin de re-écriture complète de ces libs pour e18.
  • # C'est bien...

    Posté par  . Évalué à 7.

    ... mais l'année n'est pas précisée !

Suivre le flux des commentaires

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