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
Bonjour,
Oups désolé. Mais l'information n'en est pas une. On ne sait jamais, le représentant de Delphi sur ce forum, à force de lire les choses, pourra peut-être influer dans le bon sens ! Pour le reste comme dit Paul, il faut attendre... Mais depuis le temps qu'on attend !
Bon je me tais sur ce fil.
Cordialement AD.
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 ?
Désolé mais pour moi et surtout pour mon patron, la visibilité ne se lit pas dans un bout de papier qui n'engage personne mais sur la politique de l'entreprise menée dans la réalité: Faire "exploser" Embarcadero en France et en Espagne, c'est de la "vraie visibilité", doubler le prix des licences pour mon patron, ce n'est même plus de la visibilité, c'est "paroles d'Evangile"!!!
De manière plus générale, j'ai la nette impression que les nouveaux stratèges de Embarcadero ne sont plus en lien avec le terrain (en espérant qu'ils l'ont été un jour). Ils ne font que de la cosmétique, mais ne répondent plus aux exigences du marché...
Il y aura plein de personnes qui ne sont pas de mon avis sur ce topic, mais il sufftit d'attendre: Il est clair que Embarcadero ne changera pas sa stragégie, le temps nous dira donc très vite qui avait raison
Je ne parle pas de dénomination!!! Je dis simplement qu'il ne s'agit que d''une opération cosmétique qui ne change rien. Que Embarcadero sorte annuellement "2 versions/an du logiciel" ou sorte "1 version + 1 update", c'est du pareil au même: On se dépêche de sortir une version "buggée à mort" pour corriger 250 bugs 3 à 4 mois plus tard.
Est-ce que quelqu'un s'est posé la question de la raison d'une telle pratique? Est-ce pour mieux servir le client ou pour mieux servir le tiroir-caisse de Embarcadero?
Bonsoir,
Ils t'ont déjà entendu car il y a y a un lien en bas de leurs mails "Manage my email subscriptions" où tu peux te désinscrire "Yes, please remove me from all future mailings."...
Je n'ai pas encore fais beaucoup de développement avec Delphi pour MAC mais je n'ai pas rencontré de problème particulier en connectant mon petit MacBook Air de 2013 (Core i5 (2 coeurs physiques avec HT) et 4Go de RAM) et le PC équipé de Delphi (le SSD du Mac ne fait que 128 Go donc pas beaucoup de place pour installer une VM sous Windows un peu sérieuse). D'un point de vue "debug" tout se passe bien (il faut installer PAServer sur le Mac), j'ai constaté cependant une réactivité moindre (baisse du framerate) du binaire généré pour MAC OS lorsqu'on fait de la 3D : je pense que c'est plus lié au fait que mon MAC ne dispose pas de carte graphique dédiée mais uniquement la composante graphique du CPU. De même, lorsque je compile pour Android, la fluidité (toujours d'une application 3D) dépend évidemment du composant graphique du périphérique et de la résolution de l'écran du périphérique utilisé...
Si cela intéresse certains, je prépare un petit tutoriel sur Développez : un petit jeu de Pong en 3D réalisé avec Delphi et FMX et multiplateformes (Windows, MacOS et Android (je n'ai pas de périphérique IOS pour tester)). Voici un lien vers les binaires et sources de ce tutoriel : http://gbesoft.fr/gbepong.php.
Bonjour,
Le problème ce n'est évidemment pas quand cela se passe bien ! J'ai un programme FMX lié à une base MariaDB distante. Avec FireDac, sous Windows RAS, cela fonctionne. Sous Mac RAS, mais cela ne fonctionne pas ! Le debug est muet.
Je remplace le composant FireDac par un UniDac, cela fonctionne dans les 2 environnements. Mais je n'aurais pas les composants UniDac, je ferais comment ?
Cordialement. AD.
ben tu ferais comme quand tu rencontres un bug sur UniDac, tu remontes le bug et demande un support c'est aussi pour cela qu'Embarcadero demande de souscrire à un abonnement.
je dis ça notamment car j'ai perdu aussi beaucoup de temps avec des bugs sur IBDac (l'UniDac pour Interbase/Firebird)
après il est possible que DevArt soit plus réactif à corriger un bug sur leurs composants que Embarcadero sur Delphi...la taille du projet n'aidant pas...c'est peut-être aussi un tort de vouloir fournir un IDE trop complet, avec des composants qui font tout sur toutes les plateformes...ça donne beaucoup de boulot J'ai même soumis un jour l'idée (qui n'a pas fait echo) de vendre FireMonkey indépendamment de Delphi, notamment car c'est un environnement qui a subi de nombreux refactoring qui ne facilitent pas la compatibilité ascendante. Je suis persuadé que les modifications de Firemonkey qui réclament une nouvelle version de Delphi sont très minimes, aussi la dernière version devrait compiler sans trop de problème avec un Delphi plus ancien.
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!!!
Bonjour Paul,
Pour le bug FireDac cela concerne l'accès à une de mes bases de données... Il n'est pas possible que je donne des codes d'accès donc encore moins le source du programme. J'aurais certainement obtenu un "bug non reproductible". D'autre part, c'était une version XE 7 Education donc, pour les corrections de bug, j'aurais eu encore moins accès au correctif que pour une version non-Education.
Et puis l'Unidac fonctionnait correctement. Je ne sais pas si Devart est efficace vu que je n'ai pas rencontré de bug avec leurs produits. Je n'utilise pas IB ni ses clones. Et l'autre société tierce avec laquelle je travaille, TMS, est très réactive... même pour des suggestions. Les quelques problèmes rencontrés avec FastReport FMX ont également bénéficié d'un soutien efficace... même si la "base" du produit (l'impression des champs HTML) est insuffisante.
Devart comme TMS ont un guichet facile d'accès. Que ce soit pour des "portées" de licences, des renseignements techniques, malgré le décalage horaire, j'ai toujours eu le contact sous 24H en partant d'un simple mail. Et en plus, ils sont accommodants.
En conclusion, le service des sociétés tierces me convient. Il est anonyme : je ne fais pas appel au "Grand Gourou qui seul à la connaissance de FireDac" mais à un technicien anonyme (rarement le même) qui répond à mes questions.
Avec Delphi, comme je change (changeais) d'appareil assez souvent et donc "transplantais" mon Delphi XE 7 (voire de manière quasi-obligatoire pour Mac), cela a été la croix et la bannière pour pouvoir ré-installer la licence (quota atteint)... Bref, je maintiens mes propos : faire une déclaration de bugs pour ne rien avoir, sauf à payer, avoir un contact difficile voire inextricable pour un soucis quelconque, c'est totalement anormal compte tenu de notre profession. Mais il est vrai qu'avec les habitudes... La concurrence ne semble pas les atteindre. Dommage.
Pour en revenir au sujet
Tout à fait d'accord. Qu'ils le vendent ou qu'ils le gardent, je souhaite en effet n'acheter que FireMonkey
Mais comme vous l'écrivez "qui n'a pas fait echo"...
Cordialement. AD.
Bonjour,
Bien que ce soit HS, je tiens à apporter mon expérience avec FMX, j'ai un mac mini ( mi-2011 ) avec un Core i5 de 2,3 GHz et 16 Go de RAM, windows est virtualisé avec Parallels Destop et je n'ai pas rencontré de problème de performance pour le développement d'application de gestion avec XE7.
J'ai même en maintenance une application de gestion de certains commerces ( front et back end ) assez conséquent qui est développé uniquement sous Windows ( donc avec la VCL ) et pas de problème de performance non plus.
[/HS]
Bonjour,
Concernant le matériel APPLE, un Mac Mini à 16Go est un appareil spécifique : http://www.apple.com/fr/shop/buy-mac/mac-mini car je vous rappelle que les boîtiers sont scellés et donc l'ajout de RAM est impossible. Donc il ne s"agit pas d'acheter un appareil à 8Go d'autant que la mémoire est soudée.
Pour en arriver à un appareil correct, équivalent en terme de rapidité à mes appareils Linux ("kités" certes mais à un prix raisonnable.. et prévu), la facture avoisine les 2722 € HT. Évidemment si vous estimez qu'un PC bas de gamme avec 4Go, sans SSD, avec Windows 10 tourne de manière fluide, j'espère que vous ne facturez pas les temps de latence à vos clients !
Pour essayer de préciser le sens des mots : fluides sont les installations de Lazarus ou Qt/MinGw sur Windows ou Qt sur un Linux. Une latence, c'est l'installation de Delphi, de VS...
Mac mini [Simulateur]
Intel Core i7 bicœur à 3 GHz (Turbo Boost jusqu’à 3,5 GHz)
16 Go de mémoire SDRAM LPDDR3 à 1 600 MHz
1 To de stockage flash PCIe
Intel Iris Graphics
Adaptateur HDMI vers DVI Apple
Clavier Apple avec pavé numérique - Français
Guide de l'utilisateur (Français)
Magic Mouse 2
Kit d’accessoires
Cordialement AD
PS : zut, j'ai oublié l'abonnement à Parallels Desktop 99€ annuellement Et il faut aimer : j'ai rarement vu un tel foutoir sur mes écrans !
Bonjour Free07,
- Pour la fluidité cela voulait être de l'humour ... et j'aime bien me moquer du lancement de mes Windows sans SSD
- Pour la Ram : Maintenant, malheureusement si... et depuis 2014. Je suppose que le vôtre date d'avant... Pour être franc, je n'ai pas ouvert le mien : je ne vais pas l'attaquer à l'ouvre-boite. Mais le commercial d'Apple m'a prévenu avant que je l'achète ; Je vais lui faire confiance.
Apple Mac mini? Ceci dit, c'est un très bel appareil et le service après-vente est sans reproche !
Cordialement. AD.
C++Builder est un vrai RAD (y compris les composants non-visuels) mais c'est important uniquement pour la conception visuelle et la simplicité.
Sinon C++Builder profit tous les avantages d'accès aux données de Delphi.
Dans "enterprise programming" t'a besoin les composants performants pour manipuler les grosses volumes des données de différentes types SGBD.
FireDAC (ancien AnyDAC) et UniDAC sont les solutions plus connues mais il y en a les autres.
En Qt c'est pas génial, i.e. QSqlTableModel / QSqlQueryModel sont assez primitifs et ne sont convenables que pour les cas simples et petites volumes.
Dans Lazarus le "data access" c'est quasiment nul (comme toute la palette de composant), il faut acheter UniDAC pour débuter le travail.
Il n'y a pas MVC dans Qt, MV uniquement.
Sinon Qt a ces avantages connus et si les pb ci-dessus ne te concerne pas c'est une très bonne outil.
Bonjour Serguei,
Parfaitement d'accord surtout quand je compare à UniDac.
Tout à fait d'accord aussi. Pour diverses raisons et suite à divers essais, j'en suis arrivé à la même conclusion et j'ai retenu cette option.
Oui, comparés à Qt, C++ Builder, Delphi et Lazarus ne sont pas à la hauteur avec les composants graphiques tels que les Grids et d'une manière plus générale, tous les champs d'affichage/saisie même en les renforçant avec ceux de TMS. Et surtout ils ne sont pas personnalisables comme on peut le faire avec Qt. Les gestions de la saisie, de l'affichage et de l'impression du HTML et du RTF sous Delphi et donc sous C++ Builder puisque ce sont les mêmes composants, ainsi que celles de Lazarus (bien que différentes) sont simplement catastrophiques, totalement désuètes et limitées, à croire que les utilisateurs de Delphi/C++ Builder/Lazarus n'ont pas besoin du texte enrichi. Pourtant au départ le principe des dbGrids connectées aux DataSet est génial et à mon avis, supérieur à l'approche de Qt en ce domaine. Mais les développeurs de Delphi/C++ Builder se sont concentrés uniquement sur l'aspect des connexions au bases, délaissant totalement l'affichage notamment du HTML/RTF. D'ailleurs il suffit de regarder les capacités graphiques des TStringGrids (VCL) et des TGrids (FMX) fournies avec les actuels Delphi et C++ Builder pour se rendre compte du retard en la matière. A ce niveau, je les considère tout à fait moyenâgeuses et elles ne présentent pratiquement pas d'évolution depuis... Delphi 7, peut-être même avant. Enfin très grosse différence, la gestion des SIGNAL/SLOT de Qt qui même si elle est difficile à appréhender au départ est un immense avantage, une facilité de développement que je trouve maintenant incomparable.
En résumé, dans Qt il manque un accès aux bases à la C++ Builder et dans C++ Builder, il manque des composants modernes et facilement améliorables par le développeur comme ceux de Qt. Et pour rester équitable : j'apprécie les SIGNAL/SLOT de Qt inexistants dans C++ Builder et la présence des exceptions dans C++ Builder inexistantes sous Qt.
Cordialement. AD
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager