Bonjour à tous,
Suite au journal Bref, j'arrête le développement web, auquel je souscris totalement, j'aurai aimé avoir des retours d'expérience sur justement comment faire un soft natif, qui fonctionne sur le maximum de plateforme avec un minimum de travail.
Pour moi maximum de plate-forme, ça se range un deux catégories:
1. Destkop: Windows, Linux, MacOs. BSD pour les plus aventureux.
2. Mobile: iOS, Android pour les majeurs. MeeGo et autres pour les plus aventureux.
Pour bien préciser le contexte, on se place dans le cadre d'un développeur, qui développe un programme relativement élaboré, avec une interface graphique notamment, éventuellement quelques dépendances. On s'intéresse pas au langage de programmation, on prendra celui qui répond le mieux à la contrainte.
En ce qui me concerne, j'ai l'expérience du point 1. J'ai toujours fais ça avec Qt, initialement avec du C++ et maintenant avec du PyQt. J'ai quelques programmes en Python et Qt qui sont largement portable sur n'importe quel desktop, et qui sont faciles à installer. Qt est hyper fonctionnel, juste un peu gros une fois packagé mais aujourd'hui, plus personne ne râle devant un soft qui fait 5 Mo à télécharger.
Je sais que Gtk, bien que maintes fois présenté comme un concurrent de Qt dans ce domaine est une horreur à gérer sous Windows. WxWidget a une réputation mitigée: globalement, ça marche bien sur toutes les plate-formes desktop mais il reste des bugs plate-forme spécifique qui sont difficiles à éradiquer.
J'ai jamais touché un développement mobile, donc je connais pas du tout les contraintes spécifiques, voire l'actualité des derniers portages.
Je suis curieux de connaître les autres solutions et vos expériences.
Quelques exemples de softs qui gèrent cette situation: DropBox, Skype, Chrome, Firefox.
Je réserve un autre journal pour la question qui tuera : quid de l'installation facile et la mise à jour facile (voire transparente) de ces softs.
# Les UI sur mobile ?
Posté par Philippe F (site web personnel) . É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…
[^] # Re: Les UI sur mobile ?
Posté par LeMagicien Garcimore . Évalué à 6.
Sur Android il y a des classes de base bien fournies: http://developer.android.com/reference/android/widget/package-summary.html
Et comme beaucoup de toolkit graphique, tu peux les customiser en étendant les classes de bases. J'ai surtout l'impression qu'il y a beaucoup de cowboys chez les dev d'application android, et qu'ils s'amusent a redéfinir le widget pour le bling bling… J'imagine que sur iOS c'est la même chose…
[^] # Re: Les UI sur mobile ?
Posté par kertiam . Évalué à 1.
L'essentiel du widget peut-être personnalisé simplement, mais sans aller jusqu'à étendre la classe. L'essentiel peut être fait dans la description (XML) de l'interface (layout).
Il est très facile par exemple de changer le curseur (thumb) d'une barre de progression (ProgressBar).
Sans chercher à faire le cowboy, cette personnalisation simplifiée permet par exemple d'harmoniser les widgets avec la nature de l'application. Le gris est passe partout mais ce n'est juste qu'une base.
Accessoirement, même si le thème HOLO est vraiment bien fichu il reste des parties non rénovées depuis les premiers thèmes, que l'ont peut corriger manuellement, sans coder.
Le vestige le plus moche, et de loin, est le feedback orangé (pas le Orange HOLO …) du onTouch d'une listview.
[^] # Re: Les UI sur mobile ?
Posté par theblatte . Évalué à 2.
Tu as du mal comprendre, ou bien tu t'es fait enduire d'erreur. Il y a tout ce qu'il faut pour écrire des UI sans jamais ouvrir Gimp. Dans Android par exemple, tu décris à quoi doit ressembler ton interface dans un bousin XML, puis tu y branches des call-backs.
# kivy
Posté par qpad . Évalué à 10.
Salut,
Je m'amuse avec kivy.
C'est une librairie graphique en python orientée mobile. Mais c'est censé marcher sur tous les os cités (quoique pour meego, j'ai un doute).
Si j'ai bien compris le rendu se fait via opengl uniquement, donc j'imagine que ça pose pbm quand ce dernier est mal supporté.
En tout cas pour ceux qui apprécient python c'est tres facile, tres flexible. Le système propose aussi en complément un langage de description d'interface (similaire à QML dans Qt) très pratique.
[^] # Re: kivy
Posté par Philippe F (site web personnel) . É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: kivy
Posté par tito (site web personnel) . Évalué à 5.
Je rajoute aussi que l'on travaille beaucoup à être performant: l'utilisation de Cython dans les couches bases permet d'avoir de bonnes performances, mais faut pas demander la lune non plus (comme tourner sur un motolora droid 1). Je dois également poster une vidéo qui montre les performances sur Android et iOS (et bizarrement, c'est aussi bien plus fluide sur iOS).
Une petite note, je serais présent à l'EuroPython pour présenter Kivy plus en détails, avec de nombreux retours d'expériences.
[^] # Re: kivy
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ca a l'air vraiment bien Kivy, mais le packaging des applications a l'air complexe : http://kivy.org/docs/guide/packaging.html
A quand un kivy package all qui génère des binaires pour chaque plateforme? :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: kivy
Posté par Philippe F (site web personnel) . É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: kivy
Posté par tito (site web personnel) . Évalué à 3.
C'est dans nos têtes :) C'est principalement un manque de ressources qui fait que l'on ne puisse tout faire. Mais quelque soit l'outil qui te simplifie la tâche, il reste néanmoins des étapes qui ne peuvent être automatisés: la signature de paquet par exemple: ios requière absolument Xcode, et android/ios requière ta clé privée.
Quoi-que l'on fasse comme système, il restera toujours une part à faire manuellement.
Pour android, j'avais monté un système qui permet d'envoyer son appli, et de récupérer un APK (debug ou en mode release non-signé): http://android.kivy.org/. Le système est en stand-by, et le code source dispo sur https://github.com/kivy/p4a-cloud
Ca demande aussi d'uniformiser les spécificités de chaque plateformes, on y travaille :)
[^] # Re: kivy
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ca peut être pris en charge par un magicien (comment traduire wizard?) qui pose les n questions nécessaires à chaque plateforme.
En tout cas pour moi le packaging est vraiment une tâche ingrate sur laquelle je ne veux pas passer de temps, c'est par exemple ce qui fait que je choisis toujours un langage interprété et pas compilé pour mes projets persos.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: kivy
Posté par CrEv (site web personnel) . Évalué à 2.
assistant
# Les toolkits portables
Posté par cedric . Évalué à 7.
Le souci quand on fait une application portable, c'est qu'elle va sensiblement avoir le meme look partout. A la rigueur si on prend un toolkit un peu malin, on aura automatiquement une ergonomie pour touchscreen sur tablet et smartphone et une ergonomie souris sur desktop. Mais globalement, ca sera toujours la meme application. Avec les meme boutons, les meme listes, … Et ca, ca veut dire que l'utilisateur se sentira souvent pas "chez lui". Car il s'attend a ce qu'une application soit coherente avec le systeme sur lequel il l'utilise, pas a ce qu'elle soit identique a ce qu'elle est sur un autre device. Cela complique pas mal les choses.
Avoir les dependences portables et n'avoir a refaire que l'interface pour qu'elle soit bien integre dans le systeme me semble deja plus sympatique pour l'utilisateur (moins pour le dev). Mettre le maximum de la logique de l'application dans une bibliotheque separe facilement portable et utilisable sur tous les systemes me semblent etre l'approche technique la plus adapte pour avoir un resultat de qualite.
Apres si tu veux d'autre exemple de toolkit portable, je te conseille les EFL, en plus tu auras la joie d'apprecier un tookit qui adapte son ergonomie au type de pointeur. Et on peut tenter de compenser le fait que ce ne soit pas le toolkit de la plateforme avec un theme adapte. Meme si ce n'est pas vraiment la solution que je preconiserais…
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . É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: Les toolkits portables
Posté par zebra3 . Évalué à 9.
Il n'y a pas qu'une histoire de look, il faut aussi que les composants se comportent de la même manière que le reste de l'environnement.
Une exemple typique : sous GTK, un clic droit sur le bouton bas d'une barre de défilement descend cette barre tout en bas.
Qt n'émule pas ce genre de truc, et c'est pour ça que même si le look est bien retranscrit, une appli Qt jure encore sous GNOME.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les toolkits portables
Posté par Niniryoku . Évalué à 7. Dernière modification le 04 avril 2012 à 14:16.
Exactement. J'attendais que quelqu'un en parle. Mais être intégré à l'OS ne veux pas dire seulement « il faut que ça ressemble au reste », il faut aussi que ça se comporte comme le reste.
Typiquement, sous KDE et Gnome, les boutons « OK » et « Cancel », sont inversé (je sais plus lequel est où).
Tout ça pour dire qu'il y a des règles d'interfaces graphique pour chaque OS :
Knowing the syntax of Java does not make someone a software engineer.
[^] # Re: Les toolkits portables
Posté par zebra3 . Évalué à -9.
D'ailleurs, c'est marrant de constater que c'est l'OS prétendu le plus intuitif qui donne le lien le plus long et le moins lisible vers ses règles d'interfaces.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . É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 claudex . Évalué à 7.
Pourtant, c'est un moyen fiable et objectif, ça permettrait de mettre tout le monde d'accord.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Les toolkits portables
Posté par CrEv (site web personnel) . Évalué à 0. Dernière modification le 27 juillet 2024 à 11:42.
C'est vrai ça https://developer.apple.com/design/human-interface-guidelines/designing-for-macos
Qui gagne maintenant ? ;-)
[^] # Re: Les toolkits portables
Posté par feth . Évalué à 7.
Faudrait censurer les urls obfusquées dans les commentaires (avec une liste noire, ou les désobfusquer (plus compliqué). Qu'en pensez-vous ?
[^] # Re: Les toolkits portables
Posté par CrEv (site web personnel) . Évalué à 2.
Pourquoi ? ça permet des choses marrantes, genre sur les 24 ayant cliqué, 13 sont sous windows par exemple :-)
Après, oui, ça serait pas mal de pouvoir les désobfusquer. Mais bon, ton histoire de sanssure ou liste noire je vois pas trop l'intérêt, t'aime pas les url courtes, ok mais de là à sanssurer…
[^] # Re: Les toolkits portables
Posté par feth . Évalué à 3.
Mon commentaire n'était pas sérieux :-)
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . É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: Les toolkits portables
Posté par barmic . Évalué à 6.
Ton commentaire et certains autres sont intéressants. Alors qu'ici même beaucoup passent leur temps à crêper le chignon pour savoir la quelle de tel ou tel solution est la plus intuitive ou la plus KISS. Dès que l'on parle de développement ce n'est plus notre affaire et ça a soudainement bien moins d'importance.
Et les dernières versions de konqueror s'intègrent très mal à KDE 3.5. C'est un argument vraiment bidon. Pourquoi ne pas parler de son intégration dans Windows 2 000 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . É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: Les toolkits portables
Posté par CrEv (site web personnel) . Évalué à 5.
Ca veut dire que parler de l'intégration d'un soft sorti en 2007 dans un OS sorti en 2001 c'est plutôt limite de la mauvaise fois. Que c'est pareil dans le libre d'ailleurs.
Et surtout, si on lit ce que tu dis "des produits développés par Microsoft s'intègrent très mal dans un environnement lui aussi développé par Microsoft" alors dans ce cas il n'y a que deux solutions :
[^] # Re: Les toolkits portables
Posté par barmic . Évalué à 2.
Les phrases dans un autre ordre avec des retours à la lignes auraient probablement étaient plus claires, mais CrEv a bien expliqué je pense.
Microsoft Office 2007 est sorti le 30 janvier 2007 et Microsoft Vista est sorti le 30 janvier 2007.
Alors oui ils ont fait en sorte que MS Office soit compatible avec XP pour que tu n'ai pas à claquer trop d'argent d'un coup. Mais il était recommandé de l'utiliser avec Vista.
Si tu veut faire de l'anachronisme, tu peut en faire avec de tout le monde. Les passages en Qt4/KDE4 et GTK3/Gnome3, sont tout autant une perte de look'n'feel que ce dont tu parle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . É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: Les toolkits portables
Posté par Philippe F (site web personnel) . É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: Les toolkits portables
Posté par barmic . Évalué à 2.
Ce qui fait la force d'Apple c'est le haut niveau d'intégration entre leurs produit et le fait que tu passe de l'une à l'autre sans être déstabilisé. On aime ou pas leur choix ergonomiques, mais ils sont cohérents entre eux et c'est ça qui donne toute la force à leur marque. C'est pour cette raison que des utilisateurs Mac ont créé Camino.
Ce n'est peut être pas un critère qui va faire que les utilisateurs vont utiliser ou non ton appli, juste que ton appli se doit d'avoir des arguments pour être utilisée. Être utile ne suffit pas (des applications utiles il y en a pleins les dépôts de packages), parce que si l'utilité n'est pas jugée si importante que tu ne le pense ou s'il existe une alternative qui est un peu moins bonne mais bien intégrée au reste de l'environnement les utilisateurs feront rapidement leur choix.
Bref c'est un critère de choix non négligeable pour les utilisateurs.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Les toolkits portables
Posté par Troy McClure (site web personnel) . Évalué à 4.
disons que le coté cohérent ça rentre dans le cadre des finitions, il s'agit de fournir un outil bien fini, bien leché, de montrer au client, ou potentiel client, que ton produit a reçu de l'amour et de l'attention et que ce n'est pas un machin branlant avec une gui torchée à la va-vite par un maçon daltonien.
[^] # Re: Les toolkits portables
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Même avec un informaticien daltonien, je peux te promettre que c'est pas triste !! :D
[^] # Re: Les toolkits portables
Posté par Gof (site web personnel) . Évalué à 1.
L'ordre des boutons Ok et Cancel ? Mauvais exemple !
Quand on utilise les API Qt correctement (QDialogButtonBox ou QMessageBox), les boutons sont bel et bien placés dans le bon ordre.
En général, Qt essaye d'abstraire ces différence autant que possible.
Pour l'exemple du bouton droit dur la barre de défilement, si Qt ne fait pas ça correctement sous gnome, il faut reporter le problème à Qt. Ce doit juste être un oubli. Il n'y a pas de raison Qt ne pourrait pas faire ça.
[^] # Re: Les toolkits portables
Posté par CrEv (site web personnel) . Évalué à 3.
Nan mais faut arrêter, se poser et regarder le calendrier. Vendredi c'est pas aujourd'hui.
Manquerait plus que Gnome l'utilise !
[^] # Re: Les toolkits portables
Posté par zebra3 . Évalué à 2.
Tu serais étonné, il utilise aussi le clic milieu et la molette, voire même en combinaison avec Ctrl et/out Alt…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les toolkits portables
Posté par cedric . Évalué à 3.
Le look est une premiere chose, qu'on emule avec un theme, mais sincerement le comportement, c'est le plus impossible a reproduire. Regarde par exemple une liste verticale sur iOS, Android, GTK, QT et EFL, pas une seule n'a le meme comportement lorsque tu interagis avec. Et lorsque j'utilise une machine, je m'attend a ce qu'elle est le meme comportement quelque soit l'appli. Mais bon, c'est juste mon ressentit.
Sinon concernant les EFLs, c'est actuellement le toolkit le plus facilement portable qu'il soit. On supporte meme des OS 'temps reel'. Mais de maniere officiel est actuellement supporte Windows (dont les variantes CE), Linux (X11, Wayland et FB). Il y a un backend MacOS, et un iOS en preparation. Mais ils ne fairont pas parti de la prochaine release. De maniere general porter les EFL sur un nouvel OS va tres vite, en 1 mois, tu as quelque chose qui permet de fonctionner n'importe quel application. Apres c'est de l'optimisation lie a la plate forme.
Apres, je ne sais pas qu'elles sont les besoins en terme d'abstraction de la plate forme dont tu as besoin. Mais il y a deja pas mal de chose pour faire une application native generaliste. Si tu me dis ce que tu essayes de developper, je pourrais mieux te dire si il y a ce qu'il te faut.
[^] # Re: Les toolkits portables
Posté par flan (site web personnel) . Évalué à 1.
Il n'y a pas que le thème (relativement facile à émuler), ou le comportement (déjà plus complexe).
Ceci dit, si Qt, GTK, Win32 et Cocoa ont beaucoup de choses en commun (genre les boutons, les listes, les arbres, …), certains composants n'existent que sur une des plates-formes.
Il y a également l'intégration avec les services proposés (ou non) par l'OS.
Par exemple, je m'attends à ce qu'une appli utilise les API du système pour des choses aussi diverses que les certificats, mots de passe, contacts, calendriers, mails, proxy, …
Je trouve énervant d'avoir accepté une CA au niveau système, et qu'Opera ou Firefox ne la prenne pas en compte.
Y a aussi d'autres choses : sous OS X, les préférences sont stockées au format plist dans ~/Library/Preferences/nom_dns.plist. Sur Linux, ça sera plutôt dans ~/.nom_quelconque.
Toute l'application sera un dossier structuré sur OS X, et plutôt un binaire sous Linux, avec des fichiers un peu partout…
[^] # Re: Les toolkits portables
Posté par claudex . Évalué à 5.
Ce n'est pas une histoire de toolkit, c'est un comportement voulu (et chiant je te l'accorde mais la raison derrière ce comportement a déjà été validée au moins une fois)
Normalement dans $XDG_CONFIG_HOME http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ou ~/.config/quelque_chose
C'est une question d'installateur, pas de toolkit.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Facile!
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
En Gambit Scheme (qui compile efficacement vers C, donc qui permet d'avoir du code natif et rapide).
Pour l'interface graphique, y'a une API Cairo…
Et puis Skype, reste à voir la portabilité hein… La version windows a des années d'avance sur la version Linux, et même Mac je crois…
[^] # Re: Facile!
Posté par Philippe F (site web personnel) . É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: Facile!
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 6.
Tourne sous windows, tourne sous MacOS (l'OS du développeur), sous Linux, sous FreeBSD (je suis mainteneur), est porté sous Android et sous iPhone.
Comme ça compile vers C (ou C++) portable, c'est pas trop dur d'être portable.
Des jeux :
http://gamerizon.com/games/quantz/
http://vimeo.com/10626459
[^] # Re: Facile!
Posté par JoeltheLion (site web personnel) . Évalué à 3.
Qui te dit que la partie UI n'est pas complètement réécrite d'un OS à l'autre?
# juce
Posté par Troy McClure (site web personnel) . Évalué à 5.
JUCE http://www.rawmaterialsoftware.com/juce.php
C'est un toolkit c++ qui reste encore aujourd'hui de taille raisonnable (ce qui permet de le customiser, ou de le debugger, quand le besoin s'en fait sentir). Pas aussi complet que Qt bien sur, mais avec pas mal de fonctionnalités quand même, pas mal utilisé dans le milieu des applications audio. ça n'est par contre pas pour faire des interfaces qui s'integrent au bureau avec un look natif, c'est plutot orienté blingbling.
Il marche sous iOS et Android mais je ne sais pas si on peut vraiment se passer de developpements specifiques sur ces plateformes..
# T'en oublies un
Posté par Grunt . Évalué à 8.
On peut citer VLC, qui a justement migré de GTK à Qt. Et qui est un exemple intéressant (comme Skype) car il utilise pas mal de fonctionnalités avancées, tels que décodage vidéo hardware, usage de différents protocoles réseau, diffusion (serveur), présentation graphique très variable (plein écran, plein écran avec contrôle par dessus, fenêtré classique). Pourtant il est multi-plateforme et fonctionne très bien.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: T'en oublies un
Posté par kursus_hc . Évalué à 4.
Ainsi que Spotify, qui a exactement le même look and feel (ça existe encore cette expression?) sous ces 3 OS.
[^] # Re: T'en oublies un
Posté par 태 (site web personnel) . Évalué à 10.
Non, de wxWidgets à Qt.
# Go, de Google ?
Posté par coid . Évalué à 1.
À mon avis, ce langage a un bel avenir devant lui.
Simple, rapide et compilable. Je viens d’essayer sous Windows, et je suis étonné de la facilité à produire un exécutable, bien que je n’aie fait aucun test poussé.
Dès qu’il y aura un binding avec Qt ou un autre toolkit graphique, ce sera àmha une bombe.
http://golang.org/
[^] # Re: Go, de Google ?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 9.
Mais le Go est lent.
[^] # Re: Go, de Google ?
Posté par zebra3 . Évalué à 1.
Mais la terre est patiente.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Go, de Google ?
Posté par petit_bibi . Évalué à 3.
Pourtant la version argentée fait tout de même du 40 km/h en vol.. Source
[^] # Re: Go, de Google ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 8.
Un IDE avec debugger, ça serait déjà pas mal…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Go, de Google ?
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 1.
Tu devrais essayer de rejoindre l'alliance pour l'avènement de gocoincoin …
# Natif
Posté par Lutin . Évalué à 8.
Ça veut dire quoi un développement en natif ? C'est pour dire: développer un logiciel ?
[^] # Re: Natif
Posté par theblatte . Évalué à 8.
Pour en rajouter un peu : le titre dit "natif", mais ensuite ça parle de Python, qui est interprété. Que se passe-t-il ?
[^] # Re: Natif
Posté par woopla . Évalué à 2.
Je pense que c'est par opposition au développement Web évoqué dans le journal précédent.
# mono?
Posté par Damien Thébault . Évalué à 2.
Y'a Mono qui fait plein de pub pour le développement mobile (iOS + Android), mais c'est pas forcément les mêmes API pour l'UI d'après ce que j'ai compris.
Sinon perso je serait plutôt parti sur du Qt, ça s'adapte sans modification à la majorité des systèmes existants, et ça c'est bien. En plus de ça l'API est bien !
[^] # Re: mono?
Posté par Philippe F (site web personnel) . É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: mono?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Les ports Android et IOS n'ont pas l'air officiel, difficile de dire dans quel état ils sont…
Sinon pourquoi se concentre-t-on autant sur ces 2 seuls OS mobiles? Blackberry OS et Bada ont aussi des parts de marché non négligeables.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mono?
Posté par Philippe F (site web personnel) . É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: mono?
Posté par zebra3 . Évalué à 3.
Et Symbian ? Il est tout de même moins négligeable que Blackberry et Bada.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: mono?
Posté par TImaniac (site web personnel) . Évalué à 7.
Ben autant le dire direct : Qt est peut être une référence en matière de toolkit sur le desktop, mais il est totalement à la ramasse pour ce qui est du mobile, donc passe ton chemin de ce côté.
Sur mobile, tu as grosso modo 4 façons de faire :
- technos "portables" à base de technos Web : HTML5 & Co. Le côté portable est tout relatif puisque tu dois te contenter d'un sous-ensemble commun de fonctionnalités, et si t'es un minimum sensible à l'ergonomie, tu dois adaptée ton IHM pour respecter les guidelines de chaque plateforme. Sans parler des contraintes de perfs qui limitent bon nombre de scénarios d'application. Bref, pratique pour vendre une appli à pas cher pour un client qui veut juste voir son logo sur les stores.
- techno "portable" façon AIR : le nouveau Java : une appli, tourne partout, l'IHM aussi. Mêmes contraintes qu'au dessus, modulo les perfs qui sont un peu meilleur.
- techno "à moitié" portable façon Mono : même outils, même langage, mêmes API hors IHM, mais toolkit natif sur chaque plateforme. Inconvénient : faut recoder l'IHM pour chaque cible. Avantages : on a un résultat identique à une appli native au niveau design, ergo & perf, et on utilise des outils plus productifs et cross-plateforme.
- techno "native" : on prend les outils de chaque plateforme, et on recode tout from scratch pour chaque plateforme. Avantages : pas de limites. Inconvénients : faut du temps.
[^] # Re: mono?
Posté par Philippe F (site web personnel) . É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: mono?
Posté par jiyuu . Évalué à 3.
En même temps, il dit pas pourquoi Qt "est totalement à la ramasse pour ce qui est du mobile".
[^] # Re: mono?
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben pour plusieurs raisons :
La première est que Qt n'est le toolkit d'aucune plateforme mobile depuis que meego & co est au point mort. Donc il est le choix naturel nul part.
Le principal avantage de Qt est sensé être sa portabilité, mais :
- il ne tourne pas sur la plateforme iOS, bref on oublie une bonne partie des Smartphones sur le marché.
- le support Android est en cours de développement, comprendre pas fini. Et même s'il devient abouti un jour, on aura tous les inconvénients d'un toolkit non intégré au toolkit officiel, qui est écrit en code natif donc nécessite plusieurs binaires pour tourner sur les différentes variantes ARM, ce qui va générer des packages d'applications bien trop gros. Sans parler du manque d'outillage & co. Bref en fait on cherche encore l'intérêt.
- ne parlons même pas des plateformes derrières : BlackBerry ou Windows Phone, là c'est le néant niveau support.
[^] # Re: mono?
Posté par coïn . Évalué à 2.
Tu vas vite en besogne mon ami. Et Qt peut être un choix intéressant.
un bon article sur Qt sur android sur http://blog.freelan.org/2010/11/27/developper-avec-qt-pour-android/ Attention, la situation s'est amélioré depuis 2010
[^] # Re: mono?
Posté par barmic . Évalué à 2.
Il faut voir ce dont tu as besoin en terme de performance. Pour quelque chose qui tourne sur à peu prêt tout, je doute que la performance soit un critère principal, mais plutôt la réactivité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mono?
Posté par CrEv (site web personnel) . Évalué à 4.
Le problème c'est que, lorsque beaucoup d'applications mobiles ne sont qu'une IHM accédant à un service web, ça veut dire qu'il faut, en général, quasiment tout recoder. Supayr !
[^] # Re: mono?
Posté par TImaniac (site web personnel) . Évalué à 2.
bah si c'est juste un appel à un service web, autant faire un site web mobile et pas se prendre la tête avec les applis.
[^] # Re: mono?
Posté par CrEv (site web personnel) . Évalué à 2.
sauf que tu veux pouvoir avoir une interface qui se comporte correctement sur la plateforme, ou qui a des effets sympa.
[^] # Re: mono?
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben tu fais alors comme tu veux : soit tu maîtrises les langages et outils des différentes plateformes pour recoder tout, soit tu réutilises ce que tu maîtrises et tu te contente d'apprendre les API de chaque plateforme.
# Sorti de Qt, point de salut ?
Posté par liberforce (site web personnel) . Évalué à 4.
Parlons en justement. Je sais qu'il y a des soucis de ce côté là au niveau simplicité de déploiement, mais je ne sais pas vraiment où en est la concurrence. C'est facile à quel point le déploiement d'une application Qt sous Windows ?
Ensuite, est-ce que tu parles uniquement du déploiement, ou aussi de bugs spécifiques Windows ? Pour info, GTK 3.4 qui vient de sortir est la première version à corriger une bonne partie des bugs spécifiques à GTK 3 sous Windows, un an après la sortie de GTK 3.0 (pas glop).
J'en ai fait un peu, et c'est surtout très moche à programmer, trop proche des MFC à mon goût, et avec un tas de variantes de méthodes spécifiques à une plateforme ou une autre au sein d'un même objet ce qui fait que le côté multi-plateforme est assez illusoire.
[^] # Re: Sorti de Qt, point de salut ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Euh… C'est quoi le problème au juste?
Tu créés lib, dans le plus facile pour l'utilisateur en lib statique, et l'utilisateur ne voit que ton .exe, il clique sur le .exe et hop. Il le déplace, pareil.
Windows, c'est simple ;-).
(Mac encore plus simple grâces aux binaires universels et aux dossiers qui s'exécutent)
[^] # Re: Sorti de Qt, point de salut ?
Posté par liberforce (site web personnel) . Évalué à 3.
Tu veux dire que ce qui est préconisé sous Qt pour un déploiement Windows c'est de tout linker en statique ?
[^] # Re: Sorti de Qt, point de salut ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Il est rien préconisé du tout, tu fais comme tu veux, tu es libre. Mais je ne vois pas ce qui te choque dans l'idée. Je te dis juste que c'est pas un point bloquant du tout, tout le monde sait très bien le faire très rapidement.
Tu peux mettre les DLLs à côté si tu as envie d'avoir plus d'un fichier, mais c'est plus gros. C'est toutefois ce que je vois le plus souvent (les projets Qt sont tous prêts pour ça, par défaut).
Si pour toi c'est "ah oui Qt c'est une lib il lui faut une install commune à tous", ben tu peux t'amuser aussi à faire ça, mais personne d'autre n'a envie de s’embêter avec des incompatibilités. La philosophie des OS n'est pas la même que sous Linux… D'un côté, ça marche pour beaucoup beaucoup de monde ;-).
[^] # Re: Sorti de Qt, point de salut ?
Posté par liberforce (site web personnel) . Évalué à 2.
Source: https://mail.gnome.org/archives/gtk-app-devel-list/2003-September/msg00027.html
Ça date de 2003, je ne sais pas si cela a changé. Je sais qu'il y a eu très récemment GResource qui permet d'intégrer les fichiers de ressources dans l'application, mais je ne sais pas si les autres problèmes ont été résolus.
De l'autre côté, Qt fournit un guide de déploiement sous Windows…
[^] # Re: Sorti de Qt, point de salut ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Mauvais SDK, jeter SDK. (surtout avec des excuses foireuses comme ça!)
Et si GTK était multi-plate-forme, ça se saurait… (c'est horrible sous Windows)
[^] # Re: Sorti de Qt, point de salut ?
Posté par liberforce (site web personnel) . Évalué à 2.
Euh… je vois pas trop les excuses foireuses dont tu parles. Ensuite, GTK est multi-plateforme, mais manque de développeurs, autant sous Linux que sous Windows. Ce qui fait que la version Linux est privilégiée par rapport aux autres, et que les développeurs GTK sous Windows se sentent comme des citoyens de seconde zone… Le fait que la version conseillées sur gtk.org soit la 2.24 alors que GTK 3 est sorti depuis un an n'aide pas, mais j'espère que la 3.4 la remplacera bientôt.
Pour ce qui est d'être horrible sous Windows, il y a toujours eu des thèmes pour Windows, pour adopter le look natif. C'est également le cas avec GTK 3 (sauf que les thèmes sont en CSS maintenant):
http://blogs.gnome.org/alexl/2011/11/25/gtk-work-on-windows/
http://blogs.gnome.org/alexl/2012/03/27/moar-windows-themes/
[^] # Re: Sorti de Qt, point de salut ?
Posté par Zenitram (site web personnel) . Évalué à 5.
Est-ce qu'on peut maintenant appeler la boite native d'ouverture de fichier pour chaque OS (Windows et Mac compris)?
Parce que mettre un verni de CSS, ce n'est pas suffisant, il y a bien plus de choses.
J'utilise par exemple GIMP, et je hurle à chaque fois que j'ouvre ou enregistre un fichier, c'est horrible ce truc pas du tout intégré.
[^] # Re: Sorti de Qt, point de salut ?
Posté par zebra3 . Évalué à -1.
Mauvais environnement, changer environnement.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Sorti de Qt, point de salut ?
Posté par Zenitram (site web personnel) . Évalué à 6.
Cool : on parle de Toolkit cross-platform, et à cause d'un toolkit merdique, il faut changer d'environnement.
Dit… Ca sert à quoi un toolkit cross-platform si l'OS de 90% des gens est pas supporté? "Bon, les gars, on fait un toolkit graphique avec un seul OS supporté, c'est beau non?"
Vraiment, on lit n'importe quoi… Juste du foutage de gueule.
PS : je hurlerai aussi avec cette boite de dialogue horrible si j'étais sur un autre environnement, et me dépêcherai de changer d'environnement pour un utilisable. la boite te plait, tant mieux, mais n'en fait pas une généralité, ce n'est pas pour rien que Linux Desktop, et les applis GTK, sont peu utilisées… Mais tu vas dire qu'il faudrait changer les utilisateurs, pas l'interface, je sais. Les utilisateur disent non.
[^] # Re: Sorti de Qt, point de salut ?
Posté par zebra3 . Évalué à 2.
Je préfère un truc qui marche parfaitement sur un seul environnement (libre qui plus est) et qui y fait exactement tout ce que j'attends qu'un truc bancal qui marche de la même manière partout mais ne s'intègre nulle part.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Sorti de Qt, point de salut ?
Posté par zebra3 . Évalué à -6.
Au passage, GTK ça tourne sur 686, amd64, ARM, tout ce qui est supporté par Linux, qui est juste le noyau le plus universel actuellement.
Niveau multiplateforme, ça me paraît suffisant.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Sorti de Qt, point de salut ?
Posté par navaati . Évalué à 3.
C'est plus NetBSD ?
[^] # Re: Sorti de Qt, point de salut ?
Posté par zebra3 . Évalué à 0.
Ah oué mince, j'avais oublié celui-là.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Sorti de Qt, point de salut ?
Posté par liberforce (site web personnel) . Évalué à 2.
http://bugzilla.gnome.org/show_bug.cgi?id=319312
La raison pour ne pas l'implémenter, outre le manque de moyens humains:
Source: http://people.redhat.com/otaylor/fosdem2003/file-selector.html#desktop-integration
[^] # Re: Sorti de Qt, point de salut ?
Posté par Littleboy . Évalué à 4.
Ca c'est parce que les mecs qui ont fait le portage Windows sont soit tres mauvais, soit ont survole la doc la veille et n'ont aucune experience de la plateforme (generalement, ils font tourner XP dans une VM et ca n'est pas leur plateforme principale, c'est exactement la meme chose avec le port de git sous Windows en passant).
Ayant du patcher plein de code pour compiler glib/pango/etc. en statique et vu la quantite de chemins codes en dur dans le code, je pencherais plutot pour les deux.
[^] # Re: Sorti de Qt, point de salut ?
Posté par Philippe F (site web personnel) . É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: Sorti de Qt, point de salut ?
Posté par CrEv (site web personnel) . Évalué à 3.
En même temps, ils partent de tellement loin que ça doit leur sembler magnifique !
[^] # Re: Sorti de Qt, point de salut ?
Posté par liberforce (site web personnel) . Évalué à 2.
Non, non, même là… J'ai commencé ma carrière comme développeur d'IHM en MFC ;-). Rien que les hacks nécessaires pour avoir une interface redimensionnable, c'était galère. Le jour où j'ai découvert GTK et que j'ai vu que tout ça était de base dans le toolkit avec un modèle très simple à comprendre, j'ai quitté les MFC sans me retourner :-p.
[^] # Re: Sorti de Qt, point de salut ?
Posté par liberforce (site web personnel) . Évalué à 2.
Oui enfin pour c'est plus le développeur de l'appli qui choisit que les dev GTK, à ce niveau… Et je n'ai jamais eu de soucis avec des applis comme pidgin ou GIMP sous Windows… Ce qui manque c'est peut être un guide de bonnes pratiques du déploiement d'application GTK sous Windows.
[^] # Re: Sorti de Qt, point de salut ?
Posté par El Titi . Évalué à 2.
Un toolkit discret et pourtant assez apprécié:
http://www.fox-toolkit.org/
# Des conseils pour avoir un environnement de packaging py2exe + pyside sous MS Windows ?
Posté par Stéphane Klein (site web personnel) . Évalué à 2.
Personnellement, avec Python + Qt (avec PySide) les seules difficultés que j'ai pour le moment c'est pour avoir un environnement de travail/compilation sous MS Windows qui soit plus ou moins correct. Voir à ce sujet mon post sur le forum MS Windows + MinGW/MSYS ou Cygwin + accès à mes outils GNU dans mon term + Python + PySide + py2exe
[^] # Re: Des conseils pour avoir un environnement de packaging py2exe + pyside sous MS Windows ?
Posté par Philippe F (site web personnel) . É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: Des conseils pour avoir un environnement de packaging py2exe + pyside sous MS Windows ?
Posté par BFG . Évalué à 2.
La licence ? PyQt est en licence GPL ou commerciale alors que PySide est LGPL.
[^] # Re: Des conseils pour avoir un environnement de packaging py2exe + pyside sous MS Windows ?
Posté par feth . Évalué à 3.
Je n'ai pas d'Android pour vérifier. Il me semble que pour Android, on n'a pas encore de support PyQt. Le 26 novembre 2011, Phil Thompson disait qu'il ne sentait pas une demande suffisante.
Je suis tombé sur ce tutoriel pour pyside/Android (je ne sais pas ce que ça vaut).
# Logiciel de gestion documentaire mutiplateforme
Posté par Claude SIMON (site web personnel) . Évalué à 10.
Comme retour d'expérience, je peux évoquer un logiciel de gestion documentaire que j'ai développé (et sur lequel je travaille encore pour apporter des améliorations), et qui est déployé chez plusieurs clients.
Ce logiciel est composé de 2 parties. Une partie prenant en charge le traitement (appelé 'backend'), et une partie prenant en charge l'interface (appelée 'frontend').
Le 'backend' est développé en C/C++ (j’entends par là en utilisant le langage C++, mais avec uniquement les bibliothèques systèmes et les bibliothèques C standards ; pas de bibliothèques C++). Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne, mais n'a pas été déployé (faute ce client en faisant la demande), également sous MacOS.
Le 'frontend' avec interface graphique native s’appuie sur XULRunner et est également développé en C/C++, avec mise en œuvre de XML, XSLT, XUL et XPCOM. Il tourne et est déployé chez des clients sous Windows. Il tourne également, sans avoir été déployé, faute de client en ayant fait la demande, sous Linux. Quand à MacOS, il y a une version en cours de développement. En fait, ça tourne, sauf qu'il n'y a pas de menus, à cause d'une particularité de MacOS (problème d'installation, qui devrait être résolu dés que j'aurais le temps de m'en occuper).
La particularité de ce logiciel, c'est qu'il a également un 'frontend' web, développé en natif (eh oui, ce n'est pas contradictoire). Ce 'frontend', qui prend la forme d'une CGI, a également été développé en C/C++, avec mise en œuvre de XML, XSLT et HTML . L'articulation des fonctionnalités étant identique pour le frontend web (CGI) et natif (XULRunner), une grosse partie du code est commun aux deux. Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne également sous MacOS, sans avoir été déployé, toujours faute de demande de la part des clients.
Concernant les plateformes mobiles, j'ai réussis à compiler et faire tourner l'application ('backend' ET 'frontend's) sous Maemo sur un Nokia N900, mais cela n'a évidemment jamais été déployé chez des clients :-> !
Pour résumer, on a donc là une application multiplateforme (Windows, Linux et MacOS) développée en C/C++, dont la partie interface graphique native s’appuie sous XULRunner. En étant discipliné et organisé, faire du développement multiplateforme en C/C++ ne pose absolument aucune difficulté. Concrètement, grâce à un framework maison, je développe mes logiciels sous Windows avec Visual C++, et, pour les faire tourner sous Linux ou MacOS, il me suffit de les recompiler sur la plateforme en question.
Pour avoir plus de détails concernant la mise en œuvre de XULRunner, je renvoie à un de mes précédents journaux (http://linuxfr.org/users/epeios/journaux/xulrunner-et-c).
Pour nous émanciper des géants du numérique : Zelbinium !
# Pascal Objet ?
Posté par Guillaume D. . Évalué à 4.
Lazarus :
Windows : OK
Linux : OK
MacOSX : OK
Android : OK mais a tester http://wiki.freepascal.org/Custom_Drawn_Interface/Android
Iphone : ca arrive : http://wiki.lazarus.freepascal.org/iPhone/iPod_development et http://freeze-dev.de/blog/2010/02/simple-iphone-example-using-freepascal-and-sdl/
et pour le même prix le même IDE windows / linux /mac !
# Pendant ce temps...
Posté par case42 (site web personnel) . Évalué à 6.
Le temps de trouver une solution qui marche partout, en HTML5+Javascript le projet serait déjà fini…
Poum, poloum, poloum…
[^] # Re: Pendant ce temps...
Posté par Octabrain . Évalué à 5.
Pas trop non, tu serais plutôt en train de :
[^] # Re: Pendant ce temps...
Posté par claudex . Évalué à 3.
Si tu change d'outils à chaque fois que tu fais un site, je comprend que ça prenne tu temps, mais normalement, tu réutilise tes libs, donc tu connais leur fonctionnement.
Même chose, ça t'arrive la première fois, après tu prend vite le coup pour les bonnes pratiques.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pendant ce temps...
Posté par case42 (site web personnel) . Évalué à 6.
CSS3 n'est pas une obscure lib sur github. Et si tu es en train de perdre du temps sur ce genre de détails cosmétiques, c'est que le projet est effectivement fini, du moins d'un point de vue fonctionnel.
Je suis un développeur pragmatique, je ne suis ni Google, ni un Hipster. J'utilise ce qui marche a un instant T. Si ton projet c'etait de faire une application qui marche et que tu te retrouve a faire du lobbying, c'est que "you're doing it wrong!".
D'expérience je me prends moins la tête pour faire marcher une web-app sur Chrome, Firefox, Safari (on laissera IE aux masochistes) que de porter une application native d'un OS X (pun intended) a un OS Y (et manifestement je ne suis pas le seul, vu les tartines que vous avez écrit sur le sujet dans ce journal).
Encore une fois, je ne suis pas un Hipster.
[^] # Re: Pendant ce temps...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
alors d'abord, si elle obscure, c'est qu'elle est mal foutue. Et tu as le même problème avec des libs "obscures" en C++ ou autre :-p
Ensuite, bon, utiliser une lib pour faire des ombres, cela démontre un haut niveau d'incompétence, puisqu'un simple style css text-shadow fait l'affaire. (et on s'en fout qu'il n'y ait pas d'ombre avec IE9, c'est rarement une fonctionnalité primordiale dans une appli, hein, comme beaucoup de style CSS d'ailleurs)
Euh, non. moi j'utilise ce que j'ai sous la main. M'enfin, si tu es du genre à faire du lobbying, je suppose que tu as alors le même syndrome auprès du consortium de standardisation du C++, ou de python, ou de {ici ton langage préféré}
Tout bon développeur ne code pas pour UN browser, mais pour plusieurs browser. Et tout bon développeur va donc vérifier sur http://caniuse.com ce qu'il peut utiliser en matière de CSS/HTML/JS pour son code.
Je ne vois pas le rapport.. Des awesome, love et cie, on en trouve dans tout les domaines. http://www.google.com/search?q=python+awesome http://www.google.com/search?q=c%2B%2B+awesome etc..
# J2ME
Posté par NanoTech . Évalué à 1. Dernière modification le 12 avril 2012 à 22:50.
Le profil MIDP du CLDC de J2ME est très largement supporté, et a une interface graphique (LCDUI) limitée (quoique pas si mal pour MIDP >= 2.0) mais abstraite et donc, facilement adaptée à tous types de périphériques.
On peut faire des trucs assez avancés (comme Opera Mini).
C'est essentiellement utilisé pour les petites applis des smartphones les moins cher, mais c'est aussi supporté par les plus puissants.
1) Tous les BlackBerry (sauf peut-être les derniers) supportent MIDP en natif en plus de RIM.
2) Il existe un programme convertissant une appli MIDP en appli Android.
Je crois qu'on perd beaucoup en performances vu que Dalvik != JVM.
3) Windows Mobile 6 supporte MIDP si le runtime adéquat est installé.
4) Les Nokia sous Symbian supportent MIDP (je ne suis pas sûr qu'ils supportent MIDP 2.0)
5) Sous Maemo, ce n'est pas supporté à la base, mais je crois qu'il existe un runtime proprio + un projet libre:
http://maemo.org/community/brainstorm/view/delivering_java_me_to_fremantle/
6) iOS est trop fermé pour qu'Apple accepte de supporter MIDP. Mais il existe apparemment des solutions pour compiler des applications J2ME en application iPhone:
http://blog.ippon.fr/2010/06/22/java-sur-iphone-utopie-ou-realite/
7) De nombreux téléphones dans des gammes de prix intermédiaire (30 à 80 euros), souvent appelés "feature phones", utilisent Nucleus RTOS ou MTK (version dérivée de Nucleus pour CPU mediatek), avec support exclusif des applications MIDP 2.0, plus ou moins nativement (je crois que certaines implémentations utilisent JBlend, et d'autres exploitent le Jazelle de l'ARM926TEJ).
8) Bada supporte MIDP en natif.
9) Windows Phone 7 ne supporte pas du tout J2ME.
Intérêts de MIDP:
1) Tourne sur prèsque toutes les plateformes mobiles.
2) Seule choix possible pour les nombreux feature phones.
Défauts:
1) Pas très "natif" sauf sur les feature phones.
2) Comme MIDP a de très nombreuses implémentations, et que certaines fonctions sont optionelles, il faut tester rigoureusement sur chaque plateforme.
3) API plus limitée, et éventuellement plus lente, que l'API native.
4) Peut nécessiter l'installation d'un runtime spécifique.
Ce qui reste le plus portable, c'est HTML+CSS+JavaScript. Notamment avec les nouvelles plateformes B2G, Tizen, WebOS. Par contre, c'est lent et pas toujours confortable à utiliser.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.