EFL 1.1 alpha

Posté par . Modéré par tuiu pol. Licence CC by-sa
40
16
nov.
2011
C et C++

Tôt ce matin, on pouvait lire l’annonce de la sortie de la version 1.1 alpha des bibliothèques Enlightenment Foundation Libraries, les EFL. Ces bibliothèques sont la base du gestionnaire de fenêtres et environnement de bureau ultra‐optimisé Enlightenment.

Enlightenment sur téléphone |Enlightenment sur laptop

Voilà quelque temps que le projet Enlightenment a commencé sa marche vers la publication de sa version stable finale, avec les EFL tout d’abord, et Enlightenment, lui‐même, pour conclure. Le voyage a été long, plus de 10 ans, mais le résultat est là. Cette version apporte un certain nombre de corrections de bogues, ainsi que de nouvelles fonctionnalités. La future version 1.1 sera la base d’Enlightenment DR17.

  • # MOUARFFF

    Posté par . Évalué à  -7 .

    La future version 1.1 sera la base d’Enlightenment DR17.

    Puti c'est pas pour demain la version 1.1. Meme dukenukem est sortie! Bon il reste encore Hurd comme plus gros vaporware mais bon E17 c'est pas loin derriere.

    • [^] # Re: MOUARFFF

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

      et gcoincoin

    • [^] # Re: MOUARFFF

      Posté par . Évalué à  9 .

      Je ne dis pas merci pour cette dépêche, maintenant je vais devoir changer d'interface graphique et d distribution :
      Bêtement je faisais confiance à mon gestionnaire de paquets, il y a environ un an je lui ai demandé d'installer E17 , ce gestionnaire de paquets avait du gober trop de pilules car il m'a répondu "oui c'est possible" il installe plein de truc avec E17 dans leurs noms !!
      Suite à cette dépêche le doute m’envahis je vérifie l’a propos de mon bureau et patatras c'est E16.999.

      Moralité depuis 1 an j'utilise malgré moi un truc entre le vapoware et la vieille interface graphique pas finie, pourtant elle fonctionne sans problème, elle n'est même pas moche et contient encore un tas d’éléments que je n'ai pas pris la peine de regarder.

      PS:si vous avez d'autres vopowares de ce style, je suis preneur....

  • # L'âge de la consécration?

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

    Les EFL ont été prometteuses, et ce depuis longtemps... peut-être même trop longtemps et je commençais à me demander si elles perceraient un jour ou si elles arrivaient trop tard dans la bataille.

    Et puis on ne suit plus trop l'actualité quelque temps, et voilà que cette dépêche me fait jeter un coup d'oeil aux infos récentes autour des EFL.

    En fait, ça bouge énormément et dans le bon sens:
    -Un installateur windows est toujours en lice (ben oui, que ça plaise ou pas, c'est toujours un plus d'être multi-plateforme en incluant celle-là)

    -Et surtout, surtout: les EFL devraient vraisemblablement être intégrées à Tizen. Tizen, le nouveau Linux soutenu par les acteurs de l'embarqué "non-alignés", qui remplace Meego, LiMo etc.

    Bref, finalement, les EFL se portent très très bien y compris en dehors du cercle de développeurs!

  • # Dommage que la dépêche soit un peu courte

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

    C'est dommage que la dépêche soit si courte, il y a beaucoup à dire dessus.

    Je ne connaissais les EFL que de nom, et je m'y suis récemment mis pour des raisons professionnelles. Et bien je les trouve vraiment excellentes. Il y a de très bonnes idées comme:

    • les fichiers edje qui décrivent l'interface, et permettent d'avoir un fichier compilé unique qui contient tout le thème, y compris les images. Les thèmes permettent de changer radicalement l'apparence de l'application

    • pas de vectoriel, tout utilise des images bitmap. La qualité graphique ne s'en ressent pas, mais au niveau rapidité ça n'a rien à voir

    • Le canvas est stateful, le mieux pour comprendre l'intérêt est de lire leur tutoriel (en gros si on dessine un rectangle et qu'on veut le faire bouger, au lieur d'effacer le canvas et en redessiner un autre comme on ferait dans la plupart des toolkits, on lui dit juste de se déplacer.

    • Elementary permet de coder en utilisant des widgets de haut niveau, tout en gardant la main sur edje ou evas, de plus bas niveau

    • Ce n'est pas juste pour faire des interface, il y a un framework complet qui s'occupe de choses comme D-Bus ou la gestion réseau, à l'instar de Gtk et Qt

    • c'est rapide ! Je veux dire très, très rapide: c'est impressionnant à voir tourner (j'ai pu comparer une genlist avec une liste gtk, c'est impressionnant la différence de ressenti)

    bon j'ai pas trop le temps pour en écrire plus, mais ça vaut vraiment le coup de s'y mettre, suivez les tutos du site, allez sur IRC, et vous pouvez vous lancer avec l'excellent tuto en français sur developpez.com: http://louis-du-verdier.developpez.com/efl/debuter/

    • [^] # Re: Dommage que la dépêche soit un peu courte

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

      Très intéressant article, une perle rare, comme il le dit lui-même...

      La documentation est assez limitée

      Et sinon, c'est la prochaine fois que je vois parler d'E18 !

      Quoi qu'il en soit, il faut noter que les changements majeurs prévus pour E17 ont été repoussés à E18.

      Après quelques recherches sur google j'ai trouvé des pistes :

      http://trac.enlightenment.org/e/wiki/CompositeManager

      For E18, the plan is to move to full composited system and maybe even drop the non-composited support. The core will be changed to make better use of this feature.

      https://desktopsummit.org/sites/www.desktopsummit.org/files/E17-DesktopSummit2011.pdf

      What's next?
      - e17 release (ASAP)
      - e18 to use elementary
      - get back to short release cycle
      - rewrite everything yet again, endlessly? :-)

      En effet malgré des chamboulements permanents, E17 reste assez traditionnel dans l'idée de concevoir une expérience de bureau... Hors les EFL, du moins Elementary, semblent s'être orientées "interface tactile" (probablement la priorité de ceux qui paient), si je cite l'articule de Louis Du Verdier :

      La bibliothèque Elementary, bien que « bien garnie », manque de widgets, et le non tactile n'est pas tellement une priorité dans le développement.

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

      • [^] # Re: Dommage que la dépêche soit un peu courte

        Posté par . Évalué à  4 .

        En effet malgré des chamboulements permanents, E17 reste assez traditionnel dans l'idée de concevoir une expérience de bureau... Hors les EFL, du moins Elementary, semblent s'être orientées "interface tactile" (probablement la priorité de ceux qui paient), si je cite l'articule de Louis Du Verdier :

        J'avoue avoir un peu du mal a comprendre ce point precisement. E17 a un pipeline de rendu graphique qu'aucun autre Composite Manager n'a. Ce qui lui permet d'etre utilisable en rendu logiciel sur un pentium-m. Il est completement modulaire, tu peux par exemple changer completement la politique de placement des fenetres (par bureau et potentiellement aussi par ecran). L'interface prend en compte la taille des doigts et s'y adapte automatiquement. Il est completement themable, meme les effets de compositing sont gere par le systeme de theme. J'en oublie surement un paquet, mais tu as l'idee.

        Donc qu'est-ce que tu entend par assez traditionnel ? Peut-etre au niveau du profil par defaut ? Clairement si tel est le fond de ta remarque, on est principalement que des coder et aucun designer n'est venu nous proposer quelque chose. Mais techniquement, il n'y a pas de limite, il faut juste un designer...

        • [^] # Re: Dommage que la dépêche soit un peu courte

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

          Est ce qu'EFL a un bus logiciel au dessus de la boucle d'évènement ? Si ce bus est si optimisé que cela, on pourrait peut être le proposer à systemd en remplacement de dbus ?

          • [^] # Re: Dommage que la dépêche soit un peu courte

            Posté par . Évalué à  4 .

            quel intérêt ? D-Bus est un protocole normalisé par fd.o (avec plein de clients) et adopté par la quasi-totalité des distributions GNU/Linux et environnement de bureau. Pourquoi le remplacer avec un machin propre à Enlightenment ? (qui propose également une bibliothèque cliente DBus)

        • [^] # Re: Dommage que la dépêche soit un peu courte

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

          De fait, je n'ai rien à dire vis à vis des bibliothèques (EFL).

          C'est plus vis à vis du "profil par défaut" ou plus simplement le bureau de base. Actuellement on reste avec un bureau à icône et une barre des tâches (dock, shelf, gondole ?) qui contient un "menu démarrer" et une liste de fenêtre ouverte et une nhorloge, pour résumer.
          C'est fonctionnel, mais ça donne le sentiment que tout ceux qui ont de bonnes idées se concentrent sur les bibliothèques. Si les EFL peuvent être très innovantes, l'expérience E17 ne l'est pas encore. Ce n'est pas un reproche, chacun son tour...

          J'ai utilisé longtemps E17, que je recompilai avec un script perso depuis le dépôt. J'ai vu disparaitre, les eap, certains outils disparaitre et d'autres apparaitre (c'est pour Emphasis que je suis passé à mpd), j'ai vu apparaitre tout doucement la prise en charge spécifications fd.o, j'ai vécu la confusion des toolkits EWL/ETK, puis les gondoles... Tout cela en moins de deux ans. Depuis, je suppose que beaucoup de code a été réécrit et les choses repensées, mais quand je lance un E17, j'ai l'impression que le seul changement d' "expérience utilisateur" est que le thème par défaut à changé.

          Ce n'est qu'une impression, mais j'ai le sentiment que le développement du bureau en lui même tourne au ralenti, mais comme je vois que les bibliothèques avancent bien avec des sorties et tout, je ne m'inquiète pas. Je sais que beaucoup se sont découragés par l'instabilité des sus-dites bibliothèques, donc je préfère voir ces bibliothèques se stabiliser d'abord. :)

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

          • [^] # Re: Dommage que la dépêche soit un peu courte

            Posté par . Évalué à  1 .

            La version E17 des dépôts est une base. Ce sont les packageurs/mainteneurs de distribution qui devraient faire leur propre version.
            GTK/Gnome c'est pareil, la version pardéfaut est horrible.

            • [^] # Re: Dommage que la dépêche soit un peu courte

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

              Je ne parle pas tant du thème mais de la logithèque minimale : menu d'applications, bureau, interface de gestion des fenêtres, interface de configuration, les divers greffons... Ça reste du code, des applis en EFL, aussi petites soient-elles...

              Et je pense que pour un logiciel aussi mouvant qu'E17, se référer à une version figée de distribution, cela n'a rien de représentatif ! On n'en est pas encore à pouvoir exiger d'un mainteneur de cuisiner une adaptation aux petits oignons, alors que ça casse plus souvent qu'une distrib à cylce court...

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

          • [^] # Re: Dommage que la dépêche soit un peu courte

            Posté par . Évalué à  2 .

            Ah, bah, c'est bien le point que je vois aussi. Si il y en a avec une ame de designer et de bonnes idees d'interfaces, faites des mockups, venait nous en parler sur #e.fr !

            PS: Surtout si ca ne ressemble pas a ce qui existe, iOS, android, KDE, Unity, GNOME3, ... :-)

    • [^] # Re: Dommage que la dépêche soit un peu courte

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

      Le canvas est stateful, le mieux pour comprendre l'intérêt est de lire leur tutoriel (en gros si on dessine un rectangle et qu'on veut le faire bouger, au lieur d'effacer le canvas et en redessiner un autre comme on ferait dans la plupart des toolkits, on lui dit juste de se déplacer.

      C'est aussi le cas des deux toolkits que j'ai programmés, à savoir Tk (widget canvas) et Gtk (widget GnomeCanvas). Cela m'étonnerait bien que Qt ne propose pas un widget analogue. Il se pourrait que la première apparition de ce type de widget soit dans Tk.

      • [^] # Re: Dommage que la dépêche soit un peu courte

        Posté par . Évalué à  9 .

        C'est aussi le cas des deux toolkits que j'ai programmés, à savoir Tk (widget canvas) et Gtk (widget GnomeCanvas).

        Tu as programmé TK et Gtk ? Balaise !

      • [^] # Re: Dommage que la dépêche soit un peu courte

        Posté par . Évalué à  -1 .

        Pas vraiment, c'est canvas travaille uniquement au niveau pixel. Une fois que ta demande est fait, ils n'ont plus aucune idee de ce que tu leur as demande, une image, une ligne, du texte. Cette information perdu est ce qui fait la difference entre un canvas statefull et un canvas classic. Qt a decide d'appeler le sien, SceneGraph, si tu preferes ce terme.

        Et ce n'est pas un widget, mais veritablement le systeme de rendu de Evas. Les widgets sont construit au dessus. Donc rien a voir avec les widget canvas de Tk et GTK. A la rigueur avec le scenegraph de Qt, mais celui-ci est beaucoup plus recent et donc moins avance que Evas.

        • [^] # Re: Dommage que la dépêche soit un peu courte

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

          Pas vraiment, c'est canvas travaille uniquement au niveau pixel. Une fois que ta demande est fait, ils n'ont plus aucune idee de ce que tu leur as demande, une image, une ligne, du texte.

          Et bien non, justement: c'est le contraire de ce que tu dis que j'ai écrit et je ne me uis pas trompé. En Tk on utilise la méthode create du canvas pour créer des objets:

          pathName create type coordList ?option value ...?
          Create a new item in pathName of type type. The exact format of the arguments after type depends on type, but >usually they consist of the coordinates for one or more points, followed by specifications for zero or more item >options. See the subsections on individual item types below for more on the syntax of this command. This command returns >the id for the new item.

          Comm indiqué par la doc cette opération retourne un id qui peut être utilisée pour manipuler ultérieurement les objets crées, ce qui vu de chez moi ne ressemble pas trop à un oubli. Dans Gtk, GnomeCanvas offre exactement le même fonctionnement et ça m'étonnerait bien que Qt ne propose pas un mécanismen analogue.

          • [^] # Re: Dommage que la dépêche soit un peu courte

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

            Qt propose un QCanvas depuis des lustres. Je me souviens de l'avoir utilisé en Qt 2 pour écrire des jeux. Il y avait de la gestion de sprite et de la gestion d'animations. Cela dit, c'était pas l'élément le plus mis en avant dans Qt et côté accélération graphique, ça pouvait vite être à la rue.

            Mais bon, avec Qt 3 puis Qt 4, le canvas de Qt est repassé au premier plan et c'est tout à fait tout à fait stable.

            C'est vraiment dommage les EFL, je me souviens de la première présentation à l'OSDEM (devenu FOSDEM depuis), c'était carrément génial. Mais plus de 10 ans après avec très peu d'évolutions de fond, c'est plus difficile de le voir comme une innovation majeure...

    • [^] # Re: Dommage que la dépêche soit un peu courte

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

      pas de vectoriel, tout utilise des images bitmap. La qualité graphique ne s'en ressent pas, mais au niveau rapidité ça n'a rien à voir

      Dis comme ça ca paraît magique, et ca va surtout à contre-courant de beaucoup de toolkit : et quand t'anime les contenus, c'est toujours aussi rapide et avec la même qualité ?

      • [^] # Re: Dommage que la dépêche soit un peu courte

        Posté par . Évalué à  0 .

        Faire du rendu de bitmap est toujours plus rapide que du rendu vectoriel, donc les animations sont forcement toujours aussi rapide et avec la meme qualite (le pixel n'est pas degrade lors de l'animation).

        • [^] # Re: Dommage que la dépêche soit un peu courte

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

          Et comment tu fais si ton animation fait tourner ton bitmap ? Comment tu fais pour le rendre proprement ? Avec un vectoriel c'est facile, avec un bitmap m'étonnerais que tu puisse facilement.

        • [^] # Re: Dommage que la dépêche soit un peu courte

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

          Oué enfin dès que tu fais une animation, tu dois soit déformer le bitmap original et perdre en qualité (si on met de côté une simple animation visant à downscaler un bitmap) ou bien recalculer le contenu de ton bitmap... à partir de contenus vectoriels.
          T'as une autre astuce magique ?

          • [^] # Re: Dommage que la dépêche soit un peu courte

            Posté par . Évalué à  2 .

            Oui, l'etre humain et plus precisement son oeuil :-)

            Tout d'abord, avec un bon algo d'interpolation et de l'anti-aliasing, tu arrives a faire des approximations lors de la deformation d'une texture qui ne sont vraiment visible que par un oeil averti en entraine. Et cela quand il n'y a pas d'animation.

            Parce que lorsqu'il y a une animation, l'oeil humain est incapable de voir les details. C'est pour cela que dans la pratique, tu peux meme desactiver les algos les plus complexe lors des animations. Edje, le format de description de scene des EFLs, permet de le faire au cas par cas.

            • [^] # Re: Dommage que la dépêche soit un peu courte

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

              Prenons un exemple tout bête : un rectangle de 200x300 avec une bordure de 5 pixels.
              Tu veux lui appliquer un effet qui le transforme en un parallépipède (angle 15°), durée de l'animation de 5 secondes.

              Si on utilise les 2 techniques :
              - recalculer la figure d'un point de vu vectoriel 10x par seconde.
              - appliquer une transformation 15x par secondes à un bitmap correspondant.

              A ton avis :
              - Laquelle va être le plus jolie, pendant l'animation, et à la fin de la transformation ?
              - Laquelle est celui qui va bouffer le plus de CPU ?
              - Laquelle peut être facilement transformé en primitives vectorielles efficaces pour un GPU ?
              - Laquelle peut toujours gérer un cache Bitmap quand c'est pertinent ?
              - Laquelle est la plus souple en terme de contenu ? (bah oui, si le contenu de ton bitmap doit être dynamique, avec des textures provenant d'images internet, il faudra que tu recalcules tous tes bitmaps...)

              • [^] # Re: Dommage que la dépêche soit un peu courte

                Posté par . Évalué à  3 .

                Donc on part sur une animation lente, va falloir garder les algo qui te font du lissage un peu intensif pour avoir un bon resultat. Je suis pret a te prendre le parie que tu distinguera difficilement la difference de resultat sur une aussi petite resolution.

                Pour ce qui est la consommation CPU, la source est peu complexe, donc effectivement en vectoriel, tu dois pouvoir avoir des performances correct. En bitmap, l'effort de calcul est assez limite aussi, c'est juste 300 spans horizontaux, rien de bien sorcie. Compter une trentaine d'instructions par pixels, deux acces memoire en lecture et un en ecriture pour la complexite complete de l'operation, quelque soit le contenu de ton image.
                Apres tu as un premier niveau d'optimisation, si le coeur de ton rectangle n'a pas d'alpha, on passe sur un algo de copy de pixels et non de blend. Resultat, un acces memoire en moins et quelques instructions de gagne. Enfin si ton rectangle est de couleur pleine, je ne fairais que les bordures avec une image, definissant le milieu comme vide et utiliserait un rectangle plein a la place. La, niveau perf, on sera au mieux dans la meme cour, voir si tu perds trop de temps dans la generation des bordures avec une tete d'avance pour le rendu bitmap (l'algo pour generer un rectangle plein sans alpha est trivial, juste un memset). Mais bon dans ton exemple avec un simple rectangle et un bon moteur vectoriel, je pense que tu dois reussir a pouvoir tenir la comparaison, mais si maintenant tu le remplis avec un gradient, ca ne sera plus le cas.
                L'interet du rendu bitmap, c'est aussi que tu as moins de primitive a optimiser et donc que tu peux potentiellement faire plus d'effort de ce cote la.

                Pour ce qui est du GPU, les spans, c'est un peu la premiere chose qu'un GPU sait faire, alors niveau optimisation, ta seule limite va etre la bande passante memoire a laquelle tu as acces. Pour ce qui est du vectoriel, tes performances vont vite avoir du mal, si les shader deviennent trop complique ou que en as trop, mais c'est sur, sur un rectangle, ca passera tres bien.

                Sinon si le vectoriel etait si performant et si bien pourquoi veux-tu pouvoir generer un cache Bitmap et perdre de la memoire pour ca ? ;-)

                Enfin pour les questions de souplesse faut-il encore que les bibliotheques qui gerent le vectoriel soit vraiment complete et fonctionne bien. Ce qui n'est pas le cas aujourd'hui. Donc ton artiste, il se limitera un peu par rapport a une image bitmap aux petits oignons... En plus, il y a une chose qui va etre embettant en vectoriel, si tu veux des images avec plus ou moins d'information en fonction de la resolution, tu fais comment ?

                • [^] # Re: Dommage que la dépêche soit un peu courte

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

                  Moi au final, mon framework me génère un bitmap en cache et fait faire l'opération par le GPU. Je garde la souplesse niveau programmation (mon rectangle peut être défini dynamiquement, avec toutes les variantes que je veux), et je conserve les perfs avec l'acceleration GPU.

                  Bref : il faut mieux un framework vectoriel qui sait aussi gérer les bitmaps qu'un framework qui ne te propose que les bitmaps.

    • [^] # Re: Dommage que la dépêche soit un peu courte

      Posté par . Évalué à  5 .

      pas de vectoriel, tout utilise des images bitmap. La qualité graphique ne s'en ressent pas, mais au niveau rapidité ça n'a rien voir

      Je suis aussi plutôt pour les trucs simples, robustes et rapides, mais les diversités radicales de résolutions qu'on rencontre aujourd'hui peuvent compliquer la donne.

      • [^] # Re: Dommage que la dépêche soit un peu courte

        Posté par . Évalué à  6 .

        Avec un bon scaler, tu peux deja supporter une vaste gamme de resolution. Tes icones ont tres peu de chance de devoir faire 512x512, donc tu as finalement besoin d'un jeu de resolution plutot limite. Enfin le vectoriel ne regle pas vraiment tous les problemes en basse resolution, tu ne peux pas mettre autant d'element graphique dans un icone que en haute resolution par exemple.

        En fait, le vectoriel est utilise sur le desktop comme une reponse generic a un probleme qui n'existe pas vraiment. Les resolutions a supporte sont borne et par la meme occasion l'usage d'un theme aussi. D'ailleur les problematiques lie aux resolutions sont plutot de l'ordre du dpi, de l'aspect ratio et de la taille du pointeur a l'ecran (doigt ou souris).

  • # Erreur dans la dépêche

    Posté par . Évalué à  10 .

    Le lien vers l'annonce officielle:
    http://article.gmane.org/gmane.comp.window-managers.enlightenment.devel/36417 (pas très intéressant, il y a juste les archives)

    Par contre attention, le Freebox Player n’utilise pas les EFL pour son interface, uniquement pour le SDK Elixir (qui était déjà présent sur la v5). Si un modérateur pouvait corriger ça…

  • # Je me lance, pas taper !

    Posté par . Évalué à  10 .

    Question d'un béotien (et pourtant Dieu sait -ou pas- que j'utilise Linux depuis longtemps) en matière d'interface graphique...

    Pour l'instant je n'ai fait que du Gnome et du KDE (avec une large préférence pour ce dernier d'ailleurs), mais j'ai jamais essayé des environnement "alternatifs". Au quotidien, y a-t-il des inconvénients ? De compatibilité ou de ne je ne sais quoi ?

    Voilà, c'est con, mais j'aime pas galérer sur des sujets que je connais pas (j'aime galérer dans les autres ;) et l'environement graphique... bin j'y connais que dalle.

    Motivez-moi et je testerai E17 avec grand plaisir !

    • [^] # Re: Je me lance, pas taper !

      Posté par . Évalué à  6 .

      Je suis resté pendant pas mal de temps utilisateur d'E17 et j'ai arrêté il y a environs 2 ans pour revenir sur gnome.

      J'utilisais et utilise toujours une ubuntu principalement par soucis de facilité. J'ai pas envie de me prendre la tête à configurer tout aux petits oignons. Comme dit plus haut, il est clair que les EFL sont d'une qualité indéniable. C'était moins le cas de E17 par contre... bien que largement utilisable, peu (voir pas) de bugs, rapide comme l'éclair, il manquait à l'époque de facilités qu'offre compiz en matière de gestion des fenêtres (exposé like, grid like et consorts). Pareil pour les ombrages dont le plugin de compositing était bien buggé.

      Rajoutons à ça le manque de thèmes suffisamment compacts et fignolés aux petits oignons, le manque d'intégration avec les applications gtk/qt, l'IHM pas très orientée desktop, etc.. j'ai abandonné malgré mon long périple avec (2 ? 3 ans ?), 2 thèmes commencés mais jamais terminé pour raison de changement d'API et de plus le temps, etc.

      Je crois que j'y retournerai le jour où j'aurai droit à la même intégration entre le E17 et les applications que j'utilise quotidiennement, et une interface plus dans l'esprit desktop. En attendant, il me manque parfois, certes, pour son aspect customisable notamment (étant sous gnome, vous comprendrez..).

      A côté de ça, d'un point de vue technique, c'est assez bluffant.

      • [^] # Re: Je me lance, pas taper !

        Posté par . Évalué à  3 .

        pareil pour les ombrages dont le plugin de compositing était bien buggé.

        Non mais sans déconner, ça sert à quoi de l'ombrage sur les fenêtres ? Comme les effets à la con, genre la fenêtre qui ondulent quand on les déplace.

        C'est beau et funky mais "what for" ?

        J'admets que la transparence puisse avoir une utilité (et encore...) mais tous les autres effets kikoolol je ne comprends vraiment pas.

        Ça doit être l'âge...

        • [^] # Re: Je me lance, pas taper !

          Posté par . Évalué à  2 .

          Ca ne 'sert' a rien si n'est que look indus, aussi efficace soit t'il finit par être déprimant a la longue. Je vais parler de Windows parce que c'est ce que je connais de mieux, même si je connais linux depuis 99.

          Globalement pour mon usage personnel, Windows 98 faisait la même chose. Apres tout un Os pour moi, ca copie des fichier, ca permet de lancer des programmes, le reste comment il fait , j'en ai franchement rien a branler. Je dois pas lancer de programmes qui nécessite de nouvelle fonctionnalités pour dire... J'utilise pas de reconnaissance vocale, je m'amuse pas a crypter mes infos, mes backups consiste a faire du copier coller (parce que mes fichiers ne se pretent a rien d'autres de toute façon) Ben même si Windows Seven ne m'apporte pas grand chose, ben l'impression est que c'est plus agréable plus 'fini'. Certes ca consomme pas mal de ram en plus mais bon ca les vaut. Parce que y a eu des ergonomes qui sont passer derrière pour calculer a quelle vitesse une fenêtre passait en arriere plan, avec quel dégradé, comment les vignettes apparaisse en bas, leurs tailles etc. C'est aussi pour ca que il y pas d'options 'fenetres qui font des vagues a la cons' alors que c'est parfaitement possible. Une foultitude de petit detail a la con qui fait qu'on se sent bien sans se dire 'il manque un truc, je sais pas quoi mais il manque un truc' Et ca out of the box: j'ai une image de fond, choisi un theme de couleur...et c'est tout.

          sous Linux y a toujours un truc a la con qui m'enerve au plus haut point: les fenetres qui se redimensionnent automatiquement parce que le texte prends plus de place. Ha ouais genial sauf que: la plupart du temps on fini avec des ascenseurs. Pourquoi ne pas donc prévoir une taille de fenêtre de base qui convient a la majorité des cas et foutre des ascenseurs au besoin. Parce que la fenêtre qui s'auto ajuste, ca veut dire qu'elle change de place/taille, ca veut dire que si tu etais en train de lire, ben t'es oblige de retrouver ou tu en etais vu que le texte a bouge! C'est pénible au possible déstabilisant et particulièrement crétin. Suffit de voir comment sont geres les miniatures sou kde: ca bouge mal , quand on passe d'une miniature a l'autre c'est pas fluide etc. Ca fait pas fini...bricolage...Et on en revient a un truc: l'OS (partie graphique) qui ne se fait pas oublier du tout. J'ai pas envie de bricoler mon outil pour pouvoir bricoler.... Linux c'est le genre formule 1, Ou si tu fais pas mouler le baquet a tes fesses ben tu y est hyper mal installe...et tu finis dans le premier platane parce que t'es pas aller assez vite...(pas d'appuis). Heureusement que Windows et Mac sont la pour fournir Rolls et Bentley.

          Et je precice mon pc c'est un Pentium M 2ghz avec 2gig de RAM, et un radeon fire gl. Un pc sorti debut 2005. (t42p)

          Le truc pour finir: j'ai installe la chose sur un duron 1,8ghz , 1gig de ram a cote d'une fedora 16 radeon hd2600 windows seven fonctionne parfaitement, et je peux lancer un dvd sans probleme. Sous fedora une fois les plugins installe je lance et ca rame comme pas possible... le coupable, comme d'habitude sous Linux je dirais:pulseaudio, sous vlc allez savoir pourquoi ca psse un peu mieux.

          Sous Seven je clique sur l'icone son, son, melangeur, et hop je peux couper le son de firefox directement, en 3 clics. J'ai pas eu besoin de lire le manuel pour trouver. Sous linux faudrait deja que le son fonctionne correctement aveant de penser a ce qu'il y ait une interface graphique qui fonctionne pour le regler. Sous linux il existait des outils graphique pour pirater le WEB du voisin AVANT que le support du WPA soit aussi efficace...(forcement le WPA se piratant pas...)

          Bref l'ombrage sur les fenetres ca sert a rien, mais c'est comme les bouclier peints couleur carrosserie. Ca rend la voiture moins moche. Et comme dans le monde automobile, c'est pas aussi evident que ca en a l'air (avoir la meme teinte qui resistent sur des supports different (acier / plastique et un cauchemard)

          • [^] # Re: Je me lance, pas taper !

            Posté par . Évalué à  2 .

            Sous gnome 3, je clique sur mon icone de son, je clique sur paramètre du son, je clique sur applications et je peux régler le niveau de volume de chaque application. Donc là il faut 4 clics pour couper le son de firefox, mais bon, la difficulté est pas surhumaine.

          • [^] # Re: Je me lance, pas taper !

            Posté par . Évalué à  3 .

            c'est comme les bouclier peints couleur carrosserie. Ca rend la voiture moins moche

            Mais ça ne sert strictement à rien.

            C'est fou comme l'analogie automobile/informatique est souvent pertinente :)

            En fait tu serais prêt à acheter une voiture parce qu'elle est belle, même si la mécanique est exécrable.

            Pour moi tu es une victime de la mode, je pèse mes mots. Tu es peut-être très sympa par ailleurs et je te remercie de donner ton avis.

            forcement le WPA se piratant pas...

            L'algorithme de chiffrement de WPA n'a pas été cassé comme celui du WEP mais ça se pirate également, par la force brute. Si tu as mis "soleil" comme clé WPA il suffit d'un seul paquet à un attaquant pour trouver la clé...

            Quand à ta mauvaise expérience sous KDE je ne dirai rien, j'ai pas utilisé KDE depuis une bonne dizaine d'années. Mais il y a d'autres gestionnaires de bureau. Tu as le choix.

            • [^] # Re: Je me lance, pas taper !

              Posté par . Évalué à  1 .

              'En fait tu serais prêt à acheter une voiture parce qu'elle est belle, même si la mécanique est exécrable. '
              Non, mais entre une voiture moche et qui fait du 6,8l au cent et une que j'aime a 6,9l je prendrais celle a 6,9l
              Et c'est un peu le genre d'ecart qu'il y a entre les differents desktop...

              'De quoi? Je n'ai pas ce comportement sur mon KDE, ni sur Gnome, ni sur un autre DM sinon j'aurai pete un cable.'
              Heu, je crois que tu ne regarde pas ton ecran...rien que le manager de connexion (gdm je crois sur fluxbox) le fait...
              tu cliques sur ton nom la fenetre s'agrandie, tu tapes ton mot de passe si tas fait une erreur elle rechange de taille etc etc...c'est globalement variable sur tout les fenetres ayant un contenu variant. Et j'ai jamais dis 'pendant que tu tappais un texte' mais 'quand tu est en train de lire'. Je crois qu'ils ont pas du ose le faire pendant la frappe...
              C'est une installation de base de fluxbow.

          • [^] # Re: Je me lance, pas taper !

            Posté par . Évalué à  7 .

            _sous Linux y a toujours un truc a la con qui m'enerve au plus haut point: les fenetres qui se redimensionnent automatiquement parce que le texte prends plus de place. _

            De quoi? Je n'ai pas ce comportement sur mon KDE, ni sur Gnome, ni sur un autre DM sinon j'aurai pete un cable. Les fenetres qui se redimensionnent quand j'ecris... Tu as un truc vraiment bizarre. Chez moi les fenetres gardent la taille que je leur ait donne et si le DM s'amusait a touchait a cela il degagerait direct.

            le coupable, comme d'habitude sous Linux je dirais:pulseaudio, sous vlc allez savoir pourquoi ca psse un peu mieux

            Une fois n'est pas coutume, je pense que tu te trompes dans ton analyse vu que VLC utilise aussi PA maintenant. Je soupconne plutot le backend Gstreamer...

            • [^] # Re: Je me lance, pas taper !

              Posté par . Évalué à  0 .

              'Une fois n'est pas coutume, je pense que tu te trompes dans ton analyse vu que VLC utilise aussi PA maintenant. Je soupconne plutot le backend Gstreamer...'
              Non je me trompe pas, et c'est ce qui est d'autant plus ridicule....VLC utilise bien Pulseaudio, mais celui ci prends moins de ressources quand VLC l'utilise...(je regardais ca avec top en ligne de commande pour comprendre)
              Certainement une question de parametres (allez savoir si tous totem ca redemander pas un surechantillonage decodage dts 7.1 au passage...)
              Comme toujours ce sont surement les reglages par default qui sont pas adaptes (j'ai pas parle de swappiness tiens...)

              • [^] # Re: Je me lance, pas taper !

                Posté par . Évalué à  1 .

                Et le son il est envoye pas quoi a ton avis a PA? Je suis persuade que c'est gstreamer le probleme. Si c'etait PA tu aurais le meme comportement avec les deux logiciels. Fait un test avec un logiciel utilisant Xine. Si tu as de nouveau le probleme tu as peut etre raison sinon je pense que c'est moi.

                • [^] # Re: Je me lance, pas taper !

                  Posté par . Évalué à  -4 .

                  Peut etre, en meme temps, je m'en fous, sous Windows Seven sur ce meme pc, le truc peut presque lire un blu ray (presque) grace a l'acceleration materiele de la radeon hd.
                  Sous la derniere Fedora, je vais pas me prendre la tete a savoir pourquoi un simple dvd rame...
                  C'est le genre de detail qui devrait etre regle depuis longtemps quand on pretends fournir un desktop moderne.
                  Alors oui c'est peut etre (surement) la faute d'un materiel pas bien supporte...mais bon, Microsoft fait ce qu'il faut pour que ca marche, Apple fait ce qu'il faut pour que ca marche....Linux ...s'en fout et ne s'occupe que du monde materiel des serveurs..

                  • [^] # Re: Je me lance, pas taper !

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

                    Le jeudi 17 novembre 2011 à 22:28 +0100, Riendf a écrit :
                    > C'est le genre de detail qui devrait etre regle depuis longtemps quand on pretends fournir un desktop moderne.

                    Qui ?

                  • [^] # Re: Je me lance, pas taper !

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

                    Microsoft fait ce qu'il faut pour que ca marche,

                    Ce sont surtout les fabricants qui développent les pilotes.

                    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                  • [^] # Re: Je me lance, pas taper !

                    Posté par . Évalué à  0 .

                    Ca je suis d'accord que les Blue-Ray devraient etre lisible sur les OS libre mais cela n'est pas possible merci les protections debiles. C'est la meme chose que lorsque les DVDs sont arrive, il a fallu attendre dvdjon et libdvdcss pour regler ce probleme. Cela n'a strictement rien avoir avec Linux et comme tu le dis toi meme cela fonctionne bien avec VLC dont le probleme n'est pas Linux. Tu fais un super raccourcis.
                    Dans le meme style d'idee tu peux aussi dire que Linux c'est de la merde parceque Microsoft Office n'existe pas dessus.

        • [^] # Re: Je me lance, pas taper !

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

          Pour moi, l'ombrage ça rajoute un peu de profondeur à la superposition des fenêtres. Et je trouve qu'au premier coup d'oeil, ça m'aide un peu mieux à distinguer les fenêtres les unes des autres. Quand tout est à plat (et qu'il y a plusieurs bouts de fenêtres visibles sur l'écran), ça fait un peu fouilli. Bon après, c'est peut-être une perception très personnelle...

        • [^] # Re: Je me lance, pas taper !

          Posté par . Évalué à  6 .

          Les ombrages ont une importance pour ce qui est du confort visuel. Quand tu travailles avec plusieurs fenêtres les unes sur les autres, c'est beaucoup plus facile de différencier quelle fenêtre est au dessus et quelle fenêtre est en dessous lorsqu'il y a l'effet d'ombrage.

          Ça permet de donner un effet de profondeur qui aide le cerveau à voir les différences.

          Du moins, c'est ce que je perçois.

    • [^] # Re: Je me lance, pas taper !

      Posté par . Évalué à  3 .

      Essaye, ça ne coute qu'un peu de temps.
      Pour ma part, à chaque fois que j'ai essayé enlightenment, ce qui m'a un fatigué c'est de ne pas pouvoir facilement créer une icone sur le bureau. Pour lancer une application, il faut cliquer au moins trois fois...
      Ceci dit, je ne demande qu'à changer d'avis.

      • [^] # Re: Je me lance, pas taper !

        Posté par . Évalué à  -3 .

        Pour lancer une application, il faut cliquer au moins trois fois...
        Ah bon ?

        Methodes que je connai :
        1) click sur le bural, qui affiche le menu, ensuite on se balade dans le menu (clavier ou souris, les deux fonctionnent) et on choisi donc l appli au click ou au clavier en appuyant sur entree (donc ca fait 2 clicks)

        2) L application est dans une ibar = 1 click

        3) Alt+Escape -> ca lance omni, tu peux soit choisir ton appli au click, ou tout au clavier, ou un mix des deux (donc ca fait entre 0 et ... plein de clicks)

        Et il y a encore bien d autres maniere de faire

    • [^] # Re: Je me lance, pas taper !

      Posté par . Évalué à  3 .

      Essaye de tester Xfce. Avec des bouts de Gnome (gvfs, gnome-session) moi j'aime bien cet environnement. C'est simple, propre, à l'ancienne (avec une barre de tâches quoi...) Les raccourcis clavier sont facilement configurables.
      Xfce

      • [^] # Re: Je me lance, pas taper !

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

        Essaye de tester Xfce.

        Non, tente plutôt d'essayer une tentative de mettre à l'épreuve un test de LXDE car contrairement à cette phrase il est encore plus simple et léger...

        GNU's Not Unix / LINUX Is Not Unix Xernel

        • [^] # Re: Je me lance, pas taper !

          Posté par . Évalué à  4 .

          tente plutôt d'essayer une tentative

          Ok. Je ne connais pas LXDE (à part de nom) mais avoue que déjà Xfce offre une alternative plus que viable à Gnome ou KDE quand il s'agit d'avoir un bureau fonctionnel et agréable.

          Après si on veut faire léger on peut aussi ne pas utiliser de DM et lancer ses applications directement dans X, mais bon.

          • [^] # Re: Je me lance, pas taper !

            Posté par . Évalué à  7 .

            Ou sinon, on peut utiliser un Wm. Au pif :
            awesome, dwm, wmi, openbox, blackbox, fluxbox, fvwm, subtle, wmfs, ratpoison, xmonad,sawfish, stump wm, window maker, etc, etc, etc.

          • [^] # Re: Je me lance, pas taper !

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

            Mais non, si on veut vraiment faire léger, on reste en mode console. Au pire il y a ncurses pour les interfaces "graphiques".

            Par contre, il faudrait plus de développeurs pour les portages de Gimp et Inkscape en ncurses, parce que moi je rame à mort!
            --------------> [ ]

  • # Application EFL sous Gnome et KDE ?

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

    Peut-on facilement réaliser une application basée sur EFL et qui tournera sous différent gestionnaires de bureau (Gnome, KDE, etc.) ?

    J'imagine que cette application serait dépendante de librairies EFL un peu comme lorsqu'on lance une application KDE sous Gnome...

Suivre le flux des commentaires

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