Guillaume Denry a écrit 2965 commentaires

UPS c'est pas fait pour les gens qui télétravaillent :( :)

Il y a aussi des framework qui n'imposent pas de restriction aussi ridicule. J'irai même jusqu'a dire que Qt est le seul à le faire…

Les mots ont un sens. Que veux-tu dire par "ridicule" ? Qt est un framework d'âge plutôt vénérable et est porteur d'un héritage technique dont chaque nouveau composant (j'allais dire "sédiment") pouvait trouver justification à chaque étape de son intégration => Trolltech trouvait le C++ une bonne base pour faire du développement multi-platforme mais n'étant pas satisfait par l'état des technologies de RTTI et des systèmes d'évents du moment (je pense principalement pour des raisons de portabilité), choisit de développer via un système de macros et de sur-couche au langage des outils supplémentaires pour simplifier la vie du développeur.
C'est quand même surprenant ta fixette, je connais pas ou peu de monde à ce point bloqué par cette phase de génération de moc en regard des énormes avantages que présente Qt en échange.
Pendant longtemps j'ai fait du Qt avec emacs et qmake s'est toujours occupé de générer les moc à ma place sans que je n'ai guère à m'en soucier.
Ensuite, je suis passé à cmake et là aussi, on trouve des modules cmake pour s'occuper de ça même si c'était un peu plus laborieux pour moi au départ. (l'écriture des règles cmake me semblait un peu plus ardue au départ que le spectre restreint des commandes qmake)
Il n'est bien sûr pas évident que si (l'ex) Trolltech démarrait ce framework de nos jours il choisirait C++ (encore que, pour des raisons de performances, pas sûr…), mais franchement, je trouve qu'ils sont vraiment parvenus à garder une cohérence globale exceptionnelle, et à reléguer cette histoire de moc dans un périmètre assez restreint pour qu'on ne s'en soucis guère.

Chez moi ça donne ça : http://img4.hostingpics.net/pics/793898pouet.jpg

Sympa ta requête google image :)

(sisi, soyez attentifs ^_^)

Oui j'allais dire, pitié, plus de concaténation de chaine entre "Ma variable =" et maVariable, pensez aux équipes de traduction ^{^} => dans ce cas là, on a plus le choix ; chaîne monolithique avec utilisation de "variables de chaînes" et un bon commentaire pour le traducteur.

Euh, j'espère ne pas me tromper mais ce que veut dire Cédric, c'est comment tu sais que la fragmentation de ton algorithme de décompression pour sera faite correctement même pour des petites machines, ou bien des contextes de surcharge intensive du processeur, c'est-à-dire en ayant une garantie minimale de rentrer assez souvent dans la boucle d'événements pour l'IHM ?
Le threading permet un réglage fin de tout ça, délégué à l'OS, mais dans le cas d'un monothreading, l'atomicité de ton traitement de décompression est statique, c'est toi qui le choisit, par exemple, tous les 10Ko de donnée décompressées, et non pas à l'instruction comme l'est le threading classique.
C'est quand même moche.
'fin bon, c'est un peu con, on est juste en train de discuter de l'avantage ou non des threads, déjà été fait mille fois :)

Même qu'ils soient regroupés sous un même nom, tant que je peux les utiliser complètement indépendamment les uns des autres, comme pour boost (quoique, certaines lib boost dépendent d'autres lib boost).

Tu le dis toi-même, certaines libs boost dépendent d'autres lib boost.
Un gros effort depuis Qt3 a été fait pour découper Qt en modules les plus indépendants possibles les uns des autres, ce qui rend le framework beaucoup moins monolithique, il est possible de n'utiliser que QtCore et avoir un binaire léger lorsqu'on a besoin que des structures de données évoluées de Qt. Ou bien QtCore et QtNetwork si on veut faire une appli réseau en CLI.
Le principe KISS est justement respecté avec l'interdépendances des libs, tu délègues la gestion des chaines et leurs différences encodages possibles à une lib pour ne pas la réinventer dans la tienne et rendre ton bouzin compliqué.

Il m'arrive de pester devant des cases à cocher qui me demandent quelques secondes d'analyse pour comprendre par exemple si je vais activer ou désactiver quelque chose.

Il y a des règles à respecter pour rendre une case à cocher digeste :

• éviter les négations :

[X] Ne pas activer la haute disponibilité

Horrible.

• privilégier la description d'un état et non une action

[X] Activer la haute disponibilité

Pas top, il y a ici trop d'information alors que :

[X] Haute disponibilité

Suffit. Je sais que si je coche cette case, il va se passer quelque chose qui va activer la haute disponibilité immédiatement ou lorsque je valide l'écran.

Pour revenir au sujet, pour moi le (petit) problème de la bascule 1|0 de GtkSwitch, c'est que l'état On/Off n'est pas représenté au même endroit sur l'écran. Mine de rien, notre cerveau est parasiter (consciemment ou non) par l'analyse de la position de la représentation de l'info en plus de la couleur et du chiffre. De façon corollaire, notre cerveau pourrait se demander également (un cours instant) si à l'endroit où on représente le 0 on pourrait avoir un 1 un jour, ce qui rend la chose un peu confuse.

Disons que je lui préfère de très loin Code::Blocks.

Purée o_O
QtCreator est juste mille fois mieux foutu, ergonomiquement parlant et mille fois plus puissant.
Ca passe des menus contextuels à la paramétrabilité du soft, à l'intégration à gcc, à valgrind, à tous les systèmes de gestion de version connus, tout est pensé aux petits oignons.
Ce soft a été une vraie bouffée d'air dans l'univers stagnant des IDE à l'époque, et il ne cesse de progresser dans la bonne direction.

Quand je vois les screenshots : http://www.codeblocks.org/screenshots
Pfiuuu. Et tu te plains d'une barre de statut en haut du code source :)

Ce que tu as posté, c'est la vue "debug" de QtCreator.
Je ne vois absolument rien de choquant à ce que les outils de debugging soient présents à ce moment là.
La vue "classique", c'est lorsque tu cliques sur "Edit" en haut à gauche.

Exemple.

De manière général, étant habitué à emacs, je trouve tout de même QtCreator vraiment efficace et très simple à prendre en main.

float pi = 3.141592;
std::ostringstream f;
f << pi;
std::string result = f.str();

Ça fait 50 lignes ça ?

ça reste toujours moins concis et expressif que :

QString str = QString::number(pi);

:)

Tu parles de std::string et std::vector ? :)

Ce que je regrette avec les outils graphiques "modernes" c'est qu'ils tiennent absolument à faire le café…
Réseau, IHM, multi-thread… ça va jusqu'a réimplémenter les outils standards comme vector et string!

Idéalement, je souhaiterais également une myriades d'outils puissants d'horizons diverses et qui s'accordent parfaitement bien entre eux, mais la vie réelle n'est pas comme ça et quand Trolltech a décidé de prendre les choses en main, de ne pas attendre l'émergence d'outils formidables d'horizons divers, et d'élargir les fonctionnalités de son toolkit tout en gardant une cohérence globale de l'API, ça n'a à mon avis, pas été une mauvaise chose. Principalement parce que Qt est (devenu tôt) libre.
Le point « négatif », c'est qu'on est en effet sans cesse en train de se demander à quel point il faut « maquer » son appli avec Qt. N'utiliser que QtGui comme VLC par exemple, ou bien intégrer complètement QtCore (ou d'autres modules) en profondeur.
Je vois donc au moins trois gros avantages pour Qt :
- Son API limpide et bien pensée, ce qui peut faire envisager plus facilement un départ le jour où on tombe sur un meilleur toolkit dans un domaine spécifique. Ca arrive rarement, en général, le projet Qt intègre assez vite ces nouvelles technos via une API.
- Le fait qu'il soit libre
- Le fait qu'il soit très activement développé et réactif, capable de s'adapter sans cesse à l'écosystème mouvant du développement

L'objective-C, je connais pas, mais tu prends une appli Qt4 de 2005, tu peux quasiment la recompiler telle quelle sans trop changer quoique ce soit.

Le gars poste une critique argumentée d'Arch, on lui dit de donner des exemples, il en donne, et on lui reproche de généraliser.

Parce qu'il généralise, relis son premier post, il conclue des problèmes qui lui sont arrivés qu'Archlinux a certains défauts comme : "Ne parlons même pas d'AUR ou quand tu regardes la gueule des packages et les discussions, tu fuis loin, très loin."

Dis comme ça, ça donne l'impression qu'il est interdit de critiquer Arch :-/

Ce genre de "meta-"considérations ne m'intéressent pas ; personne n'interdit à personne de critiquer quoique ce soit. Ton message passera toujours ici tant qu'il n'est pas illégal ou contrevenant aux règles élémentaires du site.

Ce n'est pas parce que ça marche chez vous que c'est parfait pour tout et qu'il faut nier les problèmes qu'il peut y avoir ailleurs.

Homme de paille.

Mais, pourquoi, si j'installe un service apt-get ou dpkg suppose que je veux l'activer par défaut à chaque démarrage ?

Faut pas non plus être de mauvaise foi, quand on installe un service sur une machine, dans 99% des cas, on souhaite qu'il soit lancé au démarrage de la machine :) Et ne pas l'intégrer à l'init pour ce 1% me semble une excuse un peu fallacieuse.

Ce n’est pas sous arch, si ce n’est pas un paquet officiel.

C'est jouer sur les mots. Quand on dit que c'est disponible dans AUR, c'est que c'est installable dans Archlinux, et alors ? Ca n'a jamais rien garanti en terme de qualité.

Se plaindre que AUR contient des paquets pourris, c'est comme se plaindre qu'il existe des trucs pas bons au marché de Wazemmes :) (mais au marché de Wazemmes, il y a également beaucoup de trucs bons !)

Mouais.
Je trouve franchement que tu tires un peu trop facilement des généralités des quelques disconvenues qui te sont arrivées….

J'aime arch, mais je te pertinente, pour moi, c'est un formidable terrain d'apprentissage et de compréhension d'un système gnu/linux, mais je le conseillerais clairement pas à quelqu'un qui ne veut pas perdre de temps avec ça. (qu'il connaisse ou pas très bien déjà linux d'ailleurs)

Par contre, l'arrêt est bien bcp plus rapid

Je ne sais pas ce que les gens ont avec cette histoire de temps d'arrêt trop long, alors que chez moi, c'est toujours instantané quand j'appuie sur l'interrupteur du multiprise !

Je te parle des statistiques d'émissions d'opinions favorables sur archlinux par rapport aux autres émissions d'opinions favorables. Et il me faut un truc exhaustif, hein, pas seulement ici.

Tu sors tes chiffres d'où ? de ton chapeau ? C'est pas parce que tu as vu ici et là quelques commentaires élogieux sur archlinux qu'il faut nécessairement en extraire une sorte de théorie du complot. Que veux-tu dire exactement ? Va jusqu'au bout de ton raisonnement, que quand on utilise archlinux on perd soudainement sa capacité de jugement et qu'on devient lobotomisé ? Et surtout, surtout, pourquoi ça t'obsède à ce point ? On parle bien d'une distrib libre, tu peux tout aussi bien ignorer les commentaires sur ce truc qui te fait horreur et continuer à t'éclater avec ta distrib à toi, pourquoi pondre un tel journal si ce n'est pour égayer notre vendredi ? :)

Et vous, qu’en pensez-vous ?
Est-ce de l’autosuggestion ?
Est-ce du paternalisme ? (Ces pauvres petits qui n’ont pas encore compris)
Ceux qui n’ont ni arch, ni systemD sont-ils vraiment des débiles ?

Je m'avance peut-être, mais est-ce que ça serait peut-être juste parce que Arch fonctionne plutôt bien et que sa documentation est exceptionnelle et vivante ?
Après oui, je suis peut-être victime sans le savoir du syndrome de dissonance cognitive (yes! je l'ai placé !)

pareil, marche pas.

On a un langage mauvais et lent.

C'est bien, ça fait vachement avancer le débat ça.