Les EFL (Enlightenment Foundation Libraries) sont sorties en version 1.1.0. Par rapport à la version 1.0.1, beaucoup d'erreurs sont corrigées, des améliorations en vitesse, en qualité de rendu graphique, en support de plateforme on été faites, ainsi que l'ajout d'API.
Pour rappel, les EFL sont un ensemble de bibliothèques écrites en C sous licence BSD (sauf la bibliothèque Eina qui est sous LGPL 2.1), principalement orientées vers le graphisme, mais intégrant aussi une boucle principale, support du réseau, etc. Elle se veulent extrêmement optimisées (en empreinte mémoire et vitesse dans le rendu graphique), et donc sont adaptées aussi bien aux desktops (fonctionnant bien sur un 486 par exemple) qu'à l'embarqué (téléphones portables, tablettes).
Les principales différences avec la version 1.0.1 sont (la liste n'est pas exhaustive) :
Eina (boite à outils) :
- ajouts : parseur XML SAX, Mutex et conditions ;
- améliorations : le chained mempool est plus rapide, support des threads.
Eet (compression de données avec ou sans perte, sérialisation) :
- améliorations : empreinte mémoire et vitesse pour les unions et tableaux, qualité de l'encodage/décodage JPEG au détriment de la vitesse.
Evas (canevas graphique stateful) :
- ajouts : chargeurs WBMP, PSD, ICO, ainsi que des chargeurs GPL (PDF, PS, XCF, vidéos, etc.), plus support de l'écriture bi-directionnelle, espaces de couleurs NV12 et MT12, moteur de rendu Open GL pour Mac OS X ainsi que de harfbuzz ;
- améliorations : vitesse d'affichage des rectangles et des textes, empreinte mémoire pour les textes.
Ecore (boucle principale, et tout ce qui touche aux évènements) :
- ajouts : support de Mac OS X, support de la gestion de la luminosité, IPC sous Windows ;
- améliorations : empreinte mémoire dans la boucle principale, redimensionnement des fenêtres et socket local sous Windows, couche réseau plus performante grâce aux mempools, support des threads.
Embryo (machine virtuelle pour l'exécution de scripts dans les thèmes) :
- améliorations : support Windows XP et CE.
Edje (gestion des thèmes, avec possibilité d'exécution de scripts) :
- ajouts : support du « miroir », support de Lua pour les scripts ;
- améliorations : création/destruction des objets plus rapide.
Efreet (support des standard Freedesktop) :
- améliorations : vitesse globale.
E_dbus (D-Bus et ses composants : HAL, connman...) :
- ajouts : support de connman 0.7, API pour la notification ;
- améliorations : notification pour la version 0.12.
Eeze (support de périphériques via udev) :
- ajouts : plus d'informations sur la détection des disques, API de montage des disques et partitions.
Pour la liste complète : http://enlightenment.fr/2011/12/02/alpha-beta-et-release/
Les efforts se focalisent maintenant sur la sortie de Enlightenment 0.17 et des bibliothèques Eio (accès asynchrone au système de fichiers), Ethumb (génération de vignettes), Emotion (support de la vidéo dans le canvas) et Elementary (bibliothèque de widgets haut niveau).
Un grand merci à tous les contributeurs de ce projet et bienvenue à tous les nouveaux utilisateurs !
Aller plus loin
- Annonce en francais (332 clics)
- Annonce en anglais (101 clics)
- La documentation en anglais (36 clics)
- Un tres bon article en francais d'introduction aux EFL (390 clics)
- EFL 1.1 alpha sur LinuxFr.org (66 clics)
# la suite ?
Posté par Daweed . Évalué à 5.
Good news.
Et E17, c'est pour quand ? Y a une roadmap ? :)
[^] # Re: la suite ?
Posté par cedric . Évalué à 10.
Nous avons plutot une TODO list qui devient maintenant plutot courte. Il reste principalement trois gros items dans celle-ci actuellement :
- finaliser la boite de dialogue de gestion du multi-ecran
- integrer et finaliser le nouveau theme
- rendre plus robuste le gestionnaire de fichiers
Ca nous fait esperer une release assez prochainement !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la suite ?
Posté par Grunt . Évalué à 4. Dernière modification le 07 décembre 2011 à 00:40.
La version "en ligne" sera compatible Ipv6?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# E17
Posté par Nonor . Évalué à 9.
Personnellement, un E17 abouti c'est LE truc que j'attends sous linux depuis au moins 5 ans... Car un DM entièrement bâti sur les EFL, pourvu que l'ergonomie soit soignée, ça serait enfin une interface digne du 21ème siècle que nos systèmes libres méritent. Car en plus d'offrir une expérience utilisateur réellement efficace, je veux dire par là réellement réactive et performante, son aspect soigné, ses animations travaillées, et en plus l'originalité de l'ensemble qui dégage une véritable identité qui se démarque des autres (tous OS confondus) font des EFL le support idéal d'un environnement graphique de très grande qualité.
Seulement les problèmes on les connait... Déjà E17 n'est pas un DM mais plutôt un Desktop Shell. Ensuite les EFL évoluent sans cesse et j'ai régulièrement lu cette raison pour expliquer pourquoi si peu d'applications basées sur ces libs étaient développées puis maintenues à un niveau utilisable. Peut-on enfin espérer qu'avec la stabilité que semble avoir atteint le projet courant 2011 (je pense à la publication de la version 1.0 mais aussi à celle-ci) ce problème va être réglé, que des développeurs vont enfin se pencher sérieusement sur ces libs et que des projets vont naître de toute part et vivre pour de bon, sans être cassés tous les 6 mois par de nouvelles modifications de la base ??
Je sais que je rêve un peu mais bon... J'ai envie d'y croire, car aucune autre librairie graphique sous linux ne m'a donné cet espoir, j'ai vu les gnome 2, 3, kde 3, 4, les xfce défiler sous mes yeux et sous mes doigts, et malgré les grosses qualités de chacun de ces environnements je n'accepte toujours pas d'avoir des IHM qui manquent à ce point soit de réactivité, soit de modernité, soit de finition, soit de style (rayer la mention inutile), non je n'arrive pas à m'y faire... Donc j'attends et j'espère. Et étant moi même développeur particulièrement intéressé par les IHM, je n'attends qu'un signe de réelle stabilité du projet pour m'y mettre et attaquer une appli graphique pour E17 !
Alors, ai-je encore raison d'y croire ?
[^] # Re: E17
Posté par Steven Le Roux . Évalué à 7.
Je pense que tu as plutôt tord d'attendre alors ;)
En tant qu'utilisateur e17 depuis de nombreuse années, je ne vois aucun pb en tant qu'utilisateur averti, que d'utiliser un desktop shell non finalisé.
Je te rejoins sur le plan de la performance, quand je vois des gnome au boulot, j'ai l'impression que les os ont un problème...
Pour ce qui est des Libs, réjouis toi :) Effectivement la branche 1.* veut dire que l'api est stabilisé et maintenu, et c'est aussi une des base de Tizen la prochaine version de Limo, en collaboration entre Intel et Samsung. Donc le but est bien d'asseoir une base à une communauté éventuellement plus large de développeurs. Cela n'a ceci dit pas posé de pb à Calaos.fr, ordissimo.fr ou free.fr (pour les français) qui sont partis sur une version svn et ont contribué pour les fonctionnalités qu'ils trouvaient manquantes. Ce long temps de gestation a permit aussi aux devs d'avoir le recul nécessaire aux design des fonctionnalités et API. Ceci permet de fournir dans une version assez jeune en terme de version (1.1.0) un set de fonctionnalité important et éprouvé.
Voici un exemple de dev pour interface mobile : http://dev.enlightenment.fr/~captainigloo/2011/08/25/elfe-and-the-composited-windows-list/
Ou encore l'interface tactile calaos : http://blog.calaos.fr/?p=257
[^] # Re: E17
Posté par Enjolras . Évalué à 6.
Si tu possèdes du matériel avec un écran tactile oui. Sinon, tu peux repasser, e17 n'est plus conçu pour toi.
[^] # Re: E17 - un simple colorant de fenêtres ou un emulsifiant d'expérience utilisateur
Posté par Gabin . Évalué à 6.
C'est marrant ou frustrant quand on lit ça, on a l'impression que la version précédente était toute pourrie. Et c'est toujours la même rengaine avec la présentation des "release" de LL, release N: stJ'utilise Awesome comme gestionnaire de fenêtre able, ça poutre sur 486 ( sans préciser les limitations, cas d'utilisation ), API complète, etc...
release N+1: vitesse améliorée (sans dire sur quoi on se base), beaucoup d'erreurs corrigées (sans dire si elles étaient impactant dans la N-1 ) etc..
Ne vous y trompez pas, j'apprécie les EFL (sur le papier et e16 en l'an 2000), mais il y a beaucoup trop de promesse sans vraiment présenter quelque chose d'abouti avec. Un "simple" gestionnaire de fichier à l'aune de Thunar semble réellement avoir du mal à emerger, sans parler du "bureau/shell" e17 en eternel dev.
E17 c'est quoi finalement? qu'est-ce qu'un shell/WM est sensé faire/fournir?
Que doit-on espérer en terme de fonctionnalité? (pavage automatique, tags dynamique, éléments animés, systray, outis spécifiques à base d'EFL (gestionnaire de fichiers, applets, mediaplayer, navigateur web (Webkit+EFL), client mail bref des éléments de base à l'usage)
J'ai sans doute dépassé le cadre de ce que doit être le shell e17 mais si "on" développe une telle API pour au final ne dessiner que des bordures de fenêtres, des boîtes de dialogues et une barre de tâche, c'est assez génant.
Quand je vois Awesome, Openbox dont le but est défini, a gère des fenêtres de façon spécifique, et qui font très bien le boulot d'ailleurs et l'arlésienne E17 avec son API révolutionnaire® qui est plus que basique dans sa gestion des fenêtres et configurabilité, je me dis que quelque chose cloche entre l'annonce et la réalité.
Ou peut-être que je ne connais pas e17 et là je demenderai à vot' bon coeur de nous faire une petite présentation/comparaison. =)
MERCI
[^] # Re: E17 - un simple colorant de fenêtres ou un emulsifiant d'expérience utilisateur
Posté par barmic . Évalué à 2. Dernière modification le 07 décembre 2011 à 08:31.
Je suis d'accord avec cette partie. Par exemple, j'avais entendu dire que Ethumb avaient des performances de malade qu'aucune bibliothèque n'arrivait à avoir, je pensais naïvement qu'il y avaient un développement intensif dessus, il semble que non puisque c'est maintenant que ça va commencer à bouger pour elle.
De la même manière c'est vrai que depuis que je touche à linux (6 ou 7 ans), j'entends dire que les ELF c'est fait pour être rapide, c'est surprenant de voir encore aujourd'hui des gains à ce niveau là. Mais c'est pareil pour les navigateurs avec javascript chaque version et 30% plus rapide. Un jour ils feront mieux que les langages compilés (comme le C ou l'assembleur) à se train là.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: E17 - un simple colorant de fenêtres ou un emulsifiant d'expérience utilisateur
Posté par cedric . Évalué à 3.
Peut-etre parce qu'une fois qu'on a optimise quelque chose, son profil change et donc que l'on peut optimiser quelque chose d'autre. Il y a aussi le contexte materiel qui evolue. Aujourd'hui on est partie pour avoir du multi-coeur dans tous les environnements. Il devient donc interressant d'optimiser la stack de rendu en prenant cela en compte. En fait l'optimisation est une tache sans fin, on peut toujours faire mieux.
Pour ce qui est de ethumb, les travaux actuellement en cour dessus vont principalement impacter son API et tres peu ses performances. Les performances de cette bibliotheque viennent principalement de Evas et de Eet.
[^] # Re: E17 - un simple colorant de fenêtres ou un emulsifiant d'expérience utilisateur
Posté par barmic . Évalué à 1.
Probablement et on optimise des choses spécifiques qui ne servent pas dans tout les cas. C'est la présentation que je trouve dommage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: E17 - un simple colorant de fenêtres ou un emulsifiant d'expérience utilisateur
Posté par reno . Évalué à 2.
ELF --> EFL
[^] # Re: E17 - un simple colorant defenêtresou un emulsifiantd'expérienceutilisateur
Posté par Juke (site web personnel) . Évalué à 5.
Le vendredi 09 décembre 2011 à 15:02 +0100, reno a écrit :
> ELF --> EFL
en meme temps il a raison les elf sont plus rapide que les gnom
[^] # Re: E17 - un simple colorant de fenêtres ou un emulsifiant d'expérience utilisateur
Posté par rogerwaters . Évalué à 7.
Il y a une focalisation sur e17 (le gestionnaire de fenêtres) alors que la dépêche est sur un ensemble de bibliothèques qu'utilise e17. Néanmoins, je vais essayer d'apporter une pierre à l'édifice.
c'est la même chose avec n'importe quelle bibliothèque (je ne parle pas d'e17. Tu as l'air de confondre e17 et les EFL) : quand il y a un changement de version mineure, il y a des améliorations. Elles n'ont pas été introduites avant car il y a un plan de route à tenir. Quant à l'impact avec la version N-1, les corrections d'erreurs sont backportées et une version 1.0.2 sortira certainement bientôt
quant à l'appréciation de l'augmentation de vitesse, il y a un outil de benchmark pour Evas (nommé Expedite), que tu peux tester sur ta machine, pour connaître les améliorations niveau vitesse.
e17 == windows manager + file manager + les gadgets habituels d'un WM. C'est tout.
tu dois confondre avec KDE ou Gnome : e17 n'est pas un environnement de développement comme ces 2 frameworks. C'est une application et en tant que telle, il n'y a pas d'API. Pour ça, il faut regarder du côté d'Elementary. S'il y a une "API", c'est pour l'écriture des gadgets (forcément, il faut donner un cadre pour l'écriture des gadgets, mais n'importe quel WM fait de même).
pour l'API, je pense avoir expliqué qu'il n'y en a pas. L'arlésienne, c'est sur il n'y a pas de sortie. Je l'utilise néanmoins tous les jours. Evidemment, pour des utilisateurs lambda utilisant des distro comme Ubuntu ou Mandriva/Mageia, c'est une situation inacceptable (Arch Linux est différente et propose e17). Mais il fonctionne très bien, est très réactif, prend peux de ressources (~20 Mo avec le thème par défaut, je trouve que c'est peu) et ne plante pas (pour moi).
Quant au côté révolutionnaire :
J'espère avoir un peu répondu à tes questions/remarques
# Des paquets pour Slackware
Posté par Jérôme Pinot (site web personnel) . Évalué à 7.
Le projet SlackE17 a mis à disposition des packages des EFL 1.1.0 pour Slackware et Slackware64.
Pour les télécharger directement : http://sourceforge.net/projects/slacke17/files/slacke17/efl-1.1.0/
Dans le dossier bonus, vous trouverez également un snapshot du gestionnaire de fenêtre e17.
Site Internet du projet : http://slacke17.sourceforge.net/
Happy slacking!
# Re: X—Sortie des EFL 1.1.0
Posté par Juke (site web personnel) . Évalué à -1.
Y'a t'il un truc avec les EFL (ou avec gtk cairo) qui me permette
d'afficher un texte qui scrolle qui prenne tout l'ecran ?
[^] # Re: X—Sortie des EFL 1.1.0
Posté par dinomasque . Évalué à 5.
l'Amiga le faisait il y a 20 ans !
BeOS le faisait il y a 20 ans !
[^] # Re:X—Sortiedes EFL 1.1.0
Posté par Juke (site web personnel) . Évalué à 2.
Le mercredi 07 décembre 2011 à 10:05 +0100, dinomasque a écrit :
> l'Amiga le faisait il y a 20 ans !
je sais mais je ne trouve rien de propre dans les toolkits actuels pour
faire ça simplement (une sorte de prompteur ou tableau lumineux)
# Bravo
Posté par Guilhelm Savin . Évalué à 3.
Bravo et merci aux développeurs pour leur travail !
Cela fait plusieurs années que j'utilise Enlightenment et je ne peux plus m'en passer. Il est plaisant de voir que le projet va de l'avant.
Bonne continuation.
# RAD?
Posté par Maclag . Évalué à 5.
Y'a-t-il quelque part dans les cartons une interface graphique qui permette de construire plus facilement ses interfaces graphiques, genre QtDesigner ou Glade (enfin, en utilisable, hein!)?
[^] # Re: RAD?
Posté par cedric . Évalué à 4.
Malheureusement non. C'est le point qui peche le plus. On a des trucs dans les cartons, mais rien de reelement concret/utilisable. Cela deviendra surement la priorite apres la release de E17.
[^] # Re: RAD?
Posté par coucou . Évalué à 7. Dernière modification le 07 décembre 2011 à 16:14.
RAD, IDE, SDK... quelle que soit la forme, cela viendra probablement avec le projet Tizen, dont le lancement est prévu pour le premier trimestre 2012. Ce projet d'ampleur est chapeauté par Samsung et Intel, ce serait même étonnant que des devs de ces grosses boîtes ne bossent pas déjà dessus, en interne - et en toute discrétion.
On peut imaginer un environnement de développement qui prendra en charge les EFL, entre autres. Maintenant, si c'est Intel qui fournit les outils, pas sûr que la communauté E17 ait son mot à dire... à part accepter le « cadeau » parachuté.
Quant à une éventuelle sortie de E, le gestionnaire de fenêtres, je doute que cela intervienne avant de longs mois, voire même en 2012, vu le boulot qu'il reste à faire pour qu'il soit « user-friendly ». Et, s'il sort malgré tout (parce qu'il le faut bien pour passer à la phase E18/Elementary...), alors la déception sera grande à cause des espoirs forcément déçus des fans : car non, ce n'est pas et ne sera pas une interface révolutionnaire.
Cependant, comme il a été rappelé dans les commentaires, E17 est depuis longtemps utilisable au quotidien. Et oui, son look-and-feel est unique, et oui, il est très agréable à utiliser et à customiser (à condition de passer par le svn), même s'il n'est plus vraiment en avance sur son temps (voir les progrès - et les audaces - des autres environnements graphiques plus connus).
Je pense qu'il y a un malentendu concernant E17, malentendu qui vient de la révolution graphique qu'a été e16 pour le desktop. E17 est avant tout un environnement plaisant de développement : un démonstrateur quatre étoiles. La finalité du développement est l'embarqué, pas le desktop.
Depuis des années, l'effort de dev s'est concentré sur les bibliothèques. De fait, les EFL ont acquis une reconnaissance, une visibilité au niveau industriel. Ce qui n'est pas rien ! C'est, en soi, une formidable réussite.
Il n'y a rien d'autre à attendre que ce qui existe déjà en ce qui concerne le desktop. La seule personne qui pourrait apporter de l'inédit, de l'épat'... pour réjouir les amateurs de friandises graphiques, c'est raster (le porteur du projet depuis le début). C'est lui l'artiste du code, le codeur artiste. Hélas ! sa fonction chez Samsung lui bouffe tout son temps... et peut-être une partie de son talent créatif.
Après, on peut aussi déplorer le manque de graphistes, de créateurs au sens large. C'est un comble quand on connaît les possibilités et la puissance de l'environnement ! On peut également - et à juste titre - se lamenter sur le manque d'audace des développeurs d'applications maison... rien d'extraordinaire esthétiquement parlant, ça ressemble souvent à ce qui se fait ailleurs. Et quel fossé entre ce qui est proposé au niveau de la conception, de l'aspect des applis et... le brio, le peaufinement maniaque, le souci omniprésent de la performance qui président à l'élaboration des bibliothèques !
[^] # Re: RAD?
Posté par GuieA_7 (site web personnel) . Évalué à 3.
J'ai pas mal utilisé E16 il y a une dizaine d'années, et j'en garde un très bon souvenir ; je me rappelle aussi d'un Linux Mag qui annonçait la sortie très prochaine de E17. Dix ans plus tard on comprend bien que ce n'est pas encore pour tout de suite malheureusement...
Ton commentaire est riche d'informations, mais certains points me font tiquer.
[^] # Re: RAD?
Posté par coucou . Évalué à 7.
Il faut peut-être rappeler que cette dépêche annonce la publication officielle des bibliothèques Eina, Evas, Ecore, Embryo, Edje, Efreet, E_dbus, Eeze, Expedite, Evas_Generic_Loaders en version 1.1.0, et celle de Eet en version 1.5.0.
Ce qui veut dire que ces bibliothèques sont stables et qu'aucun cassage d'API n'est toléré (pour suivre le développement de l'environnement E17 de près, je peux vous assurer que raster y veille). Ce qui signifie également que tous ceux qui veulent développer avec ces bibliothèques peuvent le faire, dès maintenant, avec confiance et sérénité. Ce ne sont pas des mots en l'air, c'est la réalité. Et tout cela est sous-tendu par une exigence industrielle de plus en plus présente.
Il faut aussi souligner l'effort de documentation entrepris en parallèle, et se souvenir que tout le monde peut venir chatter sur les canaux irc #e.fr, #e, #edevelop, etc., sur le réseau Freenode pour obtenir plus de renseignements. Il y a aussi de nombreuses listes de diffusion. Donc plus d'excuses pour ne pas se mettre à bosser avec les EFL !
Ce qui s'est passé dans Edje (et ça commence à dater...), et qui a effectivement conduit à rendre inutilisables 90 pour cent des thèmes graphiques disponibles du jour au lendemain, ne peut plus se produire actuellement.
Pour Elementary - la bibliothèque de choix pour l'embarqué - la situation est différente. Ce projet n'a pas encore atteint une maturité suffisante pour justifier une version 1.0. Ce qui n'empêche pas les devs (les « Samsung Boys » jouent un rôle d'accélérateur notable en l'occurrence) de l'utiliser de plus en plus. Comme il s'agit de l'avenir du projet Enlightenment (E18), elle fait même l'objet d'attentions particulières que n'ont pas connues les EFL de base, comme cette page qui recensent ses changements intervenus dans le svn et que l'on peut consulter ici :
http://trac.enlightenment.org/e/wiki/ElementaryChanges
Autant dire que c'est du sérieux et que tous les futurs développeurs sont invités à approfondir le sujet...
[^] # Re: RAD?
Posté par coucou . Évalué à 1.
[Coquilles dans ce qui précède, lire : « (...) comme cette page qui recense les changements intervenus dans le svn et que l'on peut consulter (...) ». Je ne sais pas pourquoi mais le site ne me permet pas de modifier mon dernier commentaire.]
[^] # Re: RAD?
Posté par barmic . Évalué à 1.
Vous parlez d'un concept :)
En tout cas le travail autour des EFL semble très sérieux (bien que développé de manière un peu trop perfectionniste).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: RAD?
Posté par coucou . Évalué à 2.
Au moins, le « concept » a le mérite de la cohérence :P
L'avenir du projet passe par Tizen (que cette initiative soit un succès ou un bide).
Pour ceux que ça intéresse, des infos fraîches ici :
http://tizensummitasia2011.com/
http://identi.ca/attachment/61882976
Si le projet Enlightenment propose un jour sa propre distribution basée sur Linux, ce pourrait bien être grâce à Tizen...
[^] # Re: RAD?
Posté par Maclag . Évalué à 5.
Ce serait une grave erreur de se positionner à 100% sur l'un ou sur l'autre.
L'avenir des applis, c'est un noyau commun et des interfaces adaptées au média: desktop avec interfaces riches (lourdes?), tél mobile qui va à l'essentiel, truc-pad qui fait un compromis.
L'exemple que j'ai en tête ce serait les suites bureautiques: je veux toutes les fonctions en version desktop, essentiellement un visualiseur sur téléphone, et un peu de "retouche" sur un pad/netbook/smartbook.
Et si je suis un développeur, j'aimerais bien ne pas me retaper une réécriture complète du bousin parce que les EFL sont pas faites pour le desktop!
Si j'écris ça en Qt aujourd'hui, il y aura plein de Qt dedans à tous les niveaux et je ferai mes interfaces en Qt pour tous les supports tranquille.
Si j'écris ça en Qt aujourd'hui, pourquoi je m'embêterais à réinventer la roue avec les EFL pour la version mobile?
Il faut penser à tous les supports, tout le temps!
[^] # Re: RAD?
Posté par cedric . Évalué à 2.
Parce que ta version Qt pour telephone est completement differente de ta version pour Desktop aussi peut etre. En tout cas, les widgets disponibles sur N9 n'ont rien a voir avec ce que tu peux avoir sur Desktop.
Enfin avec les EFL, la problematique sur Desktop, c'est juste une histoire de theme et de profile. Pas franchement de code. En fait, en se focalisant sur de l'embarque riche, on fonctionne par defaut sur n'importe quel desktop. La demarche inverse n'etant pas vrai. Et on parle d'embarque riche ici, c'est a dire que l'on veut avoir les meme fonctionnalites que sur un desktop lourd.
En fait, si tu n'as pas remarque la plus part des tablettes/telephones commencent a etre livre avec une sortie hdmi et un port usb hote. L'objectif, c'est que tu lances exactement la meme appli, exactement le meme code, mais que le theme et le profile soit different par ecran. Et ton appli s'adapte directement a l'ecran en fonction de son type, tv, ecran pc ou video projecteur. Je te laisse imaginer toutes les implications de ce genre d'idee et ce que tu peux en faire. Mais c'est ce sur quoi on travaille et c'est ca l'objectif de faire une bibliotheque pour l'embarque, que tu n'es plus besoin de ton desktop actuel.
[^] # Re: RAD?
Posté par Maclag . Évalué à 2.
Oui ben dans ce cas, il serait bon de le mettre un peu plus en avant, parce qu'en lisant le commentaire, on a un peu l'impression que "rien à battre du desktop, E17 c'est juste pour avoir une vitrine!"
Et je vais continuer à utiliser mon desktop encore un moment, parce que Blender tourne mal sur mon téléphone, et rien ne remplacera jamais un clavier de dimensions raisonnable ;)
[^] # Re: RAD?
Posté par Sylvain Colinet (site web personnel) . Évalué à 0.
Sauf que t'as pas les mêmes besoin niveau ergonomie entre de l'embarqué et du desktop, donc t'as forcement besoin de revoir ton interface entièrement en général et pas juste changer le thème ou l'emplacement de 3 machins : typiquement un explorateur de fichier va être complètement différent sur un desktop, sur un terminal tactile et une télévision (où t'as juste une télécommande)
En plus Qt tends à faire utiliser QtQuick/QML pour les appli desktop, donc la comparaison est pas trop approprié.
[^] # Re: RAD?
Posté par cedric . Évalué à 3.
Avec les EFL, c'est juste un changement de theme. Tous n'est pas techniquement operationnel aujourd'hui pour ca, mais les bases sont la. La premiere chose a bien comprendre, c'est la separation claire entre logique et interface grace a Edje. Cela veut dire que tu peux changer toutes l'interface en changeant juste le theme. Le theme est en charge du layout. Il peut te creer tes listes, tes boutons, definir leur deplacement et transition. Donc oui, le theme defini l'ergonomie de ton application dans le monde des EFL et pas uniquement une image dans un coin ou la couleur de la font.
Biensur, il y a des choses qui sont fondamentalement different entre tous les terminaux. En premier lieu, la precision du pointeur (taille du doigt sur un touchscreen vs souris) et ensuite le dpi qui fait qu'une font va etre lisible ou non. Cela implique des regles strictes quand a la maniere de redimensionner les objets a l'ecran. Ceux sont des contraintes fournit par le profile du terminal et pris en compte automatiquement par les EFL. Enfin le dernier point et que tu souleves avec raison, c'est l'interactivite, l'exemple type, c'est une liste vertical dont on espere qu'elle sera "kinetic" sur un touchscreen et classic avec une barre de navigation sur un desktop. Tu peux rajouter la navigation entre les widgets a l'aide de la touche Tab (Desktop) ou d'une croix directionnel + entre (TV et Set Top Box). Mais cela aussi fait partie du profile. Au final, cela reste un comportement gerable principalement dans le toolkit graphique via un profil.
Donc l'ergonomie d'une application peut etre juste gere par le theme et le profile de notre point de vue et c'est ce vers quoi l'on tend.
QtQuick/QML n'est pas comparable avec ceux dont on parle dans les EFL, car il ne gere pas tout ce que je viens de decrire automatiquement et il faut rajouter cette logique dans le QML. En fait, c'est un defaut de conception inherent a cette technologie, il est necessaire de mettre de la logique de ce cote la. Cela donne plus de souplesse et permet de rapidement faire des prototypes, mais avec le temps se pose des difficultes de maintenance et de performance.
[^] # Re: RAD?
Posté par coucou . Évalué à 0.
Tu as raison d'insister sur l'ergonomie. Ce qui est flagrant avec E (le gestionnaire de fenêtres), c'est le manque de choix clairs quant à l'interface. Cela s'explique par l'histoire du projet.
L'héritage : le projet traîne derrière lui 10 ans de développement (ça n'a pas toujours été aussi agité que ces dernières années...) et, au début, il s'agissait de créer une révolution pour le desktop. Contrairement à ce que l'on pense souvent, e17 n'est pas la continuation d'e16 mais s'inscrit dans un projet bien plus ambitieux et novateur qui a abouti aux EFL dont parle la dépêche. Fort logiquement, l'orientation desktop des premières années a laissé une profonde empreinte dans l'interface.
La réalité du marché : raster étant quelqu'un d'intelligent et de très expérimenté - et qui sait se projeter dans l'avenir - il a senti que les machines de bureau classiques (tours et laptops) seraient dépassées par les appareils mobiles et communicants (en terme de marché). La transition vers le monde de l'embarqué s'est faite en douceur au fil des années, jusqu'à l'apparition de Elementary dans le svn. Cette bibliothèque émane du travail effectué par raster pour Swiss Telecom - et donc conçue pour les appareils mobiles (smartphones...).
Au final, on se retrouve avec un gestionnaire de fenêtres dont l'interface n'est pas plus adaptée au desktop qu'à l'embarqué, mais qui fait un peu les deux... en attendant que quelqu'un se penche sur le problème de l'ergonomie (des menus, pour commencer...).
À l'instar de ce que dit Sylvain Colinet dans son commentaire, je doute qu'un vague profil qui joue sur « l'emplacement de 3 machins » suffise...
[^] # Re: RAD?
Posté par coucou . Évalué à 0.
Ah, cedric a posté un commentaire pendant que je prenais le temps de rédiger le mien...
La puissance des thèmes est un facteur important certes, mais c'est aussi pour cela qu'il y a si peu de créateurs de thèmes et que les graphistes hésitent à se lancer dans l'aventure... puisqu'il leur faut acquérir des connaissances qui dépassent leurs pratiques habituelles et qui se rapprochent des méthodes des développeurs.
[^] # Re: RAD?
Posté par cedric . Évalué à 3.
Le probleme sur lequel tu mets le doigt, c'est surtout qu'on n'a pas d'outil dedie aux designers, ergonome et graphiste pour faire un theme et qu'ils sont donc oblige d'avoir des methodes de developpements. C'est a dire de passer par un simple editeur de texte, compiler le theme, le tester, detecter les problemes et recommencer. Pas tres efficace, pas tres visuel et effectivement loin de leur pratique habituel.
Ensuite pour repondre a ton message precedent, effectivement E17 contient pas mal de code ecrit depuis des annees qu'on n'a pas envie de toucher tout de suite. Entre autre exemple, les boites de configuration ne sont pas decrit en Edje, donc on ne peut pas en changer leur layout facilement. E17 n'utilise pas Elementary. Mais a un moment donne, si on veut faire une release, il a fallu faire le choix de mettre en standby ces changements et ameliorations.
[^] # Re: RAD?
Posté par rogerwaters . Évalué à 2.
Voilà un exemple (déjà posté sur linuxfr) d'utilisation d'edje par un designer:
http://www.calaos.fr/pub/video/calaos_media_music.ogg
le code C a été écrit par un développeur. L'interface graphique par un designer/graphiste, qui a adoré le concept. Evidemment, la qualité et l'ouverture d'esprit du designer est fondamentale.
Autre exemple de séparation de code/thème:
http://watchwolf.fr/index.php?option=com_content&view=article&id=3&Itemid=17&lang=fr
Le code C gérant le thème fait 2 lignes. Tout le reste, c'est le thème
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.