Des nouvelles d'Enlightenment DR17

Posté par (page perso) . Modéré par Jaimé Ragnagna.
0
6
mar.
2006
Serveurs d'affichage
Enlightenment DR17 (E17), la nouvelle version du célèbre gestionnaire de fenêtres E16 voit son développement se poursuivre, toujours avec autant de dynamisme.

Après la mise à disposition des bibliothèques graphiques de base (Enlightenment Foundation Libraries ou EFL) il y a plus d'un an, la stabilisation de ce qu'il convient d'appeler maintenant un «desktop shell» s'est poursuivie. E17 en est donc maintenant au développement des applications tierces et du toolkit graphique. Il y a eu beaucoup d'améliorations sur le panneau de configuration qui est maintenant très complet. La traduction comprend actuellement plus de 20 langues.

Le développement souffre un peu de son succès et il devient de plus en plus difficile d'accéder au CVS, le miroir ayant du mal à suivre, l'équipe va installer un nouveau serveur, vous pouvez peut-être aider.

Et qu'en est-il du support de XGL ? La réponse de Rasterman a été très claire : E17 ne suivra pas la voie OpenGL/3D sur le desktop. E17 est prévu pour être léger, rapide et portable (exemple pour l'embarqué [vidéo 2Mo]) et ne veut pas s'attacher à une dépendance aussi forte.

On notera également la sortie de la version 0.4.2 de Elive, le live-CD contenant E16 et E17, basé sur Debian Morphix. Dans le CVS officiel d'E17, nous noterons :
- etk : toolkit graphique pour utiliser rapidement les puissantes EFL.
- exhibit : visualiseur d'images, clone de gqview
- extrackt : pour extraire les fichiers musicaux des CD-ROMs
- entropy : gestionnaire de fichiers avec gestion des accès Samba ou sFTP via...
- evfs : système de fichier virtuel.
- epdf : lecteur de fichier PDF utilisant Poppler.
- enhance : bibliothèque qui permet de convertir les fichiers glade pour les EFL.
- ephoto : permet de faire des présentations de photos en quelques clicks.

Et une vingtaine de modules officiels.

E17 utilise les bibliothèques de Freedesktop (cairo, D-BUS, gstreamer, poppler ou scim) quand c'est possible, ce qui évite de recoder beaucoup de choses.

D'autres logiciels basés sur les EFL commence à apparaître sur le web, surtout des modules :
- dEvian : permet d'afficher des photos ou des fils RSS en boucles
- evolume : pour régler le son
- eloquence : affiche les titres des musiques des lecteurs audios.
- moon : affiche les phases de la Lune

Mais aussi des applications, comme par exemple elitaire, jeux de cartes bien connus ou espik un client IRC.

Les graphistes ne sont pas en reste avec de nouveaux thèmes et fonds d'écran.

Des binaires sont disponibles pour la plupart des distributions et également pour Slackware).

Aller plus loin

  • # orthographe

    Posté par . Évalué à 4.

    s/Et quant est-il/Et qu'en est-il
    • [^] # Re: orthographe

      Posté par . Évalué à -3.

      C'est un effet de mode ces réponse sed ? Ou c'est permanent sur linuxfr ?
  • # Et la configuration ?

    Posté par (page perso) . Évalué à 4.

    Quand j'avais eu le temps, j'avasi essayé e17 -> c'est devenu pendant 2 mois mon wm principal (sous gentoo).
    Et puis voila qu'un jour... j'essaye de changer un peu la barre qui ressemble au dock de Mac Os X (engage ?).
    C'est toujours aussi simple de créer des icones et des boutons avec les bonliens qui vont bien ou c'est toujours aussi galère ?

    C'est le seul truc qui m'embetait. Parce que sinon, e17 c t vraiment du bonheur.

    Si quelqu'un a un paquet d'icones pour mandriva, je suis preneur.
    • [^] # Re: Et la configuration ?

      Posté par (page perso) . Évalué à 10.

      C'est toujours aussi simple de créer des icones et des boutons avec les bonliens qui vont bien ou c'est toujours aussi galère ?


      Click droit -> configuration -> eap editor
      Tu choisis l'icone, le nom de l'appli et l'executable. Quand tu enregistres, ca va directement ou il faut dans ${HOME}/.e/e/applications/all
      Pour 'engage', tu mets les noms des EAPs dans ${HOME}/.e/e/applications/engage/.order

      $ cat ${HOME}/.e/e/applications/engage/.order
      xterm.eap
      firefox.eap
      thunderbird.eap
      evidence.eap
      wmcoincoin.eap
      gimp.eap
      xine.eap
      xmms.eap

      (Par exemple)

      Il y a maintenant encore plus simple, e17genmenu est passe en phase de test, il permet de creer les menus et les EAPs automatiquement:

      Sourceforge est encore a la ramasse, alors je me permet de recopier le mail de David Seikel qui explique comment generer automatiquement les menus sous E17:

      The new menu generator is ready for testing. It's not ready for prime
      time, but it would be helpful to get it tested on a variety of boxen.

      The test procedure is this -

      Move your ~/.e/e/applications/favorite to a safe place, then nuke it.

      Optionally do the same for ~/.e/e/applications/all.

      Go to e17/apps/e_utils/src/bin/e17genmenu (yes I know it's a bit
      strange having a separate tree there, it's a temporary thing, blame
      devilhorns).

      Do the usual autofoo three step.

      e17genmenu --fdo

      After that has finished running, E will by unresponsive for a few
      minutes. This is a known issue with the eap cache regeneration.

      This will generate E17 menus based on whatever freedesktop.org menus
      you have installed in your system. It should find all the things that
      are supposed to be in your fdo menus. Not everything will have a proper
      icon, and there is not currently a method of selecting the fdo icon
      theme you want to use. Also, not all the re arranging, categorising,
      and deletions/hiding is being done properly yet. There are still a few
      big parts of the spec being ignored.

      Send me the last line that is output (the one with the timing stats)
      and let me know what distro and CPU speed you tested it on.

      If there are major parts of your fdo menus that have not been found,
      please find out what directories the .desktop files are in and let me
      know what they are. Same applies if there are .menu files being
      ignored.

      Restore your original eaps and menus when you have finished playing
      with the fdo menus.


      Pour les EAPs, il y en avait avant sur get-e.org mais pour une raison inconnue, ils ont ete retires. Reste Google...
      • [^] # Re: Et la configuration ?

        Posté par . Évalué à 2.

        Pour 'engage', tu mets les noms des EAPs dans ${HOME}/.e/e/applications/engage/.order


        Pourquoi ?
        entangle fonctionne pas chez toi ??

        e17genmenu --fdo


        Je vais voir ça de plus près...
        • [^] # Re: Et la configuration ?

          Posté par (page perso) . Évalué à 2.

          Pourquoi ?
          entangle fonctionne pas chez toi ??


          Au temps pour moi, a force de restaurer mes fichiers de configuration a la main entre chaque periode de test, je finis par oublier qu'il y a des manieres beaucoup plus simple :-)

          Ne pas oublier de creer le dossier engage (ce n'est pas automatique) et en cas de mise a jour, c'est effectivement plus rapide de copier les fichiers sauvegardes directement dans le ${HOME}.
      • [^] # Re: Et la configuration ?

        Posté par (page perso) . Évalué à 1.

        On peut aussi créer l'EAP d'un programme déjà lancé en faisant :
        => clic sur l'icone de la barre de titre || clic droit sur la barre de titre || alt + clic droit sur la fenêtre (choisir à votre convenance).
        => Create Icon (Edit Icon si elle est déjà crée, pour la modifier).
        => Et là on a plus qu'à renseigner les champs, le fichier .eap est créé de la même manière, et il ne reste plus qu'à renseigner les .order qui vont bien, ou utiliser entangle. :)

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

  • # mici

    Posté par . Évalué à 9.

    Je profite de cette dépêche E17 pour remercier l'auteur (ngc891) pour ces excellents paquets slackware ( http://slacke17.sourceforge.net/index.html ) surtout qu'une nouvelle version vient de sortir le 5 mars 2006.

    [Ma vie]Ca me de profiter de e17 sur mon vieux portable (PIII 800Mhz) et ca, c'est très sympa à lui [/Mavie]
  • # Packets RPM

    Posté par . Évalué à 7.

    A noter les packets RPM pour Mandriva et Fedora...

    http://sps.nus.edu.sg/~didierbe

    Testé sur une Mandriva 2006, ils tournent super bien, et ils sont mis a jours tres regulierement.

    J'utilise e17 depuis 6-7 mois maintenant, et je dois avouer que c'est de loin (malgré les quelques bugs qui trainent encore, mais ils ne faut pas oublier qu'il est toujours en developement) le meilleur gestionnaire de fenetres que j'ai eu l'occasion d'essayer !
  • # Enlightenment et l'embarqué

    Posté par (page perso) . Évalué à 3.

    Je suis très friant d'outils et de bibliothèques pour l'embarqué.
    C'est un peu mon dada. Malgrés mes recherches sous Google je n'ai pas vraiment trouvé d'informations pertinantes sur Enlightenment et l'utilisation sur un environnement "embarqué".
    Quelqu'un ici connaît peut-être un lien intéressant à ce sujet ?
    Les infos que je cherche sont relativement basiques:
    - l'occupation mémoire
    - les ressources CPU nécessaires
    - les librairies nécessaires/optionnelles.

    Bref la base quoi.
    • [^] # Re: Enlightenment et l'embarqué

      Posté par (page perso) . Évalué à 4.

      Le mail le plus recent de Rasterman a ce sujet:

      http://sourceforge.net/mailarchive/forum.php?thread_id=97338(...)

      Bref, beaucoup de choses possibles mais aussi beaucoup de chose a faire. Il y a pas mal d'info sur le site de Raster, il faut creuser (il y a aussi un bench) :
      http://www.rasterman.com/index.php?page=News

      Dans tous les cas, E17 reste encore un vaste terrain de decouverte. De bonnes bases ont ete posees, maintenant il faut des developpeurs qui n'ont pas peur du vide.

      Je te conseille donc :
      1) De lire la documentation sur les EFL et de jouer avec http://www.get-e.org/EFL_User_Guide/English/
      2) De rejoindre la communaute des developpeurs pour faire partager tes idees http://www.edevelop.org/
      • [^] # Re: Enlightenment et l'embarqué

        Posté par . Évalué à 3.

        Si l'EFL (Enlightenment Foundation Libraries) est taillé pour l'embarqué, ne serait-il pas possible de pouvoir l'utiliser/l'adapter pour créer un véritable Boot Graphique et tout ce qui va avec. Cela trancherait vraiment avec les initiatives des pseudos boots semi graphique qui existe actuellement, non?

        --
        “Le seul crime de la pensée est de penser pour les autres, en leurs confisquant la possibilité de penser par eux-mêmes!”
        • [^] # Re: Enlightenment et l'embarqué

          Posté par . Évalué à 7.

          sur mon portable j'ai un hack ds mon initrd qui lance une petite anim avec evas_fb et edje pendant le boot.
          Et tout ca avant init (ca apparait presque instantanement apres grub) .
          Si quelqu'un se met serieusement sur projet de boot graphique ca pourrait donner quelque chose de tres interressant.
          • [^] # Re: Enlightenment et l'embarqué

            Posté par . Évalué à 4.

            Hmmm... Je serais bien intéressé pour avoir les modifications que tu as apporté pour mettre en place ce petit hack (et je pense que je ne suis pas le seul ;-) ) !
            • [^] # Re: Enlightenment et l'embarqué

              Posté par . Évalué à 3.

              j'ai compile ecore evas edje avec le strict minimum(pas de X/gl et autres ..). J'ai ecrit un prog tout con qui se contente de charger un fichier edje. J'ai un fihcier edje avec un bg et une barre de progression completement fictive :).
              Tout cela est balance dans le initrd. le splash doit apparaitre le plus tot possible donc dans mon noyau presque tout est en module, surtout ce satane module ide qui prend une eternite a s'initialiser.

              J'ai fait tout ca pendant un week-end "Entrance en moins de 10s".
              L'objectif n'a pas ete atteins.
              Le module ide prend 5/6s a s'initialiser et X prend 6/7s a demarrer.
              Hacker le kernel et mon driver X c'est un peu au dessus de mes capacites alors j'en suis a 14/15s...

              J'ai pu me debarrasser ce cette affreuse grille qu'affiche X au demarrage. J'ai un ecran noir mais j'aurais preferer une image.
              Et puis pour l'horible grosse croix je m'arrange pour utiliser une fonte
              qui n'a pas ce symbole donc j'ai une escpece de petit point blanc a la place...
              Si quelqu'un a de meilleures solutions ...
  • # Le Vaporware le plus célèbre (et le plus ancien)

    Posté par (page perso) . Évalué à 9.

    Le développement souffre un peu de son succès et il devient de plus en plus difficile d'accéder au CVS, le miroir ayant du mal à suivre, l'équipe va installer un nouveau serveur, vous pouvez peut-être aider.

    Autant taper là où ça fait mal : je sais bien que ce type de ressources est aussi le nerf de la guerre mais leur service CVS aurait moins de mal à suivre (et le développement n'en "pâtirait" pas) si Rasterman consentait à publier des versions plus régulièrement.
    Mais non, c'était sans compter sur son perfectionnisme acharné. Je sais de quoi je parle : je dois me battre tous les jours pour rester efficace comme disent les décideurs pressés qui nous emploient...
    La différence entre lui et moi est qu'il n'a, en principe, personne à qui rendre des comptes. Personne ? Si: ses propres utilisateurs et premiers supporters de son projet. Le problème est que le cycle de développement vient de dépasser celui de Debian et ce n'est pas rien ! Même Nagios 2.0 est sorti !
    Bref: le perfectionnisme, c'est bien. Mais l'abus, ce sera toujours mal.
    • [^] # Re: Le Vaporware le plus célèbre (et le plus ancien)

      Posté par (page perso) . Évalué à 5.

      Plus celebre que Duke Nukem Forever?
    • [^] # Re: Le Vaporware le plus célèbre (et le plus ancien)

      Posté par (page perso) . Évalué à 5.

      D'un autre côté, pour E17 ils ont tout repris a zero, et l'ont fait proprement c'est à dire d'abord des bibliothèques de base qui fournissent tout le nécéssaire et ensuite on construit dessus le reste de manière solide.

      Donc publier des versions intermediaires d'un truc que l'on a pas commencé à écrire c'est pas évident...
      Pour les EFL (les bibliothèques en question) ca fait un bout de temps qu'elles sont sorties.
      Et pour E17 il y a eu des annonces de son évolution quand ils ont commencé à bosser dessus.

      Donc soit tu veux tester un truc pas finis qui change tout le temps et où à chaque mise à jours tu dois mettre les mains dans le cambouis et donc tu te colles le cvs. Soit tu restes sur la version officielle de enlightenment et tu utilise la version 16.7.1 qui a d'ailleur continué d'évoluer pendant le developpement de la version 17.

      Rasterman est perfectioniste, Ok. Mais il est aussi respectueux de ses utilisateurs, E17 sera la version officielle quand elle sera suffisament stable et fonctionelle pour remplacer E16.
      Le problème est toujours le même, si on attend d'avoir terminé sont boulot pour le sortir, on se fait critiquer par ce qu'on est trop lent, et si on le sort plus tôt on se fait critiquer par ce que c'est pas stable, que telle fonction ne marche pas, qu'il manque ceci...

      En plus si tu veux tester E17, il y a (depuis les premiere version utilisable de E17) des paquets disponiblent pour la majoritée des distributions, donc tu n'a même pas réellement besoin d'utiliser le cvs.
  • # XGL ?

    Posté par (page perso) . Évalué à 9.

    Je pensais que raster était aussi un artiste, ..., que le but de E était de faire un bureau à la fois rapide et agréable voire fun.

    Pourquoi ne pas utiliser l'accélaration 3D ?

    Outre le fait que je trouve sa réponse plutôt agressive (écrivé le vous même,...), elle est surtout courte. En effet, argumenter que c'est la dépendance à l'OpenGL qui pose problème, me paraît plutôt léger (options de compilation, ...). Surtout que dans le même temps on nous parle des bibliothèques de Freedesktop (cairo, D-BUS, gstreamer, poppler ou scim).

    A-t-il l'intention de faire lui même toute la partie 3D (drivers, biblios) ?
    Peut-être qu'il veut prendre sa retraire concernant les gestionnaires de fenêtres ?

    Ce qui me parait dommage est que Enlightenment a atteint la maturité au moment même où il est en quelque sorte déjà dépassé (sauf pour l'embarqué).
    • [^] # Re: XGL ?

      Posté par . Évalué à 2.

      De plus, je crois me rappeler une très vieille interview de rasterman dans LMF (un numéro dédié à e17 je crois, justement), dans laquelle il racontait qu'il était très intéressé par les possibilités offertes par les cartes 3D pour les effets d'e17.
      • [^] # Re: XGL ?

        Posté par (page perso) . Évalué à 3.

        Et c'est toujours le cas en ce qui concerne Evas : "Evas is a hardware-accelerated canvas API for X-Windows". Donc, certaines des EFL repose sur une accélération matérielle et E17 repose sur les EFL.

        Je pense que ce qu'il faut comprendre c'est qu'E17 ne reposera jamais sur OpenGL comme c'est le cas avec les EyesCandy comme compiz.

        On pourrait voir cela comme une utilisation raisonnée des fonctionnalités 3D des adaptateurs graphiques modernes en ce qui concerne le desktop.

        Je vais peut-être lacher mon WindowMaker pour revenir à E comme dans le temps finalement...
        • [^] # Re: XGL ?

          Posté par (page perso) . Évalué à 3.

          Utilisation raisonnée ne veux pas dire non-utilisation. Le problème, c'est qu'il existe peu de cartes performantes avec des pilotes libres.
          J'imagine qu'il n'est pas très compliqué de faire une API de rendu qui puisse se brancher sur différents backend (accélérés materiellement ou pas).
          C'est bizarre cette obsession à dénigrer l'utlisation de l'accélération matérielle des cartes graphique. Je n'ai jamais entendu de telles réticences pour les jeux d'instructions qui sont régulièrement rajoutés dans les processeurs. L'API OpenGL semble bien plus stable (reprenez-moi si je me trompe).
          • [^] # Re: XGL ?

            Posté par . Évalué à 2.

            C'est bizarre cette obsession à dénigrer l'utlisation de l'accélération matérielle des cartes graphique.

            Ce n'est pas bizarre, c'est simplement réaliste. Toutes les tentavies pour faire de l'accélération matérielle patinent sur les problèmes de drivers. Tant que l'on aura pas de drivers libre, le tout software est une bonne solution.
    • [^] # Re: XGL ?

      Posté par . Évalué à 3.

      Non je ne pense pas qu'il soit déjà dépassé. Et puis ce qui importe, dans un projet de cette envergure, ce sont les bases. Or, si j'ai bien compris, ces bases sont justement très bien travaillées et pensées (quelqu'un peut-il [con|in]firmer ?) pour que le système puisse évoluer sans devenir aussi gourmand que les systèmes actuels.

      Ce point est un énorme avantage pour Enlightenment, car il permet aux ordinateurs un peu anciens (ou aux systèmes embarqués, comme tu le précise bien) de se doter d'un bureau esthétique et convivial, et aux ordinateur plus récent d'en garder sous le coude pour les applications elles-même.

      Bon après, le non-support d'un bureau sous XGL, je trouve aussi que ca fait un peu marginal et rétrograde. Mais bon, faut pas non plus oublier qu'XGL n'est pas (encore) la panacée du bureau 3D. Une surprise est-elle en ébauche ?...
      • [^] # Re: XGL ?

        Posté par . Évalué à 4.

        A propos des nouvelles possibilites de X.
        Il faut bien avouer que tout cela n'est pas encore vraiment mature et encore instable.
        Encore plus important, ca ne profite qu'a une minorite d'utilisateurs possedant la bonne carte graphique.
        Donc compte tenu du peu de ressources que possede le projet(c'est tellement un euphemisme ...), le support de ces fonctionalites ne peux pas etre une priorite.
        Le but de Enlightenment est de pouvoir etre utilisable sur de l'embarque comme sur les machines les plus recentes.
        En ce moment, le projet se concentre sur le premier objectif.
        Les projets comme Xgl ou composite interressent beaucoup Raster meme si il peut parfois paraitre irrite.
        C'est parce qu'il en a marre qu'on lui en parle a longueur de journeee !!! :).
        L'objectif principal pour le moment est de releaser e17. Il y a une TODO list, elle doit etre videe.
        Ensuite, Raster reflechira a un moyen d'integrer les nouvelles technologies harmonieusement sans laisser les anciennes machines et les devices avec peu de ressources sur le cote de la route.

        Concernant le dev de e17 debian duke gnagnagna ... :)
        Raster fait regulierement des sortes de pre release. 0.16.999.x. en ce moment x=23.
        Seulement il ne supporte pas le systeme de release de sf.
        rendez-vous sur http://enlightenment.freedesktop.org .
        • [^] # Re: XGL ?

          Posté par . Évalué à -1.

          L'objectif principal pour le moment est de releaser e17. Il y a une TODO list, elle doit etre videe.


          Non mais seriously...
        • [^] # Re: XGL ?

          Posté par (page perso) . Évalué à 4.

          Les projets comme Xgl ou composite interressent beaucoup Raster meme si il peut parfois paraitre irrite.


          Ce qui semble surtout l'irriter c'est qu'un certain nombre de personnes voient venir XGL, compiz, etc... et estiment que cela devrait avoir un rapport avec E17. Seulement voilà, E17 n'est pas un desktop 3D et ne le sera jamais.

          Je comprend parfaitement qu'à force de le répéter, Rasterman finisse pas être un peu irrité.
    • [^] # Re: XGL ?

      Posté par . Évalué à 6.

      Pourquoi ne pas utiliser l'accélaration 3D ?
      Ton voeu est exaucé, evas utilise déjà OpenGL, depuis le début !

      J'avais regardé le code il y a quelques temps (quelques années en fait... ;) et il était rempli de switch/case avec différentes méthodes de rendu (xlib, opengl, render, imlib, et je me souviens plus des 2 autres).

      argumenter que c'est la dépendance à l'OpenGL qui pose problème, me paraît plutôt léger
      L'équipe ne veut probablement pas être _dépendante_ d'opengl, i.e. ça doit rester optionnel pour marcher vite même là où il n'y a pas d'accélération (ou de drivers libres ;), mais ça ne veut pas dire qu'il ne l'utilise pas. Au contraire, evas a été plutôt pionnier en ce sens (bien avant xgl, QT/Arthur et Cairo !) alors ça me paraît un peu fort qu'on lui reproche de ne pas avoir une fonctionnalité qu'il a été le premier (ou presque) à implémenter !

      A-t-il l'intention de faire lui même toute la partie 3D (drivers, biblios) ?
      Huh ???

      e17 est un environnement 2D. Même quand il utilise opengl, ce n'est pas pour de la "vraie" 3D mais pour tirer parti de l'accélération matérielle pour les effets graphiques (blending, etc...). Je ne vois pas en quoi des fonctions 3D seraient systématiquement nécessaires (ah, si, c'est vrai que xgl a une killer feature avec son cube à 12 faces ! :).

      Ce qui me parait dommage est que Enlightenment a atteint la maturité au moment même où il est en quelque sorte déjà dépassé (sauf pour l'embarqué).
      Je trouve que tu vas un peu vite en besogne. Attends de voir (ou essaies-le).

      Par contre, il semble bien que cairo et evas se fassent un peu concurrence (apparemment y'a dû avoir des trolls sur les ML au sujet de la duplication d'efforts inutile, de cairo qui reste très lent, etc...). D'après ce que j'ai cru comprendre cairo serait plus "bas niveau", sans scene graph...
      • [^] # Re: XGL ?

        Posté par . Évalué à 2.

        e17 est un environnement 2D. Même quand il utilise opengl, ce n'est pas pour de la "vraie" 3D mais pour tirer parti de l'accélération matérielle pour les effets graphiques (blending, etc...). Je ne vois pas en quoi des fonctions 3D seraient systématiquement nécessaires (ah, si, c'est vrai que xgl a une killer feature avec son cube à 12 faces ! :).

        Justement ! Ces fonctions ne sont pas nécessaires maintenant mais qu'en est il des futures fonctionnalités des gros du domaine (KDE, Gnome, Windows et bientôt le bureau XGL de SuSe) ? Il vaut mieux essayer de prévoir plutôt que de rattraper.

        Et dans le cas des bureaux graphiques (on pourra également se poser la question de ce qu'est un bureau graphique, comme l'équipe d'Enlightenment le propose sur son site), dans le cas des bureaux graphiques, disais-je, il faudrait essayer de voir comment tirer parti de cette 3e dimension que nous offrent certaines librairies. Plus pour faire des effets graphiques plaisant comme la déformation de fenetres ou l'alpha blending (qui sont déjà des eye-candies appréciables) mais pour améliorer le champ visuel du bureau, réorganiser l'espace de travail en différents blocs, et que sais-je encore...

        Bien entendu, ce ne sont que des idées jetées pele-mele, mais elles permettraient d'amener une mini révolution sur l'approche que nous avons d'un 'bureau' standard. Bon, après faut voir sur quel matos une telle utopie pourrait tourner, et combien d'années ca prendrait a implémenter. Hum...
        • [^] # Re: XGL ?

          Posté par . Évalué à 3.

          Il y a une différence entre utiliser les capacités offertes par du matériel conçu pour de la 3D pour afficher son bureau (comme E17) et utiliser le matériel pour rajouter une 3ème dimension ou afficher des fenêtres magiques qui tournicotent.

          Enlightenment a pour but (cf http://enlightenment.org/Enlightenment/DR17/ ) d'être rapide et rétro-compatible avec les serveurs X anciens. Il permet d'utiliser les capacités du matos moderne quand il est dispo (pour pas gâcher), mais garde la métaphore du desktop à laquelle on est habitué, en rendant juste le tout plus joli.

          Rajouter une 3e dimension permet de tester de nouvelles approches rendues possibles par le matériel, avec la possibilité de faire évoluer la métaphore actuellement la plus répandue; donc à terme dépasser les fenêtres magiques rotozoomées et les desktops scotchés sur des cubes. Dans ce cas par contre on rend les fonctionnalités dépendantes de la présence d'une carte 3D.

          Entre les deux il y a juste une différence de vision: utiliser le matériel s'il est présent pour ne pas gâcher de la puissance, ou penser un nouveau bureau rendu possible par ce matériel.
          • [^] # Re: XGL ?

            Posté par . Évalué à 1.

            Et il faut pas se leurer, le seul truc vraiment interessant de compiz c'est exposé qui apporte vraiment une vraie fonctionalité utile.

            Enlightenment aurait tord de s'en priver.

            Que son code bouge quand on bouge la fenetre on s'en fou que ça te pose un probleme tellement c'est gadget. C'est comme si c'était pas là. Ca apporte pas plus ni moins que de belles icones ou des ombres dans les menus.
      • [^] # Re: XGL ?

        Posté par . Évalué à 2.

        Ton voeu est exaucé, evas utilise déjà OpenGL, depuis le début !


        Effectivement. De plus, contrairement aux solutions actuelles comme Xgl et compagnie, evas utilise OpenGL pour le dessin de toutes les primitives, et pas seulement pour rajouter un effet 3D à un pixmap construit en software sans accélération. Ce qui est, selon moi, le meilleur moyen de tirer profit de l'accélération matérielle.

        En ce qui concerne cairo, il me semble qu'il était question d'étudier la faisabilité de mettre un back-end cairo à evas, mais je ne sais pas si ça a été implémenté (on en trouve des traces sur le cvs).
        • [^] # Re: XGL ?

          Posté par . Évalué à 2.

          ca a ete implemente, mais ca n'est plus supporte (en particulier par rapport aux nouvelles versions de cairo). De plus, cairo est lent. Tres lent.
  • # Ils font de bons choix ...

    Posté par . Évalué à 1.

    C'est totalement subjectif, mais je trouve leur choix plutôt bons :

    E17 est prévu pour être léger, rapide et portable

    Très bien, j'en ai marre de voir des GNOME ou des KDE ramer comme pas permis. Plus de 5 secondes pour ouvrir un terminal sur une bonne machine, c'est trop !

    ne veut pas s'attacher à une dépendance aussi forte

    Encore mieux. Vu les commentaires précédents, la porte n'est pas fermée à OpenGL.

    Seul petit problème, Enlightenment utilise son propre toolkit. Et je ne dis pas cela contre E, mais contre les autres : c'est bien dommage que GTK/QT/Motif et les autres soient majoritaires, car j'ai toujours trouvé le toolkit d'Enlightenment un brin plus réactif. Sans parler de l'adaptation aux couleurs personnalisées, où il est souvent impossible de profiter des thèmes en inverse vidéo (fond foncé, texte clair) : E gère cela très bien.

    Dans un monde idéal, une interface commune aux toolkits permettrait d'en changer, tout comme on change de Window Manager ou de serveur X. Vivement des moteurs de thèmes pour GTK et QT qui utilisent le toolkit d'Enlightenment ! On se rapprocherait un peu plus près de l'idéal sans recoder la moitié des toolkits.

    Ce commentaire n'est pas destiné à relancer le troll GTK/QT, mais d'appeler à la comparaison entre les deux "gros" et E.
    • [^] # Re: Ils font de bons choix ...

      Posté par . Évalué à 2.

      Je suis d'accord, les choix actuels me paraissent ce qu'il y a de mieux par rapport à la philosophie d'Enlightenment. Pour ma part l'utilisation de xgl m'apporterais pas tellemenent dans l'utilisation de mon shell et la programmation.

      Bref pour mon utilisation je trouve qu'il est très agréable et léger, c'est pour cela que je l'ai adopté.

      Et de plus, est-il utile d'avoir des fenetres qui bougent dans tout les sens quand je les déplacent commes avec les divers vidéo que on voit avec xgl?
      Avoir mon code qui se dandine dans mon terminal quand je le change de place, l'intéret me parait limité. Peut-être existe-t-il des moyens d'utiliser ces technologies pour améliorer la convivialité des wm. Mais voyant pas ex les kde actuels, et la lourdeur de ce que c'est devenu... personnellement je ne vois pas d'un exellent oeuil l'intégratoion d'opengl dans les rendus.
      Enfin je ne suis pas absolument contre non plus, mais à condition que ce soit utilisé avec raison. Par ex avec masosX où les fenetres sont dessinée en vectoriel les perfs sont plutot corrects comparé aux divers bureau dessiné avec des pixerls... et ca procure une certaine qualité de rendu sans pour autant tourner à la démo technologique inutilisable.

      Etant donné la difficulté à récupérer le CVS j'ai fait un petit snapshot que je met à disposition pour ceux que ca intéresse=> http://s140485254.onlinehome.fr/e17_snapshot.tar.gz
      • [^] # Re: Ils font de bons choix ...

        Posté par . Évalué à 3.

        ...Enfin je ne suis pas absolument contre non plus, mais à condition que ce soit utilisé avec raison. Par ex avec masosX ... ca procure une certaine qualité de rendu sans pour autant tourner à la démo technologique inutilisable.


        Ca tombe bien, habituellement, la démo technologique, c'est souvent avant l'intégration. Non ?
        Les effets sont justement exagérés pour montrer les possibilités et inspirer ceux qui vont les exploiter. (Entretemps, ca satisfait ceux qui aiment la démesure et le fun, et ça, il y en aura touours...)
        Xgl en est justement à cette phase. Laisse le temps aux bureaux pour en intégrer les possibilités...
    • [^] # Re: Ils font de bons choix ...

      Posté par (page perso) . Évalué à 1.

      > Plus de 5 secondes pour ouvrir un terminal sur une bonne machine, > c'est trop

      Perso, chez moi ca met 5 secondes avec un processeur pris a 95% ...

      Ste
  • # a propos de epdf

    Posté par . Évalué à 4.

    epdf n'est pas un lecteur de fichier pdf, mais une interface pour poppler (http://poppler.freedesktop.org/) qui affiche le contenu d'un fichier pdf dans un objet de Evas.

    le viewer de pdf est en cours d'ecriture. Il a un tres joli nom : Exorcist

    nanmoins, il y a des petites prog fournis avec epdf, pour le tester, et qui peuvent servir de lecteur basique de fichiers pdf, si on a etk ou ewl.

Suivre le flux des commentaires

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