Gof a écrit 2224 commentaires

Il y a pas mal de bibliothèques qui permettent de faire ça, en C ou en C++

Alors quelle est la différence, et les avantages/inconvénient par rapport au autre frameworks.

Le journal donne quelques avantages par rapport a Qt, par example
- Pas besoin du préprocesseur comme Moc. (Mais est-ce que un préprocesseur est vraiment un problème ?)
- Pas besoin d'hériter de QObject. (Ça c'est cool car QObject a un overhead de ~100 octets par objects sur une arch 64bit)

Par contre, un inconvénient de taille est que il faut enregistrer sois même toutes les fonctions manuellement.

Mais qu'en est-il des performances et de l'utilisation de la mémoire ?
Qt ajoute toutes les chaînes de caractère l'une a la suite des autres de manière assez compacte. Et sans presque aucun impact lors du lancement.
CAMP, va éparpier les chaînes un peu partout dans le programme, plus avoir plein de structures sur le tas. (Sans compter aussi
toutes les tables virtueles (mémoire non-partagable entre proccesses))
Et le coût lors du démarrage est il ou non négligable ? (Enregistrements de toutes les classes dans les structures internes + rélocations)

Comptez vous a long terme avoir une compatibilité source ou binaire ?

Sauf pour 1 (= 2^0)

Je ne conais pas Meego donc difficile de répondre à la question. Mais j'imagine que vu que Nokia est plutôt orienté ARM, une version ARM de meego suivra bientôt.
Ce que je pense c'est que les ingénieurs de Intel ne se dérangent pas pour supporter d'autres matériel, même si ce n'est pas difficile.

pas besoin de forker. Tu peut enfoyer des parches aussi.

Mais c´est sur que intel et nokia vont donner la priorité à leur platforme

Oui mais non, car on passe par le serveur de l'attaquant.
Sauf si ton PC est verolé, mais alors le problème est autrepart.

De toute façon, comme dit plus haut, avec une IP dynamique c'est pas faisable.
La solution c'est les certificats clients.

ça ne protège pas beaucoup puisque l´attaquant peut faire une requête sur le site de ta banque pour connaître l´image

Si suffisamment de monde n'est pas content du dictateur, il y peut y avoir une révolution.

c´est quoi cette histoire d´utiliser at() à la place de []. Dans la stl que j´ai, ils font exactement la même chose. (je parle de std::vector)

> 30 minutes pour compiler un projet en C++, c'est un extreme.

Le projet sur lequel je bosse prends bien plus de 30 minutes.
Heureusement, au bureau, on a une ferme de compilation, donc c'est beaucoup plus rapide.
Et on ne recompile pas l'entièreté du projet à chaque changement.



Sinon, si on n'aime pas les erreurs incomprhensible de GCC, il faut essayer clang:
http://fseek.me/2010/03/how-to-convince-any-c-developer-to-d(...)
http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-re(...)

Qt fonctionne sur différente platformes, dont Linux/X11 et "Embedded Linux"
La différence entre les deux est que "Embedded Linux" utilise le frame buffer, et un système de gestion des fenêtres spécifique.

Mais beaucoup de platformes dite embaquées (comme Maemo, Meego, openmoko, ...) utilisent quand même X11 (pour la compatibilité avec Gtk), donc c'est le port X11 de Qt qui est utilisé.

Il y avais aussi Qtopia, renommé plus tard Qt Extended, qui était une solution applicative complète pour smartphone (chinois). Mais Nokia n'a pas continué le développement de cette platforme après le rachat de Trolltech. Une partie du code est néenmoins réutilisé dans le projet Qt Mobility.

> D'apres ce que j'ai suivi sur QML, ceux sont les personnes qui ont essaye
> de realiser QEdje qui ont participe a la creation de QML.

QEdje était réalisé par OpenBossa, au brésil.
QML est principalement développé par des anciens dev de Qtopia, en Australie.

Mais c'est vrai que on peu voir sur le blog du dev de QEdje que il fais des truc en QML maintenant [http://blog.morpheuz.cc/]

Je suis entièrement d'accord avec toi.

Mais c'est plus ciblé pour l'embarqué, dans lequel on a juste un interface plein écran. Et chaque appli a son propre style.

Mais je regrete également l'absence de style dans QML, alors que les widgets "normaux" de Qt sont si facile à intégrer dans les différents OS/bureaux.
Ce sera peut-être pour une prochaine version.

Ah, tu parlais de Qt Designer (qui permet de dessiner les boites de dialogues).
Qt Creator est un IDE (qui intègre Qt Designer).

Et je n'ai que brièvement essayer le nouveau designer de QML, donc je ne sais pas répondre à ta question.

Je comprends pas pourquoi dis tu que Qt n'est pas adapté pour du contenu dynamique. Il y a plein d'application Qt qui le font (regarde les appli kde, comme amarok)
Qt est aussi pas mal utilisé dans l'industrie du cinéma.
http://qt.nokia.com/qt-in-use/qt-in-visual-effects
Le future Maya 2011 est fait avec Qt.
Maintenant, ils ont peut-être tous tord, et tous choisis une technologie inadaptée.

QML est basé sur QGraphicsView, donc pas de changement.

En théorie, la séparation devrais se faire entre QML pour l'interface graphique, et C++ pour la logique. (Mais biensur on est libre de faire un peu de logique en javascript dans QML quand c'est adapté.)

Sinon pour ton problème de mp3 et ogg : oui, il est facile d'instancier des composant différent.

C'est triste ton avis sur linuxfr.

Par ailleurs, sur linuxfr je peux:
[X] surveiller mes ennemis : en lisant les news sur Microsoft ou Apple
[X] LOLer et laché d koms : voir le commentaire de shift< plus haut
[X] raconter sa vie au quotidien : en postant des journaux de seconde page.
[X] ne pas rester à l'écart : grâce au nouvelle de patrick_g sur le noyaux on reste au courant de l'actualité.
[X] rester en contact avec ses amis : les moules

Par contre, "[ ] trouver l'âme soeur" ça me semble difficile voir impossible. sur DLFP.

> j'aime bien les langages compilés [...] on a pas d'erreurs bêtes qui arrivent au milieu du programme (par exemple, une concaténation entre un string et un nombre).

Tu confonds compilation et typage statique. L'un n'implique pas l'autre.

D'après le sondage, la majorité n'utilise pas de réseau sociaux. Mais DLFP n'est il pas un réseau social ?
C'est un peu paradoxal, non ?

LOL !

> Pourquoi ne pas tout faire en Python plutôt ?

QML utilise ECMAScript, qui est déjà intégré avec Qt depuis longtemps. Donc on a déjà un langage de script.
Et comme c'est prévu pour l'embarqué, les limites des langages de script sont les performances, l'utilisation de la batterie, ...
Donc associer avec un langage compilé comme le C++ c'est du bonheur.

Mais si tu veux quand même faire du Python, pas de problème, il existe des bindings Python.

Justement, quand on touche les limites du langage, on continue en C++ (Avec Qt, qui - corrige moi si j'ai tord - est « une API correctement faite »).

Et c'est là la force par rapport des technologies comme Flash, où dès que l'on atteint les limites de ce que l'actionscript peut faire, on est bloqué.

QML et QEdje sont donc projet complétement différents.

Le but de QEdje était d'essayé d'intégrer Edje dans Qt. Mais c'est difficile car Edje utilise son propre canevas.

QML est dès le départ prévu pour fonctionner avec Qt, et les éléments sont des QObject et ça utilise le méchanisme des propriété de Qt.

Et Qt peut utiliser l'accélération OpenGL/OpenVG/... alors que le canevas de Edje est purement software il me semble.

Le code est plus déclaratif. Il n'y a pas besoin de de s'y connaitre en algorithmes, pas besoin de penser a la gestion de la mémoire, ...
On décrit juste ce que l'on veux.
C'est un peu comme du HTML, ce n'est pas de la programmation.

De plus, l'objectif est de pouvoir éditer ces documents avec un outils graphique (voir le screenshot de http://labs.trolltech.com/blogs/2010/05/06/qt-creator-and-be(...) )

C'est triste ton avis sur le changement.

Linuxfr c'était mieux avant.

Les applications Qt utilisent la boite de dialogue Gtk sous GNOME
(Mais Les applications KDE forcent la boite dialogue KDE)

Je n'ai pas bien lu la documentation du RecursiveSortFilterProxyModel, mais KDE a aussi un KRecursiveProxyModel. Je ne sais pas à quel point c'est pareil.

http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classK(...)

Je pense que cette classe ne dépends pas de KDE outre mesure.