E17 pratique l'extorsion

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes : aucune
0
6
juin
2005
Serveurs d’affichage
Chacun sait que le très attendu E17 a connu ces derniers mois des avancés majeures. En fin d'année dernière le développement des bibliothèques EFL (Enlightenment Foundation Librairie) a laissé place à celui de l'environnement graphique proprement dit. Aujourd'hui il devient utilisable et implémente presque entièrement NETWM. De plus il existe déjà une belle série de thèmes ainsi que des utilitaires utilisant EFL tels que eclair (lecteur multimédia), evidence(Gestionnaire de Fichiers), Emblem (Sélectionneur de Fond d'écran)...

Pour dynamiser le développement d'applications annexes, l'équipe d'Enlightenment n'ayant pas eu droit aux primes de google, a décidé d'organiser en un mois un concours de programmation nommé "Extortion" permettant de gagner un prix (un t-shirt semble t-il) et surtout... l'adulation de la communauté Enlightenment. La compétition dure un mois et se divise en différentes sections:
- la section Graphique : il s'agit de réaliser de beaux thèmes et attention comme vous pouvez le voir sur les captures d'écrans de www.get-e.org, le niveau est élevé. De plus rappelons que les thèmes sous E17 utilise la technologie EDJE.

- la section BUG : éradicateurs fous de tout pays, lâchez-vous...

- la section "Features" : c'est un concours de bonnes idées. Si vous voyez quelques choses à ajouter de novateur dans EWL (Enlightenment Widgets Librairie) ne vous gênez pas.

- la section "Overall" : cette section fourre-tout devrait surtout voir apparaître de beaux petits programmes basés sur EWL et qui doivent en mettre plein la vue au jury. Cela promet...

Voila si vous êtes tentés pour programmer, sachez que EFL est disponible principalement en C mais aussi en C# et ruby. Sinon à vos gimp...

Aller plus loin

  • # arg

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

    donc si je comprends bien, E17 va réussir a sortir avant la sarge ?

  • # correction

    Posté par  . Évalué à 10.

    "n'ayant pas eut droit"

    hum, une ch'tite correction ?

    Pour ce qui est du programme "summer of code" de Google, Rasterman s'y est prit trop tard (le 02 juin) pour inscrire E17 en tant que projet bénéficiaire, la date limite étant le 01 juin

  • # Relation avec composite...

    Posté par  . Évalué à 3.

    Qqun sait ou a un bon lien sur le relation de E17 avec l'extension composite de xorg ?
    Parce que pour qqch qui va sortir, autant penser à l'avenir...

    • [^] # Re: Relation avec composite...

      Posté par  . Évalué à 1.

      E17 fait tout tout seul, bref, l'extension composite n'est pas utilisée.

    • [^] # Re: Relation avec composite...

      Posté par  . Évalué à 1.

      E16 utilise composite, mais pas E17 à ma connaissance.

    • [^] # Re: Relation avec composite...

      Posté par  . Évalué à 4.

      Il semble qu'actuellement E17 utilise son propre gestionaire composite.

      Le lien suivant en donne les raisons.

      http://xcomputerman.com/pages/archives/2004/11/21/why-the-e-team-st(...)

      En bref l'extension X Composite (et X Render) a des performances désastreuse. E17 utilise son propre system de Composite qui marche bien et va très vite. Toutefois quand XOrg aura des extentions qui tiendront la route en terme de performance, E17 pourra les utiliser. C'est d'ailleurs ce que souhaite la E-team car cela permettra par exemple au module dropshadow de tracer l'ombrage des fenetres sur d'autres fenetre n'utilisant pas la librairie Evas.

      • [^] # Re: Relation avec composite...

        Posté par  . Évalué à 5.

        Je comprends pas trop un truc ici.
        Normalement, l'extension composite doit offrir des services pour gérer la transparence. Mettre ce service au niveau de X est logique, car il doit pouvoir utiliser les ressources de la carte graphique.
        Par contre, mettre de la transparence dans E17 ne doit (a priori) pas utiliser le matériel ou alors à quoi sert le serveur graphique s'il ne fait pas sa fonction de couche d'abstration entre le matériel et le soft. Du coup, si la transparence est uniquement faite en soft, ça pompe des ressources (beaucoup pour quelque chose qui devrait être fait sur la carte graphique).
        (il y avait bien QT qui avait fait un truc de "fausse transparence" avec ses menus. Mais c'était du soft uniquement (et donc à mon avis d'un intérêt très minime).

        • [^] # Re: Relation avec composite...

          Posté par  . Évalué à 8.

          maiky: tu as raison sur la théorie. la transparence n'a rien à faire dans la couche """wm""".

          Mais en pratique il se trouve (voir lien plus haut) que les résultats en termes de perf de XComposite/XRender/XDamage ne sont pas à la hauteur. Le code dans XOrg semble lioin d'etre optimisé.

          La preuve les outils de Raster vont beaucoup plus vite.

          Cela est vrai aussi bien en utilisant l'accélération matériel qu'en ne l'utilisant pas. Ceux qui n'ont pas une carte graphique rapide ont de meilleurs résultats avec la version software de E17 et ceux qui en ont... c'est pareils...

          E17 repose pour sa partie graphique sur le tandem Imlib2/Evas qui est très optimisé. Evas va mème jusqu'à proposer d'utiliser un moteur de rendu GLX(et Cairo accessoirement)...

          Bref la la vraie transparence et l'ombrage actuel de E17 ne bouffe pas beaucoup de ressources... Rasterman a réalisé des benchmarks assez parlant pour illustrer cette quête de l'optimisation qui hante les développeurs de E17 et a si longtemps repoussé sa sortie.

          Il faut esperer que le dévellopement de XOrg s'accélère et que ces extentions soient rapidement améliorées.

          Après la question pertinente serait de savoir pourquoi XOrg n'utilise pas le code de E17 pour aller plus vite... Fierté mal placée?

          • [^] # Re: Relation avec composite...

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

            Mais en pratique il se trouve (voir lien plus haut) que les résultats en termes de perf de XComposite/XRender/XDamage ne sont pas à la hauteur. Le code dans XOrg semble lioin d'etre optimisé.

            Faut aussi voir la tete de son test, si c'est bien l'exemple dont je me souviens, dans la partie pour imlib, il n'y avait aucun affichage, ce qui n'était pas le cas pour xrender.

            • [^] # Re: Relation avec composite...

              Posté par  . Évalué à 1.

              Je n'ai pas le code sources des tests en question, ils faudrait les demander à Raster. Toutefois, celui ci indique lorque xrender fait l'affichage ou non en ecrivant "(offscreen)" dans l'intitulé du test.

              exemple:
              21:45:15) < @ raster> Test: Test Xrender (offscreen) doing non-scaled Over blends
              (21:45:17) < @ raster> Time: 7.460 sec.

              (voici le lien complet http://xcomputerman.com/pages/archives/2004/11/21/why-the-e-team-st(...) ).

              En ce cas la comparaison avec Imlib2 (qui ne fait jamais d'affichage, c'est le rôle de Evas) est pertinente.

              • [^] # Re: Relation avec composite...

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

                Ce qui manque surtout, c'est le support dans les drivers. Je viens de tester sur ma machine avec une carte nvidia et les drivers proprios, le 1er des 7 tests me donne :

                *** ROUND 1 ***
                ---------------------------------------------------------------
                Test: Test Xrender doing non-scaled Over blends
                Time: 0.070 sec.
                ---------------------------------------------------------------
                Test: Test Xrender (offscreen) doing non-scaled Over blends
                Time: 0.131 sec.
                ---------------------------------------------------------------
                Test: Test Imlib2 doing non-scaled Over blends
                Time: 0.399 sec.

                Le reste n'est pas acceleré. D'apres ce que j'ai vu sur un forum, nvidia ne peut pas vraiment travailler sur cette partie vu qu'il n'existe aucune procédure de test correcte. Ce qui m'étonne, c'est que le test offscreen soit plus lent que la version affichée...

                Il n'y a pas longtemps, 2 devs de trolltech ont travaillé sur l'optimisation de xrender : http://www.kdedevelopers.org/node/view/978(...)
                Ils ont bien amélioré les performances d'apres ce qu'ils disent, mais il faudra encore attendre...

      • [^] # Re: Relation avec composite...

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

        Ce que je ne comprend pas dans ce cas, c'est pourquoi la "E-Team" n'a pas tenté d'améliorer les perfs de XComposite, ca aurait contribué à tout le monde...

        Mais non, une fois de plus ils sont partis faire leur cuisine dans leur coin ...

        • [^] # Re: Relation avec composite...

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

          Peut etre tout simplement car les competences necessaires
          au developpement d'une fonction de gestion de transparence
          purement software et 1 million de fois plus simple que de

          1 decortiquer le fonction du serveur X, coté serveur
          2 gerer les optimisation hard de Xfree et la possibilité
          d'optimisation par les drivers.
          3 optimiser les dits driver en fonction du materiel

          Note qu'on pourrait rajouter qu'une bonne partie du probleme
          vient des drivers proprietaires n'implementant pas ou mal
          l'extension.

          • [^] # Re: Relation avec composite...

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

            C'est peut etre du aussi au fait qu'ils ont commencé le boulot bien avant les gens de Xorg...

            La question est plus pourquoi les gens de Xorg ne sont pas aller voir ce que les gens de E17 avaient déja fait....

            • [^] # Re: Relation avec composite...

              Posté par  . Évalué à 2.

              heeeeeeu...
              E17 ce qu'ils ont fait c'est de l'ombre déssinée au niveau du fond d'ecran, et la transparence c'est pas de la vraie...
              voir http://linuxfr.org/comments/584210.html#584210(...)

              --
              clemux

              • [^] # Re: Relation avec composite...

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

                Je ne suis pas très sûr de ce que tu avances :
                http://get-e.org/Main/FAQs.html#6(...)
                sur la faq ils disent que justement, que e17 utilise la vrai transparence, et que les programmes avec de la fausse transparence ne sont pas supportés à cause de ça.

                • [^] # Re: Relation avec composite...

                  Posté par  . Évalué à 2.

                  Au passage, merci à tous pour les réponses...
                  Bon sinon, d'après ce que je comprends plus haut, la real transparency d'E17 n'est gérée que avec les applications qui utilisent la librairie d'E... donc très peu !
                  C'est qd même un peu dommage, car sur certaines cartes, Composite ça déchire grave de vitesse... J'imagine que le test de rman n'était pas forcément avec une bonne carte... Mais bon, une carte correcte c'est 30¤ !

                  • [^] # Re: Relation avec composite...

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

                    Mais bon, une carte correcte c'est 30¤ !


                    c'est plutôt 30¤, du gaspillage (ben oui qu'est-ce que tu fais de l'ancienne carte ?), et des drivers proprio.

                    Tout le monde n'a pas forcément envie.

        • [^] # Re: Relation avec composite...

          Posté par  . Évalué à 2.

          > Mais non, une fois de plus ils sont partis faire leur cuisine dans leur coin ...

          Ouais, les gars de trolltech par contre se sont plongés dans Xrender pour l'optimiser dans tous les sens quand c'était trop lent à leur gout...

          • [^] # Re: Relation avec composite...

            Posté par  . Évalué à 5.

            Il y a quand même une très grosse différence.

            Trolltech est une boite. Ses employés sont payé pour coder.

            Rasterman et sa clique sont des bénévoles qui font ça sur
            leur temps libre.

  • # Une ch'tite question....

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

    Enlightenment est vraiment un WM (pardon desktop shell :) que j'aime beaucoup, il a vraiment la classe et beaucoup de personnalité. A l'époque j'adorais l'utiliser comme WM au dessus de Gnome 1.4.
    Mais j'aurai une petite question : quelle est la position de E par rapport à freedesktop.org ? En effet, j'avoue être enthousiaste à l'idée d'avoir des environnements certes bien différents mais bien interopérables. Je trouve que Gnome et KDE par exemple vont dans le bon sens. N'ayant pas essayé les versions de E aprés la 16.5, je ne sais pas ce que ça donne sur ce point.

    Bon lundi à tous !

    • [^] # Re: Une ch'tite question....

      Posté par  . Évalué à 7.

      Rasterman le leader du projet E17 est lui aussi très favorable à freedesktop. Actuellement l'implementation du protocole NETWM est activement en cours donc il n'y a pas de soucis à ce niveau. Les application seront interopérables grace à cela.

      D'ailleurs sur le site perso de Rasterman figure en gros un lien vers freedesktop (www.rasterman.com).

      • [^] # Re: Une ch'tite question....

        Posté par  . Évalué à 5.

        Néanmoins Rasterman ne veut pas limiter E17 et les EFL en se forçant à respecter toutes les specs freedesktop (qui ne sont pas tjs judicieuces). Du coup oui à NETWM, mais exit les fichier ".desktop". Par contre ils pensent créer tout un tas de convertisseurs (de ".desktop" vers leur format binaire : EET).

        Leur but est cependant de fournir tout cela de façon transparente et avec un tas de petits outils simples et utiles (du genre emblem, etc.) pour facilement et agréablement modifier la config.

  • # Packages ?

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

    Je recherche toujours désespérément des packages RPM pour tester de E17 qui me fait baver depuis quelques mois... Les contribs de Mandriva ne proposent à ce jour qu'une vielle version datant de juillet 2003 (:-O !).

    Quelqu'un a-t'il fait des packages ? J'ai pas envie de tenter la compilation (Est-ce seulement possible par une personne normale ?)

    • [^] # Re: Packages ?

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

      je crois qu'il est dans cooker depuis un moment, peut-être qu'un backport serait envisageable...

      J'avais fait des rpms il y a un moment, ils sont assez facile à réaliser mais j'ai pas le temps de les mettres à jour maintenant...

      • [^] # Re: Packages ?

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

        # urpmi e17
        Certains paquetages demandés ne peuvent pas être installés :
        e17-0.17-0.20030730.1mdk.i586 (en raison du manque de libevas1-1.0.0-1.20040913.1mdk.i586)
        libevas1-1.0.0-1.20040913.1mdk.i586 (car libdirectfb-0.9.so.20 est non satisfait)
        Continuer ? (O/n)


        Et la dernière entrée du changelog :
        jeu 31 jui 2003 12:00:00 CEST Lenny Cartier <lenny@mandrakesoft.com> 0.17-0.20030730.1mdk
        ...

        Bon, c'est pas par là que je vais pouvoir... ;-)

        • [^] # Re: Packages ?

          Posté par  . Évalué à 3.

          Il a des versions beaucoup plus récente de E17 dans cooker, la version actuellement dans contrib date du 24/05/2005 et est mise à jour assez souvent.

          Je m'étais fait mes propres specs pour une utilisation sous LE2005 il y a quelques mois mais quelqu'un ayant du temps pourrait aisément backporter le tout en utilisant les src.rpm ou les spec fait par Austin Acton, ça ne devrait pas poser de problèmes.

          En ce moment l'effort pour E17 sous Mandriva est surtout concentré sur le système de menu (menu debian xdg toussa quoi).

    • [^] # Re: Packages ?

      Posté par  . Évalué à 3.

      Pour une version RPM je sais pas mais que dirais-tu d'un script qui automatise l'install du CVS?

      http://www.rasterman.com/files/get_e.sh(...)

      Il te suffit d'avoir cvs et sudo (ou d'etre root en l'invoquant) et cela devrait marcher. Chez moi je l'ai un peu modifier pour compiler plus de lib et ne pas compiler entrance. Ce n'est pas très compliqué comme cela...

      En plus pour le maintenir à jour il n'y a pas grand chose à faire... Il suffit de le ré-invoquer.

      Si qqun pense avoir un meilleur script qu'il n'hésite pas à en faire partager les autres...

      • [^] # Re: Packages ?

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

        Je vais essayer ça ce soir, merci.

        Sinon, est-t'il nécessaire d'avoir l'accélération OpenGL (Enfin, une carte 3d, quoi), pour faire tourner E17 ? J'ai peur que même si ce n'est que de la 2d, il soit fait usage de fonction accélétrices... Quelqu'un a des infos ?

        • [^] # Re: Packages ?

          Posté par  . Évalué à 3.

          Il n'est pas nécessaire d'avoir une carte 3D pour faire tourner E17, d'ailleurs toutes les demo de Rasterman sont en mode software

          • [^] # Re: Packages ?

            Posté par  . Évalué à 1.

            La version software est même la seule qui soit stable, la version opengl n'a pas été beaucoup débuggé. Rasterman veut un truc qui roxor sans pour autant nécessiter une carte accélératrice. D'ailleurs il souhaite même que ça tourne sur des ordinateurs non récents. Son but : être le plus puissant possible tout en étant le plus léger possible.

            Du code non hyper optimisé c'est pas du bon code.

            • [^] # Re: Packages ?

              Posté par  . Évalué à 6.

              Du code non hyper optimisé c'est pas du bon code.

              Et ça c'est hyper discutable ;-).

              • [^] # Re: Packages ?

                Posté par  . Évalué à 2.

                C'est hypervrai dans ce cas précis comme dans le cas de toutes les bibliothèques ou services "de base" comme le noyau ou le WM. Le fait d'avoir un code non hyper optimisé dans les applications finales est bien sûr beaucoup moins grave dans la mesure où tu t'appuies sur une infrastructure qui elle est optimisée. :-)

                --
                Jedaï

                • [^] # Re: Packages ?

                  Posté par  . Évalué à 10.

                  Ça reste discutable. Qu'une bibliothèque soit implémentée hyperproprement peut également être préférable à son hyperefficacité, pour une hyperbonne maintenance.

                  • [^] # Re: Packages ?

                    Posté par  . Évalué à 8.

                    ce commentaire est hypertinent !

                  • [^] # Re: Packages ?

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

                    La ou la team E17 fait tres fort c'est quelle reussit a avoir un code à la fois hyperpropre, hypermaintenable, hyperlisible ET hyperoptimise.
                    Bref il sont fort...
                    (pour s'en convaincre il n'y a rien de mieux que de jeter un coup d'oeil au code)

    • [^] # Re: Packages ?

      Posté par  . Évalué à 1.

      Un lien cadeau pour mandriva : http://www.t27.ca/homepage.nsf/urpmi?OpenPage&ExpandSection=3%2(...)
      Avec des packages pour E17, mais je n'ai pas testé.

      • [^] # Re: Packages ?

        Posté par  . Évalué à 2.

        Ou alors utiliser cooker, et faire urpmi e.

        • [^] # Re: Packages ?

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

          J'ai essayé tout le reste, ça n'a pas fonctionné, je vais donc me tourner vers ça, merci :-) !

          Je repasserais histoire de dire ce qui a marché.

        • [^] # Re: Packages ?

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

          Bon, je n'arrive pas à trouver le nom du "meta-package" pour e17: Je vois bien que toutes les libraries (edje, etc...) sont présentes, mais je ne sais pas quoi en faire...

          Heeeelp !

          • [^] # Re: Packages ?

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

            rgs :: :v e
            Sophie:: e: 0.16.999.007-0.20050511.3mdk in contrib cooker for i586

            • [^] # Re: Packages ?

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

              Ce qui veut dire, en bon français :-? ?

              • [^] # Re: Packages ?

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

                Le nom du paquet c'est e

                • [^] # Re: Packages ?

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

                  d'une autre manière

                  [root@lyre /]# urpmq -i e
                  Name : e
                  Version : 0.16.999.007
                  Release : 0.20050511.3mdk
                  Group : Graphical desktop/Enlightenment
                  Size : 37200460 Architecture: i586
                  Source RPM : e-0.16.999.007-0.20050511.3mdk.src.rpm Build Host: n1.mandrakesoft.com
                  Packager : Austin Acton <austin@mandriva.org>
                  URL : http://www.get-e.org/(...)
                  Summary : Enlightenment DR 17 window manager
                  Description :
                  E17 is a next generation window manager for UNIX operating systems. Based on
                  the Enlightenment Foundation Libraries (EFL), E17 is much more than just
                  another window manager - it's an ambitious and innovative project that aims
                  to drive the development of graphical applications industry-wide for several
                  years to come.

                  tu as bien tes sources contrib configurées ?

                • [^] # Re: Packages ?

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

                  Bon, je resume ma manip, parce que ça ne fonctionne pas.

                  Je suis en Mandrake 10.1 (A titre indicatif, j'ai essayé aussi sur une 10.2)

                  # urpmi.addmedia cooker_main ftp://ftp.free.fr/pub/Distributions_Linux/Mandrakelinux/devel/cook(...) with ../media_info/hdlist.cz
                  # urpmi.addmedia cooker_contrib ftp://ftp.free.fr/pub/Distributions_Linux/Mandrakelinux/devel/cook(...) with ../media_info/hdlist2.cz

                  Ensuite :

                  # urpmi e

                  Pour satisfaire les dépendances, les 10 paquetages suivants vont être installés (39 Mo):
                  e-0.16.999.007-0.20050511.3mdk.i586
                  libcairo1-0.5.0-1mdk.i586
                  libdirectfb0.9_22-0.9.22-3mdk.i586
                  libecore1-0.9.9.007-0.20050524.2mdk.i586
                  libedb1-1.0.5.003-0.20050524.2mdk.i586
                  libedje0-0.5.0.007-0.20050524.3mdk.i586
                  libeet0-0.9.10.007-0.20050524.2mdk.i586
                  libembryo0-0.9.1.007-0.20050524.2mdk.i586
                  libevas1-0.9.9.007-0.20050524.2mdk.i586
                  libglitz1-0.4.0-2mdk.i586
                  Est-ce correct ? (O/n) o

                  Ah ben tiens, si, ça marche... Pfff, bon, au moins, si la manip intéresse quelqu'un, google lui dira ou venir... Pour Google: INSTALLER e17 SUR MANDRAKE : http://linuxfr.org/comments/585504,1.html(...) .

                  Bon, ça c'est fait... Pour info, mon erreur, c'est que j'ai spécifié --media cooker_contrib puis --media cooker_main, sur la ligne de commande d'urpmi, et que je n'aurais pas dû.

                  • [^] # Re: Packages ?

                    Posté par  . Évalué à 2.

                    on peut rajouter aussi les deux packages suivants :
                    urpmi e_utils e_modules

                    • [^] # Re: Packages ?

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

                      J'ai fini par m'en apercevoir, en effet... Par contre, le fait d'avoir installé e_modules ne m'a pas rajouté les entrées de menus correspondantes, je n'ai donc pas pû lancer ces choses indispensables comme "flames" ;-)
                      Pourtant, il sont bien installés dans "/usr/....", j'ai du loupé quelque chose.

                      D'autre part, j'ai du faire une bêtise: J'ai mis à jour l'ensemble avec les derniers paquets de la cooker, et plus rien ne fonctionne, j'ai des segfault, des unresolved symbol (Enfin, ce genre de choses). Je voulais juste installer un paquet enlightenment supplémentaire (une appli E)... :-(

                      Je vais opter pour la désinstallation/réinstallation de tous les paquets, mais bon...

  • # Précision

    Posté par  . Évalué à 4.

    Le concours ne concerne pas l'ensemble de E17 mais seulement EWL, qui est la bibliothèque de widgets, comparable à GTK+.

    http://www.edevelop.org/extortion/(...)

  • # Un peut déçu par ewl

    Posté par  . Évalué à 2.

    J'aime bien e17 (a priorie, je suis en train de le emerger) mais je suis un peut deçu par ewl car je m'atendait a quelque chose d'inovant et c'est vraimenent similaire a GTK (meme genre d'heritage, meme façon de caster avec des macro et tout). C'est un peut domage je trouve. M'enfin je vais qd meme essayer avant de trop critiquer

    • [^] # Re: Un peut déçu par ewl

      Posté par  . Évalué à 1.

      "c'est vraimenent similaire a GTK"
      la vitesse en plus ^^

      • [^] # Re: Un peut déçu par ewl

        Posté par  . Évalué à 0.

        Il faut savoir qu'ewl est une des seules librairies des EFL qui n'ait pas développer par Rasterman. Niveau perf, c'est vraiment très lent, et puis c'est pas vraiment utilisable pour le moment, ce qui est dommage quand on voit la qualité des EFL et leur rapidité...

        • [^] # Re: Un peut déçu par ewl

          Posté par  . Évalué à 1.

          Oui bon attention... EWL peut paraitre assez simplet de prime abord... Mais c'est plus complexe qu'il n'y parait.

          Le theme par défault de EWL n'est pas terrible. Faites un essai avec:

          ewl_test --ewl-theme e17

          Tout de suite c'est déjà plus beau...

          Et pour ce qui est de la lenteur, monitorez vos ressources système et vous verrez qu'EWL n'est pas gourmand. En fait la couche EDJE qui assure la themification est responsable de cet effet de lenteur. La rémanence des widgets traversés est VOULUE et délibérée.

          Gageons que de meilleurs themes ferons leurs apparitions grâce à Extortion.

          • [^] # Re: Un peut déçu par ewl

            Posté par  . Évalué à 1.

            bof avec le theme e17 c'est pas telement mieux je trouve, enfin a part quand on passe le curseur sur quelque chose ça devient or, mais sinon ça reste un peut fade

            un jour quand je serai grand je ferai une librairie de widgets qui sera mieux que toutes les autres :-p mais j'ai d'autres truc a finir pour l'instant

            • [^] # Re: Un peut déçu par ewl

              Posté par  . Évalué à 1.

              Hum... Fade. Tu n'a pas totalement tord. il faudrait revoir le theme pour ajouter du relief.

              un jour quand je serai grand je ferai une librairie de widgets qui sera mieux que toutes les autres :-p mais j'ai d'autres truc a finir pour l'instant

              Mieux!! c'est bien ca ... Tu as surement de bonnes idées à faire partager. Peux tu nous en faire profiter?

              • [^] # Re: Un peut déçu par ewl

                Posté par  . Évalué à 9.

                sans vouloir lancer de throll,
                personnellement je suis utilisateur de E17CVS et des differentes appli qui sont dispo sur le CVS (eclair,emblem,entangle........),et ce depuis le 1er jour ou le CVS a été dispo.
                ca remonte à y'a 6 ou 8 mois et sincèrement, ils ont fait d'enorme progrés, le theme de base est peut-etre pas trés 'eye candy', mais il est rapide et simple.
                de plus si on regarde sur www.get-e.org on y trouve d'autres thèmes trés sympathique (j'adore ice perso ;=)), ainsi que de la doc, des fonds d'écran ......

                une petite info, e17 est developpé dans le temps libre des personnes qui constituent l'équipe de dev, ils n'ont pas la chance comme pour GNOME ou KDE , d'avoir des membres de leur équipe qui sont payés à pleins/mi -temps pour le faire evoluer.
                et pour avoir discuter quelques fois avec raster sur #e,
                ils nous réservent encore bien des surprises.

                LA TODO list est énorme, mais les progrès se font à pas de geant, je reste trés confiant en e17 qui sera trés certainement une petite merveille.

                juste pour finir comparez la consommation mémoire de E17 avec celle de GNOME ou KDE et mettez ça en rapport avec les possibilités offertes et/ou à venir.
                je suis prêt à parié que e17 sort vainqueur.

                voila, mon speech est fini, vous pouvez moinser ;=)

                • [^] # Justement, les applis...

                  Posté par  . Évalué à 1.

                  N'ayant pas encore essayé, je me demandais quelles tendances allaient prendre les applis d'un futur bureau E ...
                  - intégration à l'extrème style kde ?
                  - plus séparé et simplifié visuellement (plus vers gnome) ?
                  - autre chose ?

                  Ou au moins, ont-ils décidé qqch à ce sujet ?

                  J'avoue être plutot supporter du style kde (kparts & co) mais je bave d'admiration devant les shots de E17 (promis, je teste sous peu !!).

                  • [^] # Re: Justement, les applis...

                    Posté par  . Évalué à 1.

                    hum e17 n'est pas prevus pour être un KDE ou un GNOME like , néantmoins je pense que seront intégrés des fonctions de compatibilité qui permettront aux afficionados de KDE et/ou de GNOME de pouvoir s'y retrouver un minimum (cf raster).

                    e17 est un shell desktop environnement, et non un Window Manager comme KDE ou GNOME, en clair, vous ne pourrez plus lancer e17 comme vous le faisiez avec e16 quand vous etiez sous GNOME ou KDE.
                    en partant de cette idée je pense que les applis devraient adopter un style différent de ce qui est fait sous KDE ou GNOME , il n'y a qu'a voir entangle (gestionnaire de menu) et emblem (gestionnaire de fond d'écran) pour se faire une petite idée.

                    en tous cas depuis l'implementation des key-binding, honnêtement je ne me sert plus que de e17, il manquerait plus qu'ils implementent des options a la macosX (dock et exposé) et on a la nouvelle killer application (quelqu'un que je ne citerais pas m'a laisser entendre que cela devrait prochainement apparaitre dans les TODO list ;=)).

                    • [^] # Re: Justement, les applis...

                      Posté par  . Évalué à 4.

                      e17 est un shell desktop environnement, et non un Window Manager comme KDE ou GNOME

                      Non non , KDE et Gnome ne sont absolument pas des WM , ce sont des Desktop Environnement et c'est kwin et metacity qui sont des WM.

                    • [^] # Re: Justement, les applis...

                      Posté par  . Évalué à 3.

                      il manquerait plus qu'ils implementent des options a la macosX (dock et exposé) et on a la nouvelle killer application

                      Ben justement je suis en train de bosser là dessus (exposé). Si il en a qui veulent me donner un coup de main...

                • [^] # Re: Un peut déçu par ewl

                  Posté par  . Évalué à 2.

                  Personnellement, ce qui me manque dans E17 c'est une barre du genre gnome-panel.

                  Donc le jour ou perlbar ou un truc dans le genre marchera correctement sous E17, je reessayerai.

              • [^] # Re: Un peut déçu par ewl

                Posté par  . Évalué à 1.

                Des bonnes idées...


                Alors moi ce que j'aimerai comme librairie de widgets ça serai deja une en vrais C pur sang, (j'entend pas a la gobject). Il faudrais aussi que le toolkit ne prène pas le controle de l'application ( pas de xyz_main() ), j'aimerai bien aussi que l'on puissent facilement récupéré des pointeurs sur les widgets (comme on le fait avec glade_xml_get_widget) ou encore mieux qu'on puisse se passer de pointeur , genre bouton_changer_texte("bouton1","ok"). tout ça rapide bien sur, pourkoi pas pouvoir commander le toolkit depuis une connexion distante ( je crois que le serveur Y fait un peut ça). l'idéal ça serai que tout ça soit facilement skinable (mais genre skin a la xmms/winamp) et aussi qu'il puisse faire automatiquement du café.

                bon bref ...

                pour résumé j'aimerai bien pouvoir retrouver toutes les sensation de la programmation console en graphique.

                • [^] # Re: Un peut déçu par ewl

                  Posté par  . Évalué à 0.

                  "pour résumé j'aimerai bien pouvoir retrouver toutes les sensation de la programmation console en graphique."
                  +100000

                  PLAIN C pawa ^^

                • [^] # Re: Un peut déçu par ewl

                  Posté par  . Évalué à 6.

                  pour résumé j'aimerai bien pouvoir retrouver toutes les sensation de la programmation console en graphique.

                  Tu t'es jamais demande pourquoi tous les toolkits utilisaient un modele objet ?

                  Ben essaye de la faire, ta bibliotheque C sans objets. Essaye aussi de pas avoir de xyz_main(), alors qu'une appli graphique c'est quand meme evenementiel a la base.

                  Enfin bon, serieux, j'y crois pas du tout a ton idee. Mais c'est peut-etre moi qui ai l'esprit etroit.

                  • [^] # Re: Un peut déçu par ewl

                    Posté par  . Évalué à 1.

                    Enfin bon, serieux, j'y crois pas du tout a ton idee. Mais c'est peut-etre moi qui ai l'esprit etroit.

                    nanan, c'est pas toi (ou alors on est beaucoup à avoir l'esprit etroit :) ).
                    D'ailleurs, les bibliothèque de gui c'est un peu l'exemple parfait pour pas mal de design pattern de la POO (de tête là, le schema composite par exemple).

                    Enfin pour terminer dans la pure mauvaise foi, c'est quoi la "programmation console" ? la prog procédurale ? c'est pas vraiment adapté à la programmation de gui... Si les gens de GTK et EWL se sont brisé les testicouilles à construire des structures "objets" en c, c'est pas juste pour draguer les minettes dans les réunions de geeks.

                    Bref, moi aussi je suis curieux de voir le proto de l'api...

                    et le PLAIN C pawa, c'est rigolo un moment, mais ya des fois où c'est pas la meilleur des solutions.

                    • [^] # Re: Un peut déçu par ewl

                      Posté par  . Évalué à 1.

                      le proto de l'api ... tu devras atendre un peut beaucoup je crain m'enfin bon.

                      Ceci dit peut etre que avoir l'espri ouvert ce n'est pas seulement de penser pouvoir faire une api de toolkit d'une façon diférente, il y a peut etre aussi d'autres façon de voir l'interface homme machine. A moin que je me trompe on a inventé que 2 façon de communiquer avec la machine qui sont : l'interface graphique inspiré de la mecanique (boutons, ascencseur et tout) et la ligne de commande (peut etre la commande vocale mais on vas pas chipoté). peut etre qu'il y a d'autres possibilité mais on les connais pas encore. (j'ai pas d'idée pour ça c'est juste une idée d'idée). c'est surement pour ça que quand on montre linux a un windozien (qui connais pas grand chose) la plus part du temp il dit "ça ressemble a windoz" parce que c'est le meme principe (alors qu'il s'attendait au dépaysement complet).

                      Enfin pour terminer dans la pure bone foi, je trouve le travail de l'équipe de GTK exelent. EWL sera surement aussi bien tant il ressemble a GTK (peut etre quand ewl aura qq chose de similaire a glade). Mais trouvé les toolkit existant bien ne m'enpeche pas d'espéré encore mieux.

                      le pure C c'est bien sympa qd meme

                      • [^] # Re: Un peut déçu par ewl

                        Posté par  . Évalué à 3.

                        Apres la ligne de commande et la fenetre, il y a un troisieme type d'IHM que tu as oublie : la page, qui est en train de supplanter la fenetre.

                        A part ca, bien sur que Gnome/KDE/E17 c'est des fenetres et des boutons, donc le meme principe que Windows (et MacOS, et BeOS). C'est bien de vouloir innover mais il faut savoir pourquoi et comment. Il ne faut pas faire different seulement pour se demarquer, il faut que ca aie un sens. Et sincerement, creer un nouveau type d'IHM pour "faire du plain C", je ne comprends pas bien.

                        • [^] # Re: Un peut déçu par ewl

                          Posté par  . Évalué à 1.

                          "Et sincerement, creer un nouveau type d'IHM pour "faire du plain C", je ne comprends pas bien."

                          ce n'est pas lié, c'est 2 idées diferentes

  • # un Ewebcore ?

    Posté par  . Évalué à 0.

    ça serait cool qu'ils aient leur propre Navigateur Web chez E17,
    et vu que récemment Webcore a ouvert son CVS, ça pourrait faicilité son dev, non?

    Un wm devrait avoir son propre browser intégré.

    Kde - khtml (avec konqueror)
    Gnome - gecko (avec epiphany)

    ....

    mes 0,2 centimes de francs (car il en a marre de l'euro)

    +

    • [^] # Re: un Ewebcore ?

      Posté par  . Évalué à 0.

      une fois en me balladant sur sf.net j'ai vus un projet de navigateur web ecrit à partir des EFL, mais le projet semblait être en état de stase.
      en même temps firefox marche trés bien ,
      <NO THROLL INSIDE>
      pourquoi toujours reinventer la poudre ?
      n'est ce pas du gaspillage d'energie ?
      </NO THROLL INSIDE>

      allez-y vous pouvez moinser now ;)

  • # Pour réchauffer la discussion...

    Posté par  . Évalué à 2.

    Un benchmark à été réalisé pour les WM. Et qui s'en sors haut la main ? E17 bien sur.

    Le bench est dispo ici http://www.rasterman.com/(...) (OK pour l'objectivité, mais le source du bench est dispo, faites en ce que vous voulez) et on en tro^H^H^Hcause ici: http://www.osnews.com/comment.php?news_id=10796(...) .

    • [^] # Re: Pour réchauffer la discussion...

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

      Soit dit en passant, j'étais surpris de lire Rasterman parlant d'un temps de démarrage de 0.54 secondes pour e17... Le splash-screen étant volontairement ralenti pour en apprécier toute la beauté (Et lire les messages de boot), il prend plutôt 20 secondes...

      Et bien, en lisant la doc, j'ai vu qu'il suffit de rajouter export NOSPLASH=1 à son .bashrc pour désactiver le splash. Et là, effectivement, e17 démarre en 1 seconde ! Un truc de malade pour un shell graphique :-O !!!

      C'est beau, c'est rapide, et dès que c'est stable et fiable je vire Kde (Dont j'utiliserais toujours les apllis que j'adore.)

      • [^] # Re: Pour réchauffer la discussion...

        Posté par  . Évalué à 1.

        Tu es en train de dire qu'ils ont volontairement ralenti le démarrage de 1s à 20s pour faire joli et lire les messages de boot??

        Il y en a qui sont des grands malades..
        Faire joli, pendant 1/2s ok, mais 20s..
        Et puis lire les messages de boot, bof, quand tout se passe bien quel interet?
        Avoir un moyen simple d'avertir quand il y a eu un problème au boot (genre une icone de warning) et d'afficher les messages de boot quand on clicke dessus ou bien en cas d'erreur (si l'erreur est tel que le bureau ne peut pas demarrer) ok, mais perdre 20s de temps de démarrage systèmatiquement pour ça..

        Ceci dit, 1/2s c'est cool, KDE est bien plus lent que ça à démarrer..

        • [^] # Re: Pour réchauffer la discussion...

          Posté par  . Évalué à 3.

          La variable NOSPLASH n'existe plus.
          Il y a maintenant une checkbox pour désactver l'affichage du splash screen.

          Ce ne sont pas des messages de boot.
          Ce sont des avertissements sur le fait que E17 est un application en
          version Alpha.

Suivre le flux des commentaires

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