Version imprimable
Je vois pas en quoi Delphi est plus couteux que d'autres langages...Citation:
Envoyé par Coudrak
A part si c'est pour faire du moins disant en terme de masse salariale... Mais ça c'est le crédo des SSII quelque soit le langage utilisé d'ailleurs...
Faux, j'ai débuté pas mal de nouveaux projets avec Delphi ces dernières années... Et je continue...Citation:
Envoyé par Coudrak
hello,
je peux à ce sujet partager mon expérience récente.
Après mon année sabbatique, j'ai envisagé de quitter mon poste d'enseignant. Je me suis donc mis en recherche de postes de développeur dans les langages que je maîtrise de manière "employable" autrement dit, Qt, Lazarus, et les produits PC Soft. Evidemment, j'ai regardé du côté de Delphi... en passant.
J'ai failli migrer à Bordeaux pour un poste Windev puisque le Ministère ne me proposait pas la région que je souhaitais. J'ai commencé mes recherches de développeur début juin. Cela s'est joué en quelques jours, fin juin. Je devais commencer à Bordeaux en Windev début juillet, quand un poste s'est "débloqué".
Alors
- En Qt, comment dire, c'était de la programmation au découpage. Pas intéressant. Peu de postes disponibles au final.
- En Windev, Webdev et Webdev Mobile, beaucoup d'offres... et certains projets très intéressants (de nouveaux projets à développer dans de petites équipes dans des approches très collaboratives). Le nombre de propositions dans l'environnement PC SOFT était plutôt conséquent.
- En Lazarus, aucune offre.
- En Delphi, 2 types de besoins : du mobile (Firemonkey) pour de nouveaux projets et de la maintenance ou de la mise à niveau VCL exclusivement (i.e. pas de projets nouveaux et aucun portage en FireMonkey desktop).
Alors concernant l'avenir de Delphi, de ma lorgnette, je suis dubitatif, (seulement dubitatif). Mon ressenti est que Firemonkey, pour le mobile, est évidemment envisageable... mais la concurrence est rude et le produit FMX est curieusement positionné. Si cette plateforme de développement était un outil exclusivement adapté au mobile, il aurait certainement une meilleure aura que le RAD actuel. Il occupe une position hybride à la Windows 8.
A ce moment là, on aurait un vrai Delphi, réservé au développement Desktop exclusivement. Une sorte de Lazarus. car pour le moment, et depuis longtemps, pour le Desktop, je ne suis pas convaincu par Firemonkey compte tenu de la trop lente évolution pour s'adapter aux "besoins personnalisés". La complexité du code, les problèmes rencontrés, les restrictions des composants FMX comparés à leurs homologues VCL éliminent Firemonkey à mon sens. Il reste évidemment VCL. Mais curieusement, aucune des annonces qui m'ont potentiellement intéressées ne concernait de nouveaux projets.
A bientôt. Cordialement. Gilles
Bonjour,
Je ne vois pas en quoi c'est gênant de devoir utiliser la même plateforme de développement pour le mobile et le desktopCitation:
Envoyé par Selzig
Je suis aussi étonné, je ne trouve pas que le code de FMX soit particulièrement complexe, je n'ai pas rencontré de problèmes particuliers non plus lors de son utilisation et je trouve qu'il évolue assez rapidement compte tenu du fait que cette librairie cible plusieurs OS.Citation:
Envoyé par Selzig
Bonjour,Citation:
Envoyé par free07
Très curieux comme discours pour moi. Il est en total désaccord avec mes expériences. Comme quoi les approches sont aussi nombreuses que variées.
Je prends un exemple récent pour illustrer mes propos. Vous connaissez certainement Delphi 7 ou Lazarus. J'en parlais encore ce matin dans une autre discussion : sous FireMonkey, prenez l'écriture d'un messageDialog et comparez à celui de XE vous verrez certainement une différence avec leur écriture sous Delphi 7 ou Lazarus pour une même action. On compte le nombre de lettres (plutôt de '.') ? Toujours dans cette approche que je viens de "heurter" : MessageDlg est remplacé sous XE par un machin Sync ou ASync pour le même résultat. Je ne parle pas des styles... Non ce n'est pas plus compliqué ! J'oubliais également tous les codes XE1..7 incompatibles avec ceux de XE10.3 ! J'ai renoncé à l'espoir de faire des composants sous FMX alors que j'en fais régulièrement sous LCL et Qt. On en trouve plein sous VCL, LCL. Ceux sous FMX réalisés par des amateurs (éclairés) sont nettement moins nombreux et XE existe depuis longtemps. On en est à la version 10.3.3. Même TMS Software a du mal à intégrer une gestion des styles conforme (i.e. compatible)!
Maintenant comparez les événements des objets ou des composants de la VCL et ceux de FMX et éventuellement ceux de LCL (qui gère Windows, Linux et mac OS). Vous comprendrez pourquoi les forums contiennent des "Comment remplace-t-on sous FMX l’événement... qui n'existe pas ?" Affirmer qu'avec FMX sous les 3 OS Desktop on peut faire aussi fin, aussi détaillé, aussi précis (i.e. sans concession) que ce que l'on est capable de réaliser avec la VCL sous Windows ou la LCL, est en contradiction totale avec mes approches. Des approches alambiquées, inutilement complexes, parfois inexistantes, en tout cas toujours chronophages et hésitantes, pour obtenir finalement un résultat usuel dans l'OS développé... et dont je ne veux pas faire la concession.
Cordialement. Gilles
Bonjour,
Je ne connais pas Delphi 7, à cette époque je n'utilisais pas Delphi, je l'ai utilisé à l'apparition justement de FMX ( avant j'ai utilisé la VCL pour un projet avec C++ Builder et dans les années 1998-2000 ) Je ne vais pas raconter tout mon parcours mais j'ai vécu un certains nombres d'années sans la VCL et puis découverte de Delphi avec FMX
Tout ça pour dire que c'est peut être pour cette raison, j'ai un regard neuf sur FMX ce qui m'amène à n'avoir pas la même vision que vous.
Ensuite, je n'ai jamais affirmé que l'on puisse être aussi précis en FMX qu'avec la VCL pour Windows. FMX ciblant plusieurs OS, il est normal qu'il ne vas pas répondre tout de suite à toutes les exigences et il me semble actuellement injuste de comparer les deux librairies pour un seul OS ( Windows en l'occurence ), la VCL existe depuis plus de 25 ans alors que FMX est apparu en 2011.
FMX doit évoluer mais c'est surement pas aussi rapide que l'évolution de la VCL car FMX cible plusieurs OS.
Cordialement
Thierry
bonjour,
tout à fait d'accord, FMX est un Framework qui permet de développer pour plusieurs plate-formes, qui n'est donc pas dédié à Windows ou à linux ou aux mobiles. C'est selon moi une grande force, mais sa contre partie est qu'il ne peut pas être aussi parfait sur une plateforme en particulier en comparaison avec un Framework dédié à cette plateforme.Citation:
Envoyé par free07
@++
Dany
Bonjour,Citation:
Envoyé par skywaukers
c'est une concession que n'apprécieront pas certains utilisateurs. Alors parce qu'il est développé en FMX, le logiciel sous Linux ou mac OS ne peut pas être aussi bien que celui sous Windows développé avec VCL. C'est une bonne vieille vision de "Windowsien". Donc à quoi sert exactement FMX si ce n'est au mobile puisqu'il est inférieur en Desktop ?
Comme je travaille sur tous les OS sans aucune préférence, vos propos qui traduisent effectivement une réalité, convergent avec les miens. Mais si vous voulez un vrai IDE capable de faire les mêmes choses sous Windows, Linux et mac OS (avec une finesse au moins égale à celle de VCL, qui gère les styles multi-OS de manière plus compréhensible et rationnelle donc efficace que FMX), passez à Qt ! Il sait faire du mobile aussi mais je ne pratique pas avec et donc je ne l'ai pas évalué sur ces plateformes.
Cordialement. Gilles.
soyons aussi réalistes, dans combien de cas concrets (de la vraie vie en entreprise) FMX ne va pas permettre de donner satisfaction à un utilisateur ?Citation:
Envoyé par Selzig
Avec la même productivité de développement ? Et puis comme vous dites vous n'avez pas testé sous mobile, donc vous ne pouvez affirmer que QT est parfait sur toute les plate-formes.Citation:
Envoyé par Selzig
Bonjour
Pour répondre à cela je pense être relativement bien placé ;) FMX nécessite une nouvelle tournure d'esprit par rapport à VCL (c'est là que la comparaison échoue entre les deux) , a des lacunes en exemple :Citation:
Envoyé par skywaukers
- le RadioGroupBox (très utilisé en entreprise du moins pour moi) sensible aux données (livebindings), composant que je peine à développer (partie livebindings) même s'il y a une raison plus ou moins logique à cela sous Android le radiogroupbox serait remplacé par un combobox
- rien sur un wysiwyg HTML en standard, ni de RTF (là TMS fait mieux)
Bien sûr il y a des composants tiers dont ceux de TMS, mais je suis d'accord avec Selzig, TMS ne fait pas tout (dont ce radiogroupbox lié) et n'est pas exempt de bogues même s'ils sont très réactifs
Après où je suis en désaccord c'est sur cet "impérieux" besoin de créer des composants l'immense avantage de FMX est que des composants peuvent être parents d'autres composants, ce qu'en VCL peu peuvent le faire.
Là, totalement d'accord, pour avoir un peu tâter QT on est loin de Delphi/C++ Builder. C'est même un argument que j'ai souvent mis en avant.Citation:
Avec la même productivité de développement ?
Mais, une fois de plus on s'éloigne, cela n'a rien à voir avec l'avenir pour les développeurs Delphi
Y a t-il des postes à pourvoir ? Réponse mitigée, une entreprise à quelques centaines de mètres de chez moi a cherché longtemps sans trouver de candidats d'un autre côté je ne cherche pas de nouveau poste donc ne m'y intéresse guère. Il y aura une opportunité quand je prendrai ma retraite mais qui serait assez fou pour reprendre mon activité (en télétravail depuis 1998) :mouarf:
Bonjour,Citation:
Envoyé par skywaukers
pour moi, il y a 2 types de plateformes :
- celles avec plusieurs écrans, une souris, un clavier, des périphériques extérieurs à foison... J'appelle cela Desktop. Je ne produis que des projets qui seront compilés (Pascal, C++, PureBasic,... ) et si possible sans diffusion de librairies annexes notamment pour les drivers d'accès aux BDD... simplement pour les diffuser et les installer facilement dans tous les OS. Éventuellement quelques fichiers annexes pour la gestion du i18n. Ensuite, il reste à déterminer quel GUI choisir. Par exemple en C++, il y a Qt ou WxWidgets. Les 2 sont bons. Qt intègre nativement le développement asynchrone, l'approche Signal/Slot, et ne gère pratiquement pas les exceptions. Il dispose également d'un concept génial qui s'appelle la promotion et que je n'ai retrouvé nulle part ailleurs. Avec WxWidgets, on reste en synchrone comme Lazarus et Delphi sauf à utiliser des threads évidemment.
- un écran, les doigts (un doigt), peu de périphériques, une gestion poussive et tardive du multifenêtrage, rarement de RJ45, un OS disons limité, je ne parle pas de la mémoire ni du stockage,... Le truc que j'embarque quand je veux voyager léger et encore, je préfère prendre mon portable. J'appelle cela le mobile.
En réalité, pour le deuxième cas, Windev Mobile est presque toujours à la hauteur pour mes développements. J'ai rencontré une fois une lacune dans la gestion de l'UDP (avec la version 22) et le complément a été implanté en 24. Je ne développe en mobile qu'en partie complémentaire d'un développement Desktop déjà réalisé ou en cours de réalisation. MariaDB, Wifi, UDP me suffisent en général. Je teste régulièrement les capacités de certaines solutions de développement mobile en réalisant des démonstrations pédagogiques comme l'effet de fronde (en mécanique "céleste"). Le résultat obtenu avec FireMonkey dans cet exercice est sensationnel mais quelle galère. Je crois me souvenir qu'il a été réalisé en XE7. Avec certitude il m'est impossible de compiler son source en XE10. Mais pour le reste, comme je l'ai déjà écrit, il existe d'autres solutions pour développer en mobile de manière aussi rapide et adaptée à mon cas. Je pense que Firemonkey me conviendrait pour développer en mobile.
Pour Qt, il faudrait que j'apprenne le QML pour les mobiles. Pourquoi pas... Il devient prometteur semble-t-il.
Je rappelle également qu'il m'a été plus facile de me convertir à Qt à partir de Lazarus que de m'adapter au charabia de FireMonkey et à ses approches additionnelles (Styles et LiveBinding) incontournables.
J'installe régulièrement Lazarus sous mes 3 OS Desktop habituels et je suis assez stupéfait par les progrès sous mac OS. Pour Linux, j'avais déjà l'habitude de m'adapter même si cela demande souvent un travail chronophage. Enfin les générateurs de rapports compatibles Pascal (FastReport et autres) sont minables comparés à NCReport pour Qt. On arrive quand même maintenant à générer des pages PDF grâce à AdvPDFLib (VCL) et FMXPDFLib de TMSSoftware en Delphi (mais pas en Lazarus). Mais c'est beaucoup moins pratique qu'un générateur de rapports.
A bientôt. Gilles
Non ce n'est pas vrai :mrgreen: QML a été créé en 2009 (c'est un JavaScript très bridé avec des concepts propres) et il a bidé. Et en 2017-2018, The Qt Company voulait remplacer le moteur d'affichage 2D des fenêtres par le QtQuick/ QML (pour relancer le langage)Citation:
Envoyé par Selzig
Tiens ? Curieux que cela existe encore dans les dernières versions de Qt. "Bidé" je ne sais pas ce que cela veut dire. Delphi bide-t-il ? Par contre, oui, Qt Quick est limité... comme les OS des tablettes donc de nombreux développements sont finalement des sites adaptés :weird:. A priori adapté donc :mouarf: De toute façon ce n'est qu'un projet de découverte lors de prochaines vacances.Citation:
Envoyé par foetus
Mais je le reprécise parce que j'ai l'impression de ne pas être très clair. Je distingue les outils de développement des projets desktop, de ceux des projets mobiles. Et c'est ce que je reproche à FMX qui lui ne fait pas de distinction...au même titre que j'appréciais peu Windows 8, l'OS à "tout" faire (Desktop et mobile). Je crois que chacun a ses spécificités et que marier celles des 2 approches, nuit au moins à l'une d'entre elles. Et j'estime que pour Firemonkey, la nuisance porte sur le développement Desktop... Et VCL n'est pas une solution de substitution puisque réservée à un seul OS Desktop : Windows. Voilà mon propos.
Ceci dit, je ne fais pas la promo de Qt. Ils sont assez "grands" pour la faire eux-mêmes. Mais je fais simplement part de mon expérience et de la solution que j'ai adoptée face à ma problématique... Sachant qu'évidemment, j'ai un faible (toujours) pour le développement en Pascal et spécialement tel que le proposait Delphi 7 et le propose encore Lazarus. Mais parfois le cœur et la raison s'éloignent.
Cordialement. Gilles
A mon tour de lancer un pavé dans la marre :) : quelle avantage y-a-t il à utiliser QT (mais aussi Delphi) pour le mobile plutôt que PWA ?Citation:
Envoyé par Selzig
@++
Dany
Très peu utilisée :mrgreen: Évidemment il est toujours présent dans Qt mais The Qt Company tente d'élargir son utilisation.Citation:
Envoyé par Selzig
D'ailleurs, 1 de ces freins de ce que j'ai compris, c'est qu'il faut coder une couche entre le QML et le C++ et cela demande du temps.
C'est peine perdu :wow:Citation:
Envoyé par Selzig
Windows a tué ses bibliothèques natives. Tous les développeurs qui se sont investis dans les bibliothèques WinForms et WPF et éventuellement Silverlight et qui demandent l'avenir, la seule réponse de Microsoft c'est .Net Core après que la bibliothèque UWP a bidé (<- très peu utilisée)
Mac et Cacoa a sa part de marché ultra faible contre elle. Sans parler qu'Apple et sa bibliothèque Metal non compatible Vulkan s'est mis à dos tous les développeurs multimédia/ 3D.
Et enfin Linux avec Gnome et Qt.
Mais Qt c'est une machine de guerre et ses choix de licences de l'enfer qui notamment refusent la compilation statique.
Gnone 3.0 qui se fait pourrir depuis 7 ans sur ces choix douteux d'ergonomie, de design. D'ailleurs Mate est un fork de Gnone 2, ce n'est pas pour rien.
:whistle: Ce n'est pas pour rien que les solutions à base de Chronium explosent pour le Desktop. Ou à défaut, des solutions soit qui gèrent tout l'affichage (comme Qt ou FMX) soit qui sont basées sur des langages type JavaScript (comme QML)
Et en plus cela résout le problème multiplateforme.
:mrgreen: C'est pour cela que la bibliothèque VCL fait un travail énorme afin d'apporter une solution viable sous Windows au chantier Microsoft : mais il faut avoir les composants qui vont bien, les thèmes qui vont bien et surtout la dernière version de Builder.
Rebonjour,
pour Qt, il y a des versions payantes peu chères dites startup. Ensuite si votre CA augmente, vous avez les moyens de vous payer une licence complète. Par contre, il est vrai que l'on doit compiler statiquement l'environnement et qu'il y a des limites. Mais par exemple on peut y intégrer mariaDB ce qui fait que l'on n'a plus à distribuer les bibliothèques clientes, ou par exemple, on peut intégrer SQLcipher "dans" SQlite et livrer ainsi des exe totalement "autonomes".
Je reviens à mon travail de ce matin, le portage de mon EN (la tentative).
J'ai besoin de récupérer sous Windows, les icônes des fichiers de travail de mes élèves. En Lazarus Windows et en Qt Windows, c'est fait. Je tente en FMX Windoxs. Evidemment le code VCL ne passe pas.
Je regarde sur mon moteur de recherche préféré et je lis cela qui me conseille donc de réaliser une dll VCL (ou LCL) et de l'appeler à partir de mon programme FMX. Evidemment...
S'il y a quelqu'un qui sait faire cela nativement en FMX (sans imbriquer évidemment d'units VCL) ?
Je veux bien croire que FMX sait tout faire mais, en supposant qu'il réponde à mon problème, je découvre cela où ?
Cordialement. Gilles