Guillaume Denry a écrit 2954 commentaires

Merci, c'était vraiment super informatif.

Quoique, les standards Web sont bien pire en terme de design que Java en fait. C'est 20 ans d'histoire et de hack sur une technologie qui n'a pas ete prevu pour ca, mais alors pas du tout !

Mouais, c'est un peu péremptoire de dire que cette techno n'a pas été prévue du tout pour ça.
Sûrement au départ, il y a des années, mais les organismes autour du w3c luttent quand même pour essayer d'unifier un peu le bordel, d'avoir des standards cohérents en fonction des contraintes techniques d'exécution des programmes, alors qui es-tu pour juger que cette techno n'a pas été prévue du tout pour ça ? Tu as mieux à proposer avec les mêmes contraintes ?

Ouch, je me rends compte que j'avais une connaissance faussée de l'open source OSI, je ne le pensais pas aussi "libre" que ça.

Où est-il écrit "libre" dans le documenté pointé par le journal ? Je ne vois qu'"Open source".

Gmail fait mieux que ça ?

Non, gmail est moins efficace quant au temps passé pour administrer son propre serveur auto-hébergé.

J'ai beaucoup de mal à ne pas être de ton avis, pourtant, j'ai connu des tas de clients mails depuis j'utilise internet (début des années 90), mais seul mon webmail m'a permis de ne plus jamais faire aucune (meta-)maintenance sur mes mails depuis 2004. Je ne me concentre que sur mes messages, plus sur la façon dont je vais les archiver, les transférer d'un client à un autre, d'une machine à une autre, plus à réfléchir comme accéder à mes messages quand je ne suis pas chez moi, etc etc, franchement, c'est un sacré gain en temps.
Je pense aussi quasiment tout le contraire de fravashyo : gmail est intuitif, simple, rapide, je retrouve tout ce que je cherche en un clin d'oeil, je n'ai plus jamais à me préoccuper de spam. Bref, je fais un peu l'homme sandwich là, j'en suis bien conscient, mais c'est quand même important de faire la part des choses. Ce qui ne m'empêche pas d'avoir un respect et une grande considération pour ceux qui continuent à utiliser des clients mail traditionnels pour avoir le contrôle total sur leurs messages et pour toute autre raison. Mais moi j'y trouverais vraiment plus mon compte.

Tu te serais arrêté à ta remarque sur StarOffice, ton journal aurait juste pu passer pour un truc vaguement drôle.
Maintenant, tout le monde te prend pour un pinailleur de première.

Toi aussi, vu que tu sais que c'est un connaisseur ^{(^_^)(^_^)(^_^)}

Mon fils un jour (vers les six ans) nous a demandé 5-10 mns après lui avoir dit qu’il fallait mettre le zizi dans la zezette de la maman : « Heu, j’aimerai bien que vous me montriez. »… là, blanc, et nous avons refusé.

Le fait que tu aies besoin de nous préciser que vous avez refusé me fait un peu peur, quelque part.

En quoi c'est "privateur de liberté" ?

http://www.numerama.com/magazine/23647-steam-tu-signes-ou-tu-perds-tout.html

Je dois avouer que la séparation des propriétés/méthodes en catégories fonctionnelles est très séduisante.
De plus, la présentation est claire, simple, pas trop verbeuse.
Ils sont allé encore plus loin que Qt.

Oui, savoir si une classe est "poilue" quoi, c'est de l'argot de programmeur (vois pas le rapport avec le chipotage pour le coup)

Le CTO d'Opera lance une hypothèse.

https://lists.webkit.org/pipermail/webkit-dev/2013-February/023841.html

Apple interdit le jit dans les applis pour des raisons de secu (trop facile de peter la sandbox sinon)

Même pour son propre moteur ?

(grillé par Tanguy)

Pas à grand chose mais ça peut donner une idée générale de la "pilosité" (nombre de membres) des classes ancêtres.

Parce que je ne suis pas totalement idiot et que même si je ne suis pas dev, je suis quand même sysadmin et je suis quand même capable d'avoir une petite idée de la manière dont on développe un logiciel, et de ce qu'une doc doit fournir.

Je réalise que ma phrase était mal formulée, je te présente mes excuses.

Explique en quoi, parce que j'ai du mal à voir où. J'avoue que je ne suis pas développeur, mais a-priori les deux fournissent les informations nécessaires…

Si tu n'es pas développeur, comment arrives-tu à savoir a priori ce qu'il est nécessaire d'aller chercher comme informations ?
Je sais bien que mon affirmation était péremptoire, mais franchement, il faut développer souvent en Qt pour comprendre en quoi cette doc est, à défaut d'être parfaite - aucune doc ne l'est - très bonne.
Elle anticipe de nombreux cas d'usages qui sortent un peu du cadre général d'utilisation des objets Qt, c'est en cela qu'elle cartonne, dans sa réponse à ces situations un peu tendues où l'on utilise un objet de façon peu courante.
En outre, elle n'hésite pas à intégrer des bouts de codes en exemple même dans les documentations de membres des classes en anticipant également les prochaines étapes (ou même transverses) de conception de notre logiciel, typiquement http://doc.qt.digia.com/qt/qmainwindow.html#restoreState

Je ne dis pas qu'elle est mal foutue, non plus, je dis juste que je ne la trouve pas parfaite. Son concurrent chez gtk à aussi ses défauts, elle est un peu fruste, mais de là à dire de façon catégorique que celle de Qt est la meilleure, il y a un fossé que je n'oserais jamais franchir.

Moi je le franchis, mais vraiment complètement et sans hésitation.
C'est peut-être parce que je connais les deux, je les pratique, et je prends un plaisir bien plus grand avec la doc Qt, car elle est complète et rigoureuse et m'évite des aller-retour avec des forums et des sites pour trouver de l'info.

Par contre, la doc à un problème, ici: quid de la complexité de cette fonction? "find" => "recherche" => consomme du temps. Alors?
C'est une preuve que cette doc n'est pas exhaustive.

Là franchement, y'a des mouches qui devraient mettre un peu de lubrifiant si elles veulent passer une meilleure soirée ; si tu veux une doc qui colle autant au code source de la lib, bin… lis le code source, ça tombe bien, il est libre. D'autre part, un code IHM qui cherche un widget en fonction d'un id n'a pas forcément besoin d'un algo en O(log(n)), savoir si on est dans un parcours intégral des widgets (dans le pire des cas, comme on peut le supposer) ou pas est une info d'un intérêt très relatif.
Sinon, tant que la doc ne collera pas à la ligne prêt au code source, il y aura des gens mécontents qui se serviront de ce prétexte pour avoir toujours raison dans les conversations.

mais ça me prend plus de temps pour, par exemple, connaître la totalité de la hiérarchie. De quoi hérite QAbstractButton ?

C'est plus fin que ça avec la doc Qt, dans chaque section (public/protected/private) tu as le nombre de propriétés héritées des classes ancêtres, tu peux donc indirectement voir par exemple pour le QPushButton pour les méthodes publiques que :

21 public functions inherited from QAbstractButton
215 public functions inherited from QWidget
31 public functions inherited from QObject
12 public functions inherited from QPaintDevice

Et tu as les liens directes vers les portions des scopes (public/protected/private) pour les ancêtres.

Après bien sûr, y'a toute une page avec la hiérarchie des objets Qt, mais c'est en vrac et pas pratique à lire.

Vous cherchez vraiment la petite bête.
Le ton de Tanguy est rentre dedans, je comprends que ça irrite, mais franchement, la doc de Qt est vraiment difficilement attaquable.
Encore un exemple : http://qt-project.org/doc/qt-5.0/qtwidgets/qwidget.html
Dès qu'un comportement est un peu particulier, il est décrit en détail, avec des schémas s'il le faut, des justifications sur le pourquoi du comment, etc.
Cette doc m'a de nombreuses fois évité d'aller parcourir les forums/stackoverflow

Punaise, soit tu as les paupières fermées, soit tu es d'une sacrée mauvaise foi….
Qt a des défauts, mais sa doc enterre largement celle de GTK…

Suivant Qt depuis plus d'une dizaine d'années, j'ai surtout vu une équipe de gens très talentueux et à la barre, des personnes qui ont su imposer un très gros niveau de qualité, en particulier au niveau de l'API qui est d'une très grande clarté et cohérence.
La doc est absolument géniale, elle fourmille d'exemples, de cas d'usages, est d'une exhaustivité rare, c'est un vrai bijou.
Je réalise que mon commentaire est dithyrambique mais ce framework m'a vraiment réconcilié avec l'IHM alors que je sortais d'années de développement avec Delphi.

Comparer les deux n'a absolument aucun sens, ils n'ont pas du tout la même vocation.

Oui, menfin lorsqu'on souhaite écrire un GUI multiplatforme, vient le moment où on se demande si on va opter pour tel ou tel toolkit et les candidats sont peu nombreux, entre autre : GTK, QtGui, wxWidget, Java et .NET (je déconne).
Ca paraît donc relativement pertinent de mettre Qt et GTK dans la balance à ce moment là.

Il faut surtout se demander si on peut les mettre au même niveau, Qt est très générique et VCL a l'air de loin (mais je peux me tromper) d'être une lib métier dédiée à la suite bureautique, VCL offre peut-être des outils qui seraient considérés comme appartenant à une couche au dessus de Qt, bref, est-ce vraiment comparable ? Sans compter que VCL a l'air d'être uniquement dédiée au graphique là où Qt offre beaucoup plus de possibilités.
De toute façon, qui a envie d'évaluer le temps que ça prendrait de convertir la VCL a Qt ? Qui a envie de se demander s'il faudrait utiliser uniquement QtGui ou bien plus de modules pour le coeur de l'application ? C'est très difficile de bouger l'existant, l'inertie a l'air énorme, et je ne vois pas qui trouverait ça trippant de se dire "hé ho, et si je m'amusais à adapter LibreOffice à Qt en ré-écrivant tous les composants métier de l'application avec !"

Ah mince, moi quand je vais au MacDonalds, j'y vais pour manger du canard.
Je comprends, maintenant.

Je suis curieux de savoir comment on fait un membre privé en C :)

Ce qui ressemblerait le plus à la notion de privé en C serait pour moi les déclarations static