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 pour Delphi et C++ Builder

Vers plus de mises à jour et une version majeure par an

Le 5 août 2016 à 21:09, par gvasseur58

60 commentaires

47PARTAGES

Voter pour

7

Voter contre

0

Comme décidé en février dernier, Embarcadero publie sous la plume de Marco Cantù sa nouvelle feuille de route semestrielle. L’idée essentielle est de revenir à un rythme annuel pour les versions de l’environnement de développement, avec deux ou trois mises à jour intermédiaires.

En premier lieu, Rad Studio Update 2 est annoncé pour cet automne : incluant de nouveaux styles et contrôles UX, cette mise à jour supportera l’édition anniversaire de Windows 10, en particulier Centennial.

Cependant, plus intéressante semble être la version RAD Studio 10.2 alias Godzilla prévue pour fin 2016 : inclusion des contrôles Konopka et Radiant Shapes rachetés récemment par Embarcadero à la société Raize Software (pour VCL et FMX), RAD Server multi-tenant (multi-tenancy capabilities), support de l’ordre Z pour Android (Firemonkey), QA Automation et surtout le retour très attendu de Linux sous la forme de serveurs Delphi et C++, RAD Server étant dorénavant proposé en version Linux avec intégration d’Apache.

La feuille de route voit encore plus loin puisque la version 10.3 prévue pour fin 2017 porte déjà le nom de Carnival et devrait tout particulièrement s'intéresser à macOS, mais un astérisque rappelle qu’il ne s’agit dans toutes ces annonces que de projections susceptibles d’être modifiées... Aussi nous arrêterons-nous à cette version 10.2, avec la réintroduction de Linux dont les premiers aperçus sont attendus avec impatience par la communauté des Delphistes et des programmeurs C++ Builder !

Source : Embarcadero

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

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

60 commentaires

Commenter Signaler un problème

Rédacteur/Modérateur

Le 06/08/2016 à 23:38

Je vous laisse quelques heures et paf ! ça repart dans tous les sens

Serait-il possible de vous limiter à commenter la nouvelle roadmap ; ce qui vous plait, ce qu'il y manque, ce que vous désireriez sans systématiquement dévier du sujet initial ?

La plupart des intervenants dans d'autres discussions critiquaient les nouvelles versions trop fréquentes. Il a été décidé de revenir à une version annuelle et des mises à jour régulières ; Embarcadero vous a entendu ! Alors, bonne nouvelle, mauvaise nouvelle ? Plus de stabilité mais des nouveautés retardées ?

C'est là-dessus que j'aimerais vous entendre, pas sur ce que sont capables de faire Qt ou Windev dont je me fiche éperdument

Voter pour

6

Voter contre

0

Rédacteur

Le 07/08/2016 à 8:54

Citation

Envoyé par NSKis

Voir le message

On joue sur les mots??? Que cela s'appèle "Berlin 10.2" ou "Berlin update 2", c'est exactement le même cirque!!!

Je me permets d'intervenir pour rectifier cette affirmation : les updates annoncées correspondent essentiellement à la correction de bogues avec quelques (menues) améliorations tandis que les releases prévoient des modifications de poids : serveurs Linux pour Godzilla 10.2 et plateforme macOS 64 bits pour Carnival 10.3. Finalement, on en revient aux acceptions admises pour ces deux mots alors qu'Embarcadero s'était depuis quelque temps montré obscur sur ce point.
Sachant que la maintenance est à présent incluse dans l'achat d'une licence, que les bogues corrigés le sont aussi pour les versions plus anciennes (depuis peu, hélas !) et qu'une feuille de route (certes, toujours indicative) est proposée tous les six mois, il me semble qu'on ne peut que se féliciter de ce retour à une meilleure visibilité

.

Voter pour

5

Voter contre

0

Expert éminent sénior

Le 07/08/2016 à 10:10

Citation

Envoyé par Andnotor

Voir le message

Ah bon ? Relis mieux : 10.2 = Godzilla, 10.1.2 = Berlin update 2. C'est juste deux versions différentes.

Sinon quelque chose à dire sur cette roadmap ou seules les dénominations te dérangent ?

restons pragmatiques, la roadmap n'est pas un engagement, par contre Idera s'est engagé à poursuivre le développement de Delphi sur un nouveau modèle de développement qui s'affranchit de l'équipe hispanique... attendons les résultats avec la prochaine version, qu'elle soit un update ou une release, c'est là dessus qu'il faudra se faire une idée

Voter pour

4

Voter contre

0

Rédacteur/Modérateur

Le 06/08/2016 à 18:59

On ne va pas retomber dans les travers de la précédente discussion, n'est-ce pas

Citation

Envoyé par ApproxDev

Voir le message

Et FMX sous Mac (ou iOS), c'est la nécessité d'acheter un gros (i7/16Go) appareil Mac parce qu'il faut faire tourner dessus un Windows. J'avais naïvement essayé la câblage entre un PC et un Mac Mini bas de gamme.

Je n'utilise pas FMX et ne connais pas Mac, mais n'y a-t-il pas un Remote Debugger pour Mac ? Est-ce cela qui coince dans la solution câblée ?

Citation

Envoyé par ApproxDev

Voir le message

Enfin une dernière petite remarque concernant les ancrages des "objets" dans les IHM. Lazarus est génial. Delphi est compliqué.

As-tu déjà testé le TRelativePanel ? Ce n'est pas encore parfaitement intégré (certains contrôles ne sont pas supportés) mais fonctionne déjà pas si mal. Les composants sont positionnés relativement à d'autres composants, en déplacer ou redimensionner un déplace tous ceux qui y sont rattachés. Et pas de codage, tout ce fait par l'inspecteur d'objet

Voter pour

3

Voter contre

0

Membre actif

Le 06/08/2016 à 17:41

Bonjour,

je travaille sur les 2 (sur les 3 avec Lazarus

). En Delphi je n'utilise FMX qu'à titre personnel, en tant qu'ancien enseignant (une XE 7) et j'utilise Qt/C++ et Lazarus dans une SSII que j'ai créée avec mon père il y a plus de 25 ans, et que j'ai réintégrée il y a peu à la disparition de ce dernier des suites d'une longue maladie comme on dit.

Donc je suis un Pascalien universitaire. J'ai développé épisodiquement (en soutien) pour la société jusqu'à mon abandon de poste d'enseignant. Et avant de partir pendant 3 longues années je me suis formé à Qt (à partir de la version 4.8) difficilement, laborieusement avec des périodes de rejets:

. Cela va un peu mieux

Mais l'apprentissage de FMX n'a pas été plus facile, compliqué par mes habitudes en Delphi VCL et Lazarus.

Une énorme limite de Delphi totalement insensée est l'absence de Linux, corrigée partiellement par l'apparition d'une prochaine version "serveur Linux seulement". Alors FMX c'est un énorme potentiel visiblement mais encore mal abouti. On peut difficilement faire des applications Desktop aussi sophistiquées qu'en VCL. C'est pratique par contre pour la réalisation pour les mobiles (sauf processeur Intel.. en voie de disparition paraît-il). A l'époque où je découvrais les capacités de FMX, cela fonctionnait mal sur les mobiles bas de gamme (question de composant vidéo). FMX, c'est léger au niveau du débogage sur les plateformes Mac parce qu'on utilise la cross-compilation. Et FMX sous Mac (ou iOS), c'est la nécessité d'acheter un gros (i7/16Go) appareil Mac parce qu'il faut faire tourner dessus un Windows. J'avais naïvement essayé le câblage entre un PC et un Mac Mini bas de gamme.

Car ce n'est pas comme en Qt (ou en Lazarus) où on utilise l'IDE sur la plateforme de développement. Cela à mon avis est un énorme manque. Pour atteindre les bases de données c'est FireDac. Il n'y a pas d'équivalent en Qt. Je préfère utiliser Unidac (qui existe aussi pour lazarus). Les composants graphiques sont totalement obsolètes même s'ils s'améliorent. En réalité la solution vient des composants TMS Software. Certains sont portés sur Lazarus. Le Pdf est mal géré (sauf sous Mac car nativement). Les générateurs d'états sont arriérés quand on les compare à NCreport (voire même Lime) qui coûte pour le premier grosso le même prix que la version complète de la version light qui est offerte dans Delphi et qui est gratuit pour le second. Mais les FastReport (VCL, FMX voire Beta Lazarus) s'améliorent lentement.

En terme de productivité, pour voir les programmeurs C++ ("natifs"

/Qt de mon entreprise, on fait pratiquement match nul... sauf quand je réalise une maquette Windev où là, ils sont vraiment à la ramasse. Mais Windev ne produit que du code Windows avec le niveau de sophistication que l'on peut obtenir en Qt (voire en Delphi). Mais si par exemple on veut gérer du texte enrichi, on arrive aux limites de performances de Windev et de Delphi/TMS software... et pas de delegate possible

Alors, à ce moment, la finition demande largement autant de temps que la réalisation en Qt à qualité égale. Ce qui est long en Qt, c'est de constituer ses propres bibliothèques : Dnd entre 2 tableview, SpellChecker dans des QTextEdit...

Par contre, il y a un énorme avantage en Lazarus/Delphi, c'est le déploiement des programmes réalisés. Un exécutable (éventuellement quelques bibliothèque tierces) point final. On fait aussi bien en stactic avec Qt enfin presque... c'est souvent nettement plus compliqué.

En conclusion,

Delphi n'est pas un concurrent de Qt pour le développement Desktop multiOS. D'abord parce qu'il ne gère pas Linux, ensuite même avec l'amélioration apportées par les composants TMS, je le mets au déphi (défi) de gérer du texte enrichi (HTML), de la visualisation, à l'édition et à l'impression. Avec Qt, nous arrivons à faire cela en incorporant même des images encodées en base64 y compris jusqu'à l'édition. Eux, ils en sont au "miniHTML". C'est frustrant.
Pour le mobile, je ne sais pas, je n'utilise pas Qt pour le faire mais une autre solution. Par contre j'ai pu me rendre compte à titre personnel, que c'était sympa (réellement productif) autant que Windev Mobile.
Enfin pour le moteur 3D, j'ai eu beaucoup de mal difficultés à comprendre l'approche et heureusement, les membres de ce forum ont été très patients. A l'arrivée, j'ai pu simuler la deuxième Loi de Kepler, avec des images de la Nasa (faites pour), en mettant en évidence l'effet de fronde sur les foyers, en jouant avec l'excentricité, les masses : fabuleux. J'ai bien vu les exemples fournis avec Qt (Planetarium) mais je ne les ai pas étudiés. Alors qu'avec FMX, le prof de maths et l'informaticien se font un énorme plaisir. Rien que pour cela, j'aimerais soutenir Delphi... Reste, non pas la tarification, mais l'approche commerciale du repreneur et d'ailleurs du précédent... et le soutien aux équipes de développement utilisant leurs produits. Il n'y a que des "vendeurs" dans cette nouvelle structure ?

Enfin une dernière petite remarque concernant les ancrages des "objets" dans les IHM. Lazarus est génial. Delphi est compliqué. Au départ je n'ai pas compris pourquoi... parce que je n'utilisais pas le développement pour les mobiles. Ensuite il a fallu cloner l'approche VCL (largement inférieure à celle de Lazarus) avec les exigences des mobiles. Le résultat est déconcertant mais fonctionnel. Enfin Qt (Qt Creator... on s'y fait. Plutôt efficace et rien de génial).
Et dernière chose qui fait l’intérêt à mon avis de Delphi/Lazarus, c'est l'utilisation des composants à comparer avec la réalisation de plugin sous Qt surtout si on veut les intégrer dans Qt Creator

On comprend pourquoi la promotion existe en Qt.

Cordialement. AD.

Voter pour

2

Voter contre

0

Rédacteur/Modérateur

Le 07/08/2016 à 12:02

Inutile de m'expliquer ce qu'est une roadmap et il ne s'agit pas de se taire mais d'être constructif

Les interventions qui prennent une page écran, franchement je les lis en diagonale. J'y ai cependant aperçu quelques points intéressants :

textes enrichis : effectivement ce serait bien de faire évoluer le TLinkLabel pour permettre certaines mises en forme (j'aurais par exemple dernièrement préféré mettre un texte en gras plutôt que l'entourer de guillemets pour le faire ressortir) ;
améliorer non pas le développement mais le debuggage sous Mac (c'est ce que j'ai cru comprendre, je me trompe peut-être) ;
Linux desktop : personnellement, je n'ai jamais eu la moindre demande pour cette plateforme (mais ça ne concerne que moi) ;
améliorer les composants : Une grille multi-lignes par exemple serait effectivement agréable mais en matière de visuel, je préfère me tenir à celui "imposé" par l'OS. Avoir une fenêtre rouge à côté d'une fenêtre bleue ne rend pas les choses plus intuitives.

Mais encore ?

Voter pour

2

Voter contre

0

Membre expert

Le 08/08/2016 à 21:46

Citation

Envoyé par NSKis

Voir le message

Et on fait comment lorsque l'on veut rester au courant de l'évolution d'un produit que l'on utilise depuis des décennies? Sommes-nous condamnés à étouffer sous les communications commerciales de Embarcadero ou à ne plus recevoir la moindre news???

Le "respect" est vraiment une notion en perdition!!!

Si certains mails t'intéressent et pas d'autres, le mieux est peut être de créer une règle dans ta messagerie... Je suis d'accord avec toi sur la notion de respect mais la limite entre une information sur l'évolution d'un produit et une publicité est assez subjective...

Voter pour

2

Voter contre

0

Expert éminent sénior

Le 11/08/2016 à 15:56

Citation

Envoyé par ApproxDev

Voir le message

à croire que les utilisateurs de Delphi/C++ Builder/Lazarus n'ont pas besoin du texte enrichi.

Tu confonds les développeurs et les utilisateurs des applications faites en Delphi
C'est le métier de l'utilisateur qui décide du besoin technique

1) HTML
En 15 ans, j'ai utilisé du HTML qu'une seule fois pour afficher un Hint et j'ai utilisé le THTMLCredit de TMS
le HTML était lui même issu d'un XML transformé via un XSLT et affichait tout l'historique de modification des valeurs (un besoin de forte traçabilité pour l'utilisateur de qui modifiait quoi et quand)
C'était l'approche choisi en D5 parce que le développeur voulait s'amuser avec ces nouveautés de l'an 2000, je n'ai fait que l'améliorer et stabiliser
la même chose pouvait être faite en stockant les infos dans une table et en jouant avec des TLabel positionnés manuellement (ben oui, le TFlowGrid n'existait pas et TDBCtrlGrid aurait été visuellement trop lourd)
Mais c'était moins fun et moins innovant !
D'ailleurs ce développeur avait aussi fait un XLST qui transformait un XSL en DFM, et la DFM pouvait être chargé via ReadComponent
Clairement un délire technique pour exploiter à fond le XSLT

Sinon, la plupart du temps un TWebBrowser affichant le résultat d'un script PHP, cela ne va pas plus loin !

Delphi VCL\FMX c'est du client lourd, on a tout plein de composant pour afficher ce que l'on veut, pourquoi se faire chier avec du HTML
(perso, la partie IHM du web est une vraie tannée pour moi, je préfère coder la partie serveur qui retourne du XML ou mieux du JSON laissant les pro du JS et du CSS faire leur boulot)

2) RTF
j'ai utilisé le TRichEdit, le plus souvent en lecture seule (finalement comme pour le HTML)
J'ai travaillé 9 ans dans le Médical\Socio-Médical, c'est là ou j'avais le plus de "texte" à afficher ou à produire
Le RTF, était un grand classique des versions informatisées du Vidal, des catalogues d'appareil médicaux, d'un diagnostique CIM ou d'un acte CCAM.
cela se limitait souvent à un titre, un sous-titre et un texte
Le plus souvent l'utilisateur préférait une version épurée du texte dans la TDBGrid pour une lecture rapide et le TDBRichEdit soit en dessous soit accessible en double-clic pour un texte plus long
A l'époque faut dire que la résolution phare c'était le 800x600 voire le luxe avec un 1024x768, il fallait faire des compromis

Pour avoir inclu, l'éditeur de RTF fourni sur le CD de Delphi 5 dans des applications, tu vois rapidement, que mieux vaut utiliser Word en OLE et faire du Publipostage

Avec un modèle Word + Publipostage, tu as obtients un beau document au contenu enrichi tout beau et un code simple ne se préoccupant que des données
C'est faisable en OLE, même si un peu pénible

Avec TReportBuilder + TwwppRichEdit, c'est plus cher mais à l'avantage de fonctionner sans Word sur un serveur d'impression (quand tu imprimes 5000 à 20000 documents par jour, tu n'as pas peur d'investir en outil et matériel)

Depuis, les 6 dernières années, alors que les utilisateurs ont maintenant des machines puissantes et des résolutions HD (mais pas des écrans beaucoup plus grand, les pixels sont devenus plus petits)
Beaucoup d'utilisateurs demande qu'on passe leurs Windows en 125% ou 150% pour avoir du texte plus grand.
Au final, un écran 1920x1080 avec le scale Windows, revient à un écran 1024x768, on affiche à peine plus de chose pour privilégier le confort sans noyer l'utilisateur d'effet visuel inutile et encombrant !

Mes autres années de travail en robotique ou vidéo-surveillance, le seul HTML que j'ai vu c'était parce que les appareils intègrent souvent un server web pour leur administration et supervision
Pas besoin de le faire soit même, un ShellExecute ou un TWebBrower sur l'URL cible et basta !

Maintenant, je travaille sur un ERP maison,
quand tu as une base produit de 400000 références, avec autant d'image miniature et HD, avec le descriptif en 5 langues, tu vas à l'essentiel !
Ce n'est pas du texte enrichi qui aide à vendre les 10 000 000 de produits par an !

Dans quel cadre tu travailles pour être obsédé par le Texte Enrichi, pour moi, c'est un élément anecdotique de mon travail
A part, les ressources humaines qui utilise du publipostage pour générer les contrats de travail, c'est bien la seule chose dans ce genre

Tout le reste, c'est du PDF généré via ReportBuilder pour les bons de commandes, bons d'expédition, de réception, les factures, les avoirs, ce qui compte c'est l'exactitude, le respect de la législation, la clarté, la simplicité de lecture du document
Et puis, évidemment, le plus important c'est l'EDI qui l'accompagne pour que les systèmes soit interopérables pour que tous les acteurs gagnent du temps !

Voter pour

2

Voter contre

0

Expert éminent sénior

Le 11/08/2016 à 19:04

Citation

Envoyé par ApproxDev

Voir le message

...
Donc la question se pose autrement pour moi. Pourquoi n'utiliserais-je pas le HTML dans la plénitude de ses fonctions avec un langage compilé de mon choix ?

personnellement ça me semble contre nature de faire du HTML en natif, mais pourquoi pas...il existe un composant qui semble très complet ici http://delphihtmlcomponents.com/

Citation

Envoyé par ApproxDev

Voir le message

...
Alors j'ai maquetté cela en Windev (en RTF) y compris le ratio (exe de R&D dispo) puis je l'ai réalisé en Qt. Évidemment les images sont déplaçables, codées en base 64 avec une vérification orthographique autonome, un dictionnaire basé sur Hunspell et un dictionnaire pour chaque utilisateur, l'ensemble peut générer du PDF dans tous les OS et le visualiser.

Deux jours de travail pour faire cela en Qt, exe de R&D également disponible aussi à l'appui.

ça doit pouvoir se faire aussi avec trichview.com par exemple

Citation

Envoyé par ApproxDev

Voir le message

...
Bref, Delphi est un langage généraliste. Qu'il soit incapable de faire facilement ce que font d'autres langages généralistes cela énerve un peu. Alors évidemment, avec des recettes de sorciers, un truc plus ou moins portable sur la prochaine version de FMX, avec 50 ans d'expériences... peut-être, je vais vous croire sur parole, c'est faisable... Pas par moi, ni par beaucoup d'autres d'ailleurs. Que vous le vouliez ou non, dans ce domaine Qt est nettement supérieur car il permet sans bricolage simplement en utilisant les méthodes natives d'arriver à son but.

je ne comprend pas cette opposition QT/Delphi, car en fait ça n'a rien à voir. QT est un framework, Delphi est un langage de développement (qui propose 2 frameworks).

QT étant développé en C++ il n'est pas très simple de l'utiliser autrement qu'en C++ (Builder y compris j'imagine) sauf à passer par un Binding ... il en existe d'ailleurs un pour FreePascal qui doit possiblement fonctionner sous Delphi. Kylix et Delphi 6, avec la CLX, proposaient un binding Delphi, mais ça n'a pas été une révolution...

Citation

Envoyé par ApproxDev

Voir le message

Ce qui n'empêche pas que j'apprécie Delphi mais que le FMX doit gérer proprement le HTML vu qu'une de ses cibles est le mobile...

je ne comprend pas bien le lien entre les deux ?! quand on développement en natif sur mobile, c'est justement pour éviter les lourdeurs du HTML non ?

Voter pour

2

Voter contre

0

Expert éminent sénior

Le 12/08/2016 à 10:53

Citation

Envoyé par ApproxDev

Voir le message

le positionnement de FMX et TMS l'a bien compris avec ces composant d'un nouvel âge... alors que d'autres comme TMS innovent chaque jour ?

Tu n'as jamais pensé que TMS ou Dev Express profite de cette situation ?
Si demain, Embarcadero se met à inclure des composants natifs aussi puissant que ceux de TMS ou DevX, c'est un manque à gagner pour ces deux sociétés !
D'après toi, pourquoi Embarcadero invite TMS à présenter ses composants durant les Code Way Tour !

C'est du Business !
Embacadero laisse la place à ses partenaires de faire le beurre !

Voter pour

2

Voter contre

0

Commenter Signaler un problème