Delphi + Python : un avis

Version imprimable

06/06/2022, 11h12
Invité

Delphi + Python : un avis

Bonjour,

j'ai reçu plusieurs annonces d'Embarcadero mettant en avant les liaisons possibles entre Python et Firemonkey. Dernièement encore, ce matin : version en ligne.

J'avais commencé hier un message dans le blog Firemonkey intitulé "Encore ronchon". Je ne l'ai pas publié. Je suppose que ma frustration ne concerne que moi et mes exentriques projets. J'essaye d'améliorer un système d'évaluation de la progression pédagogique en mathématiques de chaque élève avec un système de remédiation en cas de difficulté, sachant que je privilégie toujours la feuille, le stylo et surtout l'Enseignant comme ressource tout en sollicitant au maximum l'autonomie de l'élève. C'est un vieux projet de 15 ans commencé uniquement en mode papier, le suivi étant assuré en back-end (informatiquement) à l'époque.

Donc je cherchais un moyen d'afficher la progression d'un élève. En développement Web, j'ai abandonné le développement propriétaire WebDev de PC SOFT pour utiliser des approches non propriétaires. J'utilise par exemple pour que chacun puisse visualiser sa position par rapport aux objectifs opérationnels du programme des bibliothèques comme arborjs.

Je me heurte en permanence aux discours d'Embarcadero et la réalité de la mise en œuvre dans la réalité d'un projet.

Dans un premier temps, j'ai regardé comment intégrer un moteur d'IA dans mon projet avec FMX. Facile semble-t-il : TensorFlow n'est pas pour moi le moteur idéal [les moteurs d'IA sont encore très spécialisés]. Il n'y a qu'a regarder ... Par contre l’adaptation est beaucoup plus délicate. A croire que l’exemple a été choisi pour répondre à la propagande "facilitaire". C'est possible, regardez... Oui effectivement sur cet exemple. Ce qui ne rend pas du tout le portage de TensorFlow dans une approche générale. Sinon aucune bibliothèque native ne semble disponible en Delphi.

Maintenant en C++, on trouve d'autres librairies que TEnsorflow. Et il y a C++ Builder, donc sauvés ! Sauf que C++ Builder n'admet pas les mêmes cibles que Firemonkey Delphi... C'est bête. Depuis le temps que l'on attend.

Pour en revenir à mon affichage, j'ai tenté d’incorporer arborjs dans un TWebBrowser. Cela ne fonctionne pas. Certainement un problème d’incorporation des bibliothèques Javascript nécessaires dont jQuery. C'est du lourd effectivement. Existe-t-il une implantation native de "graph network visualization" en Delphi ? Que nenni ! Évidemment on en trouve en C++, en Java et... en Python. On trouve également des moteurs d'IA en Python.

Et cela rejoint la pub que je reçois. Delphi est-il tellement limité qu'il faille utiliser Python pour obtenir quelque chose ? Mais dans ce cas-là, pourquoi ne pas utiliser Python directement. Je comprends la même démarche en Qt avec Python. On récupère le GUI Qt qui à mon sens est d'excellente facture aussi bien qualitativement que quantitativement.
Alors Delphi, son livebindings et Python cela présente quel intérêt au juste quand on connaît la complexité de mise en œuvre de l'interface GUI proposé par Delphi ? J'aimerais avoir un éclairage objectif là-dessus.

Merci. Cordialement. Gilles
06/06/2022, 11h48
Paul TOTH

Hello,

alors, en Java et en C++ ou trouve TOUT, du bon et du moins bon, mais je pense qu'aucun sujet n'a jamais été traité dans un de ces deux langages.

en Delphi on trouve beaucoup de choses, mais pas tout, il y a des domaines qui ne sont pas explorés par les développeurs Delphi - quand bien même c'est possible.

il y a parfois des choses surprenantes, comme une implémentation native de OpenSSL sous Delphi, ou le portable de Quake ... des projets qui montrent que c'est est possible....sauf que oui, il est sans doute préférable d'utiliser OpenSSL sous forme de DLL mis à jour régulièrement par une floppée de développeurs que la version Delphi aussi chiadée soit-elle, et utilisée par sans doute très peu de gens (mais là il est question de sécurité donc c'est particulier).

Pourquoi utiliser Python sous Delphi ? personnellement je ne le ferais pas...je n'aime pas Python :) mais une des raisons serait d'offrir à un utilisateur la possibilité de créer un plugin pour un logiciel dans un langage plus populaire que Delphi....et d'utiliser éventuellement les bibliothèques Python existantes dans ce plugin...

Pourquoi utiliser TWebView ? pour exploiter HTML/CSS/JS dans une application Delphi...c'est un choix, notez que la dernière version de Delphi a remplacé le HTML de la page d'accueil par des composants natifs car au final, c'était pas plus difficile de faire un rendu sympa sous Delphi que de faire fonctionner JS avec Delphi :)

Bref, je pense que ces bindings sont là pour séduire des développeurs qui aiment ces technologies en disant, avec Delphi vous avez la porte ouverte...je ne suis pas sûr que ce soit payant, mais est-ce dérangeant que cela existe ?

Après, je l'ai déjà expliqué à plusieurs reprises, dans mon activité, j'utilise plus volontiers PHP pour faire du Web car mes sites Web sont à 80% en Javascript...les 20% qui restent sont plus simples à faire en PHP sur un hébergement OVH que de monter une VM dédiée pour installer une appli Delphi....si j'avais le temps je passerais sans doute un peu de temps sur Pas2Js histoire de remettre du Delphi dans mes développements Web :) voir un truc qui produise le code PHP côté serveur... ce sont essentiellement des requêtes SQL qui retournent du JSON...quelque chose qu'on doit pouvoir automatiser.
06/06/2022, 12h04
SergioMaster

Bonjour Gilles,

Comme d'habitude un peu de mélange ;) et des bindings qui ne passent pas :ptdr:
Côté Delphi+Python je n'ai touché que la partie utilisation de Python dans Delphi et non utilisation de Delphi pour faire des Interfaces utilisateur pour Python et encore n'ai-je fait qu'explorer deux ou trois bibliothèques. Expérience sympa, mais courte, qui m'a laissé un peu sur l'expectative
premier test
Après je me suis "amusé" avec d'autres bibliothèques.
Je suis resté perplexe sur la récupération de traitement d'images via Python
06/06/2022, 13h18
Invité

Bonjour,

Citation:

Envoyé par Paul TOTH

[...]Après, je l'ai déjà expliqué à plusieurs reprises, dans mon activité, j'utilise plus volontiers PHP pour faire du Web car mes sites Web sont à 80% en Javascript...les 20% qui restent sont plus simples à faire en PHP sur un hébergement

Oui, j'en suis arrivé à cette même conclusion.
06/06/2022, 13h43
Invité

Citation:

Envoyé par SergioMaster

Comme d'habitude un peu de mélange ;) et des bindings qui ne passent pas :ptdr:

Oui mélange est bien le terme... pour les bindings,je passe :aie:

Toutes ces "complications" et ces démonstrations "aguicheuses mais limitées dans la réalité" me lassent. Tu fais une étude et tu vérifies point par point si oui ou non c'est réalisable en Delphi, si possible en natif et si tel n'est pas le cas sans "limiter" ce qu'est capable de faire la bibliothèque écrite dans un autre langage et appelée par le code Delphi.

Il ne me semble pas sublimer le passé mais quand Delphi ( <=7) était mon langage de développement je n'ai jamais butté sur un développement, sur une idée, un "truc à ma sauce". C'était pour moi LE langage généraliste et à tout faire.

Avec Firemonkey, je rencontre trop d'impasses, trop de solutiosn de contournement. On va bientôt m'expliquer que pour faire de l'IA à partir de Delphi, il faut que j'intègre des bibliothèques Python ! Et comme Paul je ne suis pas adepte de Python... et si je devais "reprendre" mon projet, Python a lui seul me suffirait.:weird:

J'assimile maintenant le Pascal à un langage de niche. Peut-être l'a-t-il toujours été ? Mais le C++ n'est pas un langage de niche alors comment peut-on m'expliquer que les cibles de compilation atteintes par C++ Builder soient limitées par rapport à celles de Delphi Firemonkey ? Et autre question, l'énorme socle de librairies développées en C++ sont-elles intégrables dans C++ Builder ? Ciompte tenu que ce dernier impose -parce que dans les faits c'est une quasi obligation- d'utiliser le LiveBindings et autres bizarreries, je n'ai même pas de certitudes à ce niveau. En attendant même si ce n'est pas raisonnable mais purement psycho-affectif, je n'ai pas l'intention d'abandonner le Pascal... même si j'estime que la solution propriétaire actuelle n'est pas à la hauteur.

PS : j'ai commencé à faire un composant FMX pour régler ce problème de visualisation, système qui doit optimiser (limiter) les croisements de liens... Il me semble que c'est jouable. Mais combien de temps cela va me prendre ? J'ai basculé vers Qt en production dans mon entreprise parce que Lazarus était trop chronophage au niveau de la réalisation de composants adaptés à mes besoins. A la retraite maintenant, j'ai du temps il est vrai. Alors un pseudo-moteur d'IA (c'est en réalité un mixe de proba et de stats), un composant de visualisation... En lazarus j'avais participé sur ce forum à la création de composants, il y a très longtemps avec quelques passionnés... Cela existe encore de nos jours... en FMX ?

Cordialement. Gilles
06/06/2022, 13h52
Paul TOTH

tu compares Delphi du jour avec Delphi 7...est-ce que tes développements n'ont pas évolués entre deux ? à l'époque de D7 je faisais 100% de Windows natif en client "lourd", aujourd'hui j'ai bcp plus de webservice ou d'interaction avec le web en général...mais Delphi continue à répondre à mes attentes.

j'ai aussi 90% des mes développement sous VCL...FMX est vraiment à la marge

et pour ajouter un Binding, il y a un projet Skia4Delphi qui propose de remplacer le moteur graphique de FMX (disponible aussi pour VCL) par Skia de Google...ceux qui bossent dessus sont très enthousiastes...personnellement j'aurais préféré une initiative de réécriture de Skia en Pascal :)
06/06/2022, 15h19
Invité

1 pièce(s) jointe(s)

Citation:

Envoyé par Paul TOTH

tu compares Delphi du jour avec Delphi 7...est-ce que tes développements n'ont pas évolués entre deux ?

C'est là le problème. Effectivement la demande des utilisateurs a évolué. Je prends toujours cet exemple : en delphi 7, je n'avais pas besoin de gérer le texte enrichi. Mais cela fait quand même "quelques" années que mes Collègues m'ont réclamé la gestion du texte enrichi dans les bulletins scolaires. Mon premier gestionnaire a été réalisé en Turbo-Pascal ! Va falloir informer Embarcadero que l'on a changé d'époque. Pas facile de trouver une machine à écrire maintenant. Pourtant, ils en sont restés là :ptdr: : TMemo, TEdit, TLabel, TGrid gèrent-ils nativement le texte enrichi ? TMS Software si on aime... Je ne parle pas de l'impression avec le mini :mouarf: HTML de FastReport et pire, pour moi, l'incapacité de générer nativement du pdf dans toutes les cibles desktop. Allez-voir Qt pour avoir un aperçu de la différence ! Il faut quand même pas pousser ! Ils font quoi les programmeurs d'Embarcadero ? En terme de générateur de rapports, actuellement c'est Fastreport un truc antédiluvien comparé à NCReport. Peut-être Quickreport est-il plus performant ?

Quant à mac et linux, c'est quoi le problème pour C++ Builder ? Il faut dire que la doc m'est incompréhensible :
Pièce jointe 620362Source : RAD Studio 11.1 Spécifications techniques

Pour Builder, IHM FireMonkey est disponible pour macOS, avec un add-on tiers pour Linux, mais la compilation est impossible en C++ pour ces 2 cibles. Si je comprends bien, cela ne me permet pas de réaliser des programmes macOS ou Linux avec C++ Builder. 8O PAr contre, on observe qu'en ce qui concerne le mobile RAD 11 est "complet". Dans la réalité, j'estime que Delphi a totalement raté son ciblage Linux et mac OS. Donc, on a VCL pour Windows et on a Firemonkey pour le mobile. On est très loin de Qt qui gére Windows, mac OS, Linux, Androïd et iOS, et d'autres) et très proche des produits PC SOFT Windev pour Windows et Windev Mobile pour Androïd et iOS,.. Et PC SOFT commence à développer nativement des outils pour l'IA et des outils de visualisation. Et Delphi ?

Bon je vais aller un petit peu coder :D

Cordialement. Gilles
06/06/2022, 16h19
pprem

Hello

Pour les composants de saisie je suis d'accord avec toi : ne rien avoir pour faire de l'enrichi en multiplateforme (au moins sur Windows / Mac / Linux) c'est un tantinet gonflant. Mais il y a des alternatives (toutes payantes). Faut dire aussi que la version VCL est assez limitée.

Pour l'affichage on trouve des trucs exploitables sur GitHub (comme le composant DzHTML qui n'affiche pas du HTML mais un truc avec un système de balises à lui) et plein de choses payantes. Skia4Delphi propose un champ texte amélioré. Pour afficher du HTML, il y a le TWebBrowser (quand on n'a pas de soucis de configuration) mais c'est l'artillerie lourde.

Pour saisir et afficher du HTML avec une bonne prise en charge, la seule librairie que j'ai pu tester qui soit efficace c'est https://delphihtmlcomponents.com (payant, mais version d'évaluation dispo).

Concernant C++Builder, on ne peux pas dire qu'il soit complet sur mobiles : sans Android 64, pas de publication d'applications chez Google, donc le grand public ne peut plus être ciblé depuis quelques années. Les compilateurs C++ et Delphi ne sont pas les mêmes. Ils tardent à finir de faire évoluer les librairies C++ pour coller aux dernières évolutions du langage et de FMX pour fournir quelque chose d'exploitable. Peut-être que LLVM sera la solution dans les mois qui viennent ? En tout cas on ne peut pas vanter les mérites de C++Builder en dehors des plateformes desktop (essentiellement Windows). Embarcadero l'assume en ne communiquant quasi que sur Windows et les évolutions du langage, de l'éditeur de code et de la compatibilité avec des librairies open source prisées. A ce titre normalement ce qui se fait en C++ doit passer avec C++Builder.

Quant à WinDev et PCSoft, même si beaucoup comparent les deux, je ne suis pas d'accord. PC Soft et Embarcadero n'ont pas les mêmes contraintes historiques, les mêmes approches ni la même vision.

PC Soft n'a pas de revendeurs. Tout l'argent encaissé pour les licences, la formation, le support va globalement dans la pub et le développement des outils. La base de WinDev, WebDev et WinDev Mobile n'évolue pas énormément. Ils ajoutent des composants métier parce que c'est la seule chose qu'ils fassent pour faire évoluer le produit et vendre leur version annuelle à plusieurs centaines de nouveautés et améliorations (incluant le nombre de clics pour afficher un truc ou un changement de couleur). WinDev n'a pas d'écosystème (ou en tout cas je ne le connais pas).
Le côté multiplateformes et multi langages généré chez eux est bancal : une partie s'appuie sur un runtime payant, l'autre sur des générations dans d'autres langages qui ne supportent pas toutes les fonctionnalités annoncées. Côté bogues, y a aussi pas mal de choses à dire, mais ils sont réactifs au niveau du support et ceux qui payent les mises à jour ont des correctifs.

Embarcadero a hérité d'un fonctionnement avec des revendeurs et un découpage du monde par régions. Truc typique des entreprises anglophones. Difficile de revenir en arrière si tant est que quelqu'un le décide un jour.
Ils développent des outils de développement et fournissent ce qu'il faut pour créer avec le minimum vital pour que ça fonctionne dans la plupart des projets de leurs clients. Ils nous donnent ce qu'il faut pour nous laisser entièrement libres d'en faire ce qu'on veut.
Ils partent sur un réseau de distributeurs, ce qui réduit le cash disponible pour l'outil et un écosystème qui compense pour l'absence de trucs sexys fournis avec la base du produit. Ils achètent parfois des licences de produits tiers (FireDAC et FMX Linux sont de bons exemples) pour les inclure au produit.
Delphi (et C++Builder par ricochet) bénéficie d'un écosystème impressionnant, réparti entre projets libres, open source et commerciaux. A ma connaissance il n'y a que dans le web où il y a autant de choses disponibles, créées et mises à disposition par la communauté de développeurs.

Alors forcément, on ne trouve pas tout, ni comme on le voudrait, puisque chacun développe ce dont il a besoin à sa façon ou ça passe par des entreprises qui visent la vente, donc se focalisent sur ce qui a un avenir commercial.
06/06/2022, 16h29
Invité

Citation:

Envoyé par Paul TOTH

[...]et pour ajouter un Binding, il y a un projet Skia4Delphi qui propose de remplacer le moteur graphique de FMX (disponible aussi pour VCL) par Skia de Google...ceux qui bossent dessus sont très enthousiastes...personnellement j'aurais préféré une initiative de réécriture de Skia en Pascal :)

Très intéressant ! En plus les exemples de code me parlent. A la "mimine" :oops: A l'ancienne quoi. Merci pour l'info !
06/06/2022, 16h51
pprem

Citation:

Envoyé par HTML-Dev

En plus les exemples de code me parlent. A la "mimine" :oops: A l'ancienne quoi. Merci pour l'info !

Ca, ça fonctionne aussi dans FMX de base. JDCJDR
06/06/2022, 17h06
Invité

Citation:

Envoyé par pprem

Ca, ça fonctionne aussi dans FMX de base. JDCJDR

Cest quoi FMX de base [liveBindings :arf: ?] Je peux l'avoir sans base ? :oops:
06/06/2022, 18h11
Invité

Citation:

Envoyé par pprem

Pour les composants de saisie je suis d'accord avec toi : ne rien avoir pour faire de l'enrichi en multiplateforme (au moins sur Windows / Mac / Linux) c'est un tantinet gonflant. Mais il y a des alternatives (toutes payantes). Faut dire aussi que la version VCL est assez limitée.

Ouais, c'est en natif chez Qt ! Et ce n'est pas récent. Les composants de base possèdent cette fonction et pour les "Grids" on peut l'implanter. Bref c'est navrant parce que FMX est un produit jeune...

Citation:

Envoyé par pprem

Pour l'affichage on trouve des trucs exploitables sur GitHub (comme le composant DzHTML qui n'affiche pas du HTML mais un truc avec un système de balises à lui) et plein de choses payantes. Skia4Delphi propose un champ texte amélioré. Pour afficher du HTML, il y a le TWebBrowser (quand on n'a pas de soucis de configuration) mais c'est l'artillerie lourde.

Échec et mat pour moi avec mon arborjs. :aie: Par contre, je viens de le porter -pour vérifier- en Webdev 27 et en Windev 27. C'est un comble !

Citation:

Envoyé par pprem

Concernant C++Builder, on ne peux pas dire qu'il soit complet sur mobiles : sans Android 64, pas de publication d'applications chez Google, donc le grand public ne peut plus être ciblé depuis quelques années. Les compilateurs C++ et Delphi ne sont pas les mêmes. Ils tardent à finir de faire évoluer les librairies C++ pour coller aux dernières évolutions du langage et de FMX pour fournir quelque chose d'exploitable. Peut-être que LLVM sera la solution dans les mois qui viennent ? En tout cas on ne peut pas vanter les mérites de C++Builder en dehors des plateformes desktop (essentiellement Windows). Embarcadero l'assume en ne communiquant quasi que sur Windows et les évolutions du langage, de l'éditeur de code et de la compatibilité avec des librairies open source prisées. A ce titre normalement ce qui se fait en C++ doit passer avec C++Builder.

En desktop, "essentiellement Windows" ou exclusivement windows ? D'après ce que je comprends ni la compilation Linux ni la compilation mac OS ne sont disponibles. Donc me concernant l'intérêt est quasi nul.

Citation:

Envoyé par pprem

Quant à WinDev et PC Soft, même si beaucoup comparent les deux, je ne suis pas d'accord. PC Soft et Embarcadero n'ont pas les mêmes contraintes historiques, les mêmes approches ni la même vision. PC Soft n'a pas de revendeurs. Tout l'argent encaissé pour les licences, la formation, le support va globalement dans la pub et le développement des outils. La base de WinDev, WebDev et WinDev Mobile n'évolue pas énormément.

C'est très réducteur. Historiquement, ils sont a peu près aussi anciens mais depuis le temps, à quelques années près, la date d'apparition n'est pas significative. Ils ont les mêmes cibles dans ma réalité ! Pour Windev, Windows (un petit Linux, un petit mac OS par Java). Donc pas de multi OS réellement. Il faut du temps pour maitriser leurs 3 produits mais franchement cela fonctionne bien, y compris la gestion du texte enrichi, la production de pdf notamment avec un bon générateur d'états (reports) intégré. Évidemment, il faut un peu de temps avant qu'un nouveau "composant" ne soit fiable, 2 voire 3 versions. Leur publicité :aie:. Le service technique a fait énormément de progrès. Il suffit de quitter le RAD et c'est réellement productif. Malheureusement Windev n'est pas ce que je cherche parce que j'ai besoin de développer avec un même niveau d'exigence mes programmes dans les 3 OS. Mais je fais le maquettage de l'IHM de certaines "Form" avec... histoire de réaliser une simulation "dynamique". Tu vas me dire que Firemonkey cible Linux et mac OS. C'est un avantage, certes. Mais comme il ne permet pas de disposer des éléments que je souhaite y intégrer que ce soit au niveau du texte enrichi, de la génération de pdf dans les 3 OS, de l'IA, de la visualisation, au final, il perd son avantage. Les 2 produits pour le résultat que j'en attends sont insuffisants. Pour le reste, même combat pour Embarcadero et PC SOFT et donc même orientation : un IDE purement Windows. La messe est dite contrairement à Qt, Lazrus, Java Python. C'est rassurant de voir qu'ils sont capables de porter leur IDE sur tous les OS desktop cibles. Sans aucune préférence. Rassurant et pérenne. La cross-compilation de desktop à desktop ? Je ne suis pas convaincu du tout. En plus cela manque de souplesse.

Citation:

Envoyé par pprem

...fournissent ce qu'il faut pour créer avec le minimum vital pour que ça fonctionne dans la plupart des projets de leurs clients.

Ben je ne suis pas dans la "plupart" :aie:

Citation:

Envoyé par pprem

Ils nous donnent ce qu'il faut pour nous laisser entièrement libres d'en faire ce qu'on veut.

J'aimerais bien croire ce discours. En attendant, c'est une pure vue de l'esprit ? Un vœu pieux ? L'implantation du Livebindinds démontre le contraire. J'ouvre n'importe lequel de mes fichiers Qt ou Lazarus avec un simple notepad, et le corrige ! Tu vas me dire que le LiveBindings peut s'écrire à la main ? Facile donc !

Citation:

Envoyé par pprem

Ils achètent parfois des licences de produits tiers (FireDAC et FMX Linux sont de bons exemples) pour les inclure au produit.

Ils feraient mieux de se concentrer sur leur métier de base : la programmation. Chaque intégration nécessite des rafistolages... et à la fin, l'ensemble manque de cohérence et de "practicité" au point que j'ai eu l'impression de devenir un chef... cuisinier. On applique, on copie des recettes sans comprendre.. Un soupçon de vaudou peut-être ?

Citation:

Envoyé par pprem

Delphi (et C++Builder par ricochet) bénéficie d'un écosystème impressionnant, réparti entre projets libres, open source et commerciaux. A ma connaissance il n'y a que dans le web où il y a autant de choses disponibles, créées et mises à disposition par la communauté de développeurs.

Tu oublies dans les langages compilés Qt, Lazarus et dans les autres Java, Python.

Citation:

Envoyé par pprem

Alors forcément, on ne trouve pas tout, ni comme on le voudrait, puisque chacun développe ce dont il a besoin à sa façon ou ça passe par des entreprises qui visent la vente, donc se focalisent sur ce qui a un avenir commercial.

L'IA a un certain avenir, la visualisation des données produites aussi... Si je dois utiliser des bibliothèques tierces, pourquoi pas... mais du solide et du simple, de l'actuel et pas du "mini". Sinon -sans jouer les oracles- ce sera funeste... et permettra certainement l'émergence d'une autre plate forme de développement en Pascal.

A bientôt. Gilles
--------
PS : une petite anecdote. Je possède une licence PureBasic. Concernant la reconnaissance de caractères, un truc faisable en Delphi (cf la pub euh je veux dire l'article technique évoqué ci-dessus et très justement commenté à mon avis par Gouyon), voici ce que l'on faisait il y a 5 ans. PureBasic est un produit de niche, propulsé par un passionné, doté d'un "IDE" multiplateforme... C'est une licence à vie à un prix modique. Tu vois il ne s'agit pas d'un problème de cashflow de la société éditrice. Le spirit fighting est ce qui manque à Embarcadero. Borland le possédait. Il suffit simplement de la volonté d'un dirigeant, d'un créateur et d'une communauté. Cela laisse perplexe.
07/06/2022, 08h00
SergioMaster

Citation:

Envoyé par HTML-Dev

PS : A la retraite maintenant, j'ai du temps il est vrai.

Moi - pas encore, un an ou plus si les choses n'avancent pas.

Citation:

Envoyé par HTML-Dev

forum à la création de composants, il y a très longtemps avec quelques passionnés... Cela existe encore de nos jours... en FMX ?

Du moins je tente d'en faire avec quelques modestes succès (tu trouveras un pdf dans ce dépôt). Gouyon aussi a fait quelques essais. Je suis prêt à ajouter mon expérience à un groupe même hors forum (dépôt git par exemple) dans la limite de mon temps
07/06/2022, 08h06
SergioMaster

Citation:

Envoyé par Paul TOTH

j'ai aussi 90% des mes développement sous VCL...FMX est vraiment à la marge

J'ai choisi la voie inverse pour toutes mes nouvelles applications

Citation:

Envoyé par Paul TOTH

et pour ajouter un Binding, il y a un projet Skia4Delphi qui propose de remplacer le moteur graphique de FMX (disponible aussi pour VCL) par Skia de Google...ceux qui bossent dessus sont très enthousiastes

une bibliothèque tierce, comme il y en a déjà beaucoup, mais, effectivement, intéressante en tout cas niveau graphique elle corrige certains bugs (pas toujours)

Citation:

personnellement j'aurais préféré une initiative de réécriture de Skia en Pascal

Moi j'eusse préféré que SKIA soit intégré "nativement" dans Delphi
07/06/2022, 08h11
SergioMaster

Citation:

Envoyé par HTML-Dev

C'est quoi FMX de base [liveBindings :arf: ?] Je peux l'avoir sans base ? :oops:

Arrête de te faire une fixette sur LiveBindings, cela n'a rien à voir

Citation:

Envoyé par HTML-Dev

Tu vas me dire que le LiveBindings peut s'écrire à la main ?

Oui, c'est possible, je l'ai d'ailleurs démontré je ne sais plus dans quel tuto ou billet blog suite à ma présentation (un peu :aie:) à Paris
Tiens, d'ailleurs, cela me donne une idée de TodoAlaRetraite : éplucher les .fmx et faire des Livebindings une procédure "à l'ancienne" intégrable à l'unité .pas
07/06/2022, 09h25
Invité

Hello,

Citation:

Envoyé par SergioMaster

Arrête de te faire une fixette sur LiveBindings, cela n'a rien à voir

Oui, c'est possible, je l'ai d'ailleurs démontré je ne sais plus dans quel tuto ou billet blog suite à ma présentation (un peu :aie:) à Paris
Tiens, d'ailleurs, cela me donne une idée de TodoAlaRetraite : éplucher les .fmx et faire des Livebindings une procédure "à l'ancienne" intégrable à l'unité .pas

Il y a quelque chose que je n'ai pas saisi : tu es capable avec Delphi de faire un programme GUI (de gestion par exemple) sans utiliser de LiveBindings ? Moi pas. Tous tes exemples utilisent le LiveBindings. C'est un effet de style, un choix délibéré ? Ou une obligation éventuellement contournable par un code délirant pour s'en passer. Tu te souviens comment tu utilisais les BDD avec Delphi 7 ? Ce n'est pas une fixette mais une pratique de développement incontournable avec Delphi. Et à partir de ce moment-là

Je me demande comment un jeune programmeur biberonné au LiveBindings peut lui échapper ensuite et migrer vers un autre langage. J'ai pas eu ce problème pour migrer vers Qt. Je n'ai pas eu le temps de me reconfigurer "LiveBindings". Je juge cette inféodation nuisible et improductive quant aux problèmes et aux insuffisances rencontrés. Vivement qu'on tourne la page et qu'on dispose d'un produit commercial ouvert, solide, réellement généraliste, moderne... Bref un Qt en Pascal :mouarf: Pas de chance pour les Pascaliens qui ont le choix entre un produit opensource qui a le mérite d'exister, qui dispose d'un IDE multi OS, mais qui est dépassé faute de moyens quand on le compare à Qt, un produit commercial composé de bidouilles, d'add-on ou d'add-in, un puzzle commercial bling-bling au final beaucoup moins performant qu'un Qt.

Bon j'arrête-là. Mais je ne comprends pas vos positions. Vous êtes réellement satisfaits de cet IDE ? de la manière de programmer qu'il impose... Tout cela au motif qu'il est plus ou moins multi-cibles, qu'il dispose d'un moteur graphique de qualité -c'est indéniable d'autant que c'est une intégration- mais vide de composants moderne [ie ceux du défunt Delphi 7 tels qu'ils étaient et encore souvent avec des évènements en moins, voire des méthodes en moins, voire des propriétés en moins] ? Si tel est le cas, rien ne changera :sleep:

pour en revenir à LiveBinding, ce n'est pas magique...la VCL et FMX sont blindés de code permettant à LiveBinding de fonctionner...j'ai d'ailleurs fait une version de la VCL avec des {$IFDEF REMOVE_LIVE_BINDINGS} et {$IFDEF REMOVE_THEMES} pour alléger le code :)

pour LB, on a par exemple ce code dans KeyPress des Edit qui va informer les "Observers" qu'une touche est appuyée...ce code ne sert qu'à LiveBindings (mais on pourrait le réexploiter pour autre chose). et on a ce genre de chose sur un peu tous les évènements des composants...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
procedure TCustomEdit.KeyPress(var Key: Char);
var
  LEditLink: Boolean;
begin
  inherited;
  LEditLink := Observers.IsObserving(TObserverMapping.EditLinkID);
  if LEditLink and (Key >= #32) and
    not TLinkObservers.EditLinkIsValidChar(Observers, Key) then
  begin
    MessageBeep(0);
    Key := #0;
  end;
  case Key of
    ^H, ^V, ^X, #32..High(Char):
      if LEditLink and not TLinkObservers.EditLinkEdit(Observers) then
        Key := #0
      else
      begin
        if LEditLink then TLinkObservers.EditLinkModified(Observers);
        if Observers.IsObserving(TObserverMapping.ControlValueID) then
           TLinkObservers.ControlValueModified(Observers);
      end;
    #27:
      begin
        if LEditLink then
        begin
          if TLinkObservers.EditLinkIsEditing(Observers) then
          begin
            TLinkObservers.EditLinkReset(Observers);
            SelectAll;
          end;
          Key := #0;
        end;
      end;
    Char(VK_RETURN):
      begin
        if Observers.IsObserving(TObserverMapping.EditLinkID) then
          if TLinkObservers.EditLinkIsEditing(Observers) then
            if TLinkObservers.EditLinkTrackUpdate(Observers) then
              Key := #0; // No beep if tracking (note that descendent classes like TMemo will not get VK_RETURN)
        if Observers.IsObserving(TObserverMapping.ControlValueID) then
        begin
          if TLinkObservers.ControlValueTrackUpdate(Observers) then
            Key := #0;
        end;
      end;
  end;
end;

l'approche TDBEdit me semble plus simple et naturelle...même si elle impose de rendre les composants DBAware

et le code est similaire ... en plus simple :)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
procedure TDBEdit.KeyPress(var Key: Char);
begin
  inherited KeyPress(Key);
  if (Key >= #32) and (FDataLink.Field <> nil) and
    not FDataLink.Field.IsValidChar(Key) then
  begin
    MessageBeep(0);
    Key := #0;
  end;
  case Key of
    ^H, ^V, ^X, #32..High(Char):
      if not FDataLink.Edit then
        Key := #0;
    #27:
      begin
        FDataLink.Reset;
        SelectAll;
        Key := #0;
      end;
    ^A:
      begin
        SelectAll;
        Key := #0;
      end;
  end;
end;

Pour la gestion des Themes c'est un peu pareil, pour chaque composant stylé on a ce genre de chose

Code:

1
2
3
4
5
 
class constructor TCustomEdit.Create;
begin
  TCustomStyleEngine.RegisterStyleHook(TCustomEdit, TEditStyleHook);
end;

avec une class "Hook" qui vient prendre en charge le rendu par thème

07/06/2022, 09h44
SergioMaster

Citation:

Envoyé par HTML-Dev

Il y a quelque chose que je n'ai pas saisi : tu es capable avec Delphi de faire un programme GUI de gestion par exemple sans utiliser de LiveBindings ?

Oui, un peu plus long à écrire mais oui

Citation:

Tous tes exemples utilisent le LiveBindings. C'est un effet de style, un choix délibéré ?

un choix délibéré, pour montrer les Livebindings

Citation:

Ou une obligation éventuellement contournable par un code délirant pour s'en passer.

pas "délirant", juste plus long à écrire (ce que ma philosohie de scaphandrier m'évite de faire. Le principe, utilise la poussée d'Archimède quand tu en as la possibilité

Citation:

Tu te souviens comment tu utilisais les BDD avec Delphi 7 ?

je maintiens encore des programmes D3.

Quelle est la différence entre un composant DB et un composant FMX avec LiveBindings
- Dans le DBxxxxx il y a un Datasource utilisé
- Dans le composant FMX cela passe par un BindSource (qui fait, en gros, la même chose de le Datasource) et qui permet à RTTI (car oui Livebindings n'est que du RTTI) de faire le boulot

Et à partir de ce moment-là je ne suis plus d'accord avec ta liste car avec VCL c'est la même chose

Citation:

ce n'est pas une fixette.

Oh que si :mouarf:
07/06/2022, 09h45
SergioMaster

Citation:

Envoyé par Paul TOTH

pour en revenir à LiveBinding, ce n'est pas magique...la VCL et FMX sont blindés de code permettant à LiveBinding de fonctionner...j'ai d'ailleurs fait une version de la VCL avec des {$IFDEF REMOVE_LIVE_BINDINGS} et {$IFDEF REMOVE_THEMES} pour alléger le code :)

Intéressant ça, et tu vires RTTI ?
07/06/2022, 10h02
SergioMaster

1 pièce(s) jointe(s)

Citation:

Envoyé par pprem

Pour l'affichage, on trouve des trucs exploitables sur GitHub (comme le composant DzHTML qui n'affiche pas du HTML mais un truc avec un système de balises à lui) et plein de choses payantes. Skia4Delphi propose un champ texte amélioré. Pour afficher du HTML, il y a le TWebBrowser (quand on n'a pas de soucis de configuration) mais c'est l'artillerie lourde.
Pour saisir et afficher du HTML avec une bonne prise en charge, la seule librairie que j'ai pu tester qui soit efficace c'est https://delphihtmlcomponents.com (payant, mais version d'évaluation

Ce week-end, je me suis amusé avec DzHTML pour écrire un programme censé être mieux (pas difficile à mon goût) que le programme Todo de Microsoft.

À ce propos, je me demandais comment extraire les todos des sources d'un projet entier, mais, j'entrevois la réponse avec les expressions régulières, futur todo dans mon programme Todo :ptdr:
ça plus l'ajout de fichier seront mes étapes du WE prochain. Prévu initialement hier, je ne vous raconte pas la galère depuis dimanche après midi quand j'ai voulu mixer une version Lite (SQLite) et une version "collaborative" (Firebird) :bug: je m'en suis sorti :aie: (de justesse et mal) après même apperçu d'un problème de copier-coller d'un composant FDSQLUpdate

Pour ce que j'avais comme idée en tête DZHTML me semblait suffisant
Pièce jointe 620387
Dommage que l'auteur ne ce soit pas davantage attaché aux balises standard

Citation:

{DZHtml tags
<A[:abc]></A> - Link
 - Bold
 - Italic
 - Underline
<S></S> - Strike out
<FN:abc></FN> - Font Name
<FS:123></FS> - Font Size
<FC:clColor(VCL)|Color(FMX)|$123456|$12345678|#123456|#12345678></FC> - Font Color
<BC:clColor(VCL)|Color(FMX)|$123456|$12345678|#123456|#12345678></BC> - Background Color
 - Line Break
<NBR> - Prevent line break after #13#10 sequence
<L></L> - Align Left
<C></C> - Align Center
<R></R> - Align Right
<T:123> - Tab
<TF:123> - Tab with aligned break
<IMG:nnn> - Image from ImageList where 'nnn' is image index
<IMGRES:name> - PNG image from Resource where 'name' is the resource name
<UL></UL> - Unordered list
<OL></OL> - Ordered list
<LI></LI> - List item
<FLOAT:X,Y[,Width]></FLOAT> - Floating area
<SPOILER:name></SPOILER> - Spoiler Title
<SDETAIL:name></SDETAIL> - Spoiler Detail
<LS:nnn></LS> - Line spacing where 'nnn' is the height in pixels
 - Superscript
 - Subscript}

mais rien ne nous empêche d'améliorer le code (une fois compris :mrgreen:)

bon l'interface laisse encore à désirer (pour info @gilles cette page n'a pas de LiveBindings :lol:)

Je n'avais pas pensé à Skia4Delphi :oops: et voulais éviter DelphiHtmlComponent
07/06/2022, 10h09
Invité
Citation:

Envoyé par Paul TOTH

pour en revenir à LiveBinding, ce n'est pas magique...

Je ne dis pas que c'est magique. Je dis 2 choses [voire 3]
1. Je ne veux pas m'en servir non pas par fixette mais pas raisonnement. J'ai toujours demandé à mes élèves de développer leur sens critique.
2. C'est pour moi une gymnastique qui ne vaut pas le coup compte tenu du reste du contexte [des composants vieillots dignes de delphi 7 : TEdit, Tlabel, TMemo,...] et encore en desktop firemonkey avec moins d'évènements qu'en VCL
3. Une approche [pas un code puisqu'il n'y en a plus] outrageusement compliquée, totalement absconse pour un résultat et des performances douteuses : en XE 7, j'avais réalisé 5 tests de traitements statistiques d'une base de données de relevés automatiques de température par une sonde distante, données chargées dans une TGrid ou équivalent.
- XE7 Livebinding et FireDac
- XE7 sans Livebinding avec Unidac directement connecté de manière classique sur des composants TMS
- Lazarus même code que le précédent
- Qt avec une programmation type Lazarus : on lit direment sur le Query
- Qt avec des classes QTableModel
Quel était le moins performant ? XE7 Livebinding et FireDac !

Bon je me remets au travail même quand on est à la retraite... Fini le WE !
PS : Pour moi, les lfm, dfm... sont simplement la traduction de l'UI Designer. Quand on commence à faire des liaisons avec des des bases de données dans ces fichiers, cela devient une mixture indigeste... On laisse l'UI d'un côté dans son langage de description et tout le reste s'écrit en C++ ou en Pascal
07/06/2022, 10h16
Paul TOTH

Citation:

Envoyé par SergioMaster

Intéressant ça, et tu vires RTTI ?

virer RTTI c'est plus compliqué, car toute la gestion des flux DMF/FMX est basée dessus :) mais à une époque de l'avais fait LVCL est un début de réécriture de la VCL de Delphi 6 / Kylix, complètement débarrassée des RTTI...mais ça impose que chaque composant connaisse le nom des ses propriétés.

et la RTTI c'est pas le mal, c'est super pratique en fait pour sérialiser en JSON/XML/CeQueTuVeux ... après elles souffrent de l'historique...C'est une structure mémoire assez mal foutue quand on y pense, mais la changer casserait sans doute la compatibilité avec pleins de produits. Exemple de choses que je ferais : extraire les chaînes dans un dictionnaire afin d'avoir des structures de taille fixe et éviter les redondances...aujourd'hui tu es contrains de parcourir la structure pour sauter les chaînes de taille variable qui sont nécessaire dupliquées si deux objets ont des propriétés avec le même nom.
07/06/2022, 10h29
pprem

On s'est nettement éloignés du sujet de base, Python dans Delphi, Delphi dans Python, oui ou non ?

Pour moi, il faut voir Python comme une extension possible de nos programmes. Au lieu de passer par une DLL pour faire un truc, on passe par du code dans un autre langage.

Etrangement on se posait moins de questions il y a 20 ans quand on devait distribuer 20 DLL avec un exe pour afficher un truc à l'écran.

Ceci dit, si on peut éviter les dépendances, quelles qu'elles soient, c'est toujours mieux, donc trouver l'équivalent Pascal de ce qu'on aurait déjà en Python me semble être la meilleure approche. Après tout est question de temps et d'ampleur du travail à faire. Le bénéfice / risque est-il vraiment en faveur du bénéfice ? Est-ce que c'est pas juste pour le plaisir d'avoir un truc qu'on sera seul à utiliser et maintenir alors que le troupeau (et la team de mainteneurs) se focalisera sur l'autre projet ?

--

Concernant les LiveBindings, oui, Gilles tu te concentres trop dessus et surtout sur l'assistant visuel (forcément très simpliste) pour les mettre en place. On peut très bien s'en passer quand on sait coder comme on l'a toujours fait depuis Delphi 1. Peut-être devrais-tu jeter un oeil à Open Wire que Boian Mitov a finalement mis à disposition gratuitement. Ca ajoute un éditeur dans la conception des fiches pour lier les composants entre eux. Une sorte de Live Bindings aussi, mais avec une philosophie légèrement différente.

Concernant le manque de HTML dans FMX (ou au moins de flexibilité de mise en forme des textes, puisque pour le reste on peut tout faire nous-mêmes), c'est aussi un truc qui n'était pas apparu à l'époque comme nécessaire : ceux qui l'ont développé n'avaient probablement pas la culture web où tout se paramètre facilement avec une feuille de style. C'est frustrant, j'en conviens, mais rien n'empêche de le faire nous-même et distribuer la solution.

On peut aussi faire des tickets de demandes de nouvelles fonctionnalités. C'est disponible sur https://quality.embarcadero.com et peut-être que ça permettra à Embarcadero de voir qu'il y a des demandes dans ce sens qui ne seraient pas remontées par leurs clients entreprises car elles utilisent du DevExpress ou du TMS Software partout plutôt que le socle de base fourni avec delphi.

--

Pour DzHTML, c'est vrai que son choix de balises est étrange, mais après tout ça reste un format classique pour mettre un texte en forme et même si son code source n'est pas limpide, on peut l'adapter (ou convertir du HTML) assez facilement.
07/06/2022, 10h31
pprem

Citation:

Envoyé par HTML-Dev

Quand on commence à faire des liaisons avec des des bases de données dans ces fichiers, cela devient une mixture indigeste... On laisse l'UI d'un côté dans son langage de description et tout le reste s'écrit en C++ ou en Pascal

C'est pourtant ce qui se fait en VCL avec les composants dédiés depuis Delphi 1.
07/06/2022, 11h08
Invité

Citation:

Envoyé par pprem

C'est pourtant ce qui se fait en VCL avec les composants dédiés depuis Delphi 1.

Ouii mais on fait cela avec une chaine de composants spécialisés donc optimisés pour cette fonction.

D'ailleurs, je n'ai jamais été vraiment convaincu par la fragilité des composants TDBxxx. A une époque les liaisons internet étaient fragiles et tout s'écroulait y compris l'application en cas de rupture de la liaison. Aussi en Lazarus et un peu en VCL, j'avais créé mon proprement composant un TlzStrindGrid. J'utilisais les threads pour les chargements pour avoir les premiers enregistrements affichés disponibles immédiatement, le reste du chargement, threadé lui aussi, continuait en sous-tache. Pas facile de threader une connexion... Et évidemment comme à l'époque le multisemect non contigu n'était pas disponible dans les TStringGrid de base, j'avais dû le créer. Ainsi que des icones de tris dans les header et des champs de recherche intégrés. Je m'étais inspiré de ce que proposait Windev à l'époque qui ergonomiquement laissait Delphi à des années... de retard. Il doit y avoir plein de discussions à ce sujet dans le forum Lazarus.

Mais là encore tu vois, je n'apprécie pas les composants FireDac and Co de Delphi. C'est typiquement orienté Windows où tu copies la libmyslclent.dll dans le répertoire de l'application. Mais il en est tout différemment en Linux et sous mac OS. Tu déploies régulièrement tes productions sur Linux et os mac ? Donc tu es obligé de faire des paquets pour installer les drivers des bases de données comme MariaDB. C'est une horreur surtout si un autre driver de la même BDD utilisée par un autre programme mais d'une autre version est déjà installé sur le poste. Il faut prévoir le cas. C'est pas parce que tu installes ton programme que celui de ton Collègue doit ne plus fonctionner. Avec UniDac, on ne déploie pas de driver de BDD. En Qt, je compile statiquement en incluant openssl et le driver de la BDD utilisée et cela d'ailleurs sous les 3 OS. Pour le déploiement cela change tout, y compris pour les mises à jour. En Lazarus/Delphi c'est un add-on payant. En Qt, c'est un savoir-faire, chronophage à chaque changement de version notamment de compilateur, mais très satisfaisant. La liberté, la fierté aussi :oops:

Cordialement. Gilles
07/06/2022, 12h18
SergioMaster

Citation:

Envoyé par HTML-Dev

Mais là encore tu vois, je n'apprécie pas les composants FireDac and Co de Delphi.

FireDac est l'ancien <machin>Dac (AnyDac ?) concurent de Unidac à l'époque de D7

Citation:

Avec UniDac, on ne déploie pas de driver de BDD.

Là, c'est de l'exagération.
Tout dépend du SGBD, seuls certains SGBD sont en direct (SQLite, MySQl, PostGreSQL, RedShift, Nexus, DBF ?)
dans mon cas, Firebird, je suis obligé de déployer la dll cliente tout pareil
07/06/2022, 12h22
SergioMaster

Citation:

Envoyé par pprem

Pour moi, il faut voir Python comme une extension possible de nos programmes. Au lieu de passer par une DLL pour faire un truc, on passe par du code dans un autre langage.

Étrangement, on se posait moins de questions il y a 20 ans quand on devait distribuer 20 DLL avec un exe pour afficher un truc à l'écran.

:plusser:

Citation:

Envoyé par pprem

Concernant les LiveBindings, oui, Gilles tu te concentres trop dessus et surtout sur l'assistant visuel (forcément très simpliste) pour les mettre en place.

:plusser: aussi surtout la partie "très simpliste"

Citation:

Peut-être devrais-tu jeter un oeil à Open Wire que Boian Mitov a finalement mis à disposition gratuitement.Une sorte de Live Bindings aussi, mais avec une philosophie légèrement différente.

à l'époque je n'avais pas accroché

Citation:

Envoyé par pprem

Pour DzHTML, c'est vrai que son choix de balises est étrange, mais après tout ça reste un format classique pour mettre un texte en forme et même si son code source n'est pas limpide, on peut l'adapter (ou convertir du HTML) assez facilement.

Je m'y mettrai un jour, peut-être
09/06/2022, 09h57
pprem

Juste histoire d'en rajouter une couche sur Oui/Non Python et qu'est-ce qu'il propose à intégrer à Delphi, Embarcadero a publié plusieurs dépôts de code sur GitHub cette semaine pour simplifier les interactions entre un projet Delphi et des librairies d'IA / ML en Python.

A 17 heures Jim McKeeth présentera une session sur l'intégration de PyTorch à un projet Delphi en utilisant ces codes sources publics. dispo pur tout le monde, y compris les utilisateurs de la Community Edition.
https://blogs.embarcadero.com/pytorc...ces-libraries/
04/07/2022, 11h57
der§en

Je vient d’installer, Python 3.10.5 ainsi que PyScripter.

Ensuite, j’ai voulu installer Python4Delphi, mais impossible de compiler PythonVcl270.bpl sur l’erreur identificateur non déclaré : PyExc_RuntimeError dans le fichier WrapVclForms.pas.

Dommage que ce package, ne soit pas mieux testé avant sa publication :aie: , car cela avait l’air très intéressant !
05/07/2022, 10h32
pprem

Citation:

Envoyé par der§en

Ensuite, j’ai voulu installer Python4Delphi, mais impossible de compiler PythonVcl270.bpl sur l’erreur identificateur non déclaré : PyExc_RuntimeError dans le fichier WrapVclForms.pas.

Dommage que ce package, ne soit pas mieux testé avant sa publication :aie: , car cela avait l’air très intéressant !

Difficile de tester toutes les combinaisons et configurations possibles surtout lorsqu'un langage ne respecte pas la compatibilité ascendante à laquelle on a été habitués en tant que développeurs Delphi (ou Pascal en général).

Tu n'as plus qu'à ouvrir un ticket directement sur le projet https://github.com/pyscripter/python4delphi/issues
(et éventuellement proposer la solution si tu l'as trouvée)
15/07/2022, 10h02
Gouyon

Citation:

Envoyé par Paul TOTH

Pourquoi utiliser Python sous Delphi ? personnellement je ne le ferais pas...je n'aime pas Python :) mais une des raisons serait d'offrir à un utilisateur la possibilité de créer un plugin pour un logiciel dans un langage plus populaire que Delphi....et d'utiliser éventuellement les bibliothèques Python existantes dans ce plugin...

Moi non plus je ne suis pas très Pythonphyle mais il se trouve que pour un projet je suis en train de faire de l'IA (réseau de neurone et deep learning) et la plus part des librairies sont sous python (TensorFlow...). Du coup bien forcé d'en passer par là.
03/08/2022, 14h38
der§en

Je vient d'installé, la dernière version (M+1 depuis ma précédente tentative) et mon problème a l'installation a disparu :mouarf:

Du coup, je regarde les démos de Python 4 Delphi !

Je vais aussi regarder du coté de Delphi VCL 4 Python.

:ccool: