c'est plus de la comparaison GTK vs Qt, c'est de la comparaison C vs C++.
Je vais faire mon Zenitram : c'est vraiment de le pure mauvaise foi pour ne pas reconnaître une très grosse faiblesse de Gtk: c'est fait en C et ça pue pour l'héritage et plus généralement les fonctionnalités Objet.
On parle bien de comparer Gtk avec son implémentation de référence et Qt avec son implémentation de référence. Et pas d'un binding Gtk quelconque avec Qt, ou d'un binding Qt quelconque avec Gtk.
Et de fait, Gtk utilise une sur-couche par dessus le C pour faire de l'objet, et bien que ce soit fait intelligemment, ça reste très moche et limité. Il faut écrire un km de code pour faire de l'héritage, et on en a besoin de l'héritage si on fait une application évoluée.
Pour faire un reproche équivalent à Qt (et me dédouaner de toute accusation de partialité), on peut reprocher à Qt le fait de n'être pas du C++ mais du C++ avec une surcouche gérée par l'outil Moc.
Je ne te répondrai pas que le reproche est débile, et qu'il faudrait comparer boost.signal avec Qt pour être honnête (comme tu viens de le faire). Ou bien que tu n'as qu'à faire du PyQt où le moc n'est pas utilisé.
C'est vrai que Moc est indispensable pour faire du Qt, mais ça permet de pallier avec élégance (et une petite complexité à la compilation) à un manque de fond du C++.
Un des clients mercurial les mieux foutus que j'ai rencontré a aussi migré de Gtk a Qt. On vous l'avait dit il y a 10 ans, vous ne vouliez pas nous croire !
Pour moi, l'argument no 1 de Qt reste la portabilité. Il y a beaucoup d'autres atouts mais pour une application moyenne développée en Gtk, la partie graphique de Qt même si elle est plus simple ne fera pas un tel différentiel. La différence se voit surtout :
- pour des applis complexes
- dès que tu veux porter sous Windows
Là, c'est assez violent. Le portage de Gtk sous Windows reste une grosse grosse difficulté.
C'est plus juste en effet, en ajoutant que c'est un bureau Gnome portable sous Windows, MacOs, tous les unix et Android, avec un look natif sur toutes les plate-formes citées.
Développeur / testeur, c'est un peu limité. J'aurai plutôt mis une option "développement logiciel", avec la possibilité pour les développeurs, les testeurs, les chefs de projets, les architectes logiciels de faire ce choix.
lpod est très intéressant mais semble très léger sur les exemples de fichier spreadsheet. Les tutoriaux ne repondent pas aux questions suivantes :
- comment inclure une formule
- comment formatter une cellule
- comment faire immobiliser des lignes dans l'affichage
Mais en tout cas, il y a une base et c'est intéressant.
Désolé de ne pas participer au développement de ODF et LO mais pour le coup, je me place dans la position d'un simple utilisateur. J'ai mentionné SOMMESIENS mais ce n'est pas la seule fonction Excel 2010 qui manque à LibreOffice. Je pense que des gens plus calés que moi sauront en sortir une liste exhaustive, c'est pas comme si la documentation Microsoft sur ce sujet n'était pas accessible en ligne.
Honnêtement, je n'utilise pas LibreOffice car j'ai besoin d'être très productif à mon travail et que il n'est pas à la hauteur des solutions Microsoft. Autant il y a 10 ans, je faisais tout sous OO et je perdais presque rien par rapport à Word, Excel et autres, autant aujourd'hui, en terme de convivialité, LibreOffice est très très loin du compte et je convertis tous mes documents sxc et sxw en fichiers Office.
Pour la barre de statut, je ferai la demande par les voies officielles.
Pour prendre un exemple pratique, les 3/4 de mes feuilles de calcul utilisent des sommes avec condition. J'utilise donc la fonction très pratique SOMME.SI.ENS() qui permet de faire la somme d'une plage de données en fonction d'une multitude de critères provenant de plusieurs autres plages de données. Mais cette fonction n'est pas présente sous LO, quel dommage…
L'autre truc pratique, c'est par exemple de sélectionner une plage de valeur et de regarder sur la barre de statut la somme, le nombre de valeurs et leur moyenne en un coup d'oeil. Et de comparer ça vite fait avec une autre plage. Sous LO, c'est vaguement possible, mais tu ne peux voir que une seule information à la fois: soit la somme, soit la moyenne, soit le nombre de valeurs. Bof bof bof.
Et des détails comme ça, il y en a des tonnes. C'est un somme de détails qui fait un bon produit et on peut dire que dans l'ensemble LO a les fonctionnalités de bases, mais sur la somme de détails, il est à la rue!
Est-ce qu'il y a un bon lecteur et générateur de feuilles de calcul en Python ? J'utilise http://www.python-excel.org/ mais j'ai l'impression que côté format libre, c'est un peu la misère. Et pitié, pas de solution à la "tu fais tourner libreoffice et …", c'est pour mettre sur un serveur où il n'y a pas X.
Tu oublies l'immense pollution que génère leur fabrication et leur rapide obsolescence. Malheureusement, les fours qui font le café et qui poste sur twitter commencent à leur faire de la concurrence en terme de pollution !
Ca prouve que ceux qui défendaient Gnome avaient tort et qu'ils devraient immédiatement faire des excuses à tous les développeurs KDE et tous les trolleurs KDE / Qt de LinuxFr. Quand je vois d'ailleurs le ton agressif avec lequel ils se sont débattus, je me demande d'ailleurs si il y aurait pas là un sujet de mise en demeure ! Ils ont clairement nuit à la réputation d'un projet honorabl. Je vais de ce pas en parler à KDE et vous pouvez vous attendre à un avis d'huissiers fissa !
C'est écologique au moins sur l'aspect durée de vie: perso, je fais de temps en temps du pain (à peu près sans recette) et il dure facilement 4 jours, voire une semaine si t'as des bonnes dents. Ca fait pas mal de trajets éliminés l'air de rien.
Quand je dis faire des trucs façon printf, je mets la barre un peu plus haut que afficher juste un float:
QString s; s.sprintf("Nous sommes le %02d/%02d/%04d, le total de votre facture est %0.2f", day, month, year, totalTtc );
La version recommandée est plutôt:
QString s("Nous sommes le %1/%2/%3, le total de votre facture est %4").arg(day,2,'0').arg(month,2,'0').arg(year,4,'0').arg(totalTtc,0,'f',2,'0')
Vas-y en STL, je compte les lignes.
Je veux bien voir la conversion d'encodage aussi, juste pour rire.
La STL, ça reste quand même un truc limite académique, avec une utilité pratique très limitée. Dès que tu fais un programme qui intéragit avec le monde extérieur, ce sera très très très insuffisant. Heureusement, il y a des framework qui tiennent la route pour boucher les trous, comme boost. D'ailleurs si tu regardes de près dans boost, il doit plus rester beaucoup de STL, je pense qu'on peut lui faire le même procès qu'à Qt.
Je voulais surtout souligner que pour faire du GUI et pour faire de l'asynchrone, le besoin n'est pas comme semble l'indiquer le commentaire précédent "les threads" mais une bonne boucle d'évenement.
Les threads sont utiles pour gérer une tâche longue sans bloquer le GUI (calcul, IO), mais pas pour faire un bon GUI réactif.
Trop de gens pensent que les threads sont la panacée de l'asynchrone, à tort !
Pour ce qui est de l'intégration des threads dans Qt, j'ai un peu décroché depuis Qt3 mais à l'époque, je trouvais ça pas très naturel vis a vis du fonctionnement du reste du framework. Il y avait des limitations. Beaucoup de progrès ont été fait depuis et c'est très bien !
Tu as besoin d'asynchrone. Tu as besoin de thread.
Tu as surtout et avant tout besoin d'une bonne boucle d'évènement. D'ailleurs les threads ont été rajoutés très tardivement dans Qt, genre dans Qt 3. Et globalement, ca reste peu recommandé.
Par contre, avoir un évènement "rappelle-moi quand il y a des données sur ma socket sans bloquer le GUI en attendant", c'est top et ca se fait sans threads…
Un troll Qt/Gtk/STL, ca fait bien 10 ans que j'en ai pas vu un beau.
Aller, je me lance: std::string a très peu de chose à voir avec une QString. Ah si, le seul point commun, c'est que c'est un conteneur.
Mais voyons ce qu'on fait couramment avec une chaîne de caractère de nos jours:
- la stocker en latin1() pour l'afficher dans de vieux outils qui utilise encore le latin1: 1 point pour QString, 0 pour std::string
- la convertir en UTF8() pour un format d'échange standard: 1 point pour QString, 0 pour std::string
- connaitre son encodage pour pas se rater dans les conversions: 1 ponit pour QString, 0 pour std::string
- la couper en petits bouts: 1 point pour QString, 0 pour std::string
- vérifier si elle contient une chaine particulière, si elle commence par une chaine particulière, si elle se termine par une chaine particulière: 1 point pour QString, 0 pour std::string
- y stocker des floats, doubles, entiers, autres chaines de caractère: 1 point pour QString, 0 pour std::string
- la parcourir avec des itérateurs standard du C++: 1 point pour QString, 1 point pour std::string .
Conclusion: la std::string n'a a peu près rien à voir avec une QString. Les trucs les plus pénibles à faire avec une chaine de caractères de nos jours (conversion d'encodage, affichage de valeur facon printf), vérification de contenu, découpage, … se font en un appel sur une Qtring et en 50 lignes de code dans le meilleur des cas en std::string.
Mais est-ce qu'il existe un seul exemple de cela ?
J'ai souvenir d'une intervention de RMS qui expliquait que ça arrivait régulièrement. Après, libre à toi d'appeler ça du FUD, surtout que c'est assez vague. Ca parait quand même assez crédible: une grosse boite ne va pas passer son produit principal en GPL parce qu'un glandu de développeur a piqué du code GPL…
Zenitram me corrigera si je me trompe, mais il me semble qu'ils sont plus ouverts que la moyenne des grosses boites, puisqu'ils acceptent de bosser avec un indépendant, qui en plus travaille pour les communistes fait du logiciel libre. Il y a beaucoup de boites qui s'enfuient en courant en voyant ça, et vont préférer signer un gros contrat 10 fois plus cher avec la grosse boite du coin, soit hyper spécialisée dans le secteur, soit au contraire pas du tout spécialisée mais avec qui ils ont un contrat annuel de toute façon.
En revanche si le marché était hautement concurrentiel est-ce que tu ne penses pas qu'il y aurait un risque que quelqu'un prenne ton code, apporte des améliorations et revende le tout sous licence propriétaire ? Il aurait donc un gros avantage sur toi puisque ton travail serait incorporé à son produit (il prend tes patchs qui sont sous BSD) alors que les siens te sont interdits
Le risque est identique sous licence GPL. La GPL te rajoute une protection théorique pour ce cas, mais pas facile à mettre en oeuvre :
Le mec doit distribuer les sources des modifs qu'il a faite, mais il peut se contenter de les livrer uniquement sur demande, et uniquement à ses clients. Ouch, les partisans de la GPL oublient bien souvent cet écueil.
Tu dois donc être soit client de ce mec là, soit être pote avec un de ses clients qui te refile les sources. Il se peut d'ailleurs que ledit logiciel fasse partie d'une suite à plusieurs dizaine de milliers d'euros. Difficile de devenir client juste pour récupérer des modifs.
Quand bien même tu récupères ledit code, il peut être difficile à réintégrer, parcqu'il est mal codé, parce qu'il fait des modifs de fond sur ton logiciel pour accomoder ses besoins qui ne te conviennent pas (cf Android vs Linux), parce qu'il emmène ton logiciel dans une direction que tu ne souhaites pas avoir. Tout le monde n'a pas l'intelligence de faire un plugin ou un module séparé du code principal. Les entreprises qui ont l'attitude que tu décris ont d'ailleurs plutôt l'habitude de considérer le code comme un truc jetable.
Dans la pratique, la protection offerte par la GPL vs BSD est limitée. Si tu prends le cas Android, au final, c'est bien la volonté de Google d'intégrer son code à Linux qui a permis de faire évoluer la situation, et pas le fait que le code soit disponible sous GPL.
Il ne faut pas oublier que la viralité de la gpl est ce qui a obligé des entreprises à collaborer avec le libre en leur donnant du code "gratuit", et parfois du très bon code pour des milliers d'heures.
Ce point central de ton argumentation est complètement non démontré. Par exemple, Apple contribue à llvm et clang bien que ces derniers utilisent une licence de type BSD. Et on peut dire la même chose du serveur web Apache.
RMS lui-même dans plusieurs des conférences que j'ai écoutées, disait que la nature virale de la GPL est un frein majeur à l'adoption de code dans les entreprises, et que pour une entreprise qui passe un soft en GPL à cause de l'utilisation d'un code GPL, il y en a des centaines voire des milliers qui dégagent tout simplement le code.
La perte pour une entreprise qui utilise un projet libre au coeur de ses logiciels, sans pouvoir participer au développement dudit logiciel est telle que au final, l'entreprise contribue. La pression "sociale" marche finalement aussi bien que la pression juridique. Et pour les cas où elle ne marche pas, je dirai qu'elle marche aussi mal que la pression juridique…
Petite information gratuite: l'antenne ne passe pas là ou la carte est en relief, car le processus mécanique la couperait. Ton schéma n'est bon que pour une carte sans embossage.
Dans le cas de l'embossage, c'est une demi-antenne, qui couvre en gros toute la partie non embossée.
L'antenne est prise en sandwich dans le plastique donc il faut faire une "bonne" incision, aller jusqu'au milieu de la carte.
On a même pas besoin de satisfaire le facteur ce que je possède pour effectuer une transaction, il suffit de se coller à des gens dans le métro (ce n'est pas comme si avoir plein de gens autour de soi dans le métro était exceptionnel).
Si tu te colles à quelqu'un dans le métro, tu pourras lire sa carte NFC, mais c'est pas pour autant que tu pourras faire une transaction NFC par la suite. Chaque transaction (au moins pour les normes Visa, Mastercard et American Express) est sécurisée par une authentification avec la carte.
Par contre, c'est vulnérable à une attaque "Man in the Middle" bien que la mise en oeuvre me paraisse difficile : il faut sortir un bidule électronique connecté à la place d'une carte NFC devant le vendeur (qui doit n'y voir que du feu), il faut une liaison sans-fil haut débit avec un gus collé au vrai porteur pour suivre les exigences de timing de la carte sans-contact (le lecteur envoie des données, il faut répondre très vite), et il faut une parfaite synchronisation pour lire les infos de la carte du porteur à ce moment-là.
nous pouvons aisément supposer qu'il ne respecte pas les limites de puissances légales, comment la carte réagit-elle dans ce cas ?
Il peut certainement passer de 5 cm à quelques dizaines de cm, mais pas à 3-4m. Quoiqu'on peut imaginer un lecteur avec une antenne ultra-directive. Si il met trop de patate pendant longtemps, ta carte va chauffer, voire brûler…
Il semble y avoir un problème de vie privée, puisqu'il semble être possible de récupérer des informations nominatives sur les personnes.
Ca va dépendre des applications mais de fait, dans pas mal de cas que j'ai vu sur le terrain, il est assez facile de demander des informations à la carte pour lui dire qu'elle doit s'authentifier, avant de prouver qu'on est un demandeur légitime.
Je suis tout à fait d'accord que produire une documentation dite professionnelle à l'arrache en accolant 3 outils est tout à fait inadapté.
Faire une vraie doc demande plus d'investissements que ça, bienvenue dans le monde réel !
Ca me fait penser à ces lobbyistes du libres qui se moquent de moi parce que j'utilise PowerPoint et Excel alors que « LibreOffice sait tout faire de la même façon » . Sauf que quand on tombe face à des utilisations autres que extrêmement basiques, LibreOffice n'est plus un clone des outils Microsoft et on tombe sur des incompatibilités, fonctions manquantes [1], rendus incorrects, ou tout simplement une interface beaucoup plus difficile à exploiter.
[1]: j'utilise très fréquemment sous Excel les fonctions NB.SI.ENS et SOMME.SI.ENS qui sont bien pratiques, mais non dispo sous Calc. Et j'ai pas trouvé d'alternatives.
J'ai globalement le même problème dans ma société et j'ai finalement opté pour Dropbox. C'est de loin la solution la plus simple, avec conservation de tout l'historique.
Par contre, les inconvenients de Dropbox:
si tu travailles sur le fichier en mode "brouillon", il est quand même synchronisé à chaque sauvegarde, donc des gens voient des versions non finalisées. A compenser en travaillant au brouillon dans un répertoire à part mais c'est pas pratique.
si tout le monde travaille en même temps sur le fichier, c'est la zone. Sans que ce soit en même temps, il suffit que ce soit beaucoup de gens qui consultent le fichier au même moment par exemple.
j'ai pas mal de cas où dropbox dégage des modifications déjà faites… et c'est la zone pour les retrouver.
Globalement, ca reste le plus simple sans être le plus fiable.
Avant, j'avais testé SVN qui marche pas trop mal, sauf quand tu commences à déplacer des fichiers, renommer, avoir des conflits, ou simplement SVN mal luné qui te nique ses fichiers metadata.
# Très intéressant
Posté par Philippe F (site web personnel) . En réponse au journal i18n: la langue la plus concise est le chinois. Évalué à 3.
On savait tous que traduire une interface en français pose un problème de place, mais là on a des stats concrètes.
Je note que en gros, il faut doubler la place pour faire tenir la majorité des textes anglais en français dans une interface graphique. Oups…
[^] # Re: Qt vs Gtk
Posté par Philippe F (site web personnel) . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 7.
Je vais faire mon Zenitram : c'est vraiment de le pure mauvaise foi pour ne pas reconnaître une très grosse faiblesse de Gtk: c'est fait en C et ça pue pour l'héritage et plus généralement les fonctionnalités Objet.
On parle bien de comparer Gtk avec son implémentation de référence et Qt avec son implémentation de référence. Et pas d'un binding Gtk quelconque avec Qt, ou d'un binding Qt quelconque avec Gtk.
Et de fait, Gtk utilise une sur-couche par dessus le C pour faire de l'objet, et bien que ce soit fait intelligemment, ça reste très moche et limité. Il faut écrire un km de code pour faire de l'héritage, et on en a besoin de l'héritage si on fait une application évoluée.
Pour faire un reproche équivalent à Qt (et me dédouaner de toute accusation de partialité), on peut reprocher à Qt le fait de n'être pas du C++ mais du C++ avec une surcouche gérée par l'outil Moc.
Je ne te répondrai pas que le reproche est débile, et qu'il faudrait comparer boost.signal avec Qt pour être honnête (comme tu viens de le faire). Ou bien que tu n'as qu'à faire du PyQt où le moc n'est pas utilisé.
C'est vrai que Moc est indispensable pour faire du Qt, mais ça permet de pallier avec élégance (et une petite complexité à la compilation) à un manque de fond du C++.
# TortoiseHG aussi
Posté par Philippe F (site web personnel) . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 10.
Un des clients mercurial les mieux foutus que j'ai rencontré a aussi migré de Gtk a Qt. On vous l'avait dit il y a 10 ans, vous ne vouliez pas nous croire !
Pour moi, l'argument no 1 de Qt reste la portabilité. Il y a beaucoup d'autres atouts mais pour une application moyenne développée en Gtk, la partie graphique de Qt même si elle est plus simple ne fera pas un tel différentiel. La différence se voit surtout :
- pour des applis complexes
- dès que tu veux porter sous Windows
Là, c'est assez violent. Le portage de Gtk sous Windows reste une grosse grosse difficulté.
[^] # Re: bof
Posté par Philippe F (site web personnel) . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 1.
C'est plus juste en effet, en ajoutant que c'est un bureau Gnome portable sous Windows, MacOs, tous les unix et Android, avec un look natif sur toutes les plate-formes citées.
# Chef de projet ?
Posté par Philippe F (site web personnel) . En réponse au sondage Votre métier. Évalué à 10.
Développeur / testeur, c'est un peu limité. J'aurai plutôt mis une option "développement logiciel", avec la possibilité pour les développeurs, les testeurs, les chefs de projets, les architectes logiciels de faire ce choix.
[^] # Re: Préférée?
Posté par Philippe F (site web personnel) . En réponse au sondage Quelle est votre suite bureautique principale ou préférée ?. Évalué à 2.
lpod est très intéressant mais semble très léger sur les exemples de fichier spreadsheet. Les tutoriaux ne repondent pas aux questions suivantes :
- comment inclure une formule
- comment formatter une cellule
- comment faire immobiliser des lignes dans l'affichage
Mais en tout cas, il y a une base et c'est intéressant.
[^] # Re: Préférée?
Posté par Philippe F (site web personnel) . En réponse au sondage Quelle est votre suite bureautique principale ou préférée ?. Évalué à 1.
Merci pour ces réponses claires.
Désolé de ne pas participer au développement de ODF et LO mais pour le coup, je me place dans la position d'un simple utilisateur. J'ai mentionné SOMMESIENS mais ce n'est pas la seule fonction Excel 2010 qui manque à LibreOffice. Je pense que des gens plus calés que moi sauront en sortir une liste exhaustive, c'est pas comme si la documentation Microsoft sur ce sujet n'était pas accessible en ligne.
Honnêtement, je n'utilise pas LibreOffice car j'ai besoin d'être très productif à mon travail et que il n'est pas à la hauteur des solutions Microsoft. Autant il y a 10 ans, je faisais tout sous OO et je perdais presque rien par rapport à Word, Excel et autres, autant aujourd'hui, en terme de convivialité, LibreOffice est très très loin du compte et je convertis tous mes documents sxc et sxw en fichiers Office.
Pour la barre de statut, je ferai la demande par les voies officielles.
[^] # Re: Préférée?
Posté par Philippe F (site web personnel) . En réponse au sondage Quelle est votre suite bureautique principale ou préférée ?. Évalué à 3.
Je suis d'accord.
Pour prendre un exemple pratique, les 3/4 de mes feuilles de calcul utilisent des sommes avec condition. J'utilise donc la fonction très pratique SOMME.SI.ENS() qui permet de faire la somme d'une plage de données en fonction d'une multitude de critères provenant de plusieurs autres plages de données. Mais cette fonction n'est pas présente sous LO, quel dommage…
L'autre truc pratique, c'est par exemple de sélectionner une plage de valeur et de regarder sur la barre de statut la somme, le nombre de valeurs et leur moyenne en un coup d'oeil. Et de comparer ça vite fait avec une autre plage. Sous LO, c'est vaguement possible, mais tu ne peux voir que une seule information à la fois: soit la somme, soit la moyenne, soit le nombre de valeurs. Bof bof bof.
Et des détails comme ça, il y en a des tonnes. C'est un somme de détails qui fait un bon produit et on peut dire que dans l'ensemble LO a les fonctionnalités de bases, mais sur la somme de détails, il est à la rue!
Est-ce qu'il y a un bon lecteur et générateur de feuilles de calcul en Python ? J'utilise http://www.python-excel.org/ mais j'ai l'impression que côté format libre, c'est un peu la misère. Et pitié, pas de solution à la "tu fais tourner libreoffice et …", c'est pour mettre sur un serveur où il n'y a pas X.
[^] # Re: four.....
Posté par Philippe F (site web personnel) . En réponse au journal Une recette pour auto-héberger sa boulangerie. Évalué à 4.
Tu oublies l'immense pollution que génère leur fabrication et leur rapide obsolescence. Malheureusement, les fours qui font le café et qui poste sur twitter commencent à leur faire de la concurrence en terme de pollution !
[^] # Re: Interface graphique.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Wireshark 1.10. Évalué à 2.
Ca prouve que ceux qui défendaient Gnome avaient tort et qu'ils devraient immédiatement faire des excuses à tous les développeurs KDE et tous les trolleurs KDE / Qt de LinuxFr. Quand je vois d'ailleurs le ton agressif avec lequel ils se sont débattus, je me demande d'ailleurs si il y aurait pas là un sujet de mise en demeure ! Ils ont clairement nuit à la réputation d'un projet honorabl. Je vais de ce pas en parler à KDE et vous pouvez vous attendre à un avis d'huissiers fissa !
[^] # Re: Interface graphique.
Posté par Philippe F (site web personnel) . En réponse à la dépêche Wireshark 1.10. Évalué à 0.
Si je ne m'abuse, ça fait plusieurs logiciels qui passent de Gtk à Qt ces derniers temps, principalement pour cause des problèmes sur le port Windows.
Ahhh… si j'avais pu sortir ces exemples il y a 10 quand on trollais sur Qt, Gtk, KDE et Gnome, ça en aurait fait taire plus d'un !
[^] # Re: four.....
Posté par Philippe F (site web personnel) . En réponse au journal Une recette pour auto-héberger sa boulangerie. Évalué à 2.
C'est écologique au moins sur l'aspect durée de vie: perso, je fais de temps en temps du pain (à peu près sans recette) et il dure facilement 4 jours, voire une semaine si t'as des bonnes dents. Ca fait pas mal de trajets éliminés l'air de rien.
[^] # Re: Trollons
Posté par Philippe F (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 5.
Quand je dis faire des trucs façon printf, je mets la barre un peu plus haut que afficher juste un float:
La version recommandée est plutôt:
Vas-y en STL, je compte les lignes.
Je veux bien voir la conversion d'encodage aussi, juste pour rire.
La STL, ça reste quand même un truc limite académique, avec une utilité pratique très limitée. Dès que tu fais un programme qui intéragit avec le monde extérieur, ce sera très très très insuffisant. Heureusement, il y a des framework qui tiennent la route pour boucher les trous, comme boost. D'ailleurs si tu regardes de près dans boost, il doit plus rester beaucoup de STL, je pense qu'on peut lui faire le même procès qu'à Qt.
[^] # Re: Trollons
Posté par Philippe F (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.
Je voulais surtout souligner que pour faire du GUI et pour faire de l'asynchrone, le besoin n'est pas comme semble l'indiquer le commentaire précédent "les threads" mais une bonne boucle d'évenement.
Les threads sont utiles pour gérer une tâche longue sans bloquer le GUI (calcul, IO), mais pas pour faire un bon GUI réactif.
Trop de gens pensent que les threads sont la panacée de l'asynchrone, à tort !
Pour ce qui est de l'intégration des threads dans Qt, j'ai un peu décroché depuis Qt3 mais à l'époque, je trouvais ça pas très naturel vis a vis du fonctionnement du reste du framework. Il y avait des limitations. Beaucoup de progrès ont été fait depuis et c'est très bien !
[^] # Re: Trollons
Posté par Philippe F (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Tu as surtout et avant tout besoin d'une bonne boucle d'évènement. D'ailleurs les threads ont été rajoutés très tardivement dans Qt, genre dans Qt 3. Et globalement, ca reste peu recommandé.
Par contre, avoir un évènement "rappelle-moi quand il y a des données sur ma socket sans bloquer le GUI en attendant", c'est top et ca se fait sans threads…
[^] # Re: Trollons
Posté par Philippe F (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 10.
Un troll Qt/Gtk/STL, ca fait bien 10 ans que j'en ai pas vu un beau.
Aller, je me lance: std::string a très peu de chose à voir avec une QString. Ah si, le seul point commun, c'est que c'est un conteneur.
Mais voyons ce qu'on fait couramment avec une chaîne de caractère de nos jours:
- la stocker en latin1() pour l'afficher dans de vieux outils qui utilise encore le latin1: 1 point pour QString, 0 pour std::string
- la convertir en UTF8() pour un format d'échange standard: 1 point pour QString, 0 pour std::string
- connaitre son encodage pour pas se rater dans les conversions: 1 ponit pour QString, 0 pour std::string
- la couper en petits bouts: 1 point pour QString, 0 pour std::string
- vérifier si elle contient une chaine particulière, si elle commence par une chaine particulière, si elle se termine par une chaine particulière: 1 point pour QString, 0 pour std::string
- y stocker des floats, doubles, entiers, autres chaines de caractère: 1 point pour QString, 0 pour std::string
- la parcourir avec des itérateurs standard du C++: 1 point pour QString, 1 point pour std::string .
Conclusion: la std::string n'a a peu près rien à voir avec une QString. Les trucs les plus pénibles à faire avec une chaine de caractères de nos jours (conversion d'encodage, affichage de valeur facon printf), vérification de contenu, découpage, … se font en un appel sur une Qtring et en 50 lignes de code dans le meilleur des cas en std::string.
[^] # Re: merci :-)
Posté par Philippe F (site web personnel) . En réponse au journal Mon évolution vis à vis du copyleft. Évalué à 3.
J'ai souvenir d'une intervention de RMS qui expliquait que ça arrivait régulièrement. Après, libre à toi d'appeler ça du FUD, surtout que c'est assez vague. Ca parait quand même assez crédible: une grosse boite ne va pas passer son produit principal en GPL parce qu'un glandu de développeur a piqué du code GPL…
[^] # Re: Trop long, pas lu
Posté par Philippe F (site web personnel) . En réponse au journal Mon évolution vis à vis du copyleft. Évalué à 2.
Zenitram me corrigera si je me trompe, mais il me semble qu'ils sont plus ouverts que la moyenne des grosses boites, puisqu'ils acceptent de bosser avec un indépendant, qui
en plus travaille pour les communistesfait du logiciel libre. Il y a beaucoup de boites qui s'enfuient en courant en voyant ça, et vont préférer signer un gros contrat 10 fois plus cher avec la grosse boite du coin, soit hyper spécialisée dans le secteur, soit au contraire pas du tout spécialisée mais avec qui ils ont un contrat annuel de toute façon.[^] # Re: GPL et BSD sont dans un bateau...
Posté par Philippe F (site web personnel) . En réponse au journal Mon évolution vis à vis du copyleft. Évalué à 6.
Le risque est identique sous licence GPL. La GPL te rajoute une protection théorique pour ce cas, mais pas facile à mettre en oeuvre :
Le mec doit distribuer les sources des modifs qu'il a faite, mais il peut se contenter de les livrer uniquement sur demande, et uniquement à ses clients. Ouch, les partisans de la GPL oublient bien souvent cet écueil.
Tu dois donc être soit client de ce mec là, soit être pote avec un de ses clients qui te refile les sources. Il se peut d'ailleurs que ledit logiciel fasse partie d'une suite à plusieurs dizaine de milliers d'euros. Difficile de devenir client juste pour récupérer des modifs.
Quand bien même tu récupères ledit code, il peut être difficile à réintégrer, parcqu'il est mal codé, parce qu'il fait des modifs de fond sur ton logiciel pour accomoder ses besoins qui ne te conviennent pas (cf Android vs Linux), parce qu'il emmène ton logiciel dans une direction que tu ne souhaites pas avoir. Tout le monde n'a pas l'intelligence de faire un plugin ou un module séparé du code principal. Les entreprises qui ont l'attitude que tu décris ont d'ailleurs plutôt l'habitude de considérer le code comme un truc jetable.
Dans la pratique, la protection offerte par la GPL vs BSD est limitée. Si tu prends le cas Android, au final, c'est bien la volonté de Google d'intégrer son code à Linux qui a permis de faire évoluer la situation, et pas le fait que le code soit disponible sous GPL.
[^] # Re: politique ou pragmatique l'éternel débat
Posté par Philippe F (site web personnel) . En réponse au journal Mon évolution vis à vis du copyleft. Évalué à 6.
Ce point central de ton argumentation est complètement non démontré. Par exemple, Apple contribue à llvm et clang bien que ces derniers utilisent une licence de type BSD. Et on peut dire la même chose du serveur web Apache.
RMS lui-même dans plusieurs des conférences que j'ai écoutées, disait que la nature virale de la GPL est un frein majeur à l'adoption de code dans les entreprises, et que pour une entreprise qui passe un soft en GPL à cause de l'utilisation d'un code GPL, il y en a des centaines voire des milliers qui dégagent tout simplement le code.
La perte pour une entreprise qui utilise un projet libre au coeur de ses logiciels, sans pouvoir participer au développement dudit logiciel est telle que au final, l'entreprise contribue. La pression "sociale" marche finalement aussi bien que la pression juridique. Et pour les cas où elle ne marche pas, je dirai qu'elle marche aussi mal que la pression juridique…
[^] # Re: Pareil
Posté par Philippe F (site web personnel) . En réponse au journal Moyens de paiement : j'ai peur de l'avenir. Évalué à 3.
Petite information gratuite: l'antenne ne passe pas là ou la carte est en relief, car le processus mécanique la couperait. Ton schéma n'est bon que pour une carte sans embossage.
Dans le cas de l'embossage, c'est une demi-antenne, qui couvre en gros toute la partie non embossée.
L'antenne est prise en sandwich dans le plastique donc il faut faire une "bonne" incision, aller jusqu'au milieu de la carte.
[^] # Re: Le mot de passe statique
Posté par Philippe F (site web personnel) . En réponse au journal Essais avec une Yubikey. Évalué à 1.
Si tu te colles à quelqu'un dans le métro, tu pourras lire sa carte NFC, mais c'est pas pour autant que tu pourras faire une transaction NFC par la suite. Chaque transaction (au moins pour les normes Visa, Mastercard et American Express) est sécurisée par une authentification avec la carte.
Par contre, c'est vulnérable à une attaque "Man in the Middle" bien que la mise en oeuvre me paraisse difficile : il faut sortir un bidule électronique connecté à la place d'une carte NFC devant le vendeur (qui doit n'y voir que du feu), il faut une liaison sans-fil haut débit avec un gus collé au vrai porteur pour suivre les exigences de timing de la carte sans-contact (le lecteur envoie des données, il faut répondre très vite), et il faut une parfaite synchronisation pour lire les infos de la carte du porteur à ce moment-là.
Il peut certainement passer de 5 cm à quelques dizaines de cm, mais pas à 3-4m. Quoiqu'on peut imaginer un lecteur avec une antenne ultra-directive. Si il met trop de patate pendant longtemps, ta carte va chauffer, voire brûler…
Ca va dépendre des applications mais de fait, dans pas mal de cas que j'ai vu sur le terrain, il est assez facile de demander des informations à la carte pour lui dire qu'elle doit s'authentifier, avant de prouver qu'on est un demandeur légitime.
[^] # Re: Mauvaise interprétation
Posté par Philippe F (site web personnel) . En réponse au journal Systemd dans Debian. Évalué à 4.
Si il y a Ex ! Tellement user-friendly qu'il est d'ailleurs intégré dans vi !
[^] # Re: Partager les sources plutôt que les binaires
Posté par Philippe F (site web personnel) . En réponse au journal Un DCVS pour des documents 'binaires' ?. Évalué à 2.
Je suis tout à fait d'accord que produire une documentation dite professionnelle à l'arrache en accolant 3 outils est tout à fait inadapté.
Faire une vraie doc demande plus d'investissements que ça, bienvenue dans le monde réel !
Ca me fait penser à ces lobbyistes du libres qui se moquent de moi parce que j'utilise PowerPoint et Excel alors que « LibreOffice sait tout faire de la même façon » . Sauf que quand on tombe face à des utilisations autres que extrêmement basiques, LibreOffice n'est plus un clone des outils Microsoft et on tombe sur des incompatibilités, fonctions manquantes [1], rendus incorrects, ou tout simplement une interface beaucoup plus difficile à exploiter.
[1]: j'utilise très fréquemment sous Excel les fonctions NB.SI.ENS et SOMME.SI.ENS qui sont bien pratiques, mais non dispo sous Calc. Et j'ai pas trouvé d'alternatives.
[^] # Re: SparkleShare, Seafile, Dropbox
Posté par Philippe F (site web personnel) . En réponse au journal Un DCVS pour des documents 'binaires' ?. Évalué à 2.
J'ai globalement le même problème dans ma société et j'ai finalement opté pour Dropbox. C'est de loin la solution la plus simple, avec conservation de tout l'historique.
Par contre, les inconvenients de Dropbox:
si tu travailles sur le fichier en mode "brouillon", il est quand même synchronisé à chaque sauvegarde, donc des gens voient des versions non finalisées. A compenser en travaillant au brouillon dans un répertoire à part mais c'est pas pratique.
si tout le monde travaille en même temps sur le fichier, c'est la zone. Sans que ce soit en même temps, il suffit que ce soit beaucoup de gens qui consultent le fichier au même moment par exemple.
j'ai pas mal de cas où dropbox dégage des modifications déjà faites… et c'est la zone pour les retrouver.
Globalement, ca reste le plus simple sans être le plus fiable.
Avant, j'avais testé SVN qui marche pas trop mal, sauf quand tu commences à déplacer des fichiers, renommer, avoir des conflits, ou simplement SVN mal luné qui te nique ses fichiers metadata.