Strash a écrit 981 commentaires

La encore je vais citer Aaron pour répondre :

More and more components used on the desktop will be written in QML. It's simply an easier and more designer-friendly way of achieving the results we have been aiming for. However, we will not be engaging in a re-write of the desktop shell in QML. In fact, it's quite likely that plasma-desktop will remain using QGraphicsView (via a support library that will ship alongside libplasma2, if all goes well) and that the usage of OpenGL, compositing, etc. will not change in the foreseeable future. The plasma-desktop shell works, we have more pressing things to do than break it. ;)
So while the desktop will benefit from the work we're doing in Plasma Active, it won't be hugely changed by it. We will also continue to refine and add features and increase the stability and performance of plasma-desktop. This is about expanding our scope, not shifting it.

Donc non, ils ne vont pas changer de direction jour au lendemain.

Je me suis mal exprimé, voici les propos d'Aaron pour plus d'exactitude :

In Platform 4.6 and newer, Plasma supports writing components in QtQuick's QML. One tantalizing thing QML holds out is using an OpenGL accelerated scene graph for all rendering. Having seen this in action, the results are impressive. To put it mildly. Think "better performance on a mobile device than on the typical desktop running the QGraphicsView equivalent". To get to the point that Plasma can use this scene graph, however, we need to have everything in a given shell done in QML.
This implies not using QGraphicsView. What we are planning to do is to put the QGraphicsView implementation in a second support library so that we aren't forced to rewrite plasma-desktop, plasma-overlay (aka Widgets-on-Screensaver) and plasma-netbook or the hundreds of Plasmoids people have written. libplasma2 will then rely on ScriptEngines for things like QML (as it currently already does) and allow us to write QML-only shells (as Plasma Tablet and Mobile already are) and take advantage of the OpenGL scene graph wherever we can.

Donc QML va être utilisé à la place de QGraphicsView, le premier utilise OpenGL pour le rendu, ce qui est beaucoup plus rapide que QGraphicsView.

Juste au moment où je met en ligne ce Journal, Aaron met en ligne son message à propos de Contour.
Voici le lien.

Plus il est gros, plus il passe ?

J'ai lu ça un peu partout ces derniers temps et j'étais surprit à chaque fois.

Je suis allé vérifié et il semble que ce que tu affirmes est faux : l'espace typographique est masculin à part si l'on désigne la pièce métallique qui servait à créer cet espace en imprimerie. Seuls les typographes utilisent le féminin, mettre le mot au masculin n'est pas une faute.
sources (entre autre) :
http://fr.wikipedia.org/wiki/Espace_typographique
http://www.pincetonfrancais.be/v1/article.php3?id_article=5

Merci d'éviter de répandre ces fausses rumeurs orthographique qui écorchent les yeux.

"For instance" veut bien dire ce que ça veut dire, c'est un exemple ! Faut pas voir le mal partout...

Google AI challenge avait fait un concours d'IA pour un jeu de type TRON il y a quelques années. Si tu veux regarder les diverses stratégies ça peut-être intéressant.
Un système de match automatique permettais un classement des IA.

http://ai-contest.com/

Faut aussi voir que le but du cadastre n'est pas de fournir une carte routière. Le cadastre est une carte d'occupation du territoire. C'est donc normal que ça ne soit pas facilement importable.
Les bâtiments sont eux importés de façon quasi-automatique, vu qu'un des buts du cadastre est de tracer les bâtiments, c'est faisable.
Comme tracer les routes est secondaire sur le cadastre, ben il n'y a pas de moyen facile de l'importer dans OSM, donc non, on a pas tout pour le faire rapidement !

En fait flash est non-supporté sur toute plateforme hardware autre que x86, ainsi que sous toutes les distributions BSD actuelles, et tous les Unix propriétaires.

Heu... flash tourne très bien sur un ARM sous Android. Donc pas x86.

En gros c'est comme un clic milieu sur la barre de défilement sauf que ça ne marche que pour le début et la fin ?
Je préfère le comportement où l'on peut atteindre directement n'importe quel niveau sur la barre :)

Qt est justement très bon pour respecter le Look&Feel du système sur lequel il est installé. Sous MacOSX le menu est bien détaché, les différents éléments de l'interface font bien "OSX", les préférences vont bien sous le bon menu, etc... Je pense qu'avec du travail on peut très bien respecter le Look&Feel d'Android, de Meego... avec Qt.

Car c'est une fondation Germanique qui a été choisie ?

Bref, suis le lien du journal ( http://challenge.documentfoundation.org/why/ ) et ils ont expliqué cela mieux que je ne le ferais. En gros, pour les non anglophones : ça assure de meilleures garanties au niveau de la stabilité et de la sécurité, les statuts ne peuvent être changés.

Qu'appelles-tu un lecteur OpenStreetMap.

La carte est visible sur le site, donc un navigateur peut te servir de lecteur, mais il faut un accès au web.
Maperitive ( http://wiki.openstreetmap.org/wiki/Maperitive ) te permet de faire du rendu personnalisé de zones de la carte, plus facile à mettre en oeuvre qu'un serveur Mapnik ou Osmarender.
Ensuite de nombreuses applications Android utilisent les cartes OSM : http://wiki.openstreetmap.org/wiki/Android
De plus pleins d'applications desktop (libres ou pas) utilisent aussi les cartes OSM, je pense notamment à Marble, le GoogleEarth de KDE.
Ensuite les outils d'édition affichent les données OSM : JOSM, Merkaartor

Bref, précise un peu ce que tu entends par "lecteur" OSM

Sur le coup je ne vois vraiment pas ce que l'on peut reprocher à Microsoft :
- En Aout 2010 ils ajoutent une couche OSM à leur Bing Maps, permettant de mettre un peu de lumière sur ce projet libre.
- En Novembre ils annoncent qu'ils ont embauché Steve Coast, fondateur d'OpenStreetMap et ils annoncent dans la foulée la disponibilité des vues aériennes pour servir de base à la création de la carte OSM.

Je l'ai essayé il y a quelque temps mais je me suis perdu dans les histoires de calques, habitué à JOSM j'ai renoncé très vite. D'autant plus qu'à l'époque le plugin Cadastre n'était pas encore là.

Je pense que je vais y replonger car j'ai parfois des problèmes de mémoire avec JOSM, sûrement qu'un logiciel en Qt sera plus léger que JOSM.

Comme je l'ai dit dans le journal, survole l'onglet sans y cliquer dessus et Potlatch 2 apparaîtra. Il est en phase de test depuis quelques mois et je le trouve très stable.
Tu peux aussi le mettre par défaut dans tes préférences utilisateur.

Les liens :
http://www.osmfoundation.org/wiki/License/Contributor_Terms
http://www.osmfoundation.org/wiki/License/Contributor_Terms/(...)

On peut le lire ici et ici en Français.

@Michaël L : J'aimerais bien savoir ce qui te choque dans cet Agreement, en le lisant je n'avais pas vu quelque chose qui puisse mettre en danger la liberté de la base de donnée. Mais je suis très loin d'être un expert dans ce sujet.

Ça n'empêchera pas de créer des test du type Acid test qui permettront de créer une compétition de qui a le plus gros résultat. Donc on reste selon le modèle actuel.
Il faut juste que ces tests soient complets et fiables, ce qui reste plus difficile à mettre en place.

Mais de toute façon cette décision n'est que le reflet de ce qui se passe actuellement, HTML5 n'est pas encore sorti et les navigateurs se trient déjà la bourre sur les différentes fonctionnalités.

Je ne disais pas que grâce à ça ils gagnaient le fond de carte OSM. Je disais que grâce à leur contribution OSM allait s'améliorer, et que du coup le layer OSM sur bing maps va s'améliorer aussi.
Ils vont donc gagner en précision sur un des fonds de carte qu'ils proposent.

Le fond de carte OSM est disponible sur Bing maps. Donc ils y gagnent une carte plus précise sur Bing maps.

> Je crois franchement que les gros développeurs de jeu n'en ont franchement rien à carrer des 1% de part de marché de Linux. Et puis bon, comme le linuxien moyen est assez bidouilleur, ceux qui veulent jouer sous Linux s'en sortent avec Wine.

Justement, ça sera toujours mieux pour les joueurs sous Linux si Wine utilise une implémentation native de Direct3D à la place de ce qu'ils ont actuellement.

Merci beaucoup, je ne connaissais pas cette bibliothèque et effectivement ça a l'air très puissant.

Seulement j'aurais besoin de quelque chose de plus facile à mettre en oeuvre, je n'ai hélas pas le temps de coder.

Je vais voir s'il n'existe pas une GUI basé sur matplotlib.

Ce n'est pas le cas ?

Je cite la dépêche :
Le projet doit concerner "PostgreSQL et la francophonie".

Même s'il est unique, le mois prend bien un "S".