Maintenant que je sais qu'on peut faire une voiture complète et plus performante en OpenSource ( http://www.wikispeed.com/ ), faire un projet comme une caméra me semble … à la portée d'une équipe motivée.
Je me suis gouré sur le plafond, c'est 2336 € (ce qui est quand même confortable pour une demi-part !).
Et pour citer précisément le mode de calcul :
1.2 CALCUL DU PLAFONNEMENT
Le mécanisme du plafonnement consiste à comparer deux termes :
1er terme : impôt calculé en fonction du quotient familial réel de l’intéressé sans plafonnement.
2ème terme : impôt calculé sur la base d’un quotient familial de deux parts si vous êtes mariés ou liés par un pacs ou d’une part si vous êtes veuf(ve), célibataire, divorcé(e) ou séparé(e). La somme ainsi obtenue est ensuite diminuée du montant du plafond correspondant à l’ensemble des demi-parts ou quart de parts additionnelles selon votre situation de famille.
Si le premier terme est inférieur au second, le plafonnement est applicable et l’impôt à retenir est celui correspondant au second terme.
Si le premier terme est supérieur au second, le plafonnement n’est pas applicable et le montant de l’impôt à retenir est celui correspondant au premier terme (voir exemple ci-après)
Pour ce qui est de la part, rassures-toi, les génies qui conçoivent l'usine à double-retro-pédalage à combustion mixte fiscale notre système fiscal y ont pensé:
la réduction que tu peux obtenir avec une demi-part supplémentaire est majoré à 1500 € si je me souviens bien.
Donc soit tranquille, les riches ne peuvent gagner que 1500 € de réduction d'impôt par nouvel enfant.
C'est un des 2600 seuils qui s'appliquent dans nos impôts.
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).
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 ?
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.
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):
Mon terminal, c'est Console. Un programme plus maintenu mais qui marche hyper bien.
Mon shell, c'est cygwin bash.
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.
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.
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
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.
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.
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.
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…
# Ca roule !
Posté par Philippe F (site web personnel) . En réponse à la dépêche Apertus va créer une caméra de cinéma numérique entièrement nouvelle. Évalué à 4.
Maintenant que je sais qu'on peut faire une voiture complète et plus performante en OpenSource ( http://www.wikispeed.com/ ), faire un projet comme une caméra me semble … à la portée d'une équipe motivée.
Bon courage !
[^] # Re: Pas la même conclusion
Posté par Philippe F (site web personnel) . En réponse au journal [Humeur] Sondages et éditocrates, une histoire d’amour. Évalué à 3.
Par exemple:
http://vosdroits.service-public.fr/F2702.xhtml
Je me suis gouré sur le plafond, c'est 2336 € (ce qui est quand même confortable pour une demi-part !).
Et pour citer précisément le mode de calcul :
[^] # Re: Pas la même conclusion
Posté par Philippe F (site web personnel) . En réponse au journal [Humeur] Sondages et éditocrates, une histoire d’amour. Évalué à 2.
Pour ce qui est de la part, rassures-toi, les génies qui conçoivent
l'usine à double-retro-pédalage à combustion mixte fiscalenotre système fiscal y ont pensé:la réduction que tu peux obtenir avec une demi-part supplémentaire est majoré à 1500 € si je me souviens bien.
Donc soit tranquille, les riches ne peuvent gagner que 1500 € de réduction d'impôt par nouvel enfant.
C'est un des 2600 seuils qui s'appliquent dans nos impôts.
[^] # Re: Assez d'accord, mais...
Posté par Philippe F (site web personnel) . En réponse au journal [Humeur] Sondages et éditocrates, une histoire d’amour. Évalué à 3.
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).
[^] # Re: Weboob
Posté par Philippe F (site web personnel) . En réponse au journal [HS] Hacker le problème du logement. Évalué à 6.
Flatboob ? Trop fort, je suis pêté de rire !
[^] # Re: Question con
Posté par Philippe F (site web personnel) . En réponse au journal Les avantages du paiement sans contact.. Évalué à 5.
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".
[^] # Re: Question con
Posté par Philippe F (site web personnel) . En réponse au journal Les avantages du paiement sans contact.. Évalué à 2.
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.
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 2.
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…
[^] # Re: kivy
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 4.
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…
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 1.
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).
[^] # Re: mono?
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 3.
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 ?
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à -1.
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 ?
[^] # Re: mono?
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 2.
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 ?
[^] # Re: Des conseils pour avoir un environnement de packaging py2exe + pyside sous MS Windows ?
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 3.
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à…
[^] # Re: mono?
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 5.
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.
[^] # Re: Oh que je connais !
Posté par Philippe F (site web personnel) . En réponse au message MS Windows + MinGW/MSYS ou Cygwin + accès à mes outils GNU dans mon term + Python + PySide + py2exe. Évalué à 3.
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.
# Oh que je connais !
Posté par Philippe F (site web personnel) . En réponse au message MS Windows + MinGW/MSYS ou Cygwin + accès à mes outils GNU dans mon term + Python + PySide + py2exe. Évalué à 3.
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):
Mon terminal, c'est Console. Un programme plus maintenu mais qui marche hyper bien.
Mon shell, c'est cygwin bash.
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.
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.
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
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.
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.
[^] # Re: Sorti de Qt, point de salut ?
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 5.
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.
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 10.
Euh, perso, je juge pas le niveau d'intuitivité d'un OS à la longueur des URL pour accéder à sa documentation. Toi si ?
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 7.
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.
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.
[^] # Re: kivy
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 6.
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.
[^] # Re: Facile!
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 2.
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.
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 2.
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 ?
[^] # Re: Contributeurs académiques
Posté par Philippe F (site web personnel) . En réponse au journal Microsoft, un sacré contributeur au noyau Linux !. Évalué à 2.
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.
# Les UI sur mobile ?
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 7.
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…