EFL atteint le stade de preview release

Posté par . Modéré par Pascal Terjan.
0
5
août
2004
Serveurs d'affichage
Après plusieurs années de développement, puis leur réécriture complète débutée il y a environ un an, les Enlightenment Foundation Library viennent enfin d'entrer en Preview Release.
Ces bibliothèques sont à la base de la prochaine version du gestionnaire de fenêtres Enlightenment E17.

NdM : merci à Fanf pour avoir également proposé cette nouvelle. Bien que cette annonce ne concerne que les fondations d'Enlightenment, elle permet d'espérer le développement rapide de la nouvelle mouture du plus design des gestionnaires de fenêtres.

Le projet Enlightenment est connu pour la qualité de son Window Manager E, mais moins pour la puissance des outils conçus pour son développement. Les versions précédentes d'Enlightenment étaient basées sur la bibliothèque imlib, réputée alors pour sa flexibilité et sa rapidité.
Lors de son développement préliminaire, Enlightenment 0.17 (aka E17) a vu ses fonctionnalités améliorées et augmentées de telle sorte que de l'avis de ses auteurs, son statut est passé de celui de « Window Manager » à celui de « Desktop Shell ». Cette dénomination est justifiée par les nouvelles capacités d'interaction avec le système offertes par cet environnement graphique.
Durant sa phase de développement, les bibliothèques d'E17 ont été totalement réécrites, et alors que l'on pensait la sortie du Desktop Shell relativement proche, Rasterman, le leader du projet, a décidé de tout remettre à plat, considérant que l'architecture globale des fondations pouvait être améliorée.

Cette remise en question a donné naissance aux Enlightenment Foundation Library, désormais composées de (traduction sommaire):

  • Ecore, une couche d'abstraction pour Xwindow et les évènements ;

  • Edb, bibliothèque conçue sur Berkeley DB en charge de faciliter l'accès et la portabilité de données relatives à E ;

  • Edje, en charge des tâches graphiques complexes ;

  • Eet, bibliothèque dédiée à la prise en charge des opérations d'archivage et de compression ;

  • Embryo, langage de script basé sur "Small Language" ;

  • Emotion, offrant des capacités de prise en charge de la video basée sur libxine ;

  • Epeg, pour la création ultra rapide de vignettes au format jpeg ;

  • Evas API pour Xwindow capable d'offrir des capacités d'affichage supportant l'accélération hardware, l'alpha-blending, etc ;

  • Imlib2, le successeur d'Imlib pour la manipulation d'images.

Aller plus loin

  • # ELF rentrera-t-il dans la danse?

    Posté par . Évalué à -4.

    Devrions nous à présent le décrire comme un environnement de bureau plutôt qu'un simple gestionnaire de fenêtres?

    ça donnerait du sang neuf de plus
    Gnome s'barre en vrille et est lourdeau pas possible
    KDE3.2... moué j'n'ai rien contre lui il m'a même fort étonné il y a encore peu mais bon Qt, caî pa très bO (l'argument quoi! héhé)

    E17, c'est beau, simple, et super pratique mais pas encore aussi complet
    • [^] # Re: ELF rentrera-t-il dans la danse?

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

      sans entrer dans le gros troll proposé, j'en profite pour demander des éclaircissements sur la différence que tu fais entre un
      "environnement de bureau"
      et un
      "gestionnaire de fenêtre"

      car je vois très mal la différence :/
      • [^] # Re: ELF rentrera-t-il dans la danse?

        Posté par . Évalué à 5.

        D'après ce que je sais un gestionnaire de fenêtre se contente de gérer les fenêtres (héhé) rien de plus alors qu'un gestionnaire de bureau intègre plusieurs outils notamment un gestionnaire de fichier...
        • [^] # Re: ELF rentrera-t-il dans la danse?

          Posté par . Évalué à 4.

          Antoine t'a répondu.

          Mais loin de moi l'idée de "troller" comme tu dis, en plus vous me saouler avec ce mot.
          Non c'est une opinion nourrit par quelques expériences perso, ceci dit je ne nie pas que le problème puisse venir de moi...

          Je voulais juste soulevé l'idée que E17 pourrait entrer, disons, dans un niveau supérieur tel celui de l'environnements de bureau ou desktop s'tu veux vu qu'il intégre à présent plus d'outils, qu'il dispose maintenant de sa propre interface utilisateur (j'utilise peut-être le mauvais mot là), d'un gestionnaire de fichier original etc etc.. .


          qu'est-ce que vous en pensez?
          • [^] # Re: ELF rentrera-t-il dans la danse?

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

            Il suffit d'aller voir dans la FAQ :

            What exactly do you mean by "E 17 will become a desktop shell?"
            It means that E 17 combines features of a window manager and a file manager. It will provide nicely integrated GUI elements for managing your desktop elements, both files and windows. It does *not* mean that E 17 is another application framework like Gnome and KDE.


            Donc E va devenir un gestionnaire de fenêtre, avec un gestionnaire de fichier intégré. Et il fournira en plus tout ce qu'il faut pour construire des interface qui s'integrerons parfaitement à l'environement.

            Il faut entendre gestion de fichier au sens large, car il integrera notament un visualiseur d'image (qui est déjà fonctionel et magnifique)

            Le tout etant themable à l'extreme.
            • [^] # Re: ELF rentrera-t-il dans la danse?

              Posté par . Évalué à 0.

              Mais ce n'est pas un "framework" (plate-forme de développement) comme Gnome ou KDE. Donc les "grosses" applis seront toujours faites avec Gnome et/ou KDE. Son "concurrent" le plus proche est XFCE.
              • [^] # Re: ELF rentrera-t-il dans la danse?

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

                J'aimerais que tu details ta notion de framework?

                car pour avoir programmé avec les EFL un petit peu, tu n'utilises que les EFL (ecore evenement awl/edje/evas pour l'affichage,imlib2 pour le traitement d'image si pas possible directement pas evas...)pour développer, tout comme je le ferais avec gtk/gnome ou qt/kde.

                Les EFL, c'est vraiment un framework pour moi, donc j'aimerais connaître ta définition (j'ai cherché sur wikipedia us, et comme la reponse n'avais rien à voir, je ne mettrait même pas le liens ici)
                • [^] # Re: ELF rentrera-t-il dans la danse?

                  Posté par . Évalué à -1.

                  > J'aimerais que tu details ta notion de framework?

                  J'ai parlé de "grosses" applis. Tu peux toujours dire qu'on peut faire de "grosses" applis avec la libc et la libX11 mais je te souhaites du courage.

                  Les possibilités fournis par Gnome n'ont rien à voir avec E même si les EFL peuvent être suffisantes pour beaucoup d'applis.

                  > c'est vraiment un framework pour moi

                  Comme la libc. Mais j'ai parlé de grosses applis.
                  • [^] # Re: ELF rentrera-t-il dans la danse?

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

                    bon alors quitte à être chiant, qu'appels tu "grosse appli" ?

                    Un gimp, un mplayer, un filemanager, c'est pas hyper compliqé a faire avec ces libs.
                    Un navigateur basé sur gecko ne me semble pas plus hors de portée...

                    En fait je vais pauser la question autrement:

                    Tu retrouves tout ce qu'il faut pour faire des applis d'un taille conséquente (y compris une base de données optimisée pour les settings et ce genre de choses), ca va du timer au widgets standards, à la gestion de thèmes, de font, d'image, la compression, en passant par les listes chainées et au canevas... tu veux quoi de si merveilleux qui est uniquement dans kde et gnome pour toi ?
                    • [^] # Re: ELF rentrera-t-il dans la danse?

                      Posté par . Évalué à -2.

                      > tu veux quoi de si merveilleux qui est uniquement dans kde et gnome pour toi ?

                      Pour les mêmes raisons que les nombreux développeurs gnome et kde :
                      - Ça bouffe de la place mémoire et ça utilise mon CPU dernier cri pour rien et j'aime ça.
                      - Ça me donne un côté décideur pressé qui fait craquer les filles.
                • [^] # Re: ELF rentrera-t-il dans la danse?

                  Posté par . Évalué à 1.

                  je partage l'avis de Temsa.
                  On peut considèrer les EFL comme un framework, dés lors...

                  ça va être le pied, et on va avoir des themes terribles, optimisés et surtout facilement accèssibles pour le graphiste non codeur. Non pas que ça ne soit pas possible avec GTK ou QT, mais ça reste quand même chaud de faire un theme en natif...


                  +
    • [^] # Re: ELF rentrera-t-il dans la danse?

      Posté par . Évalué à -1.

      > Gnome s'barre en vrille et est lourdeau pas possible

      Rigolo. Il y a quelques années (j'ai plus testé E depuis un bon moment) c'était Enlightenment qui était "lourdeau pas possible" alors qu'il ne fesait "que" gestionnaire de fenêtre.

      Pour les vrilles, je me demande quand E va nous faire une belle figure. Le délais entre release se chiffre en années maintenant...
      • [^] # Re: ELF rentrera-t-il dans la danse?

        Posté par . Évalué à 10.

        E est passé, notamment dans les versions qui ont précédée la 0.15, par des thèmes carrément lourdingues. E n'était pas vraiment en cause, c'est juste qu'il était utilisé dans des configurations loin d'être optimales pour lui (sans compter qu'à l'époque -ça fait facile 5 ans-, les configs de PC n'avaient pas grand chose à voir avec les configs actuelles). Les dernières versions de 0.16 sont vraiment très correctes et plutôt jolies, mais ça n'est "qu'un" WM.

        Que ce soit Gnome ou Kde, ils deviennent chacun de plus en plus lourd (avec un bémol pour KDE qui essaye de réduire les besoins matériels).
        Ceci dit, c'est assez compréhensible, on peut difficilement faire tourner un browser, des outils bureautique et une pléïade d'applet sans que ça mange sur la RAM.

        Personnellement, je suis développeur et j'utilise Eclipse. Mon PC n'a "que" 256 Mo de RAM, l'utilisation de desktop style gnome ou KDE est prohibitif sur ma config pour que j'en fait (ça swappe a mort). Sans compter que je n'utilise que peu des applications des desktops sus-sités. Actuellement j'utilise XFCE, et c'est très suffisant. au repos (sans rien de lancé), Il mange beaucoup moins qu'un gnome ou un kde ; et, au besoin, je peux toujours lancer evolution, konqueror, ou n'importe quelle autre application KDE/Gnome en cas de besoin.

        Pour en revenir à E, je pense, vu le temps qui a été passé dessus, que les librairies de base seront de très bonne qualité et très efficaces (rasterman a toujours été très bon en X11), ce qui pourrait permettre de sortir un E17 "qui déchire sa race" + quelques outils annexes. Pour ce qui est de l'émergence d'un nouveau desktop sous Linux, je ne me fait pas trop d'illusion : E a 2-3 ans de retard, les développeurs potentiels ont tous été drainés par KDE ou gnome (à part quelques projets "marginaux" -xfce, rox, etc...-), alors l'avenir de E en temps que desktop, j'ai des doutes (l'histoire est pleine de programmes/librairie/environnement de qualité supérieure mis à la poubelle pour cause de manque de popularité). Reste que j'attend avec une certaine impatience le retour du WM qui reste clairement l'un des meilleurs, même après quelques années d'absence.
        • [^] # Re: ELF rentrera-t-il dans la danse?

          Posté par . Évalué à -10.

          > Que ce soit Gnome ou Kde, ils deviennent chacun de plus en plus lourd

          Ça c'est une légende. Compares la place mémoire d'un Gnome 1.4 avec Gnome 2.6 (j'utilise pas KDE, donc je ne sais pas). Compares avec l'évolution du matériel et reviens ici pour un bilan...

          > j'utilise Eclipse

          Et tu oses dire que Gnome et KDE sont "lourds"...

          En fait, j'en ai rien à foutre de ces "conneries", pleurnicheries.
          Linux, la libc, Gnome/KDE, etc, etc, etc ont de plus en plus de fonctionnalités et bouffent de plus en plus de mémoire. Si ça ne plait il faut installer une distribution avec Linux 2.0.
          Pour ma part, je n'ai pas l'intention de retourner sous Linux 2.0 et FVWM 2 avec un PC de 5 ans ou un PC de maintenant.

          Qui ici utilise une vieille distribution (hors Debian :-)).
        • [^] # Re: ELF rentrera-t-il dans la danse?

          Posté par . Évalué à 1.

          Personnellement, je suis développeur et j'utilise Eclipse.

          Haaa bon....
          Ben c'est pas Gnome ou KDE ou (rajouter_ n'importe_quoi_ici) qui pèse lourd alors....

          Histoire de forker le Troll je vois pas trop l'intérêt de ses éditeurs...
          Un bon shell UNIX, un emacs ou un vim, la pléthore d'outils UNIX (grep, find, sed, awk, tac, cut...) et on a un environnement de développement sans aucun équivalent...
          • [^] # Re: ELF rentrera-t-il dans la danse?

            Posté par . Évalué à 6.

            compilation a la volee sur eclipse => ca ca r0x plutot pas mal et ca te fait gagner pas mal de temps.

            sinon, les fonctionnalites de navigation dans le code (style sauter a la definition d'une variable/methode etc.. en faisant ctrl click), le refractor qui est tres puissant, la recherche des references a une variable/methode etc.. (et pas juste un grep -R monNomDeMethode bourrin)

            bref, le seul defaut que je trouve a eclipse c'est la qualite de l'editeur de texte qui est plutot bof bof..
            • [^] # Re: ELF rentrera-t-il dans la danse?

              Posté par . Évalué à 5.

              et encore j'en oublie plein :
              importation automatique des classes voulues, ecriture des squelettes des interfaces implementees, generation automatique des getters/setters, la foultitude de plugins (de totalement inutile a indispensable), la todo list bien pratique, la machine virtuelle lancee en permanence, on travaille avec des classes et non avec des fichiers.
              Des editeurs de GUI, possibilite de lier la javadoc au code, navigation dans le code "a la browser" (alt gauche/droite pour se deplacer aux derniers points d'edition), completion automatique bien pratique quand on ne se rappelle plus trop des specifs des classes...

              etc. etc. etc.

              en fait, c'est comme le telephone portable, au debut, on se dit que ca sert a rien, pis apres on se rend compte que c'est quand meme 'achement utile.
              • [^] # Re: ELF rentrera-t-il dans la danse?

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

                Emacs sait faire tout ça. Par exemple, la recherche des fonctions ou des variables, ainsi que l'endroit où elles sont référencées est assurée par etags.

                Et surtout, l'éditeur n'est pas "pourri", puisque c'est sa fonction première et cela me semble tout de même le principal. Le seul truc que tu n'auras pas, c'est l'éditeur de GUI.
                • [^] # Re: ELF rentrera-t-il dans la danse?

                  Posté par . Évalué à 1.

                  dans ce cas, ca devient dur de consider emacs comme un editeur de texte, et tu dois donc le considerer comme un IDE.

                  apres, les gouts et les couleurs hein, chacun fait fait fait c'qu'il lui plait plait plait, mais qu'on vienne pas me dire qu'emacs n'est qu'un traitement de texte.

                  pitite question pour ma culture perso : est ce que la recherche de fonction etc.. est intelligente?
                  je m'explique sous eclipse, quand tu cherche une methode, il te retourne uniquement celles qui correspondent a la signature (ie: typeRetour Classe.nomMethode(args) ), et pas celle qui correspondent juste au nom (ie: autreType AutreClasse.nomMethode(args)
                  • [^] # Re: ELF rentrera-t-il dans la danse?

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

                    pitite question pour ma culture perso : est ce que la recherche de fonction etc.. est intelligente?
                    je m'explique sous eclipse, quand tu cherche une methode, il te retourne uniquement celles qui correspondent a la signature (ie: typeRetour Classe.nomMethode(args) ), et pas celle qui correspondent juste au nom (ie: autreType AutreClasse.nomMethode(args)


                    Non, elle ne sait pas ce qu'est une signature. Cela dit, y'a un bidule proprio que l'on colle par-dessus emacs et qui sait alors faire des choses beaucoup plus fines. Je ne connais plus le nom.
                  • [^] # Re: ELF rentrera-t-il dans la danse?

                    Posté par . Évalué à 2.

                    >apres, les gouts et les couleurs hein, chacun fait fait fait c'qu'il lui plait
                    > plait plait, mais qu'on vienne pas me dire qu'emacs n'est qu'un
                    > traitement de texte.

                    Arghh .. Emacs n'ext *pas* un traitement de texte. Emacs est un editeur de texte extensible .. Il s'appuie sur des outils exetrnes pour augmenter ses possibilite (pour les tags par exemple) .. Comme le fait vim et certains autres ...

                    > pitite question pour ma culture perso : est ce que la recherche de
                    > fonction etc.. est intelligente?
                    > je m'explique sous eclipse, quand tu cherche une methode, il te
                    > retourne uniquement celles qui correspondent a la signature (ie:
                    > typeRetour Classe.nomMethode(args) ), et pas celle qui
                    > correspondent juste au nom (ie: autreType
                    > AutreClasse.nomMethode(args)

                    Non .. mais ECB doit le faire. Il s'agit d'un package poru Emcas qui le transforme en "IDE" .. Il est apparamment vraiment pas mal pour peu que l'on fasse du C/C++ ou du Java. On peut bien sur lui ajouter de nouveau langage mais il faut alors s'investir un peu ...
                • [^] # Re: ELF rentrera-t-il dans la danse?

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

                  > Emacs sait faire tout ça

                  Non. Eclipse est à Emacs ce que Emacs est à vi, ou même ed. Ce n'est pas *du tout* le même niveau de fonctionalités.

                  Mais tu n'apprécies les features d'Eclipse que lorsque tu travailles sur un projet Java sufisamment gros (disons plus de 10KLOCS), en dessous la lourdeur d'Eclipse te pénalise plus qu'autre chose.

                  C'est un débat récurrent ici, chaque fois que quelqu'un parle d'Eclipse ou d'un autre IDE du même genre (Intellij Idea par ex.) il y en a un pour sortir la liste des modules Emacs qui "font tout pareil". C'est souvent comique (bravo pour le 'M-x make' pour la compil à la volée, très réussi), et la personne qui s'y colle ne connait évidemment pas du tout Eclipse (et à peine Emacs).
              • [^] # Re: ELF rentrera-t-il dans la danse?

                Posté par . Évalué à 2.

                Pour l'éditeur de gui, tu utilises un plugin ? Lequel ?
                • [^] # Re: ELF rentrera-t-il dans la danse?

                  Posté par . Évalué à 1.

                  en pratique, je l'ai pas utilise pour de sombres histoires d'utilisation commerciale etc.. mais sinon, je me serais servi de SWT Designer (bah vi, je fais du swt, mais tu dois avoir equivalent sous SWING)
            • [^] # Re: ELF rentrera-t-il dans la danse?

              Posté par . Évalué à 4.

              compilation a la volee sur eclipse
              M-x make sous Emacs
              ! make sous vim(ou vi)

              fonctionnalites de navigation dans le code
              etags et ctags sous emacs ou sous vim
              Voir aussi l'excellent taglist sous vim (source browser pour C, C++, Java, ...)

              http://www.geocities.com/yegappan/taglist/images/taglist_java.gif(...)

              Bon, ceci dit je m'enflamme pas, hein !
              Chacun utilise ce qu'il veut :-)

              Ce que je dis juste, c'est que les "gros éditeurs tout intégré", ne font généralement que reprendre ce qui existe déjà à coté.
              • [^] # Re: ELF rentrera-t-il dans la danse?

                Posté par . Évalué à 1.

                bah vi, on va pas reinventer la poudre.
                l'avantage est d'avoir tout deja integre et de pas avoir a chercher ce qui pourrait convenir.
                mais bon, les gouts et les couleurs, hein, c'est po qqchose qui se discute..

                sinon, pour la compilation a la volee, c'est a la volee, ie pas de meta chose a taper, ca se fait tout seul : tu sauve ton fichier et la compile se fait toute seule en arriere plan sans que t'ai rien a demander, je te garantit que c'est vraiment confortable..
              • [^] # Re: ELF rentrera-t-il dans la danse?

                Posté par . Évalué à 4.

                compilation a la volee sur eclipse
                M-x make sous Emacs
                ! make sous vim(ou vi)

                Non, ça c'est de la compilation incrémentale.
                La compilation à la volée d'eclipse c'est comme le correcteur orthographique de Word et consorts: il compile au fur et à mesure que tu tapes, et il te souligne les erreurs de compilation en rouge :)
                • [^] # Re: ELF rentrera-t-il dans la danse?

                  Posté par . Évalué à 1.

                  La compilation à la volée d'eclipse c'est comme le correcteur orthographique de Word et consorts: il compile au fur et à mesure que tu tapes, et il te souligne les erreurs de compilation en rouge :)

                  Je crois que c'est ce qui m'a le plus énervé quand j'ai essayé de l'utiliser! Ca doit pouvoir se désactiver, mais les fichiers de configurations en xml disséminés un peu partout sont un peu confus pour moi. Le xml c'est bien mais c'est pas très lisible (ceci dit, un fichier de conf emacs c'est encore pire: il faut apprendre le lisp avant de faire quoi que ce soit...)
                  • [^] # Re: ELF rentrera-t-il dans la danse?

                    Posté par . Évalué à 2.

                    Ben alors toi t'es sacrement tordu :o)

                    Pourquoi diable t'embetes tu a aller trifouiller du xml alors que Eclipse possede une interface de config. ( lisible pas comme le XML ).

                    En plus tu ne peux pas manquer cette option, elle est dans le premier paneau (Workbench).

                    Comment c'est deja la pub de Ducros qui se decarcasse ? :o)
        • [^] # Re: ELF rentrera-t-il dans la danse?

          Posté par . Évalué à 0.

          Je crois que tu vas être deçu car Enlightenment a toujours eu pour réputation de bouffer énormement de mémoire. Je ne sais pas si ils vont entretenir cette réputation dans E17.

          Rasterman justifiait cette consommation car il préferrait sacrifier de la mémoire, afin pré-calculer certaine opération et ainsi décharger le CPU.
          Car à l'époque et c'est tjs vrai, l'augmentation de la mémoire d'un PC coûte bien moin cher que l'augmentation de la fréquence d'un CPU.

          Je n'ai pas reussi à retrouver l'article sur Google.

          Qui se rappelle de l'époque de E14 et E15 qui était recommandé uniquement pour les Workstations Alpha de Digital ou les très gros PC de l'époque. Je dois même encore avoir le Dream qui en parle. C'est peut être sur cette revu que j'avais lu cette interview d'ailleur.
          • [^] # Re: ELF rentrera-t-il dans la danse?

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

            J'ai pas spécialement remarqué de lourdeur mémoire (mais bon avec 784 Mo à priori c'est pas specialement embêtant...), et par contre j'ai très vite remarqué a quel point c'est optimisé(sse,opengl...),et a quel point tout ce qui est transparence alpha,animations, etc. donne un aspect hyper fluide, sans que l'activité processeur bouge vraiment pour autant (surtout en opengl!)
          • [^] # Re: ELF rentrera-t-il dans la danse?

            Posté par . Évalué à 4.

            Euh ... E16.7 tourne superbement sur mon portable avec 32Mo de ram... Pour tout dire le noyau linux, le serveur X, quelques démons, E16.7 et quelques epplets ne me mange qu'entre 11 et 16 Mo de ram... En toute honnêteté.

            Et pour le général, mon desktop lancé sous GNOME comparé à la consommation avec E16, ça n'a rien à voir ^^

            Pour ce que j'ai pu voir des EFL, ça a l'air d'être vraiment le plus optimisé possible (comprendre léger, rapide, réactif tout en étant efficace et sans sacrifier au eye candy). Suffit de voir epeg par exemple. Sachant que E17 est conçu à la base pour tourner aussi bien sur un tout petit PDA que sur un gros desktop, c'est prometteur ^^
        • [^] # Re: ELF rentrera-t-il dans la danse?

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

          > rasterman a toujours été très bon en X11

          J'ai des souvenirs de discussions avec Raph Levien ou Havoc Pennigton qui n'étaient pas exactement de cet avis :-). Mais c'était il y a longtemps (vers 99 ou 2000), il a pu changer depuis.
    • [^] # Re: ELF rentrera-t-il dans la danse?

      Posté par . Évalué à 0.

      s/ELF/EFL/g
    • [^] # Re: ELF rentrera-t-il dans la danse?

      Posté par . Évalué à 3.

      En fait ni l' un ni l'autre... au milieeeuuuu (comme dirait Bayrou). Le terme anglais que Rasterman avait utilisé il y a quelques années pour désigner E17 était "desktop shell". Un peu comme le défunt(?) UDE, ou XFCE, voire le combo Rox-Oroborox.
      Un gestionnaire de fenêtres, un gestionnaire de fichier, des applis simples (visualiseur d'images,éditeur de texte, outils de configurations, etc.).

      Ceci dit, il n'y a pas que Gnome et KDE dans la vie (je partage +/- ton avis sur ces 2 là). Rox est vraiment impressionant sur une petite machine. XFCE aussi (si on remplace son gestionnaire de fichiers par Rox-Filer ;) ).
      • [^] # Re: ELF rentrera-t-il dans la danse?

        Posté par . Évalué à 3.

        > Rox est vraiment impressionant sur une petite machine.

        Et encore plus sur une "grande" machine ^^ Perso je n'utilise que lui pour manipuler mes fichiers. Sachant qu'en plus il respecte de plus en plus les standards de freedesktop, c'est le navigateur de fichier par excellence je trouve.

        Bon, certes je ne serai pas contre le même mais architecturé autour des EFL ^^
  • # Xwindows

    Posté par . Évalué à -5.

    Qu'est-ce donc ? Une nouvelle interface graphique développée par Microsoft pour créer un lien entre X et Windows ?

    BeOS le faisait il y a 15 ans !

    • [^] # Re: Xwindows

      Posté par . Évalué à -4.

      Rhhaaaaaaaa !
      le temps de poster mon message mesquin la brève a été corrigée.

      BeOS le faisait il y a 15 ans !

  • # Accélération graphique matérielle

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

    J'avais cru comprendre que E17 utilise << massivement >> l'accélération graphique matérielle. Est-ce vraiment sensible ? E17 résoudrait-il une fois pour toute le compromis vitesse (comme window maker) / esthétisme (comme gnome) ?
    • [^] # Re: Accélération graphique matérielle

      Posté par . Évalué à 3.

      Les librairies de base (ELF, donc) font usage de l'accélération matérielle lorsqu'elle est possible.
      E sera beau. L'équipe de dev a quelques compétences en terme de graphisme, alors u peux être sur que ce sera beau.
      Et on peut compter sur Rastermen pour faire en sorte qu'il soit le plus rapide possible. Après, faudra voir à l'utilisation, mais tu peux être certain que ce sera efficace.
      Actuellement, la seule chose qui m'empèche de remettre un bon vieux E16 à la place de mon desktop actuel, c'est qu'il faudrait que je me retape les fichiers de config texte à la main -avec leur syntaxe proprio-, et j'ai pas le courage (ni le temps, d'ailleurs).
      • [^] # Re: Accélération graphique matérielle

        Posté par . Évalué à 4.

        En parlant de fichiers de config, quelqu'un sait en quel mesure Embryo sera utilisé? Aura t'on droit à une conf bien scriptable et tout, ou le même système qu'avant (cf E16)? Perso quand j'utilise un wm, je le choisis car sa config est scriptable. Par example en ce moment je tourne sous Ion qui est scriptable en Lua. C'est très pratique pour un wm.
        • [^] # Re: Accélération graphique matérielle

          Posté par . Évalué à 2.

          Pareil, c'est exactement pour la même raison que je suis sous Sawfish. Pour moi, qu'un WM soit scriptable, c'est aussi important que pour un éditeur de texte : je ne veux pas être cantonné à un ensemble de features fixé par d'autres que moi ; quand j'imagine un nouveau comportement pour gagner en temps ou en confort, je veux pouvoir le rajouter.
        • [^] # Re: Accélération graphique matérielle

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

          A vrai dire, embryo a été sortie de edje (qui était le seul composant à l'utiliser, pour les fichiers de thèmes) par rasterman, à priori pour ce genre de choses, je ne peux donc pas te l'assurer, mais il y a de fortes chances!

          De plus il est possible de "scripter" directement pas mal de choses, graphiquement, rien qu'a partir de edje (enfin du fichier de thème si tu préfères)
      • [^] # Re: Accélération graphique matérielle

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

        Pour les fichiers de conf de e16, e16keyedit et e16menuedit sont tes amis, ainsi que les trucs de configuration dispos dans e16 meme... Bon je dis ca, j'utilise openbox 3 :)
    • [^] # Re: Accélération graphique matérielle

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

      oui, c'est extrèmement sensible, ma barre en bas de mon écran type OS X (avec les icône qui grandissent à l'approche de la souris, et la barre s'adaptant à la nouvelle taille, le texte d'aide antialiasé et la semi transparence avec le fond, le tout réagissant instantanément, même en bougeant la souris très vite) accélérée par l'opengl (mais pour l'aceleration software mmx/sse ç'est presque pareil) me le rappel à chaque instant...

      à comparer avec la transparence du nouveau E16.7 qui est touts de même moins réactive (mais très jolie :D )
  • # Intégration aux nouveaux projets

    Posté par . Évalué à 5.

    À une époque, rasterman avait l'air intéressé par les projets "expérimentaux" de xwin & co. XCB, cairo... Il disait qu'il n'aurait aucuns problèmes à, et serait très intéressé pour, porter ses librairies là dessus.

    Maintenant qu'elles ont pris un peu d'age et de corps, où en est EFL là dessus?
    • [^] # Re: Intégration aux nouveaux projets

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

      ben pas très avancées je crois, mais elles tournent sur IPAQ (zaurus aussi?) et sur framebuffer... le portage vers d'autres plateforme ne semble pas un problème, aux lumière des discussions que j'ai eut avec les développeur...
      Je me demande même si on les verra pas un de ces jours débarquer aussi sous Windows...
  • # et xcl/xcb?

    Posté par . Évalué à 1.

    A une époque, il me semble que Rasterman s'était plus qu'enthousiasmé pour la libraire naissante xcl. Où en est E17 avec xcl aujourd'hui? Ce serait dommage que la finalisation soit bloquée pour une librairie externe pas finie...
    • [^] # Re: et xcl/xcb?

      Posté par . Évalué à -1.

      zut! je suis vraiment trop lent sur ce coup là...
  • # Intégration avec KDE et/ou Gnome ?

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

    Sans vouloir relancer le débat sur la lourdeur de l'un, l'autre ou du nouveau, j'amerai me poser avec vous la question de l'intégration possible de E17 avec KDE/Gnome, car il me semble que Rasterman l'a prévu au départ comme impossible.

    C'est vraiment dommage car un desktop KDE "classique" avec E16 comme gestionnaire de fenêtre doit être assez génial (j'a jamais essayé, car jamais trouvé où était le fichier de conf de KDE à ce sujet), ne serait-ce que la possibilité de voir une réelle minitature de ses différentes fenêtres dans les différents bureaux afin de reconnaitre du premier coup d'oeil où est telle ou telle (lorsque l'on a 15 fenêtre cela arrive vite...)


    Bref quid de KDE avec un gestionnaire de fenêtre valable (terme totalement subjectif) ?
    (je ne parle pas de Gnome je ne l'utilise plus depuis 2 ans, mais on peut se poser la même question)

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: Intégration avec KDE et/ou Gnome ?

      Posté par . Évalué à 2.

      Tout dépendra je pense du niveau de ICCCM compliance de E17 pour avoir une "bonne" intégration. Normalement on peut utiliser n'importe quel wm avec gnome, et après en bidouillant un peu on peut obtenir dans la plupart des cas une intégration quasi parfaite.

      Si par un malheur sans nom (dont je doute), quelque chose rendait E17 inutilisable avec gnome, reste toujours que l'on peut se servir de l'EFL (c'est fait pour), et donc toutes les applis de qualité qui en découlent.

      Si c'est juste pour le pager, il y aura surement moyen d'en écrire un qui soit compatible avec les bureau de gnome. Mais par exemple, je n'ai qu'un bureau gnome, mais plusieurs avec ion. Et pout autant ion s'intègre trés bien avec gnome.

Suivre le flux des commentaires

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