IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Nouvelle feuille de route d'Embarcadero 2017-2018
Les projets pour RAD Studio, Delphi et C++ Builder

Le , par gvasseur58

65PARTAGES

10  0 
Embarcadero vient de publier la nouvelle feuille de route courant jusqu’à fin 2018 pour RAD Studio, Delphi et C++ Builder. Comme la précédente, celle-ci ne constitue pas un engagement formel, mais bien un objectif à atteindre. Gageons que l’équipe d’Embarcadero fera le nécessaire pour satisfaire ses clients qui se sont sans doute vite habitués à un suivi plus rigoureux selon un planning tenu !

RAD Studio, qui rassemble Delphi et C++ Builder, se verrait ainsi amélioré avec la prise en compte des hautes définitions (HiDPI), du fenêtrage natif Z-Order d’Android et des contrôles natifs du même OS dans FireMonkey (en commençant par les contrôles de saisie de données). Les débogueurs autour de la technologie LLDB, les contrôles GUI pour WinRT/Windows 10, ainsi que l’utilitaire d’installation GetIt qui serait simplifié, constituent d’autres axes de développement mentionnés. Comme l’ont demandé de nombreux utilisateurs, dont les habitués du forum Delphi sur developpez.com, les prévisions insistent pour les versions intermédiaires avant la 10.3 (baptisée Carnival) sur l’amélioration de la qualité et des performances des produits.

Plus spécifiquement, Delphi continuerait à étendre ses possibilités sous Linux, en particulier avec la bibliothèque RTL et un débogage amélioré, et prendrait en charge MacOS en 64 bits. À noter aussi l’introduction, comme en C#, des types Nullable pour des valeurs indéterminées.

Quant à C++ Builder, il s’ouvrirait lui aussi aux serveurs Linux 64 bits avec un compilateur Clang étendu, et améliorerait son intégration des bibliothèques C++ et de CMake. La complétion de code et le refactoring devraient eux aussi être rendus plus performants.

Embarcadero a décidé de poursuivre son développement en direction de Windows sur les machines de bureau, Android et Apple sur les appareils mobiles, et Linux pour les solutions serveur. Les applications client-serveur ne sont pas en reste avec la technologie DataSnap pour laquelle il est prévu de nouveaux drivers ; il en est de même pour RAD Server, la solution proposée pour le développement et le déploiement d’applications basées sur des services, qui devrait prendre en charge les clients Angular.JS.

Comme il est permis de rêver, la feuille de route se conclut par des pistes de recherche : les cibles ARM y côtoient les interfaces graphiques Linux, les outils pour la construction de clients Web, ou encore un EDI en 64 bits... Affaire à suivre, mais assurément sur le long terme !



Source : RAD Studio Roadmap May 2017


Que pensez-vous de cette feuille de route ?

Ces prévisions peuvent-elles avoir une influence sur votre politique d'acquisition de licences ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de gbegreg
Membre expert https://www.developpez.com
Le 28/05/2017 à 15:04
Citation Envoyé par ApproxDev Voir le message
Oui toujours mais je lis dans ce forum toujours les mêmes certitudes... inexactes.
C'est valable dans les deux sens il me semble : beaucoup de critiques sont fondées sur des certitudes inexactes...

Je ne suis pas un évangéliste non plus, loin de là, et je regarde pas mal de chose dans le domaine du développement mais je manque de temps. J'aimerai aussi refaire du Javascript récent (React, Angular, NodeJs...) car j'en avais fait mais il y a longtemps... Je n'ai jamais pratiqué Qt mais il faudrait faut que j'essaye .

Citation Envoyé par ApproxDev Voir le message
Et le changement de "logiciel" que m'a imposé Qt et son détachement obligé vis à vis de ma (très) vieille pratique Delphi VCL/Lazarus LCL, m'a permis ensuite d'aborder FMX comme un nouveau produit, en me libérant d'une bonne part de cette ancienne approche enfin celle à laquelle je m'accrochais désespérément pour essayer de "comprendre" FireMonkey. Là, j'ai découvert un potentiel extraordinaire, mais un potentiel... comme les roadmaps. Enfin, ce que je veux dire, c'est que j'ai réalisé des choses dont je ne me soupçonnais même pas capable pour butter sur des problèmes minables et inadmissibles d'interface comme l'impression de documents.
Oui, avec Firemonkey, il faut repartir sur de nouvelles bases et oublier les habitudes VCL. C'était indiqué dès le départ. Maintenant que je le pratique, j'ai même un peu de mal à revenir en VCL...
Pour les impressions, quels problèmes avez vous rencontrés ? Que ce soit en VCL ou Firemonkey, il est possible d'accéder au canvas de l'imprimante pour dessiner ce que l'on souhaite. Quoi qu'il en soit, le potentiel est bien là, il faut apprendre à l'utiliser. C'est d'ailleurs la définition du mot potentiel : les ressources sont là, il faut les exploiter.

Citation Envoyé par ApproxDev Voir le message
je n'illustre pas tous les jours en 3D la 3ème Loi de Kepler au vidéo-projecteur que j'ai présentée à mes élèves de Terminales peu avant de quitter l'Enseignement (le truc extraordinaire -pour moi- lorsque j'ai découvert péniblement je l'admets la 3D de FMX).
C'est dommage : en tant qu'astronome amateur cela m'aurait intéressé

Citation Envoyé par ApproxDev Voir le message
Si mais je n’ai pas besoin de Windows pour le faire ! Il ’y a pas une petite nuance.
J'en déduis que vous ne développez pas pour Windows. Sinon comment faites vous vos tests sans Windows ?

Citation Envoyé par ApproxDev Voir le message
Votre IDE non, surtout si c’est Delphi [32], mais l’environnement qui le fait tourner ? Voyons, voyons… J’imagine mal mes 16Go fonctionner en 32 bits… et devenir alors 4Go disponibles en 32 sous VirtualBox. C’est de la propagande Microsoft qui, alors que les autres OS adoptaient le 64 bits ,en restait pépère au 32, rente oblige. Avec un peu de rhétorique où excelle Microsoft, on nous fait avaler n’importe quoi.
Alors, j'ai du mal m'exprimer. Oui l'IDE est en 32 bits et du coup il ne voit pas les 16 Go de RAM. Ce que je dis c'est que je n'ai jamais eu le besoin via l'IDE d'utiliser autant de RAM. Par contre, les applications produites avec en mode 64 bits voient bien les 16 Go de RAM. Mon Pc est sous Windows 10 64 bits et Delphi 32 bits fonctionne parfaitement.
Et puis, Microsoft a proposé des versions 64 bits de ses OS (au début les versions serveurs) puis avec Windows XP. Un des problèmes majeurs pour eux était la multitude de drivers 32 bits qu'il fallait réécrire en 64 bits et que cette tâche était au bon vouloir des constructeurs de matériel.

Citation Envoyé par ApproxDev Voir le message
Oui mais je n’ai pas payé le produit de base !
En fait, moi non plus : j'avais reçu une boite Delphi 7 Pro Studio lors d'une réunion utilisateurs du temps de Borland (je l'ai toujours d'ailleurs, avec les CD et les livres). Du coup, je l'ai fait évolué via la maintenance.

Citation Envoyé par ApproxDev Voir le message
Il y a enfin cet obsolète FastReport pour lequel je n’ai aucune solution.
Je n'ai jamais utilisé les générateurs de rapport (enfin si une fois QuickReport). Depuis longtemps, je génère mes propres rapports sous forme de pages web.

Citation Envoyé par ApproxDev Voir le message
Et comme je l’ai écrit déjà plusieurs fois, j’aimerais avoir un vrai interlocuteur, pas une boîte aux lettres, et pas un «diffuseur» local . Bref comme je l’ai chez Qt, chez PC Soft, chez Tms, chez uniDac... un vrai correspondant.
Justement, il y a eu du nouveau depuis XE7 dans ce domaine aussi. La société Barnsten a repris la partie commerciale et le support pour la France (avec des anciens de chez Borland). Cela est récent, il faudra prendre un peu de recul pour voir ce que ça donne.

Cordialement.
5  0 
Avatar de gbegreg
Membre expert https://www.developpez.com
Le 28/05/2017 à 0:52
Citation Envoyé par NSKis Voir le message

Est-ce qu'un seul lecteur de ce forum serait d'accord de payer pour réparer les défauts de sa voiture achetée neuve???
La voiture neuve est sous garantie un certain temps : le tarif est inclus dans le prix d'achat, donc on ne le voit pas directement. Par contre, une extension de garantie, on voit bien le surcout. En plus, ils s'arrangent souvent pour couvrir le moins de chose possible dans la garantie... La preuve quand on a un problème, il faut souvent envoyer un courrier au contentieux ou passer par une association de consommateurs pour que la totalité ou une partie des frais soit pris en compte par le constructeur !

Citation Envoyé par NSKis Voir le message
Y-a-t-il un seul de vos clients qui est d'accord de payer les correctifs pour faire fonctionner correctement un logiciel que vous avez livré sans qu'il réponde au cahier des charges?
En situation réelle, le cahier des charges spécifie les choses. Les tests effectués sont également tirés du cahier des charges (et le client effectue également ses propres tests). Le client valide le bon fonctionnement et met en prod la solution. Donc, la solution répond au cahier des charges. Toutefois, des bugs peuvent survenir (on s'aperçoit régulièrement que tous les points n'ont finalement pas été abordés dans le cahier des charges, ou alors des choses ont changé et pas l'appli), même principe : il y a un délai de garantie mais passé ce délai, c'est la maintenance qui prend le relai.

Citation Envoyé par ApproxDev Voir le message
Allez visiter https://www.qt.io/buy-product/ et sélectionnez "I qualify for Start-up Pricing." Prix mensuel affiché : 79$ si vous payez à l'année.
Pour mon cas personnel (Delphi Pro + mobile pack), je paye 660 euros par an de renouvellement de maintenance (= 55 euros par mois donc moins que les 70 euros de Qt) sans plafond de CA (mais je suis très loin (en dessous je précise ) des 100000$ annuels). Et si je ne renouvelle pas la maintenance, ma licence reste valable et je peux continuer à utiliser Delphi. Est ce la même chose avec Qt si on arrête la souscription ?

Citation Envoyé par ApproxDev Voir le message
Delphi est très pauvre en composants modernes. Sans TMS Software, on dispose d'un logiciel avec une interface graphique des années 1990.
Effectivement, ceux de TMS sont nettement plus modernes et évolués (les grilles en particulier) mais il y a quand même les multiviews, les styles (pour améliorer le rendu graphique), les ribbons et pour les applications Firemonkey, on peut faire très simplement beaucoup de choses avec des rendus graphiques évolués, les listbox ont bien évolué, des animations sans saccades, ni scintillements et dans certains cas sans code et le résultat peut être tout à fait moderne !

Citation Envoyé par ApproxDev Voir le message
J'ai testé et je n'en démords pas : j'ai un Mac mini i7 quadricore avec 16 Go de Ram et 1 SSD de 1To. Là c'est jouable.
J'ai un pc portable de 2011 (donc pas récent) et un MacBook Air 11" de 2013 (core i5 2 coeurs, 4Go de RAM et 128 Go de SSD). Les deux sont reliés par un câble ethernet et les applis Mac OS tournent correctement. Le Mac mini avec votre configuration doit revenir plus cher que ma config.

Citation Envoyé par ApproxDev Voir le message
Je rappelle également qu'il y a d'autres coûts induits avec Delphi : l'achat d'un mac si on veut développer en OS X et iOS
Je ne connais pas Qt (mais je vais essayé si j'ai le temps, je ne suis pas enfermé j'utilise régulièrement Eclipse (pour du Java et du Groovy), Android Studio et parfois XCode + éditeurs de textes évolués pour du Python et du PHP). J'ai une question : il n'y a pas besoin de Mac pour développer pour Mac OS ou IOS avec Qt ?

Citation Envoyé par ApproxDev Voir le message
Le 64 bits, un machin étrange totalement inutile au point que l'IDE est resté et l'est peut-être encore sous 32. Là, il faut faire un effort parce que les machines 32 se font rares. Sous Windows cela ne pose pas de problème. Avec les autres OS, on ne peut pas en dire autant.
Cela fait maintenant des années que Delphi compile en 32 et 64 bits pour Windows. Ce n'est pas parce que l'IDE est en 32 bits que l'on ne peut pas faire d'applications en 64 bits. Sous Windows 64 bits et Mac OS, les applications 32 bits fonctionnent (ça serait bien que l'IDE soit porté sous d'autres OS mais là c'est du rêve et personnellement, je préfèrerai la cible desktop Linux). Pour Linux, pour le moment ce n'est que du 64 bits. Pour Mac OS, c'est du 32 bits (mais comme indiqué, le 64 bits arrive). Personnellement, je n'ai pas encore ressenti de besoin particulier nécessitant que mon IDE puisse adresser plus de RAM par exemple.

Citation Envoyé par ApproxDev Voir le message
En effet on démarre vite jusqu'au moment où on a besoin d'une méthode triviale avec d'autres outils de développement et qui est impossible à produire avec Delphi ou tellement chronophage à contourner qu'il est totalement illusoire de parler de rapidité de développement.
Comme pour NSKis et les problèmes qu'il rencontre, ça serait bien d'avoir un exemple de cas.

Pour mon cas, j'ai rencontré un problème avec la dernière version Tokyo alors que ça fonctionne bien avec la version précédente Berlin : dès que je place un TViewport3D sur la form, l'application ne fonctionne plus sous Android (alors que sous Windows et Mac OS ça fonctionne). Il y a eu manifestement des évolutions sur la partie Android et un patch est prévu prochainement pour Tokyo.
4  0 
Avatar de SergioMaster
Rédacteur/Modérateur https://www.developpez.com
Le 27/05/2017 à 18:54
Re,

NSKis soulève toujours le même débat que ça en devient lassant. Je le soupçonne mettre d'y mettre quelques fois de la mauvaise foi
Citation Envoyé par gbegreg
Relis bien la phrase de SergioMaster, il dit la même chose que toi... et pourtant tu dis que son argument est faux...
je n'en prendrai pas ombrage, il s'agit peut être d'une question de langue ou d'une imprécision de ma part, j'aurai du ajouter un avec à la fin de ma phrase
cela ne veut pas dire que l'on ne peut pas garder et utiliser sa "vieille version" et écrire des programmes "commerciaux" <avec>
Je préfère décortiquer un peu les arguments avancés par Approxdev (toujours a peu près les mêmes aussi d'ailleurs )
j'adore les feuilles de route qui ne sont pas des engagements.
effectivement, ce ne sont pas des engagements, mais étrangement et après maints cafouillages je te ferai remarquer que depuis deux ans Embarcadero respecte cette dernière a peu de choses près.
Je suis toujours surpris par l'extase manifestée par les Delphistes.

Extase, le mot est fort, enthousiasme modéré plutôt. Pour moi l'important, n'est pas tant l'annonce de la mise à jour de la feuille de route, mais le fait qu'il y en ai une et donc que Delphi continue à évoluer en fonction de nos besoins disparates (du moins de ceux contactés par leurs sondages)

Maintenant ses adorateurs s'en prennent à Qt ?
n'exagérons pas ni pour le terme "adorateur" ni pour le "s'en prennent à". Pour ma part je ne fais que constater que : QT n'est pas "gratuit" dés que l'on veut aller "un peu loin". Comparer les versions déclinées par QT et celle de Delphi (enfin quand j'écris Delphi je devrai plutôt écrire RAD Studio Delphi ou Rad Studio C++) risque d'être délicat aussi ne m'y lancerai-je pas.

Avec Delphi, on ne payerait qu'une fois ? Mauvais argument. Vraiment marre de lire de tels propos !

Où est-ce écrit ?

Cela pourrait être également vrai si on n'achètait pas les Add-on nécessaires car Delphi est très pauvre en composants modernes. Sans TMS Software, on dispose d'un logiciel avec une interface graphique des années 1990.
pas faux, que serions nous sans les composants tiers ...
Quant au "pauvre en composants modernes" je ferais remarquer que pour VCL généralement ce sont des interfaces aux composants natifs de windows et combien d'entre les "Delphistes" (ce n'est pas les "Lazarusiens" qui me contrediront) font remarquer que D7 est/était un must.

Je ne parle pas du générateur d'états qui date de la même époque.
à ce propos ils changent encore (sob) de cheval si j'en crois l'annonce d'un Webinaire sur Gnostice XtremeDocumentStudio (ce qui nous ferait encore débourser d'avantage composants tiers ). Mais Embarcadero n'a jamais, à ma connaissance, proposé de composants maison pour la génération d'états, quelque part il faut tirer sur le bon pianiste, il s'est toujours agit de composants tiers.

Il m' a même fallu aller chercher des connecteurs à mon sens meilleurs que ceux intégrés par Delphi pour accéder aux bases de données, uniDac de Devart, payants eux-aussi.
perso je suis hyper satisfait de Firedac qui répond à mes besoins (j'insiste sur mes)

Et qu'on ne me dise pas qu'on peut développer plus vite qu'avec Qt. En FireMonkey, c'est tout à fait faux.
ça, c'est plus une question d'habitude qu'autre chose. Je suis moins jeune qu'autrefois mes compétences QT sont parcellaires je serai certainement plus efficace avec un outil que j'ai la prétention de maitriser un peu. Moi aussi j'ai eu, surtout au début, pas mal de difficultés avec Firemonkey approche totalement différente de la VCL = grosse claque. Petit à petit, je m'y fais, mais si je décroche de la programmation avec FMX pour retourner à la VCL les retours sont difficiles (et ce dans les deux sens).

Je rappelle également qu'il y a d'autres coûts induits avec Delphi : l'achat d'un mac si on veut développer en OS X et iOS,
ça c'est pour moi le point noir

les propos que j'ai lus ci-dessus sont de simples considérations entre Delphistes qui sont un peu restés murés dans leur environnement... ou qui essaient de se rassurer... entre eux.
pas faux, vivement la retraite. Mais quelle idée clamer que son outil c'est de la daube, qu'il ferait mieux d'en changer, qu'il est trop cher etc...
1- on sait que ce n'est pas l'outil qui fait l'ouvrier
2- chacun voit midi à sa porte
3- chacun a son budget, ses objectifs, ses besoins et ses envies/lubies

A chaque annonce (version ou feuille de route) , dés que NSKis s'en mêle on retombe dans les mêmes discussions qui deviendront vite stériles, chacun restant sur ses positions
4  1 
Avatar de Andnotor
Rédacteur/Modérateur https://www.developpez.com
Le 27/05/2017 à 21:41
Citation Envoyé par NSKis Voir le message
Dans le monde réel (le mien), le client te fournit un cahier des charges décrivant par le détail les fonctionnalités que doit réaliser le logiciel que tu lui développes...
Bien ! Donc tu as fournis à Embarcadero un cahier des charges qui correspond à l'usage que tu en as. Peux-tu s'il te plaît nous montrer ce cahier des charges ?

Citation Envoyé par NSKis Voir le message
Est-ce aussi exotique pour certains? Est-ce que les "afficionados de Delphi" auraient déjà tous quitté le monde professionnel?
Mon pauvre ami, que racontes-tu là ?

Tu ne livrera jamais rien à ton client si tu comptes suivre l'évolution, que tu le veuilles ou non, ton développement aura toujours un train de retard et ne sera jamais... comment dire... finalisé !

Les gens (comme toi) croient qu'il suffit de presser Ctrl+F9 pour avoir toutes les nouveautés, les dernières évolutions, le High-DPI, les senseurs, des thèmes automatiques (je pense bleu... pourquoi il est pas bleu ???), le driver universel de base de données, Linux, Mac, etc. C'est triste.

Je te sens très aigri... peut-être le moment de prendre des vacances (en tout amitié ).

Citation Envoyé par NSKis Voir le message
Idem pour les défauts, ceux qui n'ont pas à utiliser leur IDE pour autre chose que des applications de gestion avec un joli DBgrid et un bouton "ok" ne risquent évidemment pas d'être confrontés à des bugs dans l'implémentation de certains composants par exemple!!!
Ben dis-nous, c'était ma question !

Parle-nous technique pour une fois plutôt que gros sous
3  0 
Avatar de gbegreg
Membre expert https://www.developpez.com
Le 28/05/2017 à 9:08
Citation Envoyé par foetus Voir le message
J'utilisais C++ Builder xe et ceci me fait doucement rire
"Tu as vu, on compile en 64 bits, on est "cross-platform", on a les génériques, maintenant les outils arrivent sous Linux..."
Mais ce que tu oublies de dire, pour le cas C++, c'est que tout cela est possible que depuis le support clang et xe7-xe8 (<- je te laisse compter le "maintenant des années"
Parce qu'avec l'ancien étron propriétaire, le 64bits qui était arrivé avec xe5-xe6 (annoncé en 2009 soit 6 ans plus tard) mais, si j'ai suivi l'affaire, ce n'était que pour un programme "ligne de commande"
Je ne parlais que de Delphi pour lequel la compilation Windows 64 bits est arrivée, de mémoire, avec Delphi XE2 donc en 2011 : cela fait bien quelques années. Je reconnais moins suivre l'actualité de C++ Builder.
Il est vrai que Borland avait délaissé ses outils de développement pendant de nombreuses années, mais depuis la reprise par Embarcadero, il y a eu de nombreuses évolutions (sur les fonctionnalités, la qualité du produit et même sur la documentation qui s'améliore car elle avait beaucoup perdu depuis celle de Delphi 7). De nombreux webinars et autres sont maintenant organisés sur tout type de sujet, chose qui ne se faisait pas avant.

Chacun a ses contraintes, besoins et appétences. Je trouve ça bien qu'il y ait plusieurs produits pour faire la même chose. Ce que j'ai choisi par ce que cela correspond à mes besoins ne répondra aux besoins de mon voisin. Il fera donc un autre choix. Nous sommes libres ! Est ce que cela signifie que j'ai raison et lui à tord ou inversement ? Bien sur que non !
Pour ceux qui se posent des questions rien de tel que de se faire sa propre idée en téléchargeant la version gratuite (limitée en fonctionnalité mais pas dans le temps) ou la version d'essai (limitée dans le temps mais pas en fonctionnalité).

Pour en revenir au sujet du départ, c'est bien qu'il y ait une feuille de route (quelque soit le produit et l'éditeur). Ça montre que le produit vit et la trajectoire que souhaite lui faire suivre l'éditeur. Évidemment, cela n'engage en rien : par exemple, Oracle a bien repoussé des fonctionnalités prévues en Java 7 en Java 8, puis des fonctionnalités de Java 8 en Java 9... Pour les histoires de bugs, quels produits n'en contiennent pas (à commencer par ceux que l'on développe nous même) ?
2  0 
Avatar de matthius
Inactif https://www.developpez.com
Le 28/05/2017 à 13:31
Lazarus permet de créer des interfaces QT, Windows, Gnome, iOS, voire Android.

Il coûte 0 €. Il a sauvé Delphi.

La seule demande de Lazarus, c'est de participer.
2  0 
Avatar de SergioMaster
Rédacteur/Modérateur https://www.developpez.com
Le 27/05/2017 à 11:04
Bonjour
Citation Envoyé par archqt Voir le message

j'étais resté sur des licences à 1000 euros MAIS visiblement on est autour de 3500 euros minimum pour une licence.
Cela dépend de la version Starter (gratuite), Pro , Entreprise ou Architecte, mais oui si l'objectif est le multi-plateforme Entreprise est "la version"

Si on regarde un produit équivalent (Qt/C++) on est sur les même prix, sauf qu'il faut payer cela tous les ans avec Qt (si je ne me trompe pas). On doit pouvoir négocier une licence UNE FOIS je pense mais il faut voir avec le service commercial.
Je suis "heureux" de lire que Qt n'est pas gratuit, contrairement à ce que peuvent me dire certaines connaissances

si on veut un produit "à jour" , dans le cas de Delphi ou C++ il faudra renouveler son abonnement tous les ans pour un peu plus (sic) d'1/4 du prix, cela ne veut pas dire que l'on ne peut pas garder et utiliser sa "vieille version" et écrire des programmes "commerciaux".
Reste en suspend les hotfixes d'une version "ancienne" la politique d'Embarcadero à ce sujet a plusieurs fois changée ....

Citation Envoyé par kilroyFR
Qu'est ce que ça vaut en terme d'efficacité de développement par rapport à l'usine à gaz qu'est devenu visual studio ? Est ce vraiment du rad ? Multi plateforme efficace et réel ?
N.B. pourquoi ne pas se faire une opinion en téléchargeant une version d'essai limitée dans le temps mais complète ?

Poser ces questions sur un forum dédié c'est presque automatiquement obtenir des réponses non objectives
Pour moi, qui ne connai pas Visual Studio mais un peu QT, OUI c'est un vrai RAD.
Multi-plateforme pour le peu que j'en ai testé,
- oui, mes programmes tests compilés ont fonctionné sous Androïd, sous Ubuntu (et pas seulement la partie serveur, et ce grâce à un Addon)
- mais non RAD Studio ne tourne que sur Windows et n'existe encore qu'en 32 bits
pour bien comprendre : on écrit son programme sous windows, on le compile pour nos cibles Androïd, MAC, IOS, Linux (limité à 2 versions) et on transfère le programme compilé et les ressources nécessaires via paserver (cette partie est je trouve un peu "artisanale" vers les machines hôtes ou les "stores" adéquats.

Pour en revenir à la feuille de route, j'ai fait partie des "sondés" certaines de mes demandes ont certainement rejoint la majorité car sont dans la feuille de route, d'autres (les interfaces graphiques Linux) sont toujours dans le domaine du rêve quoique, avec les bons additifs ...
2  1 
Avatar de gbegreg
Membre expert https://www.developpez.com
Le 27/05/2017 à 12:51
Citation Envoyé par NSKis Voir le message
Delphi n'est pas un langage, c'est un EDI qui utilise le langage Pascal orienté objet!!!

Il serait temps que certains s'en souviennent d'autant plus qu'il existe d'autres EDI tout aussi simples, efficaces et assurant une maintabilité du code optimale sans avoir les dérives "mercantiles" des successeurs de Borland!!!
Je sais parfaitement que Delphi est l'IDE et qu'il utilise le langage Pascal Objet. Je connais d'autres IDE et langages et si tu avais lu mon commentaire jusqu'au bout, la phrase qui suit était : "Ce n'est qu'on avis personnel donc il n'engage que moi.".

Citation Envoyé par NSKis Voir le message
Ton argument est tout simplement faux: Tu peux très bien utiliser une "vieille version" tout en écrivant des programmes "commerciaux"!!! Cela dépend des technologies mises en oeuvres dans tes programmes.
Relis bien la phrase de SergioMaster, il dit la même chose que toi... et pourtant tu dis que son argument est faux...

Enfin, les politiques commerciales des éditeurs sont ce qu'elles sont et Embarcadero n'est pas le seul à agir de la sorte. Ils sont nombreux à faire payer la maintenance (et donc les corrections de bugs) mais bien souvent la maintenance inclue les montées de version : le ticket d'entré est certes cher au départ (licence + maintenance) mais ensuite tu n'as que la maintenance (du coup c'est avec ton exemple 1000 euros par an => 83.33 euros par mois).
2  1 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 27/05/2017 à 14:28
Citation Envoyé par archqt Voir le message
Si on regarde un produit équivalent (Qt/C++) on est sur les même prix, sauf qu'il faut payer cela tous les ans avec Qt (si je ne me trompe pas). On doit pouvoir négocier une licence UNE FOIS je pense mais il faut voir avec le service commercial.
Sinon il faut utiliser la licence LGPL (que le code objet à fournir) et cela fonctionne, certains composants ne seront pas utilisables car en GPL/Commercial.
Qt est entièrement gratuit… pour l'édition libre, avec un bon paquet de fonctionnalités mais pas toutes (l'édition commerciale est presque nécessaire pour tout ce qui touche à l'embarqué ; pour les autres utilisations, c'est surtout du support). Avec la LGPL, tu ne dois pas fournir de code objet ou autre : il doit être possible de lancer ton application avec une autre version de Qt. Les composants GPL sont assez rares, ce sont surtout des outils comme Qt Creator, bien que quelques fonctionnalités autrefois commerciales ont été libérées sous GPL, nettement plus stricte que la LGPL (https://www.developpez.net/forums/d1...s/#post8504983).
1  0 
Avatar de ApproxDev
Membre actif https://www.developpez.com
Le 27/05/2017 à 15:48
Bonjour,

j'adore les feuilles de route qui ne sont pas des engagements. Je suis toujours surpris par l'extase manifestée par les Delphistes. FireMonkey cela a combien de temps déjà !? Et ce RAD sous cette "plateforme" -qu'ils n'ont pas créée eux-mêmes mais rachetées- fait déjà tout cela ? J'en reste stupéfait, j'allais dire presque sans plume ! Bon, c'est incontestable, ils sont "un peu" partis en retard... persuadés que le monde resterait éternellement VCL c'est à dire Windows 32 bits et exclusivement.

Maintenant ses adorateurs s'en prennent à Qt ? Est-ce de la jalousie ? Il ne faut quand même pas exagérer ! Qt en version commerciale est à la portée des "petites" entreprises ce que n'est pas le RAD Delphi. Allez visiter https://www.qt.io/buy-product/ et sélectionnez "I qualify for Start-up Pricing." Prix mensuel affiché : 79$ si vous payez à l'année. Qu'appelle-t-on une Start-Up dans ce cas précis? Une entreprise avec CA < 100 000$. Pour celles qui ont un CA > 100 000$, c'est 275$ par mois.

Avec Delphi, on ne payerait qu'une fois ? Mauvais argument. Vraiment marre de lire de tels propos ! Cela pourrait être vrai si on ne prenait pas les mises à jours. Ce qui est totalement in-envisageable ne serait-ce que pour (essayer de) pérenniser pour le moins cet investissement.... Cela pourrait être également vrai si on n'achètait pas les Add-on nécessaires car Delphi est très pauvre en composants modernes. Sans TMS Software, on dispose d'un logiciel avec une interface graphique des années 1990. Je ne parle pas du générateur d'états qui date de la même époque. Il m' a même fallu aller chercher des connecteurs à mon sens meilleurs que ceux intégrés par Delphi pour accéder aux bases de données, uniDac de Devart, payants eux-aussi. Je rappelle également qu'il y a d'autres coûts induits avec Delphi : l'achat d'un mac si on veut développer en OS X et iOS, mac sur lequel on fait tourner un Windows. J'ai testé et je n'en démords pas : j'ai un Mac mini i7 quadricore avec 16 Go de Ram et 1 SSD de 1To. Là c'est jouable. Mais pour le prix, avec Delphi je ne peux pas développer en Linux Desktop. Enfin, si peut-être, grâce à une société tierce... et il va falloir également payer. Et pour toutes ces sociétés, il faut également payer pour la mise à jour. Aussi ai-je arrêté les frais avec Delphi et les sociétés qui lui fournissent une valeur ajoutée nécessaire et que devrait normalement fournir Delphi lui-même.

Et qu'on ne me dise pas qu'on peut développer plus vite qu'avec Qt. En FireMonkey, c'est tout à fait faux. En effet on démarre vite jusqu'au moment où on a besoin d'une méthode triviale avec d'autres outils de développement et qui est impossible à produire avec Delphi ou tellement chronophage à contourner qu'il est totalement illusoire de parler de rapidité de développement. Je parlerais plutôt de coûts induits... encore !

J'ai regardé avec intérêt le cheminement d'un visiblement bon développeur Qt vers Delphi et les questions posées. Il a même fait un détour par Lazarus. Je rappelle qu'Apple gère le 64 bits ! Bon Delphi va y arriver bientôt sur leurs OS. Le 64 bits, un machin étrange totalement inutile au point que l'IDE est resté et l'est peut-être encore sous 32. Là, il faut faire un effort parce que les machines 32 se font rares. Sous windows cela ne pose pas de problème. Avec les autres OS, on ne peut pas en dire autant. J'ai pratiqué la démarche inverse et du haut de cette toute petite expérience, je retrouve que ceux qui discréditent Qt au profit de Delphi sont dans l'erreur.

Donc avant de recevoir une volée de bois vert des habituels participants à ce forum, pour moi, les propos que j'ai lus ci-dessus sont de simples considérations entre Delphistes qui sont un peu restés murés dans leur environnement... ou qui essaient de se rassurer... entre eux.

Sur ce je retourne à "mon" Qt. Bonne fin de journée.
Cordialement. Un ancien adepte. AD.
3  2