Sous Windows, cela ne m'arrive que très rarement de devoir compiler un programme. Beaucoup plus rarement que sous GNU/Linux. Cela vient du fait que quand un programme Windows est compilé, les problèmes sont rarissimes. Sous GNU/Linux, je dois souvent compiler le programme après plus de deux heures de recherche infructueuse pour tenter d'installer le binaire. Du coup, je me demande si je ne devrais pas, dès qu'un programme UNIX ne s'en présente pas du gestionnaire de paquet, le compiler directement, puisque c'est souvent plus simple. Après, je suis d'accord pour dire que la gestion des logiciels est simple pour l'utilisateur lambda. Mais pour le moindre programme moins "lamdba", c'est 100 plus difficiles que Windows. On l'oublie trop souvent, mais la force de Windows ne se situe pas dans la facilité d'utilisation, mais dans la facilité d'administration (je n'imagine même pas la différence sous des postes multiples). D'ailleurs, seul Windows permet d'administrer le système en profondeur sans utiliser la ligne de commande pour un autre usage que les scripts/l'automatisation. Tous les UNIX (GNU/Linux/BSD/MacOS/Android) nécessitent d'utiliser la ligne de commande pour administrer le système. Je suis donc d'accord pour dire que GNU/Linux ne pose pas de problème particulier pour les débutants. Pas plus que MacOS. Sauf que même sous MacOS, j'en c*** pour administrer le système. Et Android et un cauchemar en matière d'administration.
D'ailleurs, pour comprendre cela, il faut situer l'histoire de Windows, avec l'apparition de Windows NT et d'OS/2, ce qui apportait un excellent support multi-utilisateur, et une excellente gestion des paramètres (grâce à la base de registre). Tout cela ne change rien à la performance du système, mais cela change beaucoup de choses sur le plan de l'administration. J'ai l'impression que les UNIX (et UNIX-Like) étaient plus puissants bien avant, à l'époque où Windows n'était qu'une surcouche de l'antique DOS, mais c'est reposé sur cette puissance, et n'ont jamais proposé une interface adaptée à cela.
Alors, pour le premier point : vous avez raison, c'est n'importe quoi l'interface de Windows depuis 2012 et surtout depuis 2015 (depuis Windows 10). Mais c'est parce que Microsoft sabote toutes ces anciennes réalisations.Heureusement, les développeurs ne sont pas dupes, et continuent pour la plupart d'utiliser une bibliothèque compatible avec Win32. Mon propos porte justement sur les contrôles Win32.Je ne comprends pas très bien ce que tu veux dire. Si c'est l'hétérogénéité des interfaces, sous windows avec la moitié de la config dans le panneau UWP et l'autre moitié ± redondante dans le panneau win32 depuis windows 8, comment dire ?
Ensuite, je suppose que les thèmes sont meilleurs sous windows, mais je crois que plus personne ne s'intéresse à savoir si un programme a une interface native, à part les informaticiens. Il y a plein de programmes avec des kits graphiques variés, ou en web et ça ne gène personne (sauf ceux qui veulent programmer de l'automatisation).
De toutes les bibliothèques graphiques, celle que je préfère, quel que soit la plate-forme, c'est QT, car il est possible de sélectionne l'apparence des contrôles sans changer les couleurs (sous Windows, c'est uniquement le cas du thème classique, le plus ancien, dessiné par GDI), car les styles visuels ne contiennent pas des images matricielles. Sauf que dans la pratique, il n'est malheureusement pas possible d'utiliser un GNU/Linux 100% QT. Et que les autres styles ne sont pas compatibles. Et surtout QT (comme GTK) possède un gros défaut : chaque version majeure casse la compatibilité avec la précédente. Il serait pourtant très facile d'émulé une version sur une autre, puisque cet exactement ce que fait QT sous Windows (il émule les contrôles Win32). Sous GTK, c'est exactement le même problème.
Windows, même si les styles visuels sont écrits n'importe comment (des images entières sans transparence donc avec des couleurs imposées, sont utilisées, comme de nombreux thèmes GTK), et que le seul style correct de sur ce point est le thème classique, présente un gros avantage : toute les bibliothèques graphiques (à l'exception des stupides bibliothèques "modernUI et co." depuis 2012) sont synchronisées les une avec les autres sur la base de la bibliothèque native de l'API Win32 (et des programmes utilisant directement les graphismes de l'API Win32). C'est le cas des bibliothèques spécifique à Windows (MFC, WinForm, WPF), et des bibliothèques traditionnellement sous GNU/Linux (QT, GTK). Ce qui fait que sous Windows, même GTK et QT sont compatibles entre eux !
Non, je parle de l'aspect visuel. Sous Windows, si ont change le thème, un programme QT 3 va changer de la même manière qu'un programme QT 4. Pas sous Linux.Ensuite, tu parles des problèmes de compatibilités de version de QT, GTK mieux sous windows que linux. Mais à ma connaissance c'est un problème de compatibilité binaire dont tu parles, donc le même problème sous windows que linux. C'est juste que sous windows, ces lib sont souvent redistribuées avec chaque programme justement pour ça (il suffit de chercher les dll de QT pour s'en convaincre), alors qu'autrefois sous linux elle n'étaient installées et chargées qu'une fois pour alléger le système. (flatpak résout assez largement le problème historique des dépendances et de la fragmentation sans dégrader notablement les performances)
Partager