Gof a écrit 2224 commentaires

Puisque c'est libre, je me permet de donner mon avis :
Il faudrait trouver une autre couleur pour vos abris à vélos

Cependant, d'après mon expérience, en réalité, les pointeurs n'occupent pas tellement de mémoire comparé au reste (pixmaps, images, chaîne de caractères, autres données)
Je parle ici principalement d'applications desktop. Peut-être que d'autre type d'applications utilisent plus de pointeurs. Les benchmarks nous dirons si ça vaux le coup.

Mais j'en profite quand même pour citer Donald Knuth

It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less
than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only
waste half the memory, they effectively throw away half of the cache.

Les programmes sont recompilé de manière à utiliser plus de registres, un time_t de 64bit, et plein d'autre trucs de la nouvelle architecture, mais en utilisant des pointeur de 32 bit au lieu de 64 bit.

Avantage: moins d'utilisation de mémoire (et donc moins de cache-miss)

En effet, si tu as une structure du genre:

struct Node {
   Node *left; 
   Node *right;
   Data *payload
};

Chaque node utilise 24 octets si les pointeurs font 64 bits, mais seulement 12 octests avec des pointeurs en 32bits. S'il y a beaucoup de node, tu perds énnormément en mémoire.

L'ABI du noyaux ce sont les appels systèmes. (c.-à.-d. l'interface entre le mode utilisateur et le mode noyaux)

La manière de gérer les appels de fonctions et l'utilisation des registres est plutôt dictée par L'ABI du langage ou du compilateur

Le principe avait déjà été mentionné sur DLFP l'an passé:

https://linuxfr.org/nodes/56510/comments/1165991

Mais non, c'est tout faux, c'est pas KDE 5.0, c'est KDE Frameworks 5
C'est à dire que ça ne concerne que les librairies. Mais pas les applications.

Rappellez vous du rebranding il y a quelques années ?
http://dot.kde.org/2009/11/24/repositioning-kde-brand

La conclusion, c'était que GTK s'intègre très bien dans un environnement Qt mais que la
réciproque est fausse.

Foutaise !

Certaines applications en Qt ne s'intègre pas parfaitement dans GNOME car le développeur de ces dites applications n'ont fait aucun effort (en particulier les applications KDE).

Mais si tu développes une application avec Qt, avec très peu d'effort il est possible de s'intégrer à Gnome. Example parmis d'autres: QtCreator.

-nokia-developer permet
1) d'utiliser les miroirs git interne à la place des dépots publics.
2) est l'équivalent de -developer-build -confirm-licence dans le configure
(les employés de nokia n'ont pas besoin de confirmer la licence)

Bref, rien de bien différent avec ces options.

Par ailleurs, si tu lis le blog, le "in the open" n'a pas encore commencé. Mais il est prévu que ce soit finalement le cas à partir de juin pour la rencontre des contributeurs.

Heureusement, grâce aux voleurs de contenus, il est possible de lire l'article original.

Trouvé sur google:
http://www.google.no/search?hl=no&source=hp&q=SaaS+Agmt+Enforceable+Against+Cat&btnG=Google-s%C3%B8k&aq=f&aqi=&aql=&oq=

Mais, si par malheur il y a un bug à un endroit ou un autre dans le code qui appelle cette fonction, dans un cas tu aura

ASSERT "data != null" in monfichier.c:42

et dans l'autre

segmentation fault

Et pas plus d'info sans sortir un débuggeur.

QGraphicsview peut effectivement utiliser OpenGL. Mais via une autre couche d'abstraction (QPainter), qui a une API interactive.
Bref, QGraphicsView même en utilisant OpenGL, ne peut pas en profiter au maximum. Par example, lors du rendu tu texte, il vaux mieux dessiner touts les pixmap et puis tout le texte, pour éviter les changement de contexte. Mais QGraphicsView n'est pas capable de faire ça.
Mettre QML par dessus ce qui est appelé le "Scene Graph" permet d'obtenir les meilleurs performances a partir des information fournie par une interface écrite en QML

http://labs.qt.nokia.com/2010/05/18/a-qt-scenegraph/ http://labs.qt.nokia.com/2010/12/02/velvet-and-the-qml-scene-graph/

Le rachat étais il y a presque trois ans.

Et par longtemps, je voulais dire des mois, mais je ne sais pas combien de temps exactement. Ça prends du temps a se finaliser un accord comme ça.

Qt pour linux est GPL depuis 2001 (donc libre)
Qt multiplatforme est GPL depuis 2005 (sortie de Qt 4.0)
En 2008, la licence GPLv3 est ajoutée, et en 2009 la LGPL

Je trouve le titre un peu négatif. Comment arriver à de tels conclusions si rapidement ?

Quelques clarifications : cette transaction étais déjà prévue et planifiée depuis longtemps. Avant le changement de stratégie.

Cela fait déjà plusieurs années que Nokia concentre principalement le dévelopement de Qt pour ses téléphone, et que les clients étaient assez mal servi. Avoir une boite indépendente qui s'occupe de ça permettra de satisfaire mieux les clients, notemment sur les autres platformes (Desktop, Android, ...) Reppelons que le dévelopement de Qt est ouvert, et que Digia est déjà un contributeur de Qt [http://blog.rburchell.com/2010/10/qt-contribution-ecosystem.html]

c'est triste ton point de vue sur le comique de répétition

Est-ce que le bug a été reporté ?

Qt essaye aussi de respecter le comportement. En fonction du gestionaire de fenêtre, certains widgets se comporte différement. La scrollbar par example : sous windows, si on s'écarte de plus d'un certains nombre de pixel avec la souris, ça reviens à l'encienne position. Les menus : dans gnome, la navigation au clavier ignore les entrées désactivés, alors que sous kde, elles sont prise en compte. etc.

"extra" est activé par défaut, c'est le dépot principal.
("core" ne contient que le kernel et les lib nécessaire au fonctionement de pacman.)

Tu veux dire les (dixaines? de) milliers d'employés

Qt a toujours de l'importance pour Nokia.
Dans le cours terme avec tous les smartphone qui seront encore vendu avent le passage à Windows Phone. Mais aussi pour le bas de gamme.

Et puis, il n'y a pas que Nokia derière Qt. C'est un projet réellement libre ou tout le monde peut contribuer, et qui s'ouvre de plus en plus.

Qt est aussi important pour de nombreuse autres boîtes.
Meego continue (Intel viens juste d'annoncer une tablette utilisant Meego)

KDE (qui est justement en train d'essayer de remonter des fonctionalités de kdelibs ver Qt)

C'est un des gros problème de Nokia : Il y a beaucoup trop d'employé.

Il y a une dixaine d'années, alors que l'entreprise était au mieux de sa forme, ils ont engagé tous les informaticiens qu'ils pouvaient, bon ou mauvais.
Il y a plein d'employés qui bossent sur la même chose, et font le travail en double (ou triple), et mettent des battons dans les roues des autres pour que ce soit le travail de leur équipe qui soit pris (et donc pour avoir leur bonus sur leur salaire)

Les méthode de travail sont lourdes et fastidieuse. La pluspart des employés sont manageurs et passent leurs journées en réunion devant des présentation power point pour décider des requirements stricte que les développeurs (souvent des consultants) essayerons d'implémenter.

C'est la raison pour laquelle Nokia n'a pas réussi a produire des téléphones avec des logiciels de qualité.

Ma description est un peu caricaturée, et ce n'est pas comme ça dans toute les équipes, mais c'est une excellente chose pour Nokia de se débarrasser de tous ces gens qui au final ne produisent rien.

Oui Nokia comptait utiliser Qt, non la societe Nokia ne dependait pas de Qt pour son futur, c'etait un element utile mais pas essentiel.

Non. Nokia misait tout sur Qt et QML. La stratégie était de baser tout sur Qt. Et Qt étais un élément essentiel.

Maintenant, la stratégie a changée. Qt est toujours important pour nokia, mais plus pour les smart phones haut de gamme.

Il semblerais qu'il n'y a pas de possibilité d'avoir des programmes « natif » pour Windows Phone.

De plus, Microsoft ne souhaite pas fragmenter les outils de dévelopment sur sa plates-forme.

Nokia ne portera pas Qt sur Windows Phone, ça ne fait pas partie de son plan.

Et il sera difficile pour une tierce partie de faire le port vu l'absence d'applications natives.

Ce n'est pas une argumentation, c'est un fait.
Nokia ne portera pas Qt sur Windows Phone 7.

Pour l'argumentation, c'est que ils ne veulent pas fragmenter l'écosystème (de dévelopment sous Windows Phone) (sic)

Nokia ne portera pas Qt sur Windows Phone 7.

Sauf qu’ils appellent ça un compas.

En fait ils appellent ça une boussole, qui est l'utilisation la plus courante d'un magnétomètre.
Tu confond peut être avec l'anglais, où « compass » signifie (entre autres) « boussole ».