Discussion :

[tintinux]

Bonjour à tous.

J'ai trouvé un nom disponible : gestinux et j'ai créé un projet sur sourceforge.

C'est donc là que peuvent s'inscrire les volontaires...

Il faudra mieux s'exprimer en anglais !

EDIT : Je découvre SourceForge : il faut apparemment me demander de vous inscrire au projet (en donnant votre pseudo sourceforge, obtenu après inscription sur ce site).

A bientôt

Tintinux

[girardhenri]

Salut,
Il y a déjà comptalinex en espagnol.
J'ai eu du mal à compiler mais il existe un deb
Mais comme trame ça peut donner une idée.
Autrement sous gambas2 il existe laurux.fr une compta excellente

[tintinux]

Bonjour,

J'avais essayé de contacter les développeurs de comptalinex, sans réponse à ce jour. Il faudrait qu'il puisse être traduit en français et je n'ai pas vu que les états soient paramétrables pour des exigences non espagnoles (mais je me trompe peut-être, ne parlant pas un mot de cette langue).

Quant à Laurux, il bourré de bugs, je le trouve mal conçu et peu robuste, et il lui manque encore beaucoup de fonctions. Il doit être possible de faire beaucoup mieux, avec un AGL digne de ce nom.

Mes développements avancent, mais j'ai eu moins de temps disponible que prévu. L'importation de données et une saisie d'écritures vont être bientôt montrables, d'ici mi-juin j'espère.

Cordialement,
Tintinux

[tintinux]

Voici quelques nouvelles et un premier bilan :

Aucun problème avec les StringGrid en 0.28.2, quoi qu'en dise selzig. Certes, des colonnes invisibles et un événement de validation de cellule seraient appréciables mais cela ne justifie pas à mon avis l'utilisation d'une version instable.

Pas trop de soucis non plus avec LazReport et l'exportation en PDF est parfaite. Le designer de report est toutefois un peu pénible et plante très souvent sous Linux, mais apparemment marche mieux sous Windows. Pas moyen non plus de faire marcher les fonctions utilisateur.

J'ai fait un module qui, en faisant utiliser le designer de LazReport par l'application devrait permettre de concevoir des états fiscaux pour un grand nombre de pays.

Ce qui m'a le plus ennuyé a été l'impossibilité de faire hériter des Form d'un ou plusieurs modèles, comme je faisais autrefois avec Delphi. On a des erreurs imprévisibles en lisant les dfm. Les TFrames ne sont pas non plus parfaites, et leurs événements doivent être assignés par code, ou sinon se perdent...

Le bilan est donc positif pour Lazarus, même si la version 0.30 ou 1.0 est attendue avec impatience !

En l'équivalent d'un mois à plein temps, passé surtout à tester différents composants et fonctionnalités, j'ai une petite comptabilité presque opérationnelle pour une TPE. Il y a évidemment encore beaucoup à faire, mais comme je démarre un nouveau boulot, je vais devoir y passer beaucoup moins de temps.

J'ai une demande pour continuer sur des fonctions ventes et achats, afin de remplacer un petit ERP dans une PME, mais je ne peux pas la satisfaire. Elle pourrait pourtant être rémunérée. Avis aux amateurs !

[Invité]

Bonjour Tintinux,

Merci pour votre CR mais je comprends mal certains de vos propos. Un déni de bug ? Question d'interprétation ?

Voici quelques nouvelles et un premier bilan :
Aucun problème avec les StringGrid en 0.28.2, quoi qu'en dise selzig. Certes, des colonnes invisibles et un événement de validation de cellule seraient appréciables mais cela ne justifie pas à mon avis l'utilisation d'une version instable.

En 0.9.28, les StringGrids sont buggées ! C'est un fait que j'ai pris la peine de vérifier avant de le ré-écrire... [J'ai installé la dernière 0.9.28 alors que je ne me sers plus de ces versions]. Maintenant que vous ne vous serviez pas de la fonction que j'évoque, tant mieux... Mais en quoi la non-utilisation de la fonction de visibilité des colonnes peut-elle relativiser ce bug ? Il faut rester pragmatique. Il y a bug ou pas bug : si "Aucun problème... quoi qu'en dise selzig"... alors pas bug ! Et pourtant, je maintiens qu'avant la 0.9.29, si votre StringGrid possède X colonnes dont Y déclarées invisibles, le code affiche les X-Y premières colonnes de la StringGrid et ceci quelque soit le N° des colonnes déclarées invisibles...

En quoi la non-utilisation de la fonction de visibilité des colonnes peut-elle relativiser ce bug ? La réponse semble être dans la suite de vos propos : "Certes, des colonnes invisibles [...] seraient appréciables". Evidemment vu ainsi... Justement en 0.9.28, cette fonction est implantée sur les colonnes... et buggée. Mais, puisque les colonnes invisibles ne fonctionnent pas, elles "disparaissent" ? Donc, en élargissant grossièrement le propos : il n'y a pas de problème parce que tout ce qui ne fonctionne pas, n'existe pas... et donc, "évidemment", à ce titre, ne peut pas poser de problème... CQFD. Avec un tel angle d'attaque, je ne peux que souscrire à votre conclusion.

En attendant avec la 0.9.28, on peut contourner le problème évoqué, par exemple comme je l'avais fait en associant une StringGrid.visible := false; à la StringGrid initiale dont toutes les colonnes seront visibles (puisqu'on ne peut pas en rendre invisibles). Après c'est un choix. Il faut déterminer et évaluer l'impact d'une telle solution de contournement. En ce qui me concerne, le codage de la couche métier me semble souvent suffisamment compliqué...

Ce qui m'amène à ne pas partager non plus -décidément c'est beaucoup de contestations pour 2 phrases citées- votre assurance quant à l'emploi "obligatoire" d'une version stable... D'abord, il y a là une "interprétation linguistique" toute Lazarusienne que j'ai eu un peu de mal à comprendre lorsque j'ai découvert Lazarus. Mais en réalité, il faut "entendre" que seule la 1.0 sera stable... et encore quand on voit le postulat de départ, on peut en douter... (et tant mieux). Le reste, c'est du beta. La 0.9.28 est la dernière évolution de la version de développement 0.9.27 qui n'a jamais existé réellement avec cette appellation... Elle ne représente qu'un aboutissement d'un cycle de développement en cours... (alors qu'un autre, le suivant est déjà en projet). Le code est alors en effet "stabilisé" (et non pas stable) dans son développement et... dans ses erreurs. C'est très déroutant au départ. Ainsi, les 0.9.26, 0.9.28 bâties conceptuellement grosso-modo sur le même Grid.pas n'ont pas permis de corriger le problème des colonnes invisibles. Un nouveau cycle de développement a permis de réécrire de manière importante les "ancêtres" nécessaires à cette correction.

Alors évidemment, utiliser une version stable m'a paru au départ plus rassurant et habituel... et efficace. Je l'ai écrit plusieurs fois dans ce forum. Et j'ai changé d'avis pour 2 raisons :

• Depuis la 0.9.29, je développe "normalement" avec des StringGrids, le normalement signifiant "tel que l'on peut l'attendre du cahier des charges de la fonction invisible des colonnes" par exemple. Si j'attends la future "stable" (la 0.9.30), en "conservant" la 0.9.28, je reste avec des StringGrids buggées, amputées de fonctionnalités qui nécessitent, pour être utilisées, un code de contournement qui impacterait tellement fortement mon développement (tenant compte du bug) qu'il ne sera pas réversible... au point qu'il faudra totalement le ré-écrire avec une 0.9.30 ! Donc, ce cas est typiquement un contre-exemple de productivité avec l'utilisation d'une version stable. Je ne dis pas que c'est généralisable... Mais cela peut ébranler quelques certitudes...
• De plus, utiliser les dernières releases me permet de participer modestement mais constructivement au développement de Lazarus. Je teste, je signale, je propose quand je le peux. Je rouspète également... en utilisant le canal privé du bug tracker.

A chacun d'adapter sa pratique donc... Mais utiliser une version de développement non "stable" ne doit pas être éliminé d'un simple trait de plume... ou être présenté comme un non-sens, une hérésie...

Au final, j'apprécie énormément Lazarus : c'est un projet extrêmement ambitieux et sympathique. Mais, sans aucune polémique, quelque soit cet attachement, un bug est un bug et doit être signalé comme tel. Il est acceptable ou non. Chacun choisit. On sait (ou on peut) le contourner ou pas... In fine, cela reste un bug qu'il faut corriger sinon, à terme, l'ensemble devient incohérent et peu praticable... Et par soucis de maintenir des sources d'information fiables, il ne doit être ni minimisé (c'est la mauvaise interprétation sans doute dont je parlais au départ et dont je veux ici simplement supprimer l'équivoque), ni maximisé (j'espère que je n'ai pas donné cette impression), mais simplement signalé.

Bon WE.
Cordialement. Gilles