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.
|
|
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.
Aller plus loin
- Les sources des EFL 1.1.0 (266 clics)
- Enlightenment France (1467 clics)
- Enlightenment (727 clics)
- Twitter du projet (66 clics)
# MOUARFFF
Posté par Albert_ . É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 dyno partouzeur de drouate . Évalué à 4.
et gcoincoin
[^] # Re: MOUARFFF
Posté par Michaël (site web personnel) . Évalué à 4.
et gpanpan
[^] # Re: MOUARFFF
Posté par gregR ☯ (site web personnel) . Évalué à 2.
mais non, le 13/12/11 n'est pas si loin... \_o<
http://gregr.fr
[^] # Re: MOUARFFF
Posté par Michaël (site web personnel) . Évalué à 2.
PANPAN
[^] # Re: MOUARFFF
Posté par Pierre . É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 Maclag . É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 Goffi (site web personnel, Mastodon) . É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 Thomas Debesse (site web personnel) . Évalué à 6.
Très intéressant article, une perle rare, comme il le dit lui-même...
Et sinon, c'est la prochaine fois que je vois parler d'E18 !
Après quelques recherches sur google j'ai trouvé des pistes :
http://trac.enlightenment.org/e/wiki/CompositeManager
https://desktopsummit.org/sites/www.desktopsummit.org/files/E17-DesktopSummit2011.pdf
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 :
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 cedric . Évalué à 4.
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 Sytoka Modon (site web personnel) . É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 GeneralZod . É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 Thomas Debesse (site web personnel) . É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 Watchwolf . É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 Thomas Debesse (site web personnel) . É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 cedric . É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 Michaël (site web personnel) . Évalué à 6.
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 ecyrbe . Évalué à 9.
Tu as programmé TK et Gtk ? Balaise !
[^] # Re: Dommage que la dépêche soit un peu courte
Posté par cedric . É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 Michaël (site web personnel) . Évalué à 5.
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
createdu canvas pour créer des objets:Comm indiqué par la doc cette opération retourne un
idqui 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 Philippe F (site web personnel) . É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 TImaniac (site web personnel) . Évalué à 3.
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 cedric . É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 CrEv (site web personnel) . É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 TImaniac (site web personnel) . É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 cedric . É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 TImaniac (site web personnel) . É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 cedric . É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 TImaniac (site web personnel) . É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 Guillaume Knispel . Évalué à 5.
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 cedric . É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 Aissen . É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…
[^] # Re: Erreur dans la dépêche
Posté par Nico C. . Évalué à 4.
+1
D'ailleurs, dans une offre d'emploi sur le site, ils parlent plutot de QtQuick
[^] # Re: Erreur dans la dépêche
Posté par gallenza . Évalué à 1.
Oui, la Freebox utilise QML, le screenshot de le dépêche est une grossière induction en erreur, les EFL étaient juste utilisées pour un SDK (javascript) mytheux de jeux vidéo pour les freebox (sans succès connus).
[^] # Re: Erreur dans la dépêche
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 10.
"mytheux" ? c'est un synonyme de "en tiques" ?
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Erreur dans la dépêche
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 4.
...ou plutôt de "haut en tiques" ?
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Erreur dans la dépêche
Posté par Julien Fontanet (site web personnel) . Évalué à -1.
25 minutes que le bonhomme il cherche des jeux de mots :)
[^] # Re: Erreur dans la dépêche
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 5.
pfff... mais non... 84 minutes !
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Erreur dans la dépêche
Posté par Maclag . Évalué à 2.
et demi!
[^] # Re: Erreur dans la dépêche
Posté par Davy Defaud . Évalué à 2.
My bad! Deleted...
# Je me lance, pas taper !
Posté par gUI (Mastodon) . É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 !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Je me lance, pas taper !
Posté par Elfir3 . É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 Marotte ⛧ . Évalué à 3.
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...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je me lance, pas taper !
Posté par Sébastien B. . É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 Marotte ⛧ . Évalué à 3.
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.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je me lance, pas taper !
Posté par Albert_ . É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...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je me lance, pas taper !
Posté par Albert_ . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Je me lance, pas taper !
Posté par Juke (site web personnel) . É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 claudex . Évalué à 5.
Ce sont surtout les fabricants qui développent les pilotes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Je me lance, pas taper !
Posté par Albert_ . É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 Meku (site web personnel) . É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 Elfir3 . É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 xavier dumont . É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 kur1g3n . Évalué à -3.
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 Marotte ⛧ . É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 Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 9.
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 Marotte ⛧ . Évalué à 4.
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 Enjolras . É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 Tonton Th (site web personnel, Mastodon) . Évalué à 4.
twm
[^] # Re: Je me lance, pas taper !
Posté par Maclag . É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 Space_e_man (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.