Guillaume Denry a écrit 2954 commentaires

Et un photographe passait « tout simplement par là » et a « par hasard » immortalisé ce moment fugace (en fait il voulait photographier un pigeon a côté et a glissé, c’est bête hein).

De nos jours, tout le monde a un appareil photo dans la poche….

La séparation entre hommes et femmes dans les compétitions sportives repose justement sur le fait même de la différence physique entre les hommes et les femmes.
Le but d'une compétition sportive est de gagner ; les femmes ne réclament pas à concourir contre les hommes car elles savent qu'elles ne sont pas à égalité en matière de performance physique brute, et les hommes ne réclament pas à concourir contre les femmes pour les mêmes raisons.
Bref, cette comparaison est définitivement foireuse.

Tiens, oui, "personne ne s'en insurge".
Contrairement au fait que les homos ne puissent pas se marier, où là, des homos s'insurgent.

Impossible, il n'a jamais joué dans Cyrano De Bergerac.

Quelle finesse de raisonnement, c'est implacable, on dirait du Descartes.
Je pense qu'un tel niveau ne s'atteint qu'après de longues années d'études de philosophie.

Ouais ouais ouais.
En tout cas, vu les comparaisons de merde que tu convoques au lieu de t'attaquer au raisonnement lui-même, je pense que je refuserais que tu me conduises :)

(facile celle-là, j'admets..)

Si j'ai bien compris, refuser le mariage aux homosexuels est comparable à ne pas vouloir se faire conduire en voiture par un handicapé mental.
Classe.

Bref : en quoi la pub est le mal?

Ca pollue mon espace visuel en permanence (métro, télé, pancartes partout, etc).

J'ai pas bien compris. Qui sont les abrutis ? Ceux qui utilisent leur tablette pour faire du karaoké ou faire de la reconnaissance faciale ou bien ceux qui vantent cette utilisation ?

Une application est synonyme de logiciel ou de programme, c'est-à-dire une entité qui exécute des instructions (interprété, compilé, JITé, peu importe).
Sur un store, ça ne change absolument rien, je ne vois vraiment pas ce qu'il y a de discutable là dedans. Le store est juste un fournisseur d'applications, qui elles, tournent sur ta machine. L'informaticien qui dit le contraire n'a plus qu'à changer de métier et à se mettre par exemple à la confection de fromage de chèvre.
Par contre, le flou pour moi se situe au niveau du cloud, quelle est la frontière entre un site web et une application web ? Est-ce qu'à partir du moment où un site contient un peu d'"intelligence", on peut considérer qu'on a affaire à une application ?

Et vous qu'en pensez-vous ? Est ce qu'une application présente sur un store peut elle être considérée comme une application comme une autre.

Non, je crois qu'une application sur un store est un petit morceau de l'âme du développeur qui l'a créé.

Juste par curiosité, comment un programme qui affiche des copies de fichier peut avoir besoin de plus de 200 connexions o_O ?

C'est vraiment grave.
Là il s'agît d'un clip de Jean-Louis Aubert donc ça va, mais imaginez maintenant avec de la vraie bonne musique !

Je pense qu'avant d'ensevelir Marotte sous un tas de jugements moraux, il conviendrait de bien saisir son propos : il explique simplement qu'il ne voit pas pourquoi il ferait plus que le nécessaire pour retrouver la caution qu'il a livré en arrivant, sous le prétexte que le propriétaire aurait décidé de, par exemple, refaire ses murs avec du papier peint tissé de fils d'or.
De plus, ça m'étonnerait beaucoup qu'il soit possible de quitter son logement en remplaçant une serrure trois points par une planche en aggloméré sans perdre sa caution.
Il y a bien sûr des limites "morales", car le problème, c'est tout ce qui n'est pas écrit par le rapport d'état des lieux.
Idéalement, il faudrait que le propriétaire décrive des qualités minimales pour tout ce que le locataire pourrait être amené à remplacer dans la maison, mais on sent bien que c'est quasi-mission impossible.
Exemple: si j'achète une tapisserie tellement pourrave qu'elle blanchit au soleil au bout de 2 mois alors que j'avais dégueulassé l'ancienne qui était d'une qualité correcte (sans être non plus du type que celle que je décrivais au dessus), c'est pas humainement terrible.
Mais bon, ce que je comprends de ce qu'il nous dit, c'est "pourquoi en faire trop alors qu'à la base, on est dans un rapport de locataire à rentier ?". De ce point de vue là, c'est un peu comme l'idée de travailler gratuitement en plus pour son patron pour que l'entreprise se porte bien et que les actionnaires sont contents à la fin de l'année.
Il faut être correct OK, mais aucune raison de faire des cadeaux.

Tu as tant de connect() que ça pour que leurs remplacements accélèrent à ce point le démarrage de l'application ?

Ce que je faisais, c'est que je virais les incandescentes à mon arrivée, et je les remettais à mon départ.
Maintenant, je suis un gros bourge de proprio capitaliste.

La question par derrière, c'est surtout de savoir si on peut en vivre.
Et là, franchement, dans un modèle libre, à part quelques exceptions, j'ai quelques doutes…

Si sauvegarder en jpg était un export dans l'esprit des gens lorsqu'ils utilisent un logiciel de manipulation d'image, oui, ça serait une idée saine de séparer strictement les deux.
L'ergonomie n'est pas qu'une affaire de « pureté technique », mais doit s'adresser avant tout à des êtres humains.
Je comprends que les développeurs veulent coder exactement ce qu'ils veulent et ne sont pas soumis aux contraintes habituellement inhérentes aux projets proprio, mais ici, le problème adressé par ce changement de comportement aurait pu être résolu autrement.

J'utilise un mode hybride :
- du RSS dont j'aime être informé de chaque news en "temps réel" (en général des blogs, surtout techniques ou bien des web comics). En ce moment, je passe par Google Reader (mais le mode auto-hébergé me tente) et j'utilise le lien "prochaine news non lue" au sein d'un bouton dans ma barre de bookmark, ce qui me mène directement sur la prochaine news non lue sur le site (je n'aime pas lire les news dans un lecteur RSS, ne serait-ce que pour lire les commentaires de certains blogs et oui je sais, pas top l'économie de bande passante, toussa).
- Des bookmarks dans la barre du haut de mon navigateur pour soit les sites trop "verbeux" dont je n'ai besoin que d'un coup d'œil pour prendre connaissance du contenu et éventuellement approfondir manuellement sur certains articles en particulier (typiquement les sites d'actualités) ou bien soit les sites récurrents que j'utilise au boulot (wiki, fiches de bugs, webmail interne, etc)

Je voulais reposter une modification/clarification de ce que j'avais écrit à la fin de mon commentaire mais le timeout m'en empêché :)

---

De manière générale, ce qui trouble dans cette histoire, c'est d'avoir considéré que les seuls formats de sauvegarde au sein d'un logiciel qui travaille pourtant sur des images n'étaient que les formats de projets. Qui a-t'il de déconnant à considérer qu'un logiciel de retouche d'image peut utiliser un format d'image pour ses sauvegardes ?
Lorsqu'on dit aux développeurs de Gimp qu'on peut vouloir ne travailler qu'en png sans nécessairement sauvegarder un format "projet" à chaque fois (ce que j'appelle le mode "one-shot" plus haut), leur réponse, c'est "faites avec ou bien ça veut dire que vous avez besoin d'utiliser un logiciel plus basique".
Et puis peu importe si aucun autre logiciel de retouche d'image (libre ou non) n'a fait ce choix…

Je paste ici ce que j'avais répondu à une époque où l'on avait débattu de ce sujet sur google+ et que je considère toujours d'actualité =>

---

Si j'ai bien compris, ce qui gonflait les utilisateurs avancés, c'était lors des exports réguliers de leur boulot, de devoir faire "save as jpg" et ensuite, de devoir re-sélectionner le format projet. C'était carrément pénible pour leur workflow et ça, tout le monde peut le comprendre.
Etanchéifier la gestion des formats projet et les formats image a été la solution la plus simple et la plus radicale, et les développeurs de Gimp ont jugé que se mettre "à dos" (toute proportion gardée hein) leur base d'utilisateur la plus casual n'était pas un problème, car ce qui les intéresse, c'est ceux qui utilisent gimp de façon "avancée" (en réalité, plutôt ceux qui utilisent le .xcf quasi-systématiquement, ce qui ne coïncide pas forcément avec l'ensemble des utilisateurs "avancés", mais passons), les autres n'ayant plus qu'à utiliser autre chose.
Cette modif à introduit deux "nuisances" :
- Devoir perdre le réflexe de sauver lorsqu'on veut sauvegarder dans un format "destructif", après plusieurs utilisations, perso, j'ai toujours le réflexe de "sauver" quand je veux sauver en .jpg, mais bon, je suis pas forcément le meilleur exemple :)
- Lorsqu'on exporte et qu'on veut ensuite quitter, il fait chier avec une popup "attention, vous n'avez pas sauvé votre boulot, vous êtes sûr ?". C'est corollaire du premier point puisqu'effectivement, une exportation n'est pas une sauvegarde, mais bon, c'est maintenant plus pénible de bosser en mode one-shot.

On dirait que les développeurs ont jugé impossible de satisfaire autant ceux qui bossent en mode projet que ceux qui bossent en mode one-shot.

Bref, pourquoi ne pas simplement avoir plus mis en avant le format .xcf mais permettre tout de même pour ceux qui veulent bosser en "mode destructif" de le faire aussi simplement ? En quoi ça aurait empêché les utilisateurs de mode "projet" de bosser avec la nouvelle super feature d'exportation ?
Proposition :
Dès que je force la boîte de sauvegarde à utiliser un format "destructif", je passe Gimp dans un mode "destructif", comme auparavant pour la suite de la session.
Personne ne forcera les utilisateurs avancés à utiliser cette méthode.
J'imagine que les développeurs pensent que les nouveaux utilisateurs "pro" seront tentés d'utiliser le mode "destructif", mais il y a moyen de mettre en retrait cette fonctionnalité : que je parte d'une nouvelle image, de l'ouverture d'un .xcf ou bien de l'ouverture d'un .jpg, dès ma première sauvegarde, il me propose le .xcf en priorité, point barre.

---

De manière générale, ce qui trouble dans cette histoire, c'est de considérer qu'un export dans un logiciel qui travaille sur des images n'est pas une sauvegarde. Lorsqu'on dit aux développeurs de Gimp qu'on peut vouloir ne travailler qu'en png sans nécessairement sauvegarder un format "projet" à chaque fois, leur réponse, c'est "faites avec ou bien utiliser un logiciel plus basique".
Et puis peu importe si aucun autre logiciel de retouche d'image (libre ou non) n'a fait ce choix…

Tu dis qu'on ne peut plus coder dedans, mais, j'imagine que ça implique que l'on peut lier "mécaniquement" une boîte de dialogue à un contrôle?

J'ai un peu de mal à comprendre ta question.
Le .cpp généré en fonction du .ui décrit une nouvelle classe qui contient autant de propriétés qu'il y a de widgets dans le formulaire et ces propriétés sont nommées en fonction du nom qu'on leur affecte dans Qt Designer.
Pour bien séparer les choses, cette classe générée appartient à un namespace Ui.
La liaison entre le code "IHM" généré (via le .cpp généré) et ton code à la main à toi est faite soit via de l'encapsulation en instanciant une propriété de type la classe générée, soit de l'héritage multiple en déclarant une classe de même type que le widget décrit sous designer et en seconde classe la classe Ui.

La seconde question porte sur le fait du travail supplémentaire impliqué par ce type d'outil.
J'ai constaté que régulièrement, quand on modifie un truc dans le code, soit ça pourrit le RAD, soit le RAD l'écrase ensuite, quand on y retourne pour modifier un truc. Même combat ici, ou …?

Du point de vue de la conception, tu ne peux rien écraser dans quel sens que ce soit : si tu modifies ton .ui avec Qt Designer, la seule chose que tu vas écraser, c'est le .cpp généré correspondant, mais celui-ci de toute façon, ne doit impérativement jamais être modifié à la main. Ton code ui "manuel" à toi est lui bien séparé dans d'autres fichiers cpp.

En bref, le système d'Ui de Qt intervient en amont et est généralement additif ; une fois utilisé au sein d'une application, la seule chose qui reste à faire au runtime une fois que la classe Ui est instanciée, c'est d'ajouter manuellement ce qui pourrait manquer (l'exemple de la grille de bouton de chiffres dans une calculatrice dont on aurait "qt désigné" tout le reste (boutons spéciaux, écran LCD, etc)), ou bien à la rigueur de cacher des objets issus des .ui. Il est très rare d'avoir à supprimer des composants d'une classe issue d'un .ui.

J'ai longtemps fait du Delphi au boulot et je peux te dire que la propreté de Qt à ce niveau là a vraiment été une bouffée d'oxygène pour moi.

Bon, certes, ce n'est qu'un cas très précis, pas généralisable. Et j'utilise des RAD, moi aussi. Pour le prototypage, et le dev crado, c'est bien, ça accélère.
Par contre, si je veux un code propre et une appli légère, non, parce que les layouts permettent de régler le problème de la présentation très facilement à la main, et que si mon appli dois être légère, ça veut aussi dire qu'il vaut mieux ne pas trop charger l'interface.

J'ai pas mal de temps pensé comme toi, je fais du Qt depuis la version 3 et je considérais Designer de loin en me disant que pour les trucs basiques, c'était pas mal mais qu'un vrai codeur bossait en instanciant ses formulaires IHM à la main, c'est plus souple et blablabla, mais je suis largement revenu de ça, même pour des applis Pro, j'utilise Designer avec bonheur pour des morceaux statiques d'IHM (formulaire de settings, etc, même des morceaux conçus avec Designer intégrés dans des QWidget instanciés à la main), ça me fait gagner un temps fou.
On est pas dans un truc à la Delphi là, Trolltech avait pensé à bien séparer les choses à l'époque (pour Qt3, on pouvait encore coder dans Designer, mais ils n'ont pas hésité à épurer Qt Designer ensuite).

Qui te dit qu'il veut la flotte à 100°c ?

Peut-être parce que c'est un jeu qui tourne sous linux et qu'on est sur linuxfr, site susceptible d'intéresser les linuxiens (ou une partie) et pas seulement les libristes ?