Bonjour à tout le monde !
@Jipété
Envoyé par
Jipété
la seule aide qu'on peut avoir sur le
TLazIntfImage c'est cette
complètement périmée page web, où l'on peut encore lire à ce jour des énormités genre (c'est moi qui mets en gras) [...] Franchement, rien que ce point ne me donne pas envie de migrer.
Tu fais référence à une
page wiki ouverte à la communauté : il ne s'agit pas d'une page officielle de Lazarus. Moyennant un code d'accès, chacun peut y écrire (dans la langue de son choix) ce qu'il souhaite pour aider les autres. Parfois ce n'est pas une réussite ou l'information fournie peut être parcellaire ou obsolète... Ce phénomène est vrai de tous les wikis !
Certes, il y a des contributeurs qui font partie du noyau de développeurs de Lazarus, mais ils interviennent en leur nom propre. Quant à certains exemples non pertinents, il y en a certainement : il faut faire le tri !
Envoyé par
Jipété
Cependant, quelque chose qui pourrait me faire reconsidérer ce choix, c'est ce que j'avais soulevé
il y a quelque temps, et que je rappelle : la possibilité de masquer des onglets de l'EDI fonctionne-t-elle enfin ? Quelqu'un pourrait regarder et nous dire ? Merci...
Non, ça ne fonctionne pas. Mais je ne comprends pas le "enfin", car il ne s'agit, à ma connaissance, en aucun cas d
'une fonctionnalité réclamée depuis longtemps par un groupe d'utilisateurs. Autrement dit, si tu es seul à poser le problème, ne t'attends pas à une réponse individualisée !
Il ne s'agit pas d'une priorité, d'autant plus que cette fonctionnalité, à rapprocher de celle que tu réclames aussi ("Mettre en place une fenêtre permettant de choisir à l'install les compos qu'on voudrait parmi ceux qui sont matures et indispensables, je dirais"
pose de nombreux problèmes techniques (quid des volets vides ? où activer et désactiver la visibilité d'un composant ? que faire d'un composant présent sur une fiche mais désactivé sur la palette ?...). Quant à faire son marché de composants selon les critères "mature" et "indispensable", non seulement la subjectivité entre en jeu, mais le gain serait vite compensé et dépassé par l'inconvénient majeur d'une recompilation nécessaire de tout l'EDI. De plus, nombreux sont les composants proposés qui sont des éléments constitutifs de l'EDI : par exemple, tu voudrais désinstaller les composants SynEdit que tu interdirais tout simplement la compilation de Lazarus qui s'en sert dans ses éditeurs... D'ailleurs, quel serait le gain ? Une palette moins encombrée ? Franchement, elle est légère par défaut (que dirais-tu de celle de Code Typhon, alors !!!). Pour résumé, cela ferait beaucoup de travail pour pas grand chose et même avec des risques d'énerver les utilisateurs ou de rendre l'EDI instable... Cela dit, puisque les options apparaissent en grisé (et en anglais,ce qui montre que rien n'est actif), c'est qu'elles sont dans les tuyaux, mais à mon avis pas du tout en tête des priorités.
Envoyé par
Jipété
Et pendant qu'on y est,
ça, c'est corrigé ? Le pb d'aide dans la fenêtre de propriétés du TMaskEdit ?
A cette question, je vais répondre par un rappel qui vaut pour tout le monde : Lazarus (comme Free Pascal) est un produit open source, gratuit (y compris pour une exploitation commerciale des applications qu'il permet de développer), et qui
dépend entièrement du travail bénévole de sa communauté. Autant dire que personne ne peut avoir d'exigences particulières comme il serait légitime d'en avoir pour un produit comme Delphi, par exemple, avec une licence à payer. Cela n'empêche pas de formuler des souhaits, ce qui participe d'un autre état d'esprit à mon avis.
L'ensemble de Lazarus est tout de même plus qu'intéressant. Il doit encore faire des progrès, sans doute, mais il bénéficie d'une communauté très active. Free Pascal est un compilateur si abouti en termes de robustesse, d'efficacité et de rapidité du code produit, qu'il sert dans l'industrie et qu'il avait même été intégré à Delphi (partie Kylix). Les deux ont en revanche un défaut qu'on retrouve dans la plupart des applications de ce type, à savoir l'absence d'une documentation complète. Mine de rien, documenter un produit est un processus long et difficile. Les programmeurs ne sont pas non plus des spécialistes de l'écrit. Pour que "ça, c'est corrigé ?" puisse avoir une réponse positive, il faudrait que quelqu'un prenne en charge le problème, le résolve et propose sa solution à l'équipe de développement.
Envoyé par
Jipété
La réponse est "presque oui"
. En fait, tes propositions feront partie de la version 2.2 (mais sont déjà accessibles depuis le tronc SVN).
Une fois encore, l'énoncé d'un problème apparemment simple n'implique pas une solution facile à mettre en place. Déjà, pour les messages, il existe
ici même une discussion plus appropriée pour exposer les requêtes que
celle des améliorations à apporter à l'EDI. Même si tu utilises cette page, il ne faudra pas simplement changer la traduction par la nouvelle formulation. Déjà, il faut savoir où et quand la chaîne à modifier est utilisée afin d'éviter de rendre plus lisible une indication pour en obscurcir une autre (qui utiliserait la même chaîne mais ailleurs ou à un autre moment). Il faut évidemment tenir compte de la chaîne originale (en anglais) dont on peut cependant s'éloigner à ses risques et périls : si elle devait être modifiée, l'amélioration apportée peut facilement devenir incongrue ou fautive. De plus, les chaînes à considérer se comptent en milliers (> 10 000) réparties en plusieurs dizaines de fichiers. Les fichiers originaux à traduire sont régulièrement complétés afin de prendre en compte de nouvelles chaînes ou des modifications (parfois parce que les chaînes originales en anglais étaient elles-mêmes fautives !). Une fois ces tests effectués, il faut soumettre les fichiers modifiés à l'équipe Lazarus avec qui s'établit une discussion avant validation (aujourd'hui, cette partie est simplifiée, car j'ai acquis la confiance de celui qui centralise les fichiers, mais qui ne parle pas un traître mot de français !). Comme je suis moi-même bénévole (y compris dans ces colonnes), il me faut aussi du temps pour réagir. Heureusement que d'autres membres de DVP (que je remercie et salue ici) aident à ce travail de fourmi...
Envoyé par
Jipété
Qu'est-ce qu'il apporte de neuf ?
Tout et rien. Rien si tu considères tel point de détail qui t'horripile (comme TListBox, par exemple, toujours en plan) et tout si tu prends en compte les centaines de bogues et d'améliorations apportés depuis les versions 1.6, par exemple. Il faut moins de cinq minutes sur Linux ou Windows (plus longtemps sur un Mac) pour installer Lazarus. Tu n'as aucune régression de 1.6 à 2.0 et un nombre considérable d'améliorations (je te renvoie aux différents articles publiés dans nos colonnes à ce sujet qui renvoient souvent à la liste officielle publiée par l'équipe de Lazarus). Le seul argument à peu près recevable que je vois pour la non installation des nouvelles versions serait de posséder de nombreuses bibliothèques à réinstaller : même dans ce cas, étant donné l'espacement des versions, le temps "perdu" vaudrait le coup. En revanche, attendre un peu et ne pas se précipiter peut être intéressant avec des installations exotiques, le temps d'être sûr que tout fonctionne bien, mais les version RC apportent à cet égard une grande sécurité.
Alors, convaincu ?
1 |
0 |
L'équipe de développement de Lazarus a annoncé la sortie de Lazarus 2.0.0, l'EDI open source bâti autour de Free Pascal. Alors qu'une version RC4 était attendue, c'est bien la version définitive 2.0.0 qui est disponible au téléchargement dès ce jour.
Allez-vous utiliser cette version majeure de Lazarus ?
), rien d'autre! Je n'ai jamais vu une société décider de démarrer un projet en Pascal parce que Lazarus aurait remis à la mode le langage!
