Philippe F a écrit 2225 commentaires

De fait, QList ne se comporte pas comme une std::list , Qt a choisi une approche légèrement différente. De même qu'elle ne se comporte pas comme les listes java bien que pour les deux (std::list et liste java), des itérateurs existent qui reproduisent un comportement.

Tu as raison sur l'absence de constructeur acceptant des itérateurs, bien que ça semble pas trop difficile à rajouter, à coup de append(), ou sur la différence de sémantique des at().

Pour ce qui est de la performance Qt vs STL, je pense que ça dépend de chaque implémentation de la STL. En tout cas, si je dois convertir des noms de fichiers japonais (stockés en Shift-JIS) pour les afficher en UTF16, je sais lequel je choisirai: STL ne gère tout simplement pas les codecs, donc bonjour le bazar!

Pourquoi QString devrait hériter de std::string ? Ca n'a pas de sens, QString n'est pas un sur-ensemble de std::string , c'est un ensemble distinct. QString sait faire des choses que std::string ne sait pas faire, comme du partage implicite de la mémoire, des conversions dans différents types d'encodage (latin1, utf8, etc), du découpage en sous-chaînes. QString dispose d'optimisations spécifiques qui sont basées sur la manipulation brute des données de la chaîne, qui ne seraient pas possibles si QString en maitrisait pas la structure de donnée de stockage (en gros, si il utilisait std::string). De plus QString offre des garanties en terme de gestion de thread qui ne sont pas nécessairement offertes par std::string.

Par contre, il est possible de convertir facilement une std::string en QString et vice-versa, d'utiliser des algorithme de la STL sur des QString, etc etc.

Très clairement, en l'état, aucun. Il n'y a pas de mainteneurs de la branche unladen swallow, le port vers Python 2.7 ou 3.2 n'a pas été fait, et personne n'est là pour continuer à faire avancer le projet. Donc c'est pas prêt d'arriver tant que les deux ingénieurs de Google ne s'y remettent pas un brin !

Tu pourrais être plus précis sur les incompatibilités entre Qt et la STL ?

Tous les containers Qt sont compatibles avec la STL, tous les itérateurs façon STL sont aussi disponibles dans Qt donc tu peux en théorie allègrement mélanger les deux.

C'est sûr qu'ils ont leur propres containers dont ils contrôlent eux-même la performance et la portabilité et les fonctionnalités (support des threads, etc), ce qui personellement ne me choque pas (et surtout, je préfère les syntaxes Qt, ça fatigue moins les doigts).

Pour unladen swallow, le projet est à l’arrêt depuis pratiquement un an. Les devs de google qui travaillaient dessus ont eu d'autres projets internes à gérer. Cela dit, ils disent qu'ils vont s'y remettre un jour, dès qu'ils ont le temps.

En attendant, PyPy commence enfin à donner des résultats digne de ce nom, donc ce sera peut-être lui le Python JITé qui référence.

Oui, et comme presque tout les langages sont turing complet, pourquoi ne pas en choisir un genre le brainfuck et laisser tomber tous les autres ?

Plus sérieusement, présenter une interface graphique n'est pas un exercice mathématique de réduction au plus petit dénominateur commun mais plutôt un effort pour présenter des informations de façon compréhensible. Et il y a des cas, ne t'en déplaises, où un interrupteur ON/OFF sera plus clair qu'une checkbox.

Qt non dispo pour Windows Phone, tu en es sur ? Qt est relativement facile à porter sur des plate-formes embarquées, et Trolltech l'a visiblement fait assez souvent ces derniers temps. Je vois pas pourquoi Windows Phone ne pourrait pas accueillir des applications Qt.

Dans ce cas, Qt serait un GUI unique sur toutes les plate-formes de Nokia. On peut toujours rêver...

J'ai testé aussi un nouvel modèle de rame sur le RER B entre Gare du nord et Chatelet. C'était moderne, mais une horreur. Lumière puissante, hypercriarde, permettant de voir en détail les tronches des parisiens mal réveillés et emmerdés d'être sérrés comme des sardine. Merci à la RATP et au designer !

La même semaine, j'ai pu tester les nouveaux trains de la ligne K. Et là, un bonheur, j'ai presqu'eu l'impression d'être dans un TGV en première classe. En tout cas, lumière beaucoup plus tamisée. Il reste le bruit perçant des sirènes de portes qui vont se fermer à virer et ça deviendra presque confortable.

Même si visiblement, ça se passe pas aussi vite qu'on voudrait, c'est un phénomène en cours. Dans ma boite, l'un des salarié habite Redon et je le vois une fois par mois. Je connais au moins deux autres sociétés qui font dans l'informatique mais quand même avec pas mal de HARD, qui ont des salariés à distance comme ça.

Le commit partiel de fichier sous mercurial, c'est cadeau sous Windows avec TortoiseHG. Même pas besoin d'extension. D'ailleurs, TortoiseHG marche aussi sous Linux, je l'oubliais presque.

Au passage, tous les outils de commits devraient avoir la convivialité de TortoiseHG. Ceux qui disent que la ligne de commande en un hg/svn/git diff + un éditeur suffisent pour savoir tout ce que tu as modifié ne savant pas ce qu'ils perdent.

Je doute que tu arrives à satisfaire toutes les dépendances de firefox avec une seule commande dans le cas où tu fonctionnes en tgz.

C'est sur qu'ils auraient eu moins de boulot, ils n'auraient tout simplement jamais pu faire leur application !

Et oui, on est vendredi !

J'aime bien Redmine mais un point faible je trouve, c'est qu'il n'est pas possible d'éditer le wiki offline. Sur google code par exemple, le wiki est géré via un gestionnaire de sources et c'est bien pratique pour les gens comme moi qui passent beaucoup de temps dans le train.

Sinon, globalement, c'est un projet qui assure !

Et lisaac ?

Merci à Francesco car la dépêche n'indique pas que ce machin ne sert que pour du java.

Sur le site web, rien dans la page "features" ou dans la FAQ à propos d'un ou de plusieurs autres types de langages. A croire que C#, C++, C, Objective C, Python, Ruby sont des langages tellement mineurs dans l'industrie qu'ils ne méritent pas une mention pour dire qu'on les supporte pas !

M. Gaudin voudra bien j'espère une prochaine fois indiquer cette restriction dans le corps de la dépêche, pour tout ceux qui ont la chance de ne pas programmer en Java.

Un certain nombre de pays non encore contrôlés par Visa / Mastercard mettent en place des réseaux alternatifs de paiement justement pour ce type de raison.

En Pologne, il est plus courant de payer par internet par un système de virement compte à compe un peu évolué que par carte bancaire.

A Singapour, la carte fait-maison pour le paiement marche très bien et résiste vaille que vaille aux pressions du cartel Visa Mastercard American Express.

Bossant dans la carte à puce, on a plusieurs fois été contacté par des pays souhaitant faire ce genre de chose. La plupart cependant n'ont pas le niveau technique pour le faire. Il faut vraiment être calé en sécurité pour faire ça. Mais au final, c'est un investissement national qui paye pour le pays.

Mercurial a été lancé a la même seconde que git : le jour où la licence Bitkeeper a été supprimée.

Un concept sympa, un nom original, un site en redmine, du code en Python et un Qt. Ce logiciel a vraiment tout pour me plaire !

Dommage que je n'y vois pas d'utilité personnelle, ça aurait été avec plaisir.

hint: PyQt

Ce que j'aime bien avec webboob, c'est tripoter les fichiers de config.

( bon, ça vole pas très haut mais pour un lundi, ça fait du bien ).

J'ai constaté quand même des inconvénients au principe du DVCS. Dans une petite équipe, avec svn et les mails de commits, on sait assez bien ce qui se passe.

Avec un DVCS, les membres ont tendance à garder pour eux leurs développement en cours, et à faire des push moins souvent qu'ils ne faisaient de commits. Du coup, on a des périodes où tout le monde bosse sur un truc, mais ce n'est pas visible sur le dépot principal.

Autre facteur, chaque opérateur a sa petite technologie d'antenne. Pas de grandes révolutions dans la partie analogique de l'antenne elle-même, mais dès qu'on passe dans la partie numérique, il y a des protocoles, ca discute, ça se met à jour, ça s'authentifie et tout le toutim.

Free espère d'ailleurs avoir des coût d'exploitations des antennes inférieurs à ses concurrents, et des services nettement supérieur en utilisant les dernières techno hard et soft sur leurs équipements antennes et noeuds de leur réseau mobile.

Je me posais exactement la même question. De mon point de vue naïf, j'ai pas l'impression que ce serveur soit prêt pour gérer une montée en charge significative.

Le Design a l'air simple, c'est un atout, mais ça va pas plus loin. Des gens maîtrisant un peu plus la technique pourraient-ils nous éclairer ?

Parce que côté serveur web, on commence à avoir pas mal de compétition à apache, mais les autres projets que j'avais survolé m'avaient l'air mieux pensés que celui-ci.

Quick, ca semble de la bombe !

J'ai pas eu l'occasion de jouer avec l'interface mais si j'ai bien compris les démos et les exemples, ça permet de décrire une interface graphique de façon déclarative avec les notions suivantes :

- description de tous les items de l'interface, leur placement respectifs, leur propriété de base. Jusque là, rien d'extraordinaire.

- description d'un automate d'état, qui décrit les transitions avec pour chaque transition, l'évènement qui la déclenche, une condition de validation, les propriétés des objets à faire changer, signaux éventuels à émettre et des algo pour rendre les transitions fluides.

Ça permet vraiment de décrire des effets complexes de façon déclarative, c'est vraiment très fort. Pour le mobiles, c'est parfait, toutes les transitions à la iPhone se feront hyper simplement.

On peut trouver pas mal d'exemples et de video en cherchant Qt Quick sur google on regardant le blog de Qt. Quelques une comme ça :

http://jryannel.wordpress.com/ pour des mini exemples concrets
http://labs.qt.nokia.com/2009/05/13/qt-declarative-ui/

Justement, est-ce que t'as des nouvelles de PySide ? Est-ce que ça marche aujourd'hui ?

La dernière fois que j'ai regardé, ça avait l'air d'un projet de loser. A part proposer d'avoir à la fois les méthodes en MixedCase et underscore (genre avoir toString() et to_string() ), il y avait pas grand chose de concret sur le développement.

Le support de Python avait l'air quand même assez ridicule, l'utilisation de boost allait bouffer des tonnes de mémoire, et j'en passe.

Perso, je suis pas prêt de lacher l'excellent travail de Phil Thompson pour ça.