viridis a écrit 70 commentaires

Les 400 cartes allouées au projet Qt on Pi sont les mêmes que celles "des utilisateurs finaux". Elles font partie des 10000 premières cartes produites qui seront mises en vente sur le site de Raspberry Pi.

Il n'est pas question de donner des cartes "en avant première". Il y a juste une réservation de 400 cartes dans le premier lot pour le projet Qt on Pi.

Après lecture du commentaire précédent j'ai peut être mal compris le soucis. En fait il ne s'agit pas de l'affichage des images et autres qui est modifié, mais plutôt de la couleur des fenêtres, barres de défilement... Rien à voir avec la gestion des couleurs donc !

Ça vient peut être de l'intégration en standard du nouveau système de gestion des profiles de couleur (colord...) en standard dans Gnome 3.2 ?

Une interview toute fraîche de Richard Hughes (le monsieur derrière tout ça) à ce sujet :
http://libregraphicsworld.org/articles.php?article_id=42

Après lecture de cette entrevue, je dirais que c'est pour que les designers, photographes... puissent avoir une chaîne de production calibrée (ce qui inclut les logiciels) pour leur travail.

J'ai un GP zero depuis plusieurs mois, et je dois avouer que j'en ai un peu marre.

Dans le principe c'est vraiment très bien, dans la pratique moins.

J'ai installé la dernière version stable de cyanogenmod dès que j'ai eu le téléphone. Résultat: batterie qui tiens quelques heures seulement sans même utiliser le téléphone, téléphone qui ne se recharge pas à fond, niveau de la batterie non fiable, reboot du système, problème de montage/démontage de la carte SD...

J'ai installé cynagenmod 7.1.0 rc1 il y a quelques semaines, le niveau de la batterie est plus correct, ça reboot moins souvent (quoique). Mais les autres problèmes sont toujours là...et ce sont des problèmes connus.

Je n'ai pas essayé SuperAOSP. Y a-t-il les même problèmes ?

pas leurs versions flash :)

Sympa, mais c'est pas compatible avec Tree Style Tab, dommage.

Merci !

...je suis assez satisfait par ce FF4 par rapport au 3.6.

Naviguer devenait réellement de plus en plus pénible, surtout au niveau des performances, sur mon PC plus tout à fait jeune, mais pas tout à fait vieux non plus.

Au niveau de l'ergonomie, j'aime beaucoup la possibilité d'épingler les onglets qu'on utilise tout le temps. Ca prend beaucoup moins de place, et c'est bien pratique. Par contre, toujours côté ergonomie, j'utilisais constamment 'F6' sous FF3.6 pour sélectionner l'url de l'onglet courrant, me permettant ainsi de la remplacer par une autre. Je ne retrouve pas cette fonctionnalité dans FF4 (quelqu'un aurait un tuyau là dessus ?).

Quand t'as plusieurs VM, t'es content quand elles prennent pas la moitié de ton disque...

La correction des problèmes Qt + clang avance: http://labs.qt.nokia.com/2010/10/29/compiling-qt-with-clang/

A priori il y aura le choix puisqu'actuellement tu as le choix sous windows entre gcc/gdb ou msvc/cdb. Du coup toute l'infrastructure pour gérer différent compilateur/débuggeur est en place.

D'ailleurs, il serait étonnant qu'ils abandonnent gcc/gdb vu le nombre d'utilisateur de ces outils.

A noter que les développeurs de Qt Creator (l'IDE de Nokia pour développer en Qt) suivent le développement de CLang et LLDB et sont a priori assez intéressés par le bousin. On peut donc espérer une intégration dans Qt Creator, certainement une fois que LLDB sera utilisable.

source : http://labs.qt.nokia.com/2010/10/15/peek-and-poke-vol-4/

Une dépêche sur CAMP a été publiée il y a quelques jours :
http://linuxfr.org/2010/06/15/26993.html

Pour simplifier, ça permet (permettra...) de faire la même chose, mais en C++ et sans GObject.

(Je me permet de poster le lien parce que ça peut intéresser les lecteurs de ce journal qui n'ont pas vu passer la dépêche sur CAMP)

Ah ok, merci pour l'exemple concret !

La nature statique de C++ empêche évidemment de créer une classe de toute pièce.

Ceci dit je suis curieux de savoir à quoi ça pourrait bien servir concrètement. C'est juste histoire de me coucher moins bête ce soir :)

Bon, j'avais mis des liens ils sont pas passés, les voici :
- xpprefl : http://www.extreme.indiana.edu/reflcpp/
- agm::libreflection : http://www.codeproject.com/kb/library/libreflection.aspx
- boost:: mirror : http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/index.ht(...)
- xrtti : http://www.ischo.com/xrtti/documentation.html
- open-c++ : http://opencxx.sourceforge.net/occ-core/

Pas mal ? On connait :
- xcpprefl : utilise un pré-compilateur, mais semble pas mal
- agm::libreflection : grosses macros qui tachent, directement dans la classe en plus
- boost::mirror : grosses macros qui tachent (un petit appercu), pas directement dans la classe cependant
- xrtti : utillise un pré-compilateur
- open-c++ : utilise un pré-compilateur

(Si tu connais d'autres bibliothèques, merci de me le indiquer, ça m'intéresse!)

Le problème du pré-compilateur, en plus de complexifier la chaîne de compilation, c'est qu'on ne peut pas choisir ce qu'on veut exporter et ce qu'on ne veut pas (ce qui est une nécessité pour nous) sans ajouter des informations à la main. Du coup, quitte à déclarer quelque chose, autant que ce soit le binding plutôt que d'utiliser un outil supplémentaire.

En ce qui concerne l'avantage des templates par rapport aux macros, c'est qu'on peut déterminer plus de chose à la compilation (genre les types, les nombres d'arguments, les const/non const...). Du coup, il y a beaucoup moins de chose à déclarer lors du binding.

J'en ai un ! A l'époque, quand je l'ai vu, j'l'ai acheté direct :)
Maintenant je surf librement, sur le web comme sur la montagne.

Juste pour chipoter, ce n'est pas la première install party ESIAL puisqu'à l'époque du CSILL (Club de Sécurité Informatique et Logiciels Libres) plusieurs install parties avaient été organisées par les membres du club !

Ceci dit, ça fait plaisir de voir que le libre a encore sa place dans l'école !

Merci pour ces encouragements !

Nous étions un peu dans la même situation et vu qu'aucune bibliothèque ne répondaient à nos besoins, nous nous sommes attaqués à GICS.

A noter aussi que la consommation CPU a été corrigée pour la prochaine version.

Comme mentionné dans le journal, GICS est doté d'un système de skin (qui sera amélioré sous peu) permettant d'adapter le style des instruments à d'autres applications/environnements. D'autres skins verront ainsi le jour avec, par exemple, des looks plus réel, plus multimédia, plus industriel...ou plus intégrés aux bureaux classiques.

Il faut toutefois noter que le type d'instrument proposé par GICS est en général utilisé sur des applications en environnement industriels pour lesquels une ressemblance avec les instruments réels est souvent nécessaire (comme sur un pupitre de commande par exemple), d'où cette cassure avec le style habituel.

C'est juste un p'tit problème dans la conf cmake, ce sera corriger rapidement :)

C'était peut être un bundle...

Pas nécessairement. Si t'as découpé ton projet en plusieurs sous tâche (genre dev et doc) tu peux passer de l'un à l'autre régulièrement sans pour autant perdre du temps (ceci dit, c'est vrai qu'en général on reste sur le même projet toute la journée).

Après, ça peut être des changement de projet complet, parce que quelqu'un à besoin d'un bug fix urgent ou je sais pas quoi. Là c'est un peu moins efficace, mais quand y'a pas l'choix...y'a pas l'choix!

Et sinon, certaines personnes ont besoin de travailler sur plusieurs projets en "parallèles" pour être efficace, alors que d'autres préfère se concentrer sur une seule tâche à la fois.