Guillaume Denry a écrit 2954 commentaires

Aucun intérêt de passer de GTK à QuickTime, quel intérêt de remplacer un toolkit graphique par un framework vidéo propriétaire ?

Tu as tout-à-fait raison.
N'empêche que…. prends ça dans tes dents, Gtk ! =)

Bien joué, Einstein !

Sous-titrage remarquable : drôle et parfaitement calée sur les temps forts de l'extrait.
Toutes les parodies de La Chute ne sont pas comme cela…

hahaha ncmpc, le vieux truc ! Tu pourrais au moins embrasser la modernité et utiliser du bleeding edge (=> ncmpcpp)

mais moins que ls -laR

ls :)

(oui, ça peut durer longtemps comme journal)

Hé ho, on est sur le web ici, tu t'attendais à quoi ? Tu t'es fait basher par 3 ou 4 grincheux et ça suffit pour te forger un avis général et définitif sur la faune qui fréquente ce site ?
Prends un peu de recul. Si ton projet intéresse vraiment des gens pour ce qu'il est, tu auras des remontées sympathiques.
Plus ça va, plus je me dis qu'il faudrait vraiment faire passer une sorte de brevets pour encaisser/trier les commentaires web et savoir garder la tête froide…

C'est joli tout ça

Tout est relatif, j'ai regardé la vidéo et je ne sais pas qui peut bien mettre un truc pareil en fond d'écran sans devenir épileptique au bout de deux jours :)

Salut Jérôme, je voulais te dire que j'aime beaucoup ton site web

Mais tu pourrais au moins mettre un lien vers Paperwork, quand même :)

Je te donne le code source en bonus ^v^

"<a href="https://github.com/jflesch/paperwork#readme">Paperwork</a> is a tool to make papers searchable."

Tu as raison, j'aurais dû préciser :

UPS c'est fait pour les gens qui télétravaillent dans un village où les colis sont distribués normalement, comme on le faisait au 20ième siècle.

Bon, en revanche, j'ai un ADSL de merde.

J'ai souvenir des graphismes 2D qui faisaient rêver pour les Lucas Art, Delphine Soft, les King Quest. La 3D c'est un peu la douche froide (par exemple dans King's Quest 8).

Je crois me souvenir aussi d'un Simon The Sorcerer en 3D assez ignoble.
C'était à l'époque où la 3D temps réel était tellement à la mode qu'il fallait en foutre partout, mais pour les point & click, ce fût particulièrement catastrophique.

Les graphismes de ce jeu lui étaient déjà reprochés dans les tests à l'époque (en 2007), trop flashy.
Je ne les trouve pas très beaux non plus.

visiblement il s'agit d'un jeu en troidé, donc très moche par rapport à ce qui peut se faire à plat.

Par contre tu fais exactement ce que tu dénonces, tu mets en comparaison un jeu 2D et un jeu 3D en disant : graphismes 3D < graphismes 2D.

Et si on admettait que c'est comme comparer des poires et des choux ?

Cela dit, pour les point & click, je dois admettre une préférence pour la 2D, qui se prête à mon avis mieux au genre.

En même temps, il n'y a pas grand chose de bénin à forte dose ;)

Si, peut-être le pays lui-même.

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);

:)