C'est exactement ça. Je n'apprécie pas les dogmes, quels qu'ils soient, et affirmer les choses de cette façon m'agace. Je me fais même parfois un plaisir de contredire des gens en argumentant, alors que je suis d'accord avec eux (je sais, je suis vicieux). Rien que pour casser leur dogme.
J'ai juste repris l'exemple donné, et n'étant utilisateur ni de cute, ni de gétéca, je pense être assez objectif, et donc, au premier coup d'oeil, je trouve les informations qui m'intéressent plus vite dans celle de gtk.
C'est bien ça, être objectif, non?
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.
La qualité d'une doc, elle ne se juge pas sur un exemple choisi (ça signifie que tu peux m'en donner autant que tu veux), mais sur l'ensemble de la doc ET du produit documenté. Certains produits n'ont même pas besoin de doc, ils sont leur propre doc, et ça ne rend pas la chose mauvaise pour autant.
Et pour prouver mon assertion sur les exemples, regardes: http://qt-project.org/doc/qt-5.0/qtwidgets/qwidget.html#find
Vu le nom, je devine que ça cherche quelque chose, vu les paramètres, je parie que ça renvoie un widget, concept générique mais qu'ici l'on dois sûrement tous comprendre, correspondant à un numéro d'ID. J'ai pas lue la description, et j'aurai dis la même chose en voyant le prototype dans mon auto-complétion.
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. GTK a peut-être le même problème, j'en sais rien et je m'en fout, c'est pas le sujet (le sujet, c'est "la doc de qt est-elle irréprochable" pour moi. Dans cette branche de discussion du moins.).
D'ailleurs, si elle était exhaustive, ça ne rendrait pas forcément cette doc meilleure: trop d'informations noie celle que l'on cherche.
Et, vue la taille de la page, ainsi que la quantité de méthodes, je le dis et j'assume: y'a trop d'informations. L'interface de cette classe est trop complexe.
Je pense avoir été plutôt objectif, mais mon post est malgré tout très subjectif, et c'est normal, parce qu'on parle de la vision des choses que les gens ont, et différentes personnes ont une vision des choses différente, c'est normal. Quand cette vision est proche, un projet commun est réalisable, quand ce n'est pas le cas, on tiens une des explications de pourquoi on à autant de choix dans le logiciel libre.
Je pense que c'est une bonne chose, même si parfois (souvent) je m'interroge sur le bien fondé de la constellation de distributions autour de notre noyau préféré, mais je diverge.
Toujours est-il cela explique que moi, comme d'autres, je puisse ne pas aimer Qt, ne pas la considérer comme la librairie ultime. Je me souviens avoir lu un type qui pensais que wxwidgets aurait sa place dans le standard C++, par exemple. J'utilise cette lib pourtant, mais je lui ai répondu que, non, ce n'est pas une bonne idée (pour diverses raisons).
Pas plus qu'intégrer Qt ou Gtk serait une bonne idée, d'ailleurs.
Franchement, Qt, pour moi, c'est presque un langage à part entière, et qmake me conforte dans cette façon de penser, de la même façon que le 1er compilateur C++ générait en fait du code C, le compilateur de Qt, qmake, génère du code C++.
Parce que la langue française à une histoire, que cette histoire laisse des trace dans la syntaxe et le vocabulaire, et que quelqu'un qui à une maîtrise suffisante sais exploiter cette histoire afin de connaître instinctivement le sens et l'orthographe d'un mot.
Parce que cette histoire, ça rend un texte beau, et agréable à lire, et même à réciter, pour ceux qui aiment les lettres.
Oui, la forme d'un texte, ça a aussi une beauté. Certains textes n'existent même que pour ça (notamment dans la poésie). Je veux pas de ces délires féministes qui massacrent en deux décennies l'esthétisme d'une langue séculaire… que dis-je, séculaire, millénaire! (Pardonnes-moi cette emphase assez moyenne, d'ailleurs)
Et parce que masculiniser ou féminiser les mots sous un prétexte aussi stupide et biologiquement erroné tel que l'égalité homme/femme fait perdre tous ces points.
Entends-moi bien: je suis pour que la loi ne fasse aucune distinction. Mais je ne suis pas pour que la culture n'en fasse aucune.
Tiens, d'ailleurs, es-tu bisexuel? Si ce n'est pas le cas, alors tu es sexiste: tu favorises un sexe pour tes rapports amoureux.
Les féministes sont l'exact opposé des machistes, les deux sont des plaies pour les gens normaux quand ils commencent à imposer des choses.
Je n'aime ni les féministes, ni les machistes, ni, de façon générale, tout ceux qui veulent limiter mes libertés au nom de leur sacro-sainte éthique. En tant qu'anarchiste, j'ai pas la même éthique que mon voisin du FN (j'invente complètement), mais je respecte la sienne et lui respecte la mienne, et c'est comme ça qu'on peut aller boire un coup au bistrot sans se foutre sur la gueule.
Si moi, ou mon voisin, voulait imposer sa vision des choses, nul doute que ça ne se passerait pas aussi bien.
Pour une situation plus réaliste, en tant qu'athée, j'ai eu des discussions extrêmement intéressantes avec des religieux qui pratiquent. Jamais avec les intégristes. Toi, tu ressembles à un intégristes, à chasser ce qui te semble être des fautes sur un site internet, alors que ce n'en sont pas.
Mais… les marchés de niche, ça fait aussi vivre énormément d'informaticiens.
D'ailleurs, les dev qui sont sur les marchés de niche (et qui ont donc réussi à s'y caler, je dis pas que c'est simple), sont probablement ceux qui ont les meilleures payes: rapport offre/demande.
Depuis le temps que je cherche un outil capable de me montrer les trucs pas catholiques que je fais parfois… tant pis pour les faux positifs, s'il y en a des vrais, ça donne toujours des indices, c'est l'important.
Peut-être que si cet argument reviens tout le temps, c'est qu'il est valide?
Oh que oui, c'est chiant, parce que c'est infernal à utiliser avec un IDE qui n'est conçu pour Qt du coup.
Quant à l'intérêt des signaux, je sais pas, pourrais-tu me dire, code comparatif à l'appui, ce que ça apporte?
Après, pour les macros… ouai, je suis d'accord, j'aime pas non plus. Mais de nos jours, on peut faire des choses très propres en C++ sans macros, et sans pour autant imposer un outil de pré-compilation.
Au niveau de la philosophie du C: ref needed.
Bah oui, j'ai regardé les deux, la doc de Qt est mignonne (ce qui n'est pas objectif), mais ça me prend plus de temps pour, par exemple, connaître la totalité de la hiérarchie. De quoi hérite QAbstractButton ?
Avec GTK+, on à toute l'info.
D'autres ont dis qu'il y a des exemples partout, je n'en vois aucun sur cette page, pour l'un comme pour l'autre.
Avantages de GTK sur Qt, vus par quelqu'un qui n'utilise ni l'un, ni l'autre, mais utilise C++ en permanence:
pas de qmake
API C
plus léger
Ces 3 points cassent tout ton argumentaire, sauf le nombre de gens payés. Mais, franchement, ce n'est pas une référence pour moi. Je ne crois pas que quelqu'un soit payé pour faire la SDL, et jusqu'a preuve du contraire, il s'agit d'une bonne lib.
Pour l'API C, voici quelques avantages contre le C++ (que je préfère pourtant largement au C):
utilisable par n'importe quel langage (y compris les langages exotiques)
ABI moins casse-couilles! Penches-toi sur la problématique de faire une API pour créer des plug-in, et tu verras que le C++ fait que selon le compilateur, ou même selon la version du compilateur, l'ABI est complètement pétée.
Hum, analyse statique sur clang? Tu peux m'en dire plus, ça m'intéresse ça.
Pour le reste, en fait, l'avantage du compilateur, c'est que ça s'exécute pas si la syntaxe n'est pas correcte partout.
Couplé à un typage fort (ce qui n'est pas le cas du C, d'ailleurs, vu qu'on peut caster ce qu'on veut en ce qu'on veut), ça permet d'éviter de très nombreux problèmes, c'est un fait.
Merci pour le lien, il y en a 4 qui semblent intéressants.
Après, ce lien montre tout le problème des wiki: on mélange les choux et les carottes sous l'appellation patate… analyseurs statiques: valgrind (huh?), CCCC (outil de métrique)… bref…
Au niveau de ceux que j'ai essayés:
cppcheck : juste… inutile. Sort les même warnings que le compilateur, et refuse de fonctionner si on utilise des headers un peu complexe. Au revoir, STL…
flawfinder : se contente de vérifier quelles fonctions dangereuses ont été utilisées. Le seul avertissement que cet outil m'aie donné est que getenv(char const*) est dangereux car les variables système ne sont pas fiables. C'est une entrée utilisateur en même temps… bref, intéressant quant on cherche à prendre la main sur un code en langage C qui ne nous appartiens pas. Langage C, car ces fonctions dangereuses sont principalement C-style: manipulent des "char*".
CCCC : très bon outil pour identifier les endroits ou le code est complexe, et donc excellent outil pour savoir quelle zone refactorer.
valgrind : pas passé assez de temps avec pour comprendre comment il marche. C'est dans mes projets,
Après, certains semblent intéressants:
saturn
calysto (qui semble avoir été écrit pour compenser des défauts de saturn)
Mozilla's Pork
Mozilla's Dehydra
(freem pourra nous dire plus exactement ce qu'il entend par abordable, mais je pense qu'au dessus de $100 ca le fait plus).
Effectivement, au delà de 100€ ça fait beaucoup, pour mes finances actuelles :)
Je cherche un tel outil pour un but personnel pour le moment, et je ne suis pas spécialement riche. D'un autre côté, ce genre d'outils est plutôt dédié aux usages professionnels, à ce que j'ai pu voir, et les tarifs sont donc plutôt adéquats. Donc je me doute bien que je ne risque pas d'en trouver en fait, mais je me disais que, peut-être…
Je suis intéressé par un nom, si tu en connais pour le C++ dont la licence soit à un prix abordable et qui tourne sous linux ET windows.
J'ai déjà cherché, j'ai pas trouvé. Et tant que j'aurai pas trouvé, mon compilo C++ me servira aussi de vérificateur statique (oui, je sais, il faut aussi que je me mette au TDD).
Je veux bien connaître le nom de l'appli moche en question?
Si ça se trouve, tu es juste tombé sur une exception, vu que tous les toolkit permettent de ne pas respecter le thème du système.
Après… des applis utilisant wxwidget, je peux en citer 2-3, et elles respectent toutes le thème: code::blocks (bon, pour être exact, ça c'est amélioré sur cet IDE, à un moment les thèmes sombres étaient… hum… mais je pense que c'est dû au fait qu'ils aient refait la roue pour certaines widgets. La, on sait à qui reviens la faute.), amaya, et filezilla.
Avec aucune de ces applications je n'ai eu de soucis de thème, même si j'admets ne pas passer 30 ans à bidouiller mes thèmes :) (en général, je me contente de celui qui prend le moins de place possible)
D'ailleurs, il faudra que j'installe un outil pour changer le thème gtk sur ma machine, celui par défaut étant trop gourmand en place à mon goût.
Pour tcl/tk, il y a pire je crois: jettes un oeil à xpaint ;) (je ne suis même pas sûr qu'il y ait un toolkit derrière…)
Mais il a au moins l'avantage d'être utilisable par n'importe qui et d'être d'une légèreté à toute épreuve.
PS: il faudra un jour qu'on me dise exactement ce que l'on entend par "intégration". Juste l'apparence graphique?
Je suis d'accord.
Je me demande d'ailleurs toujours d'où viens la rumeur qu'il existerait des interfaces graphiques pour vim et emacs?
Je pense que gvim n'est qu'un mythe, et que les gens, tels que moi, qui considèrent que les interfaces graphiques ne sont pas forcément si efficaces que ça pour quelqu'un qui dois travailler à longueur de journée avec son clavier et n'a aucun intérêt réel à utiliser la souris si ce n'est atteindre des boutons vitaux qui n'ont pas de raccourcis clavier pratiques sont des abrutis arriérés.
Cela dis, dans mon monde d'arriéré, les systèmes d'exploitation n'ont pas besoin de 2Go de RAM, et les utilisateurs sont capables de faire leur travail avec moins de douleurs de poignet (c'est du vécu, avant de revenir aux interfaces plus centrées sur le clavier, mon bras droit me faisait souvent mal. Et je n'ai même pas 30 ans…) et plus de rapidité.
Non, non. On parle de performance et pour ça un couplage fort permet d'avoir d'améliorer les performances (plus de convention (donc moins de données échangées), chaque brique ne sait parler qu'avec une ensemble limité d'autres briques qui ne sont pas changeables).
Merci, j'avais un doute sur le propos, d'où ma question. Je suis donc d'accord sur ce point.
Ça tombe bien avec JS qui a une lib standard assez petite.
Il semblerait. Mais de nos jours, pas mal de gens considèrent ça comme un défaut (pas moi, mais bon…).
A part ça, je parlais de façon générale.
Merci pour tes éclaircissements.
Pour le C, disons qu'il faut toujours traiter le retour de fonctions comme scanf. Evidemment, comme il n'y pas de support des exceptions, soit le dev à confiance en lui et en l'utilisateur, soit il écrit un code assez lourd.
Ah, on peut aussi encapsuler, mais bon… faut aimer.
Pour le C++, en revanche, oui, ça se détecte facilement, à condition d'éviter d'utiliser l'héritage du C (et je suis un mauvais élève, j'aime toujours autant scanf/printf perso :s )
Hum… donc, Gtk est ultra moche sous linux, selon toi?
Non, parce que bon, WxWidgets, sous linux, se base sur GTK… En tout cas, je ne connais aucune application utilisant le port pour X11, vu que celui-ci n'est pas complet il me semble, et je n'ai pas non plus vue d'appli utilisant le port motif.
Sûrement parce que Debian utilise le port Gtk, cela dis. Après, si on compile WxWidgets pour utiliser Motif ou X11, on peut pas se plaindre que c'est moche, mais plutôt encenser une lib qui est capable d'utiliser plusieurs toolkits sans piper mot.
Pour rappel, l'esprit de WxWidgets, c'est d'utiliser les composants standards du système, et s'ils n'existent pas, de les implémenter.
Donc, sur windows, ils se basent sur l'api win32, et, comme beaucoup (ref needed, je sais) considèrent que gtk est l'api ""standard"" (à prendre avec beaucoup de pincettes, hein, je veux pas fâcher les utilisateurs de KDE) le port qui me semble le plus utilisé sous linux est celui basé sur Gtk.
Quant aux 5 ans d'avance de Qt… ça doit être pour ça qu'a part pour l'IDE fait exclusivement pour lui, QtCreator, que je n'apprécie d'ailleurs pas du tout, raisons esthétiques:
c'est ultra moche!
il est très pénible à intégrer?
Ah, j'imagine que KDevelop aussi dois le supporter correctement.
Ensuite, les 5 ans d'avance, j'aimerai bien voir ça, avec des preuves et une argumentation, parce que je ne considère pas que forcer un utilisateur à utiliser des fonctionnalités non standard, nécessitant une pré-compilation, pour dessiner une simple interface graphique soit être en avance.
D'ailleurs, si c'était 5 ans d'avance, j'aimerai qu'on m'explique, par exemple, pour std::vector est ré-implémenté. Par exemple.
Après… WxWidgets à des défauts, oui, c'est vrai. Mais il faut les citer. Par exemple, la version stable actuelle compile en dur les gestionnaires d'évènement, ce qui oblige à des contournements un peu dégueu pour avoir un truc dynamique. On peut aussi citer l'architecture autour des barres de menu, qui laisse quelques peu à désirer.
Mais voila, il faut au moins argumenter, et, malgré ces points, ça reste un framework important qui vois la portabilité plus dans l'esprit C++, en utilisant ce qui existe, plutôt que dans l'esprit Java, en ré-implémentant tout, comme Qt fait.
C'est redondant, je ne sais pas bien. J'ai tendance à penser que ce trio est une abstraction du système de dessin sous jacent. Et qu'à ce titre ce n'est pas vraiment une redondance, ou en tout cas, pas plus redondant que d'avoir GTK et Qt pour faire des applications desktop.
Prenons le système le plus répandu: windows.
Cas de l'application classique:
Win32 <= Qt/GtK/Wx/MFC/WhatElse <= application
Cas de l'application web:
Win32 <= Qt/GtK/Wx/MFC/WhatElse <= HTML/CSS/JS <= application
Je ne vois pas de redondance, juste une surcouche à l'utilité discutable.
Bref, j'ai découvert le pattern mvvm, j'ai adoré.
Ca, si je me plante pas, il s'agit d'un design pattern. Applicable aux applications classiques. (bien que j'aie du mal à comprendre la différence par rapport au mvc mais bon…)
Au sujet des layouts, widgets ect, comme tu le dis c'est bien développé dans ces environnements. Mais je pense cela concerne plus le bureau, que l'application.
L'application consomme ces widgets, et le bureau doit fournir un moyen à l'application de consommer le widget.
Le problème ici, c'est si les environnements de bureau ont été créés, c'est pour que l'utilisateur ne soit pas perdu à chaque fois qu'il change d'application. Avec les sites web, c'est la jungle: chaque site réinvente la roue, marche plus ou moins bien en fonction du navigateur, nécessite que l'utilisateur apprenne à utiliser l'interface, et force l'utilisateur un peu soucieux de sa sécurité à ajouter une configuration précise pour chaque site différent.
Tentons d'en rester aux spécifications, ce sont des rêves d'ingénieurs en cours d'implémentation qui ne demande qu'à être concrétisés.
Le problème, c'est que la simplicité de créer une interface avec WYSIWIG n'est plus un rêve depuis longtemps, sauf avec HTML.
HTML, c'est quand même plus primitif que Win32… Alors, c'est cool, ça veut dire qu'on peut tout réimplémenter à sa sauce… sauf qu'en fait, c'est pénible, parce qu'on à pas le choix.
On retrouve la bonne vielle idée des bons et des mauvais programmeurs
Sauf qu'il a dit qu'un mauvais ou moyen dev écrira une application plus performante en C++ qu'en JS, pas qu'un bon dev n'écrira pas une appli plus performante en JS que ce qu'il aurait pu faire en C++.
En gros, ce qu'il essaie de dire, c'est que le développeur qui n'est pas un guru créera une application plus rapide s'il code en C++ que s'il l'avait faite en JS.
Le problème, bien sûr, c'est qu'il ne la codera pas forcément aussi vite…
il y a plus de simplicité grâce à un couplage plus fort
Moins fort, plutôt, non?
Couplage plus fort, structure moins simple à faire évoluer sans tout péter… et devoir modifier en chaîne les dépendances.
Je suis d'accord que l'archi est ce qui influe le plus, après… même si le langage non, je pense que le type de langage, compilé/VM/interprété, influe également.
A noter aussi que certains langages ont une lib très riche. Le danger, pas forcément actuel de telles lib trop riches, c'est qu'elles risquent d'amener des dépendances inutiles.
Cela dis, ce problème existe avec tout type de lib, pas que les lib standards.
J'en déduis qu'il existera quelques installations où sysvinit ne sera pas utilisé par défaut.
J'imagine (imagination => pas de preuves) que ce sera exactement de la même façon qui fait que gnome n'est pas utilisé par défaut sur 2 CDs n°1 alternatifs, l'un étant dédié à KDE, l'autre à XFCE/LXDE.
Ce qui implique que les gens qui auront systemd par défaut, auront choisie l'image avec systemd par défaut. Et les images avec KDE/XFCE/LXDE par défaut ne sont pas spécialement mises en avant, et sont donc certainement les moins téléchargées.
Si on applique la même logique, excepté un nombre de "CD n°1" qui explose, il y aura effectivement un petit nombre d'installations par défaut qui auront systemd.
Rien de choquant, et je préfère de toute façon que mon OS me donne le choix.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 3.
C'est exactement ça. Je n'apprécie pas les dogmes, quels qu'ils soient, et affirmer les choses de cette façon m'agace. Je me fais même parfois un plaisir de contredire des gens en argumentant, alors que je suis d'accord avec eux (je sais, je suis vicieux). Rien que pour casser leur dogme.
J'ai juste repris l'exemple donné, et n'étant utilisateur ni de cute, ni de gétéca, je pense être assez objectif, et donc, au premier coup d'oeil, je trouve les informations qui m'intéressent plus vite dans celle de gtk.
C'est bien ça, être objectif, non?
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.
La qualité d'une doc, elle ne se juge pas sur un exemple choisi (ça signifie que tu peux m'en donner autant que tu veux), mais sur l'ensemble de la doc ET du produit documenté. Certains produits n'ont même pas besoin de doc, ils sont leur propre doc, et ça ne rend pas la chose mauvaise pour autant.
Et pour prouver mon assertion sur les exemples, regardes: http://qt-project.org/doc/qt-5.0/qtwidgets/qwidget.html#find
Vu le nom, je devine que ça cherche quelque chose, vu les paramètres, je parie que ça renvoie un widget, concept générique mais qu'ici l'on dois sûrement tous comprendre, correspondant à un numéro d'ID. J'ai pas lue la description, et j'aurai dis la même chose en voyant le prototype dans mon auto-complétion.
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. GTK a peut-être le même problème, j'en sais rien et je m'en fout, c'est pas le sujet (le sujet, c'est "la doc de qt est-elle irréprochable" pour moi. Dans cette branche de discussion du moins.).
D'ailleurs, si elle était exhaustive, ça ne rendrait pas forcément cette doc meilleure: trop d'informations noie celle que l'on cherche.
Et, vue la taille de la page, ainsi que la quantité de méthodes, je le dis et j'assume: y'a trop d'informations. L'interface de cette classe est trop complexe.
Je pense avoir été plutôt objectif, mais mon post est malgré tout très subjectif, et c'est normal, parce qu'on parle de la vision des choses que les gens ont, et différentes personnes ont une vision des choses différente, c'est normal. Quand cette vision est proche, un projet commun est réalisable, quand ce n'est pas le cas, on tiens une des explications de pourquoi on à autant de choix dans le logiciel libre.
Je pense que c'est une bonne chose, même si parfois (souvent) je m'interroge sur le bien fondé de la constellation de distributions autour de notre noyau préféré, mais je diverge.
Toujours est-il cela explique que moi, comme d'autres, je puisse ne pas aimer Qt, ne pas la considérer comme la librairie ultime. Je me souviens avoir lu un type qui pensais que wxwidgets aurait sa place dans le standard C++, par exemple. J'utilise cette lib pourtant, mais je lui ai répondu que, non, ce n'est pas une bonne idée (pour diverses raisons).
Pas plus qu'intégrer Qt ou Gtk serait une bonne idée, d'ailleurs.
Franchement, Qt, pour moi, c'est presque un langage à part entière, et qmake me conforte dans cette façon de penser, de la même façon que le 1er compilateur C++ générait en fait du code C, le compilateur de Qt, qmake, génère du code C++.
[^] # Re: Féminisation \o/
Posté par freem . En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à 3.
Parce que la langue française à une histoire, que cette histoire laisse des trace dans la syntaxe et le vocabulaire, et que quelqu'un qui à une maîtrise suffisante sais exploiter cette histoire afin de connaître instinctivement le sens et l'orthographe d'un mot.
Parce que cette histoire, ça rend un texte beau, et agréable à lire, et même à réciter, pour ceux qui aiment les lettres.
Oui, la forme d'un texte, ça a aussi une beauté. Certains textes n'existent même que pour ça (notamment dans la poésie). Je veux pas de ces délires féministes qui massacrent en deux décennies l'esthétisme d'une langue séculaire… que dis-je, séculaire, millénaire! (Pardonnes-moi cette emphase assez moyenne, d'ailleurs)
Et parce que masculiniser ou féminiser les mots sous un prétexte aussi stupide et biologiquement erroné tel que l'égalité homme/femme fait perdre tous ces points.
Entends-moi bien: je suis pour que la loi ne fasse aucune distinction. Mais je ne suis pas pour que la culture n'en fasse aucune.
Tiens, d'ailleurs, es-tu bisexuel? Si ce n'est pas le cas, alors tu es sexiste: tu favorises un sexe pour tes rapports amoureux.
Les féministes sont l'exact opposé des machistes, les deux sont des plaies pour les gens normaux quand ils commencent à imposer des choses.
Je n'aime ni les féministes, ni les machistes, ni, de façon générale, tout ceux qui veulent limiter mes libertés au nom de leur sacro-sainte éthique. En tant qu'anarchiste, j'ai pas la même éthique que mon voisin du FN (j'invente complètement), mais je respecte la sienne et lui respecte la mienne, et c'est comme ça qu'on peut aller boire un coup au bistrot sans se foutre sur la gueule.
Si moi, ou mon voisin, voulait imposer sa vision des choses, nul doute que ça ne se passerait pas aussi bien.
Pour une situation plus réaliste, en tant qu'athée, j'ai eu des discussions extrêmement intéressantes avec des religieux qui pratiquent. Jamais avec les intégristes. Toi, tu ressembles à un intégristes, à chasser ce qui te semble être des fautes sur un site internet, alors que ce n'en sont pas.
[^] # Re: Lapin compris
Posté par freem . En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à 0.
Mais… les marchés de niche, ça fait aussi vivre énormément d'informaticiens.
D'ailleurs, les dev qui sont sur les marchés de niche (et qui ont donc réussi à s'y caler, je dis pas que c'est simple), sont probablement ceux qui ont les meilleures payes: rapport offre/demande.
[^] # Re: Lapin compris
Posté par freem . En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à -3.
Comme quoi, parfois les notes sont cohérentes avec le contenu :P (et normalement, là, je devrais donc avoir -10 :D )
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 1.
Merci bien.
Depuis le temps que je cherche un outil capable de me montrer les trucs pas catholiques que je fais parfois… tant pis pour les faux positifs, s'il y en a des vrais, ça donne toujours des indices, c'est l'important.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 2.
Peut-être que si cet argument reviens tout le temps, c'est qu'il est valide?
Oh que oui, c'est chiant, parce que c'est infernal à utiliser avec un IDE qui n'est conçu pour Qt du coup.
Quant à l'intérêt des signaux, je sais pas, pourrais-tu me dire, code comparatif à l'appui, ce que ça apporte?
Après, pour les macros… ouai, je suis d'accord, j'aime pas non plus. Mais de nos jours, on peut faire des choses très propres en C++ sans macros, et sans pour autant imposer un outil de pré-compilation.
Au niveau de la philosophie du C: ref needed.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 1.
NON
Bah oui, j'ai regardé les deux, la doc de Qt est mignonne (ce qui n'est pas objectif), mais ça me prend plus de temps pour, par exemple, connaître la totalité de la hiérarchie. De quoi hérite QAbstractButton ?
Avec GTK+, on à toute l'info.
D'autres ont dis qu'il y a des exemples partout, je n'en vois aucun sur cette page, pour l'un comme pour l'autre.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à -1.
Allez, pour le fun:
Avantages de GTK sur Qt, vus par quelqu'un qui n'utilise ni l'un, ni l'autre, mais utilise C++ en permanence:
Ces 3 points cassent tout ton argumentaire, sauf le nombre de gens payés. Mais, franchement, ce n'est pas une référence pour moi. Je ne crois pas que quelqu'un soit payé pour faire la SDL, et jusqu'a preuve du contraire, il s'agit d'une bonne lib.
Pour l'API C, voici quelques avantages contre le C++ (que je préfère pourtant largement au C):
PS: je considère que qmake c'est de la bidouille.
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 1.
Hum, analyse statique sur clang? Tu peux m'en dire plus, ça m'intéresse ça.
Pour le reste, en fait, l'avantage du compilateur, c'est que ça s'exécute pas si la syntaxe n'est pas correcte partout.
Couplé à un typage fort (ce qui n'est pas le cas du C, d'ailleurs, vu qu'on peut caster ce qu'on veut en ce qu'on veut), ça permet d'éviter de très nombreux problèmes, c'est un fait.
/me pense aller voir du côté de ADA un de ces 4
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 1.
Merci pour le lien, il y en a 4 qui semblent intéressants.
Après, ce lien montre tout le problème des wiki: on mélange les choux et les carottes sous l'appellation patate… analyseurs statiques: valgrind (huh?), CCCC (outil de métrique)… bref…
Au niveau de ceux que j'ai essayés:
Après, certains semblent intéressants:
Effectivement, au delà de 100€ ça fait beaucoup, pour mes finances actuelles :)
Je cherche un tel outil pour un but personnel pour le moment, et je ne suis pas spécialement riche. D'un autre côté, ce genre d'outils est plutôt dédié aux usages professionnels, à ce que j'ai pu voir, et les tarifs sont donc plutôt adéquats. Donc je me doute bien que je ne risque pas d'en trouver en fait, mais je me disais que, peut-être…
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 0.
Je suis intéressé par un nom, si tu en connais pour le C++ dont la licence soit à un prix abordable et qui tourne sous linux ET windows.
J'ai déjà cherché, j'ai pas trouvé. Et tant que j'aurai pas trouvé, mon compilo C++ me servira aussi de vérificateur statique (oui, je sais, il faut aussi que je me mette au TDD).
# sophos aime pas
Posté par freem . En réponse au journal humours geeks. Évalué à 1.
http://www.sophos.com/fr-fr/threat-center/threat-analyses/viruses-and-spyware/Mal~HTMLGen-A.aspx
Zut, je voulais tuer le temps de boulot qui me reste à
glanderfaire de la veille documentaire![^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à -1.
Exact, il faut admettre que ce fichu 0 de fin de chaîne, couplé au fait que les tableaux commencent à l'index 0 n'est pas fait pour aider :D
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 0.
Je veux bien connaître le nom de l'appli moche en question?
Si ça se trouve, tu es juste tombé sur une exception, vu que tous les toolkit permettent de ne pas respecter le thème du système.
Après… des applis utilisant wxwidget, je peux en citer 2-3, et elles respectent toutes le thème: code::blocks (bon, pour être exact, ça c'est amélioré sur cet IDE, à un moment les thèmes sombres étaient… hum… mais je pense que c'est dû au fait qu'ils aient refait la roue pour certaines widgets. La, on sait à qui reviens la faute.), amaya, et filezilla.
Avec aucune de ces applications je n'ai eu de soucis de thème, même si j'admets ne pas passer 30 ans à bidouiller mes thèmes :) (en général, je me contente de celui qui prend le moins de place possible)
D'ailleurs, il faudra que j'installe un outil pour changer le thème gtk sur ma machine, celui par défaut étant trop gourmand en place à mon goût.
Pour tcl/tk, il y a pire je crois: jettes un oeil à xpaint ;) (je ne suis même pas sûr qu'il y ait un toolkit derrière…)
Mais il a au moins l'avantage d'être utilisable par n'importe qui et d'être d'une légèreté à toute épreuve.
PS: il faudra un jour qu'on me dise exactement ce que l'on entend par "intégration". Juste l'apparence graphique?
[^] # Re: Mauvaise interprétation
Posté par freem . En réponse au journal Systemd dans Debian. Évalué à 2.
Je suis d'accord.
Je me demande d'ailleurs toujours d'où viens la rumeur qu'il existerait des interfaces graphiques pour vim et emacs?
Je pense que gvim n'est qu'un mythe, et que les gens, tels que moi, qui considèrent que les interfaces graphiques ne sont pas forcément si efficaces que ça pour quelqu'un qui dois travailler à longueur de journée avec son clavier et n'a aucun intérêt réel à utiliser la souris si ce n'est atteindre des boutons vitaux qui n'ont pas de raccourcis clavier pratiques sont des abrutis arriérés.
Cela dis, dans mon monde d'arriéré, les systèmes d'exploitation n'ont pas besoin de 2Go de RAM, et les utilisateurs sont capables de faire leur travail avec moins de douleurs de poignet (c'est du vécu, avant de revenir aux interfaces plus centrées sur le clavier, mon bras droit me faisait souvent mal. Et je n'ai même pas 30 ans…) et plus de rapidité.
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 0.
Merci, j'avais un doute sur le propos, d'où ma question. Je suis donc d'accord sur ce point.
Il semblerait. Mais de nos jours, pas mal de gens considèrent ça comme un défaut (pas moi, mais bon…).
A part ça, je parlais de façon générale.
Merci pour tes éclaircissements.
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 0.
Pour le C, disons qu'il faut toujours traiter le retour de fonctions comme scanf. Evidemment, comme il n'y pas de support des exceptions, soit le dev à confiance en lui et en l'utilisateur, soit il écrit un code assez lourd.
Ah, on peut aussi encapsuler, mais bon… faut aimer.
Pour le C++, en revanche, oui, ça se détecte facilement, à condition d'éviter d'utiliser l'héritage du C (et je suis un mauvais élève, j'aime toujours autant scanf/printf perso :s )
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 1.
http://en.wikipedia.org/wiki/List_of_widget_toolkits#Cross-platform
Histoire de.
J'ai pas compté, mais à vue de nez, je dirais, une 20aine?
Il ne faut pas confondre "candidats pas nombreux" et "nombreux candidats peu connus" ;)
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à 0.
Mais plus lent si on ne les utilise pas.
[^] # Re: Pourquoi VCL et automake ?
Posté par freem . En réponse à la dépêche LibreOffice se met en 4.0. Évalué à -1.
Hum… donc, Gtk est ultra moche sous linux, selon toi?
Non, parce que bon, WxWidgets, sous linux, se base sur GTK… En tout cas, je ne connais aucune application utilisant le port pour X11, vu que celui-ci n'est pas complet il me semble, et je n'ai pas non plus vue d'appli utilisant le port motif.
Sûrement parce que Debian utilise le port Gtk, cela dis. Après, si on compile WxWidgets pour utiliser Motif ou X11, on peut pas se plaindre que c'est moche, mais plutôt encenser une lib qui est capable d'utiliser plusieurs toolkits sans piper mot.
Pour rappel, l'esprit de WxWidgets, c'est d'utiliser les composants standards du système, et s'ils n'existent pas, de les implémenter.
Donc, sur windows, ils se basent sur l'api win32, et, comme beaucoup (ref needed, je sais) considèrent que gtk est l'api ""standard"" (à prendre avec beaucoup de pincettes, hein, je veux pas fâcher les utilisateurs de KDE) le port qui me semble le plus utilisé sous linux est celui basé sur Gtk.
Quant aux 5 ans d'avance de Qt… ça doit être pour ça qu'a part pour l'IDE fait exclusivement pour lui, QtCreator, que je n'apprécie d'ailleurs pas du tout, raisons esthétiques:
il est très pénible à intégrer?
Ah, j'imagine que KDevelop aussi dois le supporter correctement.
Ensuite, les 5 ans d'avance, j'aimerai bien voir ça, avec des preuves et une argumentation, parce que je ne considère pas que forcer un utilisateur à utiliser des fonctionnalités non standard, nécessitant une pré-compilation, pour dessiner une simple interface graphique soit être en avance.
D'ailleurs, si c'était 5 ans d'avance, j'aimerai qu'on m'explique, par exemple, pour std::vector est ré-implémenté. Par exemple.
Après… WxWidgets à des défauts, oui, c'est vrai. Mais il faut les citer. Par exemple, la version stable actuelle compile en dur les gestionnaires d'évènement, ce qui oblige à des contournements un peu dégueu pour avoir un truc dynamique. On peut aussi citer l'architecture autour des barres de menu, qui laisse quelques peu à désirer.
Mais voila, il faut au moins argumenter, et, malgré ces points, ça reste un framework important qui vois la portabilité plus dans l'esprit C++, en utilisant ce qui existe, plutôt que dans l'esprit Java, en ré-implémentant tout, comme Qt fait.
[^] # Re: En fait c'est la page qui est mal faite...
Posté par freem . En réponse au journal GoPro OpenSource. Évalué à 1.
Ca, c'est la version chiffrée avec xor (clé binaire: 10011001)
[^] # Re: javascript, ok.
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 4.
Prenons le système le plus répandu: windows.
Cas de l'application classique:
Win32 <= Qt/GtK/Wx/MFC/WhatElse <= application
Cas de l'application web:
Win32 <= Qt/GtK/Wx/MFC/WhatElse <= HTML/CSS/JS <= application
Je ne vois pas de redondance, juste une surcouche à l'utilité discutable.
Ca, si je me plante pas, il s'agit d'un design pattern. Applicable aux applications classiques. (bien que j'aie du mal à comprendre la différence par rapport au mvc mais bon…)
Le problème ici, c'est si les environnements de bureau ont été créés, c'est pour que l'utilisateur ne soit pas perdu à chaque fois qu'il change d'application. Avec les sites web, c'est la jungle: chaque site réinvente la roue, marche plus ou moins bien en fonction du navigateur, nécessite que l'utilisateur apprenne à utiliser l'interface, et force l'utilisateur un peu soucieux de sa sécurité à ajouter une configuration précise pour chaque site différent.
Le problème, c'est que la simplicité de créer une interface avec WYSIWIG n'est plus un rêve depuis longtemps, sauf avec HTML.
HTML, c'est quand même plus primitif que Win32… Alors, c'est cool, ça veut dire qu'on peut tout réimplémenter à sa sauce… sauf qu'en fait, c'est pénible, parce qu'on à pas le choix.
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 2.
Sauf qu'il a dit qu'un mauvais ou moyen dev écrira une application plus performante en C++ qu'en JS, pas qu'un bon dev n'écrira pas une appli plus performante en JS que ce qu'il aurait pu faire en C++.
En gros, ce qu'il essaie de dire, c'est que le développeur qui n'est pas un guru créera une application plus rapide s'il code en C++ que s'il l'avait faite en JS.
Le problème, bien sûr, c'est qu'il ne la codera pas forcément aussi vite…
[^] # Re: FirefoxOS
Posté par freem . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 0.
Moins fort, plutôt, non?
Couplage plus fort, structure moins simple à faire évoluer sans tout péter… et devoir modifier en chaîne les dépendances.
Je suis d'accord que l'archi est ce qui influe le plus, après… même si le langage non, je pense que le type de langage, compilé/VM/interprété, influe également.
A noter aussi que certains langages ont une lib très riche. Le danger, pas forcément actuel de telles lib trop riches, c'est qu'elles risquent d'amener des dépendances inutiles.
Cela dis, ce problème existe avec tout type de lib, pas que les lib standards.
[^] # Re: Ah l'anglais...
Posté par freem . En réponse au journal Systemd dans Debian. Évalué à 1.
J'imagine (imagination => pas de preuves) que ce sera exactement de la même façon qui fait que gnome n'est pas utilisé par défaut sur 2 CDs n°1 alternatifs, l'un étant dédié à KDE, l'autre à XFCE/LXDE.
Ce qui implique que les gens qui auront systemd par défaut, auront choisie l'image avec systemd par défaut. Et les images avec KDE/XFCE/LXDE par défaut ne sont pas spécialement mises en avant, et sont donc certainement les moins téléchargées.
Si on applique la même logique, excepté un nombre de "CD n°1" qui explose, il y aura effectivement un petit nombre d'installations par défaut qui auront systemd.
Rien de choquant, et je préfère de toute façon que mon OS me donne le choix.