Philippe F a écrit 2214 commentaires

Interventionnisme accru de l'état sur la gestion des sociétés en faillites pour forcer la main des repreneurs.

Tentative de taxation d'activités hors du territoire français (en plus de ne pas être libéral, l'état français aimerait bien faire comme s'il était souverain dans les autres pays).

Flatboob ? Trop fort, je suis pêté de rire !

Attention, je parle des cartes de paiement sans contact, pas du NFC. Il faut voir que c'est une technologie qui a été développée aux US où les attentes des utilisateurs en terme de sécurité ne sont pas les mêmes.

Aux US, les paiement se font principalement par carte magnétique, hyper facile à frauder. Le passage à une carte sans-contact apporte donc un gain significatif en sécurité car d'une part plus difficile à contrefaire, et d'autre part, sécurisée.

Normalement, ladite carte génère un cryptogramme qui doit être vérifié en ligne par la banque avant d’accepter le paiement.

Le paiement est sans code PIN, pour des montants de moins de 20 $. Et les américains adorent le côté très rapide et sans signature. L'absence de code PIN ne les choque pas du tout.

Si jamais le terminal n'est pas en ligne, la sécurité est la même que celle d'une carte magnétique. Mais aux US, la majorité des terminaux sont en ligne, pour lutter justement contre la fraude à la carte magnétique.

Lors de l'export de la téchno vers l'Europe, ils sont passés à l'EMV sans contact, c'est à dire les normes de paiements sécurisées qu'on a en Europe, avec de l'offline, des seuls de vérifications, etc etc en gardant la capacité sans-contact. Voire code PIN aussi. Pour l’instant, c'est pas un grand succès mais des enseignes comme MacDo ou Carrefour y réfléchissent pour une carte "privée".

L'antenne est dans la couverture, donc c'est normal que ça marche parfaitement fermé ou ouvert.

Les infos dites sensibles ne sont accessibles que via la génération d'une clé de session avec le passeport, clé de session qui dépend des informations écrites sur ton passeport (les caractères bizarres en bas de la page, ça s'appelle la MRZ). La logique étant que seul quelqu'un qui a physiquement ton passeport en main est autoriser à lire les informations sensibles. Il ne me semble pas qu'elles soient plus protégées que ça.

Les références aux certificats dont parle boarf concernent l'authentification du passeport lui-même. Donc, sans les certificats des différents pays, on peut pas prouver que le passeport est authentique mais on peut le lire.

Toujours sur cette notion de cohérence Look'N Feel, Zenitram lève un sujet intéressant plus bas.

Pour une application Gtk qui tourne sous Windows, l'utilisateur aguerri de la même application Gtk sous Gnome s'attendra à avoir un sélecteur de fichier Gtk même sous Windows (cohérence on vous dit !) mais un utilisateur de Windows aguerri s'attendra à avoir le sélecteur de fichier de Windows. J'ai pas d'opinion tranché sur ce qui serait plus cohérent…

C'est le lot de tout projet en cours de maturation. Honnêtement, rien que le fait qu'il y ai trois pages de documentation dédié rien qu'à ce sujet est déjà en pas énorme par rapport à beaucoup d'autres toolkits, libres ou pas libres. J'ai donc un bon pressentiment sur le sujet, à savoir que les développeurs s'en préoccupent…

La raison de pourquoi l'application n'a pas le même Look'N Feel importe peu. Je citais un cas assez légitime d'un utilisateur qui a de bonnes pratiques, qui utilise des produits Microsoft mais qui n'a pas mis à jour son OS. Il se retrouve avec un bureau hétérogène.

Le fait est que sur le bureau d'un utilisateur aujourd'hui, tu auras des applications au Look'N Feel hétérogène. Si je prends mon cas personnel, sur mon Windows XP, j'ai du Microsoft, quelques produits Apple comme iTunes qui ne ressemblent pas au reste, j'ai un ADSL Tv qui ne ressemble pas du tout au reste de mes applications. Si je creuse, j'en trouverai plein plein d'autres.

L'idéal du bureau parfaitement intégré, ou absolument toutes les applications ont exactement le même comportement n'existe pas. Et même pas un peu, vraiment pas du tout.

A moins de prendre un ordinateur+OS 100% verrouillé, où toute installation d'application est interdite ou soumise à une validation intégriste de son interface, on y arrivera jamais. Et si jamais un tel ordinateur existait, il serait ô combien décrié par les partisans du logiciel libre (comme l'est à l'heure actuelle l'Apple Store). Et je pense que tu ferai partie des gens qui décrient le fait que cet ordinateur est inaccessibles aux logiciels libres, non ?

Je suis pas pour l'hétérogénéité des Look'N Feel à tout va (j'ai jamais pu supporter WinAmp), mais puisqu'elle existe déjà, je suis prêt à accepter des compromis en terme de cohérence de Look'N Feel. C'est à dire que si je développe une application, je ferai ce que je peux, dans la mesure du raisonnable, pour qu'elle s'intègre bien à l'OS. J'aime bien Qt pour ça en particulier, parce que je trouve leur compromis et leurs efforts de cohérence raisonnables et que je peux m'appuyer dessus sans trop souffrir.

Je suis sur que des utilisateurs aguerris de Mac trouvent les applications Qt hyper bizarre sous MacOs, mais ceux qui refusent d'utiliser une application (par ailleurs utiles) pour cette unique raison feront à mon avis partie de ceux que je serai content de ne pas avoir comme utilisateurs…

Développer X versions d'une application pour X systèmes d'exploitations, uniquement pour bénéficier d'un Look'N Feel parfaitement cohérent sur chacun d'eux me paraît un travail inutile. C'est déjà assez dur de faire marcher correctement un seul logiciel.

Rendre une application multi-plateforme plus cohérente à la marge pour un système d'exploitation donné me semble raisonnable. Ça commence en général par l'installation qui doit suivre les pratiques de l'OS, c'est à dire qu'on livre pas un .tgz ou .zip sous Windows, ( et encore moins des sources à compiler).

Je te remercie, c'était vraiment le genre de commentaires que j'attendais.

Donc Qt, exit pour le mobile.

Les trucs genre Kivy, Java, Flash, tu dis que les perfs sont à la ramasse.

Pour Mono, tu peux détailler l'aspect IHM ? Si je comprends ce que tu dis, il n'y a pas d'IHM portable mais ils fournissent de quoi faire une IHM native dans chaque cible ?

Et toi qui a l'air de t'y connaitre un peu, tu recommandes quoi ?

Je fais remarquer que des produits développés par Microsoft s'intègrent très mal dans un environnement lui aussi développé par Microsoft. Donc Microsoft est en tout cas pas super bien placé pour jouer les intégristes des règles UI.

Je comprend rien à ton commentaire. Tu veux dire quoi exactement ?

Vue les tourments de Blackberry, ce serait plutôt parier sur le passé que de développer pour eux. Mais oui quid de ces deux OS en effet ?

Pourquoi tu utilises PySide plutôt que PyQt ? Et pourquoi tu as besoin de compiler quoi que ce soit puisque tu fais du Python ? Tu m'interpelles là…

J'ai bien évidemment un a priori hyper favorable pour Qt, et ceux qui lisent les trolls sur Gnome et KDE depuis quelques années sur linuxfr doivent le savoir. Après, il est toujours bon de vérifier ses a priori, surtout sur un domaine où j'y connais queud comme le développement mobile.

J'oubliais le lien magique pour trouver les softs que j'utilise sous Windows:
http://www.freehackers.org/Surviving_on_Windows

Il reste un problème que je n'ai pas résolu: impossible d'avoir un terminal UTF8 avec Console. Même en bidouillant les polices Windows, c'est pas possible.

Je reconnais bien mon parcours. Après quelques années où je ne suis plus que sous Windows, j'ai opté pour les choix suivants (qui ne sont pas universels mais que marchent pour moi):

1. Mon terminal, c'est Console. Un programme plus maintenu mais qui marche hyper bien.

2. Mon shell, c'est cygwin bash.

3. Je privilégie tout ce qui existe en natif vis à vis des versions cygwin. Ca veut dire que j'ai un gcc msys, un mercurial, un python, un vim qui sont des installations natives sous Windows. J'ai volontairement désinstallé le gcc et le python de cygwin pour être sur de ne jamais l'utiliser par erreur.

4. J'ai un répertoire d:/program où je colle tous mes programmes Windows pseudo-unix et un répertoire d:/program/utils qui est dans mon PATH.

5. Dans mon d:/program/utils, j'ai des lanceurs en .bat et .sh pour les programmes que j'utilise le plus souvent. Quelques programmes comme mercurial ont droit de cité dans mon PATH. Et quelques alias pour appeler automatiquement mes .sh

6. Certains trucs sont tout simplement incompatible avec Cygwin. Typiquement, si je dois compiler un projet Qt sous CMake, je lance un cmd avant de faire quoi que ce soit. Sinon, CMake se goure.

7. J'ai un gvim.sh qui prend des chemins de fichiers au format cygwin et les convertit en format windows pour gvim. Ca me permet de faire des grep -r . "toto" -l | xargs gvim.sh

Donc globalement une grosse usine à gaz, sauf que avec le temps, ça marche très bien.

Quant à PySide, j'ai jamais essayé. Je préfère rester fidèle à Phil Thompson qui fait un travail irréprochable sur PyQt depuis aussi longtemps que Qt 1.4 existe si je me souviens bien.

Le déploiement Qt sous Windows, je l'ai toujours vécu comme trivial. Le code travaillant avec Qt est réellement portable, donc à part quelques petites windowseries au niveau du compilateur (qui ont tendance à disparaître avec le temps), tu génères ton appli sous Windows en moins d'une journée même si tu n'y connais rien.

Et, à partir de ton .exe, tu te bricoles vite-fait un petit installeur à coup de InnoSetup (je recommande) ou NSIS (pour les malades mentaux). Il y a même Wix, projet open source de Microsoft pour générer des .msi tous beaux tous propres (j'ai jamais testé. Ça prend aussi moins d'une journée, voire moins d'une heure. Bien sur, tu embarques toutes les DLL de Qt que tu utilises dans ton installeur, pour éviter toute source de conflit à la con. L'installeur les trouve en général tout seul, et elles se nomment toutes QtQuelque chose.

Pour définir l'icone de ton application, c'est pas comme sous x11, il faut fournir un .ico que n'importe quel logiciel de dessin te génerera en 3 secondes à partir d'un png. Le .ico doit être embarqué dans ton .exe mais c'est très facile à mettre en place.

Et voilà, tu as un package installable sur toutes les versions de Windows. Après, il peut y avoir des subtilités 32 bits vs 64 bits, ou bien l’application doit demander des droits Windows pour s'exécuter, ou bien il faut lire 5 minutes de doc pour comprendre où stocker tes fichiers utilisateurs. Mais globalement, ça marche bien et de façon fiable.

Idem pour Python + PyQt + py2exe ou pyinstaller.

Ah si, si tu veux linker Qt en static sous Windows, il me semble que ce n'est plus possible.

Disclaimer: c'est mon expérience, j'ai jamais écrit de programmes utilisés par des milliers de gens. Mais justement, pour un développeur dilettante, le temps économisé en passant par Qt est précieux.

Pour Gtk, j'ai jamais expérimenté moi-même mais j'ai ouie dire beaucoup de mal de gens qui avaient fait une application Gtk et envisageaient une version Windows. J'ai vu passer d'ailleurs des applications Gtk dont la version Windows n'est plus développée car trop difficile à maintenir, ou bien qui gardent sciemment une ancienne version de Gtk pour pouvoir facilement garder la portabilité.

Et en tant qu'utilisateur, j'ai eu quelques conflits d'applications Windows Gtk qui essayaient plus ou moins de partager leur installation de Gtk donc on va dire que je serre les fesses quand je vois du Gtk sous Windows.

Je suis content de savoir que Gtk reprend la route de Windows. Vu la réputation qu'il se sont fait, il va y avoir du travail. Et surtout, il va falloir de l’énergie pour maintenir ce port. Si je me souviens bien, un des problèmes de Gtk sous Winsows, c'est le nombre colossal de dépendance de Gtk, qui complique singulièrement la tâche. Qt de par sa nature plus monolitique est moins embêtée.

Pour WxWidget, tu confirmes ce que j'ai entendu dire. A part les anciens programmeurs MFC, j'ai l'impression qu'il n'y a pas beaucoup de gens pour dire du bien de WxWidgets.

Euh, perso, je juge pas le niveau d'intuitivité d'un OS à la longueur des URL pour accéder à sa documentation. Toi si ?

Ah, les boutons OK et Cancel inversés entre Gnome et KDE, ça faisait bien 5 ans qu'on en avait pas parlé !

Autant sur le fait de cliquer sur le bas de la barre de défilement, ou ne pas supporter le F2 pour renommer des fichiers et F5 pour rafraîchir la fenêtre, je comprends. Autant, le Ok / Cancel, je trouve ça ridicule.

Tout ça pour dire qu'il y a des règles d'interfaces graphique pour chaque OS

Règles d'interfaces qui sont copieusement ignorés par un nombre incalculable d'applications, en particulier des applications à très gros succès, ou encore des applications qui sont pourtant promues par les fabricants de l'OS.

Il n'y a qu'à prendre les versions récentes de Office, qui jurent complètement avec les autres applications développées sous Windows XP grâce à la nouvelle bande de raccourcis qui renvoie aux oubliettes le concept de menu.

Donc les règles d'UI, c'est pas ça qui va m'empêcher de choisir un toolkit générique plutôt qu'un toolkit natif. Notamment parce que si un utilisateur veut utiliser mon application, c'est pas la position des boutons Cancel / Ok qui l'empêchera de le faire, ou les autres fioritures liées à l'intégration profonde dans un OS.

En ce qui me concerne, entre supporter un OS avec un look'n feel et comportement raisonnable grâce à un toolkit générique, et ne pas supporter l'OS en question parce qu'il faudrait recoder l'application dans le toolkit natif pour ce faire, mon choix est vite fait.

Honnêtement, des intégriste de l'UI, il y en a. Ceux qui repèrent que l'application est en fait Qt native et pas MacOs à cause de l'espacement entre les menu n'est pas bon et quand on fait un racourci clavier précis, ca ne fait pas ce qu'il faut. Ok, ils ont le droit de protester. Mais je pense d'une part que cela ne constitue qu'une part mineure de la base d'utilisateurs, d'autre part que la plupart des problèmes soulevés peuvent être adressés avec le temps et l'expérience, si l'application a du succès.

Je doute d'arriver un jour où la seule évolution qui reste à faire pour une application soit de permuter les boutons Ok / Cancel, et que toutes les autres demandes et bugs aient été satisfaits…

Pour reprendre une maxime de Python: Practicality beats Purity.

J'ai lu un peu la doc en diagonal, ça me plait bien. Ca réutilise un nombre incalculable de briques python qui marchent bien depuis des années (PyGame, PIL, PyCairo, …), et package tout ça dans un framework orienté python.

Contrairement donc à Qt qui étant basé sur du C++ reste très orienté C++. PyQt, est très facile à utiliser, très prédictible mais on sent l'héritage d'un langage à classes rigides.

J'aime bien. Surtout qu'il y a une page dédiée au packaging, tâche ô combien essentielle et ingrate.

Le site web fait très pro, et dans l'esprit, ça me fait penser à django: utiliser vraiment la puissance de Python et pas juste un ou deux wrappers sur une lib existante.

Bon, sinon, c'est de la prog évenementielle classique (pour gérer du multi-touch, je pense qu'on y échappe pas) mais j'imagine que python permet de faire ça avec un peu plus d'élégance que feu Visual Basic ou Access.

Tu peux préciser la portabilité de Gambit Scheme ? Windows, MacOs, Android, iOs ? Des exemples d'applications graphiques qui l'utilisent ?

Pour Skype, même si le résultat n'est pas là, on parle bien de la contrainte que j'ai évoqué: un logiciel qui doit marcher chez tout le monde avec le minimum de développement spécifique.

Pour moi, le thème natif n'est pas fondamental.

D'une part, il existe des toolkits qui adaptent leur UI à la plate-forme (euh, j'ai parlé de Qt ?), d'autre part, même si le look n'est pas natif et que cela constitue une gène pour l'utilisateur, je trouve que c'est préférable à ne pas avoir de logiciel du tout sur cette plate-forme. Bon, c'est sur que un look Windows 3.0 dans un MacOs ou un Windows moderne, ça choque réellement. Mais si le soft est bien fait, l'utilisateur s'adaptera. Pleins de logiciels à succès ont des looks non natifs (iTune sous Windows, WinAmp, …)

Par contre, il est vrai que probablement un soft doit avoir deux versions. Une pour mobile et une pour desktop, car les interactions avec l'utilisateur ne sont pas pilotées pareille.

Quant à la solution de redévelopper un thème par OS visé, on oublie: d'une part, je ne suis pas graphiste, d'autre part, c'est justement le boulot du toolkit de gérer cela.

Tu n'as pas répondu très précisément: EFL, ça marche sous quelles plate-formes ? C'est stable ? C'est du C si je me souviens bien ? Est-ce que c'est suffisamment complet en terme d'abstraction de la plate-forme ?

Linux est quand même un projet industriel. C'est normal que les chercheurs aient peu de participation car la recherche se mélange mal avec les contraintes d'un projet industriel opérationnel comme Linux.

Faire de la recherche, c'est expérimenter, faire des trucs qui marchent pas et voir ce que ça donne, etc etc. Tout ça va pas de paire avec un noyau hyper stable dans toute les conditions possibles.

Tiens, j'en profite pour une autre question. Sur les desktop, quand on fait une appli, on fait en général des menus, des boutons, et checkbox, des listes, etc. Pour tout ça, on a des Widgets qui arrivent tout prêt à l'usage.

Comment ça se passe sur mobile ? J'ai cru comprendre qu'il faut faire soi-même ses boutons et tout parce que c'est à la mode. Pour un développeur comme moi qui est une b*te en graphisme, c'est l'horreur en fait…

On parle pas de la même chose.

Tu te places du point de vue de l'administrateur système qui se pose la question de déployer un programme sur ses postes. Programme qui apparemment répondrait déjà à pas mal de critère de déploiement automatisé.

Il me semble que l'auteur initial pose un problème différent, à savoir, du point de vue développeur, quelle est la bonne approche pour distribuer son programme face à la diversité des plate-formes. Le but étant de garder un programme simple à déployer et simple à mettre à jour pour les utilisateurs.

Donc je maintiens ma réponse, sous Windows, il est assez facile pour le développeur de générer un installeur, qui aura des propriétés d'installation automatisée (entre autres) et qui supportera un panel très large de versions de Windows.

Sous Linux, le problème est plus complexe. Tu as la solution de fainéant de fournir un .tgz avec un configure (ou un make install ou encore un python setup.py install)mais c'est loin d'être user-friendly.

Ensuite, solution 2, tu fournis un package. Le vrai truc de distrib. Sauf que qui dit package dit :
- choix dans le format: rpm ou deb ? Et ArchLinux ils vont se brosser ? Et gentoo ?
- choix dans la version de la distribution: pour une distribution donnée, il y a en général plusieurs versions utilisées par les utilisateurs à un moment donné. Laquelle choisir ?

Donc pour la problématique "comment faire un programme qui est facile à installer sur toutes les versions des OS que je vise" se résoud avec un installeur (et un peu d'huile de coude) sous Windows, et se résoud avec une armée entière de packageur sous Linux. Armée que peu de gens possèdent.

Et encore, je parle pas des bugs "sous Mageia 8.3.7 , ton soft plante en plein milieu d'un truc" qui te demandent donc d'avoir une Mageia 8.3.7 pour tester tout ça. Ouch…

Pour déployer massivement une application Qt sous Linux c'est facile. On publie un paquet sur un dépôt perso, et roulez. Mais quelqu'un a des retour d'expérience de déploiement massif d'application sur des postes Windows ?

Euh, je suis surpris que Zenitram n'aie pas déjà sauté sur l'occasion mais je vais le faire à sa place.

A ma connaissance, c'est exactement l'inverse: déployer une application sur Windows est facile, il suffit de faire un installeur et il y a pas mal d'outil pour en faire des biens. Il est aussi assez facile d'embarquer toutes les libs dont tu as besoin.

Sous linux au contraire, tu te trouves confronté à plein de questions à la con:
- quel format d'empaquetage utilisé ?
- comment m'assurer que toutes les libs dont j'ai besoin sont présentes dans la version où j'en ai besoin, pour le 86 distribitions Linux et 23 versions de chacune de ces distributions
- pour sauvegarder les données de l'utilisateur, il faut bidouiller pour créer un répertoire dans le HOME de l'utilisateur mais tu es obligé de développer vachement de code "à la con" pour gérer plein de cas particuliers.

Au final, tu passes en temps monstrueux en support pour quelques barbus.

Et maintenant, quid de Mac OS ? Je me pose la même question, facilité de déploiement…

Tu as raison dans le fait qu'ils n'ont pas à se justifier, mais je trouve ce choix d'une part moins lisible par les utilisateurs que le choix classique, et en contradiction avec la politique de Gnome qui vise à présenter quelque chose de simple aux utilisateurs.

Pour le grand public, je ne partage pas ton avis. Beaucoup de gens cherchent "à y comprendre quelque chose" et ce type de nommage de version n'aide pas. Et beaucoup de projets comme Gnome se préoccupent de la façon dont une nouvelle version est perçue et communiquée au grand public.

Après, c'est sur que ça empêche personne de dormir, mais ça me titille à chaque fois que je le vois.

Quand on voit que même mplayer s'est tourné vaguement vers une numérotation classique…