cedric a écrit 1074 commentaires

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.

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, ... :-)

Je pense que tu te trompes, il est possible de creer dans une certaine limite sur tablette. Regarde les projets d'Adobe Photoshop Touch et Photoshop Express. Un logiciel de presentation pourrait aussi tres bien fonctionner sur tablette. Il existe sur iPad un logiciel pour coder en Lua.

Oui, ca demande de repenser toute l'interface et les fonctionnalites, mais il y a quelque chose de possible et d'interressant a faire dans ce domaine.

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.

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).

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).

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...

D'ailleur si les etats empruntaient au pres de la BCE et uniquement au pres de celle-ci. La BCE devrait de fait auditer leur budget et empecher les derives. Cela creerait un nouveau pouvoir independant, le pouvoir economique qui n'est aujourd'hui pas separe des autres pouvoirs.
Cela donnerait a la BCE un outil direct pour luter contre l'inflation et empecherait les politiciens de faire des programmes irrealistes mais tellement plus vendeur...

Prendre l'Algerie en exemple alors que c'est une dictature qui oprime son peuple, cf. les manifestation de cette annee. Je trouve ca tres fort ! La raison logique, c'est qu'ils veulent juste proteger leur regime et eviter d'etre les prochains sur la liste. Pour l'instant, ils ont bien reussi leur operation...

J'aime beaucoup les ELF, mais l'un de gros problème c'est qu'il faut maintenir un binaire par machine ou presque.

Si tu prend un des bindings JavaScript, Python, Lua, Mono, et d'autres que j'ai surement oublie, ca resoud ce probleme :-)

Ce n'est pas la syntaxe qui fait la veritable difference entre QML et HTML5, la veritable difference reside dans le fait que l'on manipule des objets graphiques et non des primitives graphique. Cela permet au moteur de rendu graphique de faire plein d'optimisation plus ou moins complexe en fonction du moteur de rendu. En HTML5, il faut implementer ca en JavaScript, donc c'est forcement plus couteux et ca veux aussi dire qu'il faut forcement passer par un "toolkit" JS qui le fait pour nous, car c'est un gros travail et il vaut mieux le mutualiser.

le manque de separation entre la creation de l'UI, le code et la gestion des entrees/sorties

Et QML ?

QML est justement un probleme en ce sens. La possibilite de faire une application complete en QML, car celui ci inclu un moteur JavaScript complet, fait qu'on a au final trop de souplesse et tend a rendre le code immaintenable sur le long terme. QML est bien pour faire une tres petite application ou du prototypage, mais realiser une application avec va forcement resulter a un mix entre logique et interface ce qui est genant.
L'interet evident d'une bonne separation entre logique et interface utilisateur, c'est que tu peux facilement faire un theme dedie a un terminal particulier sans toucher au code. Que cela peut etre realiser par un designer ou un utilisateur qui n'a pas besoin de savoir coder. Avec QML, il faut une tres grande rigueur et fortement se limiter sur son utilisation pour y arriver.

Qt n'est pas si en avance que ca par rapport a Android et iOs.

Parce que Android et iOS font quelque chose de portable ? Android a un runtime spécifique et des bibliothèque spécifique et iOS utilise cocoa utilisé uniquement chez eux.

Tu m'as mal compris. Dire que QT permet de faire des applications portable et donc que c'est un bon choix pour l'embarque, car on aura plein d'application, ce n'est juste pas correct. Essaye donc d'utiliser une application KDE sur une tablette. Et oui, Android et iOS pechent completement dans le domaine, mais ca n'empeche pas non plus que QT fait pas franchement beaucoup mieux.

Comme framework portable ils ne sont même pas en concurrence avec Qt. L'un des concurrents c'était Java ME, mais il est de moins en moins utilisé …

Java ME... comment dire le truc ou chaque implementation a ses propres bugs et qu'il faut tester sur chaque environnement pour etre sur d'avoir une application qui marche a peu pres correctement ?
Je refais ma pub, mais bon, on n'en fait jamais alors pour une fois qu'on a l'occasion. Les EFL sont un toolkit portable qui propose une separation claire entre interface et code permettant de realiser des applications pour tablette, telephone et PC (Linux, *BSD et Windows) en changeant uniquement le theme ! Et pour le meme prix, tu as une solution legere en consomation memoire qui tire partie au maximum de ton hardware pour te permettre de realiser de belles interfaces graphique.

Clairement on peut toujours faire mieux ! La preuve, on a gagne entre 20 et 30% de perfs se matin sur x86 en software et pourtant on etait deja 2 fois plus rapide que pixman...

Mais bon, l'objectif, c'est de reussir a maintenir 60fps pour n'importe quelle application bien ecrit quelque soit la machine. Apres il y a du materiel ou ce n'est juste pas possible, le CPU/GPU ne pouvant pas atteindre ce fillrate meme si on faisait que ca. Mais dans l'ensemble les EFLs arrivent a atteindre les fillrate theorique du materiel pour afficher uniquement ce qui est necessaire.

Oui, les Enlightenment Foundation Library.

Sans vouloir te vexer, toutes les interfaces sont chez Nokia et absolument pas libre. Donc Meego n'etait pas du tout pret. Surtout que le N9 n'a de Meego que Qt, le reste c'est encore du Maemo. Donc Intel devait trouver un partenaire qui avait deja une interface graphique pour un telephone sous Linux. Donc Intel bazarde ses derniers liens avec Nokia et c'est normal !

Qt permet de faire des applications portable, mais cela reste quand meme un gros travaille de portage que de faire tourner une application sur different type de terminaux. En gros, le manque de separation entre la creation de l'UI, le code et la gestion des entrees/sorties font que Qt n'est pas si en avance que ca par rapport a Android et iOs. Si on rajoute a cela la lenteur de Qt, on comprend assez vite pourquoi il est difficile de l'utiliser pour de l'embarque en restant competitif !

Mais il n'y a pas que un toolkit portable dans le monde du logiciel libre...

Le fait est que Nokia a beaucoup communique sur Qt et qu'il est toujours actuellement au commande du futur de Qt. Il est donc logique pour tout deal n'incluant pas Nokia de se passer de Qt. Voir meme c'est aussi un moyen de dire a Nokia, comptait pas sur nous pour vous offrir un OS complet le jour ou vous voudrait revenir a Linux. Le comportement de Nokia a definitivement tue toute chance pour Qt d'apparaitre dans l'eco-systeme des telephone mobile.

Ensuite les partenaires de Tizen ont deja des telephones sous Linux operationnel, c'est tout l'interet de s'allier a LiMo. La grande difference, c'est que Intel apporte une infrastructure et une connaissance de la communication avec les developpeurs et les diverses communautes du libre que clairement LiMo n'avait pas. Il reste plus qu'a esperer que l'ensemble prenne le meilleur de chacun. Mais si ils veulent avoir quelque chose d'operationnel l'annee prochaine, il va bien falloir !

Le desktop est mort. Le gros PC tout moche, tout gros qui permet d'acceder a l'internet du monde et de poster des videos de chat, c'est fini. La tendance de fond est la, on se dirige vers des terminaux mobiles qui ont suffisament de puissance pour realiser toutes les taches de la majorite des gens. Deja dans les pays du tiers monde, le smartphone tend a remplacer le PC.

On peut facilement imaginer que d'ici quelques annees, les technologies permettent presque d'envisager des aujourd'hui, un smartphone qui se connecte sans fil a un ecran, reconnaisse si celui-ci est un ecran de PC, une TV, ... et affiche l'environnement qui y corresponde.

Pour l'analyse de fond, Apple tend a fusionner lentement les environnements desktop et mobile avec des mecanismes d'achat similaire et des environnements de developpement de plus en plus similaire. Google avec Android et Google Chrome semble aussi avoir une strategie, meme si un peu plus en retard que Apple dans le domaine. Certain constructeur de materiel s'essaye aussi sur le sujet. Il etait donc normal que Microsoft reagisse et propose une solution qui semble repondre a cette evolution.

Maintenant dans le domaine du libre, les deux tenords que sont Gnome et KDE ont des projets pour reussir ctte evolution. Leur gros handicap etant que les applis et leurs toolkit n'a jamais ete concu pour l'embarque ni donnee la souplesse necessaire a la realisation d'une application unique fonctionnant sur de multiple terminaux avec differentes interfaces.

Le projet Enlightenment quand a lui a ete concu des le debut pour l'embarque et propose un modele permettant de separer clairement le code et l'interface. Ainsi on peut avec un code unique cible plusieurs terminaux. Pour exemple, je ne peux que montrer le travail d'integration realise par Jeff Hoogland sur Bodhi Linux en utilisant tout le travail realise par l'equipe d'Enlightenment: http://jeffhoogland.blogspot.com/2011/09/bodhi-linux-powered-tabletnetbook-give.html . Il y a encore beaucoup de travail, mais la technologie, libre, est la et permet d'avoir la portabilite necessaire. Et pour une fois, le libre a clairement de l'avance sur le monde proprietaire !

Sauf que tu fais que des forks, pas un seul exec et un script shell, ca fait plein de exec dans tous les sens :-)

En l'occurence, elle n'est pas si inconnue que ca cette machine. Et a, a ma connaissance, deux inconvenients majeurs. Tout d'abord, tel une arme dont il faut recharger les cartouches, on a beaucoup de mal a imaginer un systeme qui pourrait faire fondre ces billes a un rythme suffisant et avec le niveau de precision requise. Pour un tir, c'est complexe, mais quand il faut en executer un toutes les 2s, ca devient juste infaisable.

Ensuite le second probleme, c'est qu'il faut fabriquer ces billes avec une extreme precision a un rythme effraine pour allimenter la centrale et ca aussi, on ne sait pas faire.

L'utilite de ce dispositif est nettement plus experimentale que pour la production d'energie. Je crois que c'est un tel dispositif qui est utilise pour simuler les bombes atomiques.

Euh, pour le coup, la majeur partie des materiaux necessaires pour une centrale solaire termique, c'est du beton et du vert. Ce qui se trouve plutot facilement localement. Ensuite, il y a des habitants dans ces regions qui pourront tres bien s'occuper de la maintenance, d'ailleur on pourrait meme les payer pour faire ca. Concept de ouf... Bon, par contre faudra attendre qu'ils arretent de se foutre sur la gueule :-)

Pour juste continuer sur la partie technique, ils existent aujourd'hui une centrale solaire termique en espagne qui fonctionne H24 sur le modele de ce que veut deployer dans le desert. Donc ca marche. De plus, elles ont comme effet de bord de pouvoir produire de l'eau desalinise, de quoi aider doublement ces regions.

Et t'inquiete, si tu n'y crois pas, les allemands, ils y croient et seront surement les grands beneficiaire d'un tel projet.

AirSpeaker client pour le protocol AirPlay permettant de recevoir en streaming la musique envoye depuis iTunes sur ses tablettes. Application en C, C++ et Qt.

Je lis depuis environ six mois que le coup reel de l'electricite d'origine solaire est divise par deux tous les dix huits mois. Je n'ai malheureusement pas trouve de source fiable sur le sujet, si quelqu'un en a ca m'interresse.

Toujours est-il que si cette information est vrai, ca donne des perpectives d'avenir vraiment interressante.

Aujourd'hui le coup pour un particulier est estime a 40c/kwh (L'energie nucleaire a un coup de 2c/kwh). Donc si cette loi est suivi en 2020, on sera a 1.25c/kwh solaire. Autant dire qu'il va falloir partir du principe que notre energie principale sera le solaire pour la prochaine decennie...

Maintenant, il faut "juste" que ca suive vraiment la loi de Moore...

Lis donc le site de Jean-Marc Jancovici, il y a un article sur sa difference d'opinion entre lui et Hulot. Apres tu peux dire que le monde est pourri et qu'il raconte juste des conneries pour se faire elire. Mais il reste quand meme quelqu'un de peu politicien qui merite plus le benefice du doute que le reste de la classe politique a mon avis.

A la difference que tu n'as pas besoin de cette puissance en permanence. Surtout dans les entreprises ou la majorite du temps CPU est passe en idle jour et nuit a consommer pour rien. C'est la ou les technologies de partage de temps CPU sur des serveurs distant prend tout son sens, meme si aujourd'hui on en est a son balbutiemment.

Avoir un bon ratio perf/watt, c'est bien, mais si tu n'as pas besoin de toutes ses perfs en permanence, c'est du gachi !