Gof a écrit 2224 commentaires

Qt pour Android ? biensur que c'est possible ! http://code.google.com/p/android-lighthouse/

Exactement.

Le future style de meego est gardé précieusement secret pour l'instant. J'imagine pour des raisons de markting.
Et donc, forcément, le code qui implémente ce style ne peux pas être publique.

Mais Qt lui même, reste ouvert comme avant.
Ce n'est qu'une branche d'une petite partie de Qt qui passe temporairement secret. (c.-à-d. qu'on ne peux plus voir les commits des dev en temps réel dans cette branche pour l'instant.)

Ah, on me souffle dans l'oreillette que Google est aussi accessible en HTTPS:
https://encrypted.google.com/

Il suffit visiter depuis https://duckduckgo.com/
Le referer n'est pas envoyé depuis les sites en HTTPS [RFC 2616 § 15.1.3]

Google en https redirrige vers le google en http.

Kopete et Télépthy ont chacun leur propre couche d'abstraction de tous les concepts d'IM (contacts, messages, discussions, ...)

Ces couches d'abstraction sont différentes, et pas compatible entre elles.
Porter de l'un a l'autre serait tout réécire au final.

Faire un "pont" entre les deux couche d'abstractions serait possible, mais comme il n'y a pas de correspondance exacte entre tous les concepts, on arriverais un un truc pas top.

Le truc c'est que Kopete n'a plus eu de dévelopment actif depuis KDE4.

Le problème, contrairement à ce que dit le journal, n'est pas qu'il a vieilli et qu'il est difficile à maintenir. Le code de Kopete est relativement propre à mon gout.

Le problème c'est le manque de dev, il n'y a plus de dévelopeur actif. Juste quelques patch de temps en temps pour maintenir en vie.

Le problème c'est que certains ce sont mis dans la tête d'utiliser télépathy, qui a une architechture complètement opposée à celle de Kopete, ce qui signifie que tout doit être réécris. Forcément ça prends du temps.

Et ça ne dois pas motiver pas les dévelopeur à ce mettre à Kopete en sachant que de toute façon Kopete va être remplacer.

J'utilise beaucoup xclip. Je n'ai jamais remarqué de problème avec klipper de KDE.

J'utilise aussi souvent
xclip -o > foo.txt
pour enregistrer le contenu du presse papier dans un fichier.

Chipotage chipotage, mais la capacité annoncé des disquettes est de 1440 Kio, soit 1.40 Mio, soit 1.47 Mo

http://en.wikipedia.org/wiki/Floppy_disk

Oui oui, les gens mélangaient les unités de base 10 et les base 2 dans le même nombre

Dénombrable:

Si on défini la taille de la bêtise humaine par le nombre de connerie que les humains peuvent faire. Le nombre de bêtise est dénombrable car on peut écrire une description de chaque bêtise avec un nombre fini de lettres

J'ai bon ?

Ce n'est pas le premmier.

Le premmier étais:
https://linuxfr.org/poll/send,1.html

Il y en a eu même d'autre sur le même sujet:
https://linuxfr.org/poll/send,116.html

Un vrai méta sondage:
https://linuxfr.org/poll/send,153.html

Et un méta sondage sur un sujet important.
https://linuxfr.org/poll/send,115.html

Mais quand on y regarde de plus près, beaucoup de sondages contiennent au moins une méta option.

Je faisais allusion à la mauvaise traduction de issue.

Pourquoi est-ce que vous parlez de toutes ces sorties ?

(La traduction du mot anglais « issue » serait plutôt « problème »)

Même pas besoin de forker, il suffit de contribuer.

Nokia accepte les contributions externes, et essaye d'ouvrir au maximum le développement de Qt.

http://labs.qt.nokia.com/2010/06/03/qt-and-open-governance/

Mobilin et Maemo étaient basés sur Gtk et Gnome, probablement à cause de la license de Qt l'époque..
Mais ils ont compris que Qt était techniquement bien supérieur, et vu que maintenant c'est LGPL, ils ont décider de faire le changement.

Ce changement prends du temps, car il consiste à réécrire tout, mais toutes les nouvelles applications sont développé avec Qt.

(Qt est-il tellement supérieur que ça vaux le coup de perdre des années travail et d'expériences avec Gtk+ ?)

Qt fait partie de la stratégie pour remédier a leur perte de vitesse sur les smartphones.

Qt deviens chez Nokia le framework de base de tout leur future smartphones.

Il y a seulement 2 ans que Trolltech a été racheté. C'est moins que le temps qu'il faut pour adapter toute la chaîne de produits.

Le prochain smartphone (N8) sera avec Qt. Et toutes les nouvelles applications développé par Nokia sont basé sur Qt.

Parce que dbus est tout pourri.

Voir les commentaires du blog.

Super, novell a contribué à la translation polonaise.
La contribution de Novell à KDE n'est certainement pas négligable mais je pense pas suffisente pour dire qu'elle est en tête

Je suis presque sur que Google et Nokia sont devant (et ce sont des distributions/revendeurs Linux, avec Android/ChromeOS et Maemo/Meego)

Mais je serais aussi interesé par un tableau pour voir ce qu'il en est.

Difficile de dire car KDE est principalement communautaire.

Mais entre Google (une trentaine d'étudiants pour 3 mois de summer of code ~= 8 dev par an)
Nokia (principal sponsor), Canonical (aussi un sponsor important), Mandriva, KDAB (develope kdepim), et les quelques petite boites fondées par des dev de KDE, il est assez difficile de donner un ordre.
Et en particulier d'affirmer que Novell est le plus important contributeur à KDE.

Par ailleurs Novell n'est pas le deuxième contributeur au noyaux Linux, Intel est avant (Et il entre dans la catégorie "distributions/revendeurs Linux" avec Mobilin/Meego)

> KDE (première)

Source ?

(Car je n'y crois pas)

Sauf que Will est pas néerlandais, il est belge.

j´ai lu quelque part que Sid était un personnage de toys story. un gamin qui casse des jouets je crois

Qt trop gros en mémoire ?

Pourtant il est possible de réduire la taille de Qt en enlevant le code qu'on a pas besoin : http://doc.trolltech.com/latest/fine-tuning-features.html

Pas besoin de boucle d'événement pour les signaux et slots de Qt, ni pour utiliser le réseau de façon synchrone.

Par ailleurs, la boucle d'événement de Qt s'intègre très bien dans une autre boucle d'événements d'une autre lib.
Il suffit d'apellet Q(Core)Application::processEvents() à chaque iterations.

Et les signaux de boost ne permettent pas de passer d'un thread à l'autre. Ou de mettre en queue des signaux.
En plus, il est impossible de rajouter des signaux boost a une classe sans casser la compatibilité binaire, alors que c'est pas un probème avec Qt.

Qt c'est le plus beau et le plus fort et puis c'est tout ! ;-)
La STL pas cohérente avec le reste de Qt. (Bon, c'est la faute de Qt)

> Un peu comme un vector de shared_ptr, c'est ça ?

c'est plus simple de faire
QString maString("foo");
que string_ptr maString(new string("foo"));

> En quoi la copie des conteneurs de la STL n'est pas déterministe ?

Tu m'a mal compris. Je disais justement que la STL voulais que ce soit déterministe et que c'est une des raisons pour laquelle rien n'est partagé par défaut.

> Se passer des templates, je trouve ça idiot. Franchement.

Qt ne se passe pas des template, ils sont juste utilisé modérément. std::vector ça va.

Les "additions" sont des macros tout ce qu'il y a de plus standards. Les analyseurs de code n'ont en général pas de problème à parser ça, sans modifications.