Pourquoi n'y a-t-il pas plus d'applications de bureau écrites avec Qt? [fermé]

Autant que je sache et que j'ai compris dans mon expérience avec Qt, c'est une très bonne bibliothèque et facile à apprendre. Il a une API très bien conçue et est multi-plateforme, et ce ne sont que deux des nombreuses fonctionnalités qui le rendent attrayant. Je suis intéressé de savoir pourquoi plus de programmeurs n'utilisent pas Qt. Y a-t-il une déficience qui parle contre elle? Quelle fonctionnalité rend les autres bibliothèques meilleures que Qt? Le problème est-il lié aux licences?

Je ne veux pas vraiment que ce soit une réponse critique, mais ce sont les raisons pour lesquelles je n'utilise pas personnellement Qt. Il y a beaucoup de bonnes choses à dire à ce sujet, à savoir que l'API fonctionne la plupart du temps et qu'elle relie de manière transparente les plateformes. Mais je n'utilise pas Qt, car:

1. Dans certains cas, les programmes natifs ne ressemblent pas. Concevoir une interface utilisateur unique pour toutes les plates-formes ne va pas forcément bien paraître lorsqu'il est déplacé de machine en machine, pour diverses raisons de style visuel. Par exemple, sur les machines Mac, les barres divisées sont généralement relativement épaisses et les boutons sont petits et arrondis avec des icônes. Sur les machines Windows, les barres divisées sont généralement étroites et les boutons sont plus textuels, avec des motifs plus carrés. Ce n’est pas parce que vous pouvez écrire une interface utilisateur pour chaque plate-forme que vous devriez le faire pour la plupart des applications.
2. Qt n'est pas une bibliothèque C ++. Cela nécessite une étape de compilation séparée, ce qui rend le processus de construction beaucoup plus compliqué par rapport à la plupart des autres bibliothèques.
3. En conséquence de (2), les IDE et les outils C ++ peuvent marquer les expressions Qt comme des erreurs, car ils ne comprennent pas les spécificités de Qt. Cela force presque l'utilisation de QtCreator ou d'un éditeur textuel comme vim.
4. Qt est une grande quantité de source, qui doit être présente et préinstallée sur toute machine utilisée avant la compilation. Cela peut rendre la création d'un environnement de construction beaucoup plus fastidieuse.
5. Il est disponible uniquement sous LGPL, ce qui rend difficile l'utilisation d'un déploiement à un seul binaire lorsqu'il est nécessaire de publier sous une licence plus restrictive ou moins restrictive.
6. Il produit des binaires compilés extrêmement volumineux par rapport aux "applications natives standard" écrites de la même façon (à l'exception des applications écrites pour KDE).

Comme on dit, chaque outil correspond à chaque problème et à chaque situation ...

Mais si vous êtes programmeur C ++, Qt est votre framework. Pas de rival.

Nous développons une application commerciale complexe pour l'imagerie médicale, et Qt tient bon.

Je ne dis pas que les «inconvénients» que les gens disent à ce sujet sont faux, mais j’ai le sentiment qu’ils n’ont pas essayé Qt depuis longtemps (cela s’améliore continuellement à chaque nouvelle version ...), et surtout tous les problèmes qu'ils commentent ne sont pas un problème si vous prenez soin de vous.

Incohérence de la plate-forme d'interface utilisateur: uniquement si vous utilisez les widgets d'interface utilisateur "tels quels", sans personnalisation ni art personnalisé.

Surcharge du préprocesseur Qt: uniquement si vous abusez du mécanisme signal-slot, ou de l'héritage QObject, lorsqu'il n'y en a pas vraiment besoin.

En passant, nous écrivons toujours des applications en C # .NET et le faisons depuis longtemps. Donc, je pense avoir une perspective enouch.

Comme je l'ai dit, chaque outil pour chaque situation,

mais Qt est sans aucun doute un cadre cohérent et utile.

De toutes les choses que je n'aime pas chez Qt, le fait qu'il ne fonctionne pas bien avec les modèles me gène le plus. Vous ne pouvez pas faire ça:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

De plus, il ne fonctionne pas bien avec le préprocesseur. Vous ne pouvez pas faire ça:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

Cela, ajouté au fait que tout ce qui répond à un signal doit être un Q_OBJECT, rend Qt difficile à travailler pour un programmeur C ++. Les gens habitués à la programmation de style Java ou Python sont probablement meilleurs en réalité.

En fait, j'ai passé beaucoup de temps et d'efforts à rechercher et à concevoir un moyen de récupérer la sécurité de type et de connecter un signal Qt à n'importe quel objet foncteur: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

Le genre de chose que je veux faire ici est le développement de base du C ++ quotidien rendu quasiment impossible par le Qt moc ... ce qui en soi est tout à fait inutile maintenant, si jamais il l’a été.

Franchement, je suis coincé avec ça parce que si vous voulez faire des tests d’interface utilisateur automatisés, Qt est quasiment le seul jeu en ville à part le MFC ... qui date de 1980 (ça craint de travailler très dur dans cette merde). Certains pourraient dire WX mais cela pose des problèmes encore plus graves. GTKmm aurait été mon premier choix, mais étant donné que tout est dessiné par le propriétaire et ne rend pas l'accessibilité… ne peut pas être piloté par un logiciel de test standard. Qt est assez difficile à cet égard ( fonctionne à peine lorsque vous modifiez le plug-in d'accessibilité).

Une des raisons de ne pas utiliser Qt est que si vous écrivez pour une seule architecture, telle que Windows, vous pouvez utiliser C # / .NET (ou Cocoa sur Mac), car ils seront invariablement en mesure de tirer parti des dernières sonneries et outils. -les sifflets de l'OS.

Si vous écrivez des applications multiplates-formes, il est possible que vous soyez déjà fortement investi dans une autre technologie telle que Java (c'est-à-dire que vous travaillez dans un "Java Shop"). Votre choix de technologie peut être dicté par l'écosystème dans lequel vous développez, tels que les API spécifiques à une langue. Dans ce type de cas, réduire le nombre de technologies peut être bénéfique.

Une troisième raison à laquelle je peux penser est que Qt est basé sur C ++ et que C ++ est un langage relativement difficile / dangereux dans lequel programmer. Je pense que c'est un langage pour les professionnels. Si vous avez besoin d’être performants et d’être méticuleux, le C ++ est probablement toujours le meilleur jeu en ville. En fait, Qt élimine beaucoup de problèmes de gestion de la mémoire si les choses tombent hors de portée. De plus, Qt lui-même fait du bon travail en isolant l'utilisateur de la plupart des problèmes C ++ méchants. Chaque langue et chaque cadre a ses avantages et ses inconvénients. C’est une question très, très compliquée qui peut généralement être résumée par l’addage souvent observé chez les convives: vitesse, qualité et prix (mais vous ne pouvez en choisir que deux).

Bien que les règles me disent que je devrais rester concentré sur la réponse à la question, je souhaite réfuter certaines des questions soulevées par Billy ONeal, qui, à mon avis, résume bien les raisons couramment invoquées pour ne pas utiliser Qt:

1. Qt est en effet un fichier bibliothèque / framework / en-tête C ++. Il est augmentépar un macro processeur (moc) qui active les signaux et les slots, entre autres. Il transforme des macro-commandes supplémentaires (telles que Q_OBJECT) afin que les classes disposent d'une introspection et de toutes sortes d'autres avantages que vous pourriez penser d'ajouter des fonctionnalités Objective-C à C ++. Si vous en savez assez sur le C ++ pour être choqué par ce manque de pureté, c'est-à-dire que vous êtes un pro, alors 1) n'utilisez pas Q_OBJECT et ses semblables ou 2) soyez reconnaissant qu'il le fasse, et programmez-vous dans les cas très limités. où cela pose un problème. Pour les gens qui disent "Utilisez Boost pour les signaux et les slots!" alors je voudrais rétorquer que vous échangez un "problème" pour un autre. Boost est énorme, et il a ses propres problèmes fréquemment cités, tels qu'une documentation médiocre, des API épouvantables et des horreurs multi-plateformes (pensez aux anciens compilateurs comme gcc 3.

2. Pour le support de l'éditeur, cela découle également de 1, je suis un peu d'accord. En fait, Qt Creator est à mon humble avis le meilleur éditeur C ++ graphique, même si vous n’utilisez pas le logiciel Qt. Beaucoup de programmeurs professionnels utilisent emacs et vim. De plus, je pense qu'Eclipse gère la syntaxe supplémentaire. Ainsi, aucun problème avec les macros Qt (Q_OBJECT) ou les ajouts de signaux / slots. Vous ne trouverez probablement pas ces macros dans Visual Studio, car (je le concède), elles constituent des ajouts à C ++. Mais dans l’ensemble, les utilisateurs de C # / .NET ne vont pas utiliser Qt de toute façon, car ils disposent de nombreuses fonctionnalités couvertes par leurs propres techniques propriétaires.

3. Quant à la taille de la source Qt, tant qu'elle compile du jour au lendemain, qui s'en soucie? J'ai compilé Qt 4 sur mon Macbook dual core en "moins qu'une nuit". J'espère certainement que ce n'est pas ce qui motive votre décision d'utiliser ou non une technologie particulière. Si cela pose vraiment un problème, vous pouvez télécharger les SDK précompilés pour Mac, Linux et Windows à partir du site Web de Qt.

4. La licence est disponible en trois choix: 1) Licence propriétaire au cas où vous voudriez modifier Qt lui -même et ne pas partager, ou cacher le fait que quelqu'un utilise Qt et ne veut pas donner d'attribution (pourrait être très important pour la stratégie de marque et l'image!) 2 ) GPL et 3) LGPL. Oui, il y a des problèmes avec la liaison statique (rouler tout Qt dans le binaire) - mais je pense que c'est plus parce qu'on ne peut pas jeter un coup d'œil à l'intérieur et remarquer que vous utilisez Qt (attribution!). J'ai essayé d'acheter une licence propriétaire auprès de Digia et ils m'ont dit "pour ce que vous faites, vous n'en avez vraiment pas besoin". Sensationnel. D'une entreprise qui vend des licences.

5. La taille du fichier binaire / bundle est due au fait que vous devez distribuer le contenu Qt aux personnes qui ne l’ont pas: Windows en a déjà? le truc Visual Studio ou vous devez installer le run-time. Mac vient déjà avec l'énorme Cocoa et peut être lié dynamiquement. Bien que je ne fasse pas beaucoup de distribution, je n'ai jamais rencontré de problème avec la distribution du fichier statique de ~ 50 mégaoctets (que je peux rendre encore plus petit avec certains utilitaires d'extraction / compression binaires comme UPX). Cela ne me concerne pas assez, mais si la bande passante était un problème, j'ajouterais une étape UPX à mon script de construction.

6. Qu'est-ce qui définit "l'apparence et la sensation des autochtones"? Je pense que "la plupart" conviendraient que Mac se rapproche le plus de l'apparence et de la convivialité. Mais je suis assis ici, regardant Safari, iTunes, Aperture, Final Cut Pro, Pages, etc., et ils ne se ressemblent pas, même s'ils sont fabriqués par le fournisseur du système d'exploitation. Je pense que l'aspect "toucher" est plus pertinent: style des widgets, réactivité, etc. Si vous vous souciez de la réactivité, voici une bonne raison d'utiliser le langage C ++ plutôt que Java, ou un autre langage très dynamique. (L'Objectif C bascule aussi, mais j'essaie de dissiper les mythes au sujet de Qt)

En résumé, c'est une question compliquée. Mais j'aimerais souligner que je pense qu'il y a moins de raisons de "ne pas utiliser Qt", comme on pourrait le penser, en se basant sur des mythes et des informations obsolètes depuis une décennie.

Une partie de cela est une licence. Voir https://en.wikipedia.org/wiki/Qt_(software)#Licensing pour consulter l'historique des licences. Jusqu'en 2000, les personnes qui s'intéressaient beaucoup à l'open source n'utilisaient pas Qt. Période. (C’était en fait la motivation initiale du développement de Gnome.) Jusqu'en 2005, les personnes qui souhaitaient pouvoir publier un logiciel libre pour Windows n’utilisaient pas Qt. Même après cette date, les personnes qui recherchaient des logiciels libres sous une licence autre que la GPL n’avaient tout simplement pas la possibilité d’utiliser Qt. Ainsi, tout projet de logiciel libre plus ancien que ces dates ne pourrait utiliser Qt. Et, bien sûr, les personnes écrivant du code propriétaire devaient payer pour ce privilège.

De plus, ce n’est pas comme s’il y avait pénurie d’autres options. Par exemple, WxWidgets , GTK + et Tk sont tous des toolkits multi-sources open source.

En outre, pendant longtemps, Windows était si dominant sur le bureau que beaucoup de logiciels ne contenaient que Windows. Si vous installez la chaîne d’outils de Microsoft, il est plus facile d’utiliser les éléments propriétaires de Microsoft que de s’inquiéter de quoi que ce soit, et beaucoup de programmeurs l’ont fait.

Je suis d'accord avec presque toutes les raisons évoquées ci-dessus, mais beaucoup de personnes ici ont déclaré qu'elles n'utiliseraient pas Qt à cause des frais généraux supplémentaires que cela entraîne. Je ne suis pas d'accord avec cela parce que tous les langages les plus courants aujourd'hui (Java, C # et Python) sont eux-mêmes assez lourds.

Deuxièmement, Qt rend la programmation avec C ++ tellement facile et directe qu’elle compense les ressources supplémentaires qu’elle utilise. J'ai rencontré pas mal d'applications console écrites en Qt plutôt qu'en C ++ standard en raison de la facilité avec laquelle elles peuvent être écrites.

Je dirais que la productivité de Qt est supérieure à celle de C / C ++ mais inférieure à celle de langages comme Python.

Ce n’est pas vraiment une tentative de déclencher une guerre des flammes, je voulais juste aborder quelques points.

Probablement la vraie raison pour laquelle Qt n'est pas plus largement utilisé est qu'il est C ++ et que moins de gens l'utilisent pour les applications de bureau.

Qt n'est pas une bibliothèque C ++. Cela nécessite une étape de compilation séparée, ce qui rend le processus de construction beaucoup plus compliqué par rapport à la plupart des autres bibliothèques.

Le vs-addin pour Visual Studio le fait automatiquement, comme le fait le processus de création de ligne de commande de Qt. Le compilateur de ressources utilisé pour créer les boîtes de dialogue pour MFC constitue également une étape distincte, mais cela reste du c ++.

Qt est une grande quantité de source, qui doit être présente et préinstallée sur toute machine utilisée avant la compilation. Cela peut rendre la création d'un environnement de construction beaucoup plus fastidieuse.

Il existe un téléchargement binaire pour chaque version de visual studio et la création à partir de la source est une commande unique. Je ne vois pas la taille de la source SDK est tellement un problème ces jours-ci. Visual studio installe désormais toutes les bibliothèques C ++ au lieu de vous laisser choisir, de sorte que la taille d'installation du compilateur est> 1 Go.

Il est disponible uniquement sous LGPL, ce qui rend difficile l'utilisation d'un déploiement à un seul binaire lorsqu'il est nécessaire de publier sous une licence plus restrictive ou moins restrictive.

La LGPL ne s'applique qu'à la bibliothèque, cela n'affecte pas votre code. Oui, cela signifie que vous devez envoyer des DLL plutôt qu'un seul fichier binaire (sauf si vous payez), mais dans un monde où vous devez télécharger un runtime Java ou une mise à jour .Net pour un utilitaire minuscule, ce n'est pas si grave. C'est également moins un problème sur les plates-formes avec une seule ABI, de sorte que d'autres applications Qt peuvent partager les bibliothèques.

Dans certains cas, les programmes natifs ne ressemblent pas. Concevoir une interface utilisateur unique pour toutes les plates-formes ne va pas forcément bien paraître lorsqu'il est déplacé de machine en machine, pour diverses raisons de style visuel.

Il est supposé utiliser des widgets et des thèmes natifs. Je dois admettre que je fais surtout des applications techniques pour que mes utilisateurs ne soient pas trop préoccupés par le style. Sur Windows, en particulier, la nouvelle mode consistant à tout transformer en un widget pour smartphone signifie qu’il existe de moins en moins de standard.

La raison est simple: il n’a pas de bonnes liaisons avec toutes les langues courantes, et comme par magie, il n’est pas toujours approprié au travail à effectuer.

Utilisez le bon outil pour le travail. Si j'écris une simple application en ligne de commande, pourquoi devrais-je la gonfler avec Qt juste pour le plaisir de l'utiliser?

Comme réponse plus générale (que je peux donner parce que je suis pertinent ici), certains programmeurs n’auront tout simplement jamais essayé et décidé de l’utiliser. Dans certains cas, il n'y a pas de raison particulière autre que le programmeur n'a jamais trouvé le besoin et a examiné.

Cadres comme Qt sont appropriés lorsque vous êtes plus préoccupé par votre produit à la recherche de la même sur toutes les plateformes que votre produit à la recherche à droite sur toutes les plateformes. De plus en plus, de nos jours, ce type d’applications passe aux technologies Web.

Je conviens que Qt est un cadre agréable pour travailler. Néanmoins, il y a un certain nombre de problèmes que j'ai avec elle:

1. Il est écrit en C ++, qui est un langage de très bas niveau. Le seul fait qu’il s’agisse de C ++ rendra chaque programmeur Qt beaucoup moins productif que les cadres écrits dans d’autres langues. Mon principal atout avec C ++ en tant que langage de développement graphique est qu’il n’a pratiquement aucune notion de gestion automatique de la mémoire, ce qui rend le processus de développement beaucoup plus sujet aux erreurs. Ce n'est pas introspectif, ce qui rend le débogage beaucoup plus difficile. La plupart des autres principaux kits d’interface graphique ont des notions de gestion automatique de la mémoire et d’introspection.
2. Chaque boîte à outils multiplate-forme présente le problème suivant: elle ne peut implémenter que le plus petit dénominateur commun de toutes les plates-formes prises en charge. Cela, ainsi que différentes directives d’interface utilisateur sur différentes plates-formes, remet beaucoup en question l’intérêt des interfaces graphiques multi-plateformes dans leur ensemble.
3. Qt est très centré sur le codage de toute votre interface utilisateur. Même si vous pouvez utiliser QtDesigner pour construire certaines parties de votre interface utilisateur, il manque sérieusement par rapport au constructeur d'interface (Cocoa / Obj-C) ou aux outils .Net.
4. Même si Qt inclut beaucoup de fonctionnalités d’application de bas niveau, il n’est pas comparable à un cadre personnalisé pour une plate-forme donnée. Les bibliothèques de système d'exploitation natives pour Windows et OSX sont nettement plus puissantes que les implémentations de Qt. (Pensez aux frameworks audio, à l’accès au système de fichiers de bas niveau, etc.)

Cela dit, j'adore utiliser PyQt pour le prototypage rapide d'applications ou les applications internes. L'utilisation de Python pour effectuer tout le codage atténue les inquiétudes liées au C ++ et fait de Qt un endroit très agréable.

Modifier, en réponse à certains commentaires:

Quand j'ai écrit à propos de Qt écrit en C ++, je ne me plaignais pas tellement de Qt lui-même, mais plutôt de l'environnement dans lequel il évolue. Il est vrai que Qt gère très bien ses propres ressources, mais toutes vos interfaces graphiques (GUI), mais Le code non-Qt doit également être écrit en C ++. Même là, Qt fournit de nombreux outils intéressants, mais au final, vous devez traiter avec C ++ à ce niveau. Qt rend le C ++ supportable, mais reste le C ++.

En ce qui concerne l’introspection, je veux dire ceci: Les cas les plus difficiles à résoudre sont ceux qui ont un pointeur sur un objet qui ne se comporte pas comme il le devrait. Avec C ++, votre débogueur pourra peut-être regarder un peu à l'intérieur de cet objet (s'il a des informations de type à un moment donné), mais même cela ne fonctionne pas toujours. Prenez, par contre, le cacao dans la même situation. Dans Cocoa / Obj-C, vous pourrez envoyer des messages ("fonctions d'appel") à un objet directement dans le débogueur. Vous pouvez changer l'état des objets, vous pouvez l'interroger pour ses attributs, vous pouvez lui demander son type et ses noms de fonctions ... Cela peut rendre le débogage beaucoup plus pratique. Qt / C ++ n'a rien de semblable à cela.

J'aime beaucoup Qt, mais c'est un peu lourd pour beaucoup d'applications. Parfois, vous n'avez simplement pas besoin de ce niveau de complexité. Parfois, vous avez juste besoin de quelque chose de simple sans tous les frais généraux de Qt. Toutes les applications ne doivent pas nécessairement être pilotées par les événements et C ++ fournit un ensemble raisonnable de modèles. Boost fournit un autre très bon ensemble et inclut beaucoup de fonctionnalités de bas niveau (fichier, socket, pointeurs gérés, etc.) que QT.

D'autres applications ont des exigences de licence qui ne fonctionnent pas bien avec les licences commerciales de GPL, LGPL ou Qt. La GPL est inappropriée pour les logiciels commerciaux. La LGPL est inappropriée pour les logiciels liés statiquement et la licence commerciale coûte de l'argent - ce que beaucoup ne veulent pas payer.

Certains ont des considérations de sécurité ou de stabilité qui n'autorisent pas les bibliothèques complexes comme Qt.

Vous devez exécuter moc pour pré-traiter vos sources. Ce n'est pas un gros problème, mais cela peut être décourageant pour le nouvel utilisateur. Beaucoup de programmeurs pensent que vous avez besoin d'utiliser Qmake avec Qt, mais c'est un terme impropre. Il est possible de connecter Qt à d’autres systèmes de compilation assez facilement.

Certaines cibles sont très limitées en mémoire ou en CPU.

Il y a des pièges spécifiques à la plate-forme. La plupart de ces pièges sont sans papiers. Construisez une application suffisamment volumineuse et vous allez vous y poser des questions et vous demander ce qui se passe (disclaimer, la dernière fois que j'ai utilisé Qt dans la colère datait de plus de 18 mois, alors elle s'est peut-être améliorée).

C'est seulement C ++. D'autres liaisons de langage existent, mais elles ont tendance à masquer ou à exposer mal une grande partie des fonctionnalités pour lesquelles vous souhaiteriez utiliser Qt.

Il y a beaucoup de raisons de ne pas utiliser Qt, c'est pourquoi il existe des alternatives. Si tout ce que vous avez est un marteau, alors chaque problème ressemblera à un clou.

La chose la plus importante mais non mentionnée. Dans les gros projets, une chose cause tellement de problèmes et de code non nécessaire. Les mécanismes d'intervalle de signal de Qt sont inefficaces. Les widgets Qt ne fournissent pas les signaux nécessaires pour les widgets simples d'événements. Par exemple, vous ne pouvez pas définir de signaux pour onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus, etc. Même le widget le plus complexe, tel que QTreeWidget, fournit un ou deux signaux extrêmement simples et inutiles.

Oui, vous pouvez utiliser les événements MAIS !!! vous avez créé une nouvelle classe pour chaque widget avec un événement personnalisé. C'est une énorme efficacité perdue;

• Vous avez réécrit chaque événement d'objet de widget personnalisé avec de petites modifications.
• Vous perdez tous les éléments de Qt Designer. Vous devez promouvoir chaque widget avec des événements personnalisés.
• Le projet est devenu plus gros et difficile à maintenir.
• Vous avez commencé à ne pas aimer qt pour cette raison. Et commencez à parler de la façon dont .net fournit aux délégués, combien il est bien meilleur que l’emplacement du signal, comment les composants .net (widgets) fournissent généralement tous les événements imaginables. Et etc.

Un de mes collègues a créé une nouvelle classe de boîtes à options pour chaque widget Boîte à options, car il devait utiliser un événement non signal. Histoire vraie...

Cependant, Qt est à ce jour le meilleur framework d’interface utilisateur C ++ avec des hauts et des bas.

Selon moi, apprendre la programmation C ++ est plus simple que de tomber dans d'autres langages qui cachent leur complexité, et le programmeur ne sait pas ce qui se passe réellement en arrière-plan. Qt, d’autre part, ajoute des avantages par rapport au C ++, pour le rendre plus avancé que le C ++ natif. Ainsi, Qt C ++ est un excellent cadre pour qui veut développer des tâches de bas niveau, ou de haut niveau, de la même manière. C ++ est (selon certaines pratiques) un langage simple et complexe. Complexe pour qui ne veut pas contester, simple pour celui qui aime. Ne le laissez pas pour sa complexité!

La raison réelle n'est pas technique.

Les gens sont différents. Tels sont leurs choix. L'uniformité n'est pas une caractéristique humaine.