Discussion :

[tourlourou]

Sortie de la version 5.30 de CodeTyphon Studio
L'IDE multiplateforme basé sur Free Pascal et Lazarus

La version 5.30 de CodeTyphon Studio vient de sortir, avec un support étendu, par exemple, à Ubuntu 15.04 et à la cross-compilation ciblant le Raspberry Pi 2. A titre expérimental, ajout des plateformes QT5 et fpGUI.

A noter l'introduction des collections génériques de FPC sous tous les OS. Et un assistant de compatibilité sous Windows pour gérer les manifestes.

Le caractère polyvalent de CodeTyphon Studio et sa compétitivité continuent de s'affirmer au fur et à mesure des enrichissements et évolutions.

Téléchargez CodeTyphon Studio

Nouveautés de cette version 5.30 :

********************************************
* CodeTyphon Studio *
* GENERATION V *
* Changes Log File *
* PilotLogic Software House *
* 2008-2015 *
********************************************


======> 29-Apr-2015 ver 5.30 ========================================

Cosmetic 1: New Typhon IDE "components" Directory Structure
Cosmetic 2: Replace TyphonIDE Main Toolbar with Customizable CoolBar
Cosmetic 3: ADD QT5 platform support (Experiment)
Cosmetic 4: ADD fpGUI platform support (Experiment)
Cosmetic 5: ADD Generics Collections support to FreePascal (for ALL OSes)
Cosmetic 6: New Building Methogology for Typhon IDE, common for all Host OSes
Step1:Build typhonstart, tyhponbuild and Small TyphonIDE with makefile method
Step2:Build Typhon BigIDE with tyhponbuild
Step3:Build IDE tools with tyhponbuild
Cosmetic 7: Add "Program Compatibility Assistant (PCA)" to Project Options,
This is for MS Windows only
Cosmetic 8: Rename a lot of Typhon IDE packages:

LazUtils.lpk ==> bs_Utils.lpk
SynEdit.lpk ==> bs_SynEdit.lpk
IDEIntf.lpk ==> bs_IDEIntf.lpk
DebuggerIntf.lpk ==> bs_DebuggerIntf.lpk
LazDebuggerGdbmi.lpk ==> bs_DebuggerGdbmi.lpk
lazcontrols.lpk ==> bs_Controls.lpk
CodeTools.lpk ==> bs_CodeTools.lpk
tachartfpvectorial.lpk ==> lz_tachartvectorial.lpk
tachartaggpas.lpk ==> lz_tachartaggpas.lpk
tachartbgra.lpk ==> lz_tachartbgra.lpk
tachartprint.lpk ==> lz_tachartprint.lpk
tachartwmf.lpk ==> lz_tacharwmf.lpk
lr_add_function.lpk ==> lz_reportaddfunction.lpk
lr_cairoexport.lpk ==> lz_reportcairoexport.lpk
lr_codereport_pkg.lpk ==> lz_reportcodereport.lpk
lr_dialogdesign.lpk ==> lz_reportdialogcontrols.lpk
lr_emailexport.lpk ==> lz_reportemailexport.lpk
lr_imgexport.lpk ==> lz_reportimgexport.lpk
lr_officeimport.lpk ==> lz_reportofficeimport.lpk
lr_pdfexport.lpk ==> lz_reportpdfexport.lpk
lr_sqldb.lpk ==> lz_reportsqldb.lpk
lr_tdbf.lpk ==> lz_reporttdbf.lpk
lr_zeosdb.lpk ==> lz_reportzeosdb.lpk
lr_extexp.lpk ==> lz_reportimgexport.lpk
lazreportpdfexport.lpk ==> lz_reportpdfexport.lpk
fpcunittestrunner.lpk ==> lz_fpcunitrunner.lpk
fpcunitconsolerunner.lpk ==> lz_fpcunitrunnerconsole.lpk
anchordocking.lpk ==> lz_anchordocking.lpk
anchordockingdsgn.lpk ==> lz_anchordockingdsgn.lpk
lazdebuggerfpgdbmi.lpk ==> lz_debuggerfpgdbmi.lpk
messagecomposerpkg.lpk ==> lz_messagecomposer.lpk
lazmouseandkeyinput.lpk ==> lz_mouseandkeyinput.lpk
multithreadprocslaz.lpk ==> lz_multithreadprocs.lpk
lazaruspackagemanager.lpk ==> lz_packagemanager.lpk
runtimetypeinfocontrols.lpk ==> lz_rtticontrols.lpk
tachartlazaruspkg.lpk ==> lz_tachart.lpk
lhelpcontrolpkg.lpk ==> lz_chmhelp.lpk
turbopoweripro.lpk ==> lz_tpipro.lpk
turbopoweriprodsgn.lpk ==> lz_tpiprodsgn.lpk
cairocanvas_pkg.lpk ==> lz_cairocanvas.lpk
aarrebase.lpk ==> lz_aarrebase.lpk
LazActiveX.lpk ==> lz_activex.lpk
chmhelppkg.lpk ==> lz_chmhelpide.lpk
customdrawn.lpk ==> lz_customdrawn.lpk
lazcustforms.lpk ==> lz_custforms.lpk
lazdaemon.lpk ==> lz_daemon.lpk
lazdatadict.lpk ==> lz_datadict.lpk
datetimectrls.lpk ==> lz_datetimectrls.lpk
lazdbexport.lpk ==> lz_dbexport.lpk
lazdebuggerfp.lpk ==> lz_debuggerfp.lpk
editortoolbar.lpk ==> lz_editortoolbar.lpk
educationlaz.lpk ==> lz_education.lpk
externhelp.lpk ==> lz_externhelp.lpk
idefilebrowser.lpk ==> lz_filebrowser.lpk
fpcunitide.lpk ==> lz_fpcunitide.lpk
fpdebug.lpk ==> lz_fpdebug.lpk
fpvectorialpkg.lpk ==> lz_fpvectorial.lpk
h2paswizard.lpk ==> lz_h2pas.lpk
ideinspector.lpk ==> lz_ideinspector.lpk
idelazlogger.lpk ==> lz_idelazlogger.lpk
imagesforlazarus.lpk ==> lz_images.lpk
lazcontroldsgn.lpk ==> lz_basecontroldsgn.lpk
industrial.lpk ==> lz_industrial.lpk
instantfpclaz.lpk ==> lz_instantfpc.lpk
jcfidelazarus.lpk ==> lz_jcf2.lpk
leakview.lpk ==> lz_leakview.lpk
macosfiles.lpk ==> lz_macfiles.lpk
editormacroscript.lpk ==> lz_macroscript.lpk
memdslaz.lpk ==> lz_memds.lpk
lazmrumenu.lpk ==> lz_mrumenu.lpk
lazopenglcontext.lpk ==> lz_opengl.lpk
lazparadox.lpk ==> lz_paradox.lpk
lazplotfunction.lpk ==> lz_plotfunction.lpk
pochecker.lpk ==> lz_pochecker.lpk
printer4lazarus.lpk ==> lz_printers.lpk
printers4lazide.lpk ==> lz_printerside.lpk
projtemplates.lpk ==> lz_projtemplates.lpk
lazreport.lpk ==> lz_report.lpk
simpleideintf.lpk ==> lz_simpleideintf.lpk
sqlite3laz.lpk ==> lz_sqlite3.lpk
sqldblaz.lpk ==> lz_sqldb.lpk
sqlitelaz.lpk ==> lz_sqlite.lpk
lazsvnpkg.lpk ==> lz_svnide.lpk
syneditdsgn.lpk ==> lz_syneditdsgn.lpk
synuni.lpk ==> lz_synuni.lpk
dbflaz.lpk ==> lz_tdbf.lpk
lazthread.lpk ==> lz_thread.lpk
todolistlaz.lpk ==> lz_todolist.lpk
svnpkg.lpk ==> lz_svnpkg.lpk
lazvlc.lpk ==> lz_vlc.lpk
lazwiki.lpk ==> lz_wiki.lpk
weblaz.lpk ==> lz_fpweb.lpk
sdflaz.lpk ==> lz_sdf.lpk
cody.lpk ==> lz_cody.lpk
lazc.lpk ==> lz_compilerc.lpk
rx.lpk ==> lz_rxbase.lpk
pl_lazpackager.lpk ==> pl_packager.lpk
pl_lazwebsolutions.lpk ==> pl_solutionsWeb.lpk
pl_lazsolutions.lpk ==> pl_solutions.lpk
pl_cgilazide.lpk ==> pl_cgiide.lpk
pl_cgilaz.lpk ==> pl_cgi.lpk

NOTE 1: ADD "CTFPC" Compiler Directive {$IFDEF CTFPC}
NOTE 2: ADD "CTDir", "TyphonDir" and "TyphonBinDir" IDE macro values
NOTE 3: Move ALL help files (pdf,chm, html, etc) to codetyphon/help directory
NOTE 4: ADD ability to build Typhon IDE for "customdrawn and "fpgui" platforms on Windows and solaris


-ADD Support for Oracle Linux Server 7.1 (MultiArch for GTK2)
-ADD Support for Debian Linux ver 8
-ADD Support for Ubuntu Linux ver 15.04
-ADD CrossBuild Support for Rapberry Pi 2

-Update GDB for Win32 to Ver 7.9 (release day 20-02-2015)
-Update GDB for Win64 to Ver 7.9 (release day 20-02-2015)
-Update make.exe to ver 4.10 for win32 and win64 (release day 05-10-2014)
-Update Wget for windows 32/64 to ver 1.16.1 (release date 08-12-2014)

-Update All CT OS Scripts

-ADD pl_RGBGraphics ver 5.3.1 to Typhon IDE Components System
-ADD pl_UOS ver 5.3.1 to Typhon IDE Components System
-ADD pl_ChipmunkPas ver 5.3.1 to Typhon IDE Components System

-Update pl_PascalScript to Ver 5.3.1
-Update pl_DCP to ver 5.3.1
-Update pl_PasDoc to ver 5.3.1 Source 07-02-2015 SVN Rev 1374
-Update pl_ZMSQL to ver 0.1.19
-Update pl_Shapes to ver 5.3.1
-Update pl_AGGPas to ver 5.3.1
-Update pl_Win_DSPack to ver 5.3.4
-Update pl_ZeosDBO to ver 7.2.0.18 Source 08-03-2015 SVN Rev 3621
-Update pl_Synapse to ver 40.1.10 Source 08-03-2015 SVN Rev 203
-Update pl_PascalSCADA to ver 5.3.1 Source 09-03-2015 SVN Rev 890
-Update pl_PascalScript to ver 5.3.4 Source 12-01-2015 GIT hash: a118089ad314f81e57c0a297bc9ba2cc8a6f96fa
-Update pl_Chelper to ver 5.3.4 Source 16-03-2015 SVN Rev 4037
-Update pl_LuiControls to ver 5.3.4 Source 21-03-2015 SVN Rev 1356
-Update pl_ExDesign to ver 5.3.1
-Update pl_Cindy to ver 6.7.4
-Update pl_OpenGL to Ver 5.3.4 (ADD support for OpenGL 4.5 API)
-Update pl_GeoGIS to Ver 5.3.1
-Update pl_BGRAbitmap to ver 8.1.0.1 Source 02-04-2015 SVN Rev 1008
-Update pl_BGRAControls to ver 5.3.1 Source 02-04-2015 SVN Rev 64
-Update pl_Win_DSPack to ver 5.3.6
-Update pl_Win_DirectX to ver 5.3.1
-Update pl_ORCA to ver 5.3.1
-Update pl_Graphics32 to ver 5.3.4 Source 08-04-2015 SVN Rev 2192
-Update pl_Indy to ver 10.6.2.6 Source 08-04-2015 SVN Rev 5270
-Update pl_GLScene to ver 5.3.6 Synchronize with Source 08-04-2015 SVN Rev 6648
-Update pl_RX to ver 5.3.6 Source 08-04-2015 SVN Rev 4078
-Update pl_WST to ver 5.3.4 Source 08-04-2015 SVN Rev 4078
-Update pl_RichMemo to ver 5.3.6 Source 08-04-2015 SVN Rev 4078
-Update pl_FPSpreadsheet to ver 5.3.8 Source 08-04-2015 SVN Rev 4078
-Update pl_OnGuard to ver 5.3.1
-Update pl_nxPascal to ver 5.3.1
-Update FpGUI to Ver 1.4 Source 11-04-2015 GIT hash: 9a165f802fa9bc59fe40dbfcadd8a18571459405
-Update pl_Orpheus to Ver 5.3.1
-Update pl_GlassDocking to Ver 5.3.1
-Update pl_ECControls to Ver 5.3.4


FreePascal 3.1.1 Source 28-04-2015 SVN Rev 30739

Et vous ?
Avez-vous essayé cet IDE ?
Que lui manque-t-il pour vous décider à le tester ?

[Roland Chastain]

Je me suis laissé tenter : je l'ai installé (sous Windows 8.1). Le processus d'installation et de construction est assez impressionnant. La personne ou les personnes qui ont conçu cet outil maîtrisent leur affaire.
Après, je n'ai pas encore travaillé avec et je ne sais pas trop ce que CodeTyphon Studio m'apportera de plus que Lazarus tout seul ; mais déjà d'être déchargé des problèmes d'installation et de pouvoir compter (théoriquement) sur des composants qui fonctionnent, c'est déjà quelque chose de très appréciable.

[tourlourou]

Bonsoir Roland

Oui, c'est déjà énorme ! Je m'étais d'ailleurs orienté vers CodeTyphon après mes soucis d'installation de Lazarus... Et c'est aussi facile sous Windows que sous Ubuntu.

[inforock]

Bonjour tout le monde,

J'utilise CodeTyphon depuis la version 4.8 (si je me souviens bien )

Je suis passé de Lazarus à Codetyphon car avec Codetyphon la palette de composants est plus importante par défaut : pas besoin de les installer. J'utilise beaucoup les composants Indy, UIB, ZEOS : par défaut, ils sont tous installés et prêt à l'emploi ... L'installation de l'environnement est facile et les mises à jours encore plus. Avec Codetyphon Studio, il est facile de construire les différents environnements dont on a besoin ...

J'ai développé avec cet IDE différents programmes, dont des services Windows (transferts FTP, envoi de mails, génération de fichiers à partir de base de données Oracle, ...). Le tout est installé et fonctionnel en environnement de production sur des serveurs depuis plusieurs mois sans aucun soucis particuliers.

Mais il y a quand même quelques inconvénients, comme, par exemple, à chaque mise à jour de l'environnement, il faut recommencer tout le paramétrage qu'on avait fait au préalable (couleurs de l'éditeur, ...). Dommage que la configuration ne soit pas sauvegardée pour ensuite être reprise après la mise à jour.

Cdt

Laurent

[naute]

Bonjour à tous.

Que lui manque-t-il pour vous décider à le tester ?

La question est un peu déstabilisante dans la mesure où pour savoir ce qui manque, il faut l'avoir testé .

Quoiqu'il en soit, je l'ai installé sous Vista sur un vieux portable pour test. Tout s'est parfaitement bien passé, mise à part une installation incomplète des composants due à un manque de place sur mon disque. Il semble qu'il y ait une installation "Light" et une installation "Big". Je n'avais pas fait attention à la taille de l'ensemble.

Cela m'a d'ailleurs permis, après avoir fait le ménage, de reconstruire l'IDE, ce qui m'a également fait constater l'absence de sauvegarde du paramétrage (j'avais aussi paramétré l'éditeur , habitudes habitudes : J'étais habitué au fond noir avec TP4 mais depuis Delphi 1 je préfère le fond blanc).

La reconstruction s'est parfaitement bien passée, et je me trouve donc en possession d'un nombre ahurissant de composants, qui me font un peu penser à la collection Jedi. Le problème, comme avec Jedi, c'est le manque quasi total d'aide, ne serait-ce qu'une brève description des composants pour, au moins, savoir à quoi ils servent. Si ça semble à peu près évident pour certains d'entre eux, c'est loin de l'être pour la majorité, du moins en ce qui me concerne.

De plus, je comptais un peu disposer des composant MDO d'accès au SGDB FireBird que j'utilise sous Delphi et que je ne sais pas modifier pour les installer sous Lazarus .

De toute manière, chapeau bas pour le boulot.

Une petite question: quel est le rapport exact entre Lazarus et Code Typhon, à part amical (j'espère)? En dehors de quelques différences cosmétiques dans l'interface, la ressemblance est énorme. Est-ce que le code est le même?

Cordialement, naute.

[tourlourou]

Bonjour,

Regarde ici pour les composants MDO.

[naute]

Merci beaucoup, tourlourou,

mais je m'étais mal exprimé. Je dispose déjà des composants MDO, que j'ai d'ailleurs téléchargé depuis le site dont tu donnes le lien, et qui sont écrits pour Delphi 5 à Delphi 2005 (voire 2006).
Le problème est que je ne sais pas les modifier pour les installer sur Lazarus, et donc sur, j'imagine, Code Typhon, notamment la clause "uses windows", que je ne sais pas par quoi remplacer.

Mais ce n'est probablement pas le bon post pour parler de ça.

Cordialement, naute.

[tourlourou]

OK, je ne l'avais pas compris ainsi. Je pense que l'avis majoritaire en pareil cas serait de passer à des composants maintenus régulièrement et performants, type ZEOS, inclus dans CT, avec bien d'autres d'ailleurs.

La question est un peu déstabilisante dans la mesure où pour savoir ce qui manque, il faut l'avoir testé

C'est assez vrai ! Cela dit, je sais ce qui manque à une Ferrari pour que je m'en serve pour déménager, même sans en posséder...
Et ce qui peut lui manquer ne réside pas forcément dans ce qu'on en peut tester, mais dans la confiance, le bouche à oreilles, la satisfaction que l'on éprouve avec ses outils et qui n'incite pas à voir ailleurs, etc.

Pour l'EDI Typhon, il est maison depuis la version 4.30 du 2 juin 2013, mais je ne sais pas à dans quelle proportion il hérite de Lazarus... Depuis la 5.10 du 30 octobre 2014, où il était encore indiqué synchronisé avec Lazarus (Source 28-10-2014 SVN Rev 46696), cette mention a disparu des deux ChangesLogs ultérieurs. Il y a pê des divergences ou choix incompatibles.

[naute]

C'est assez vrai ! Cela dit, je sais ce qui manque à une Ferrari pour que je m'en serve pour déménager, même sans en posséder...

De même qu'à un fer à repasser pour voler ou à un panier à salade pour flotter, mais avoue que c'est moins évident en ce qui concerne un logiciel de développement.

Et ce qui peut lui manquer ne réside pas forcément dans ce qu'on en peut tester, mais dans la confiance, le bouche à oreilles, la satisfaction que l'on éprouve avec ses outils et qui n'incite pas à voir ailleurs, etc.

Cet argument me parle plus: J'avais très peu entendu parlé de "Code Typhon", et le nom, à l'instar de "Tortue Ninja", ne fait, à priori, pas très sérieux. Je sais, c'est un peu primaire comme raisonnement, mais avec la quantité d'information que l'on doit traiter, on est un peu obligé d'établir des règles de tri, lesquelles sont toujours plus ou moins arbitraires.

J'ai eu plusieurs violation d'accès (Access violation) en testant des composants, simplement en les déposant ou en les supprimant, entrainant la fermeture de L'EDI, avec perte éventuelle de données. Est-ce dû à une mauvaise finalisation du composant, à une incompatibilité avec mon environnement ou à une certaine instabilité de l'EDI? Ce n'est pas très grave pendant les tests, mais en cours de développement, ça peut être pénalisant.

As-tu noté ce genre de problème?

[tourlourou]

Non, mais j'utilise peu de composants, et surtout des classiques.

[gvasseur58]

Une petite question: quel est le rapport exact entre Lazarus et Code Typhon, à part amical (j'espère)? En dehors de quelques différences cosmétiques dans l'interface, la ressemblance est énorme. Est-ce que le code est le même?

Cordialement, naute.

Bonjour,

Il y a le même rapport entre Lazarus et Code Typhon qu'entre Linux et Ubuntu par exemple : le second est une distribution du premier. On ne peut donc pas s'étonner de leurs ressemblances
Code typhon est une surcouche qui apporte en particulier une très bonne intégration des bibliothèques tierces.

Les rapports entre Lazarus et Code Typhon n'ont pas toujours été au beau fixe : l'équipe de Lazarus reproche (reprochait ?) à celle de Code Typhon de ne pas toujours respecter les licences de ses adaptations. Il semblerait que Code Typhon ait fait des progrès à ce niveau. Les deux équipes restent parallèles et s'auto-alimentent pour le moment

L'équipe de Code Typhon a sa propre politique de déclaration des versions stables de FPC et Lazarus, de licences de certains composants et de mise en service d'une nouvelle distribution : cela peut mener à des déconvenues dès que l'on sort du noyau de composants largement éprouvés. Ainsi, IIRC Code Typhon 2.5 s'appuyait sur une version de Lazarus SVN qui avait deux jours, sans tests
En revanche, pour qui cherche une large palette de composants et souhaite développer sur de multiples plateformes sans se prendre la tête avec des procès d’installation complexes, Code Typhon est très agréable.

[naute]

Bonjour gvasseur,

Bonjour,

Il y a le même rapport entre Lazarus et Code Typhon qu'entre Linux et Ubuntu par exemple : le second est une distribution du premier. On ne peut donc pas s'étonner de leurs ressemblances
Code typhon est une surcouche qui apporte en particulier une très bonne intégration des bibliothèques tierces.

Explication très claire!

Les rapports entre Lazarus et Code Typhon n'ont pas toujours été au beau fixe : l'équipe de Lazarus reproche (reprochait ?) à celle de Code Typhon de ne pas toujours respecter les licences de ses adaptations. Il semblerait que Code Typhon ait fait des progrès à ce niveau. Les deux équipes restent parallèles et s'auto-alimentent pour le moment

Pourvu que ça dure !

L'équipe de Code Typhon a sa propre politique de déclaration des versions stables de FPC et Lazarus, de licences de certains composants et de mise en service d'une nouvelle distribution : cela peut mener à des déconvenues dès que l'on sort du noyau de composants largement éprouvés. Ainsi, IIRC Code Typhon 2.5 s'appuyait sur une version de Lazarus SVN qui avait deux jours, sans tests

Oups!!! Cela explique peut-être en partie les problèmes que je rencontre sur les composants non standards.
J'ai Lazarus 1.4.0 qui tourne avec FPC 2.6.4, versions (très) récentes, alors que mon Code Typhon 5.3 tourne avec FPC 3.1.1 , versions peut-être trop récentes et, donc, non finalisées.

En revanche, pour qui cherche une large palette de composants et souhaite développer sur de multiples plateformes sans se prendre la tête avec des procès d’installation complexes, Code Typhon est très agréable.

C'est dans cette optique là que j'envisageais de passer à Code Typhon, mais si l'utilisation des composants est incertaine, ça me refroidit un peu.

J'ai été confronté à des problème de ce genre avec Jedi, et n'ayant pas les compétences suffisantes pour les régler, j'ai abandonné. Et, comme je l'ai indiqué précédemment, l'absence d'aide, ou, au moins, d'un minimum d'information sur le composant est préjudiciable à l'utilisation de celui-ci.
J'ai lu dernièrement sur un post qu'il suffisait de lire le code source d'un composant pour en comprendre la destination et le mode d’emploi. C'est probablement vrai pour certains, mais pas pour tous, et en tout cas, pas pour moi .

C'est dommage car des développeurs qui passent des heures et des heures à créer des composants qu'ils mettent gracieusement à la disposition de tous ne méritent pas ça . Mais ce qui leur parait évident, heureusement, étant l'auteur de leur composant, ne l'est pas forcément pour tout le monde, et un peu d'aide serait la bienvenue tout en rendant leur travail plus efficace en augmentant le nombre d'utilisateurs potentiels.

Merci beaucoup pour tes réponses détaillées,

amicalement, naute.

[gvasseur58]

Et, comme je l'ai indiqué précédemment, l'absence d'aide, ou, au moins, d'un minimum d'information sur le composant est préjudiciable à l'utilisation de celui-ci.

C'est souvent le cas : quelqu'un développe un outil très intéressant, mais néglige le mode d'emploi et les éventuelles applications auxquelles on ne pense pas tout de suite. Il y a heureusement des bibliothèques comme BGRABitmap qui sont bien documentées, au prix de sérieux efforts de la part de leur(s) développeur(s).

J'ai lu dernièrement sur un post qu'il suffisait de lire le code source d'un composant pour en comprendre la destination et le mode d’emploi. C'est probablement vrai pour certains, mais pas pour tous, et en tout cas, pas pour moi .

Parfois, l'auto-documentation aide : source commenté et/ou identificateurs parlants... Mais je suis comme toi : certaines productions complexes sont
parfaitement illisibles et demandent trop d'efforts pour leur mise en œuvre.

Mais ce qui leur parait évident, heureusement, étant l'auteur de leur composant, ne l'est pas forcément pour tout le monde, et un peu d'aide serait la bienvenue tout en rendant leur travail plus efficace en augmentant le nombre d'utilisateurs potentiels.

J'approuve totalement. Il faut cependant avouer que la mise au point d'une bibliothèque demande tellement d'efforts (tout en procurant des satisfactions indéniables) que la rédaction d'une documentation paraît souvent une tâche secondaire et terne. C'est dommage !

Bonne continuation,

Gilles

[AdmChiMay]

… que la rédaction d'une documentation paraît souvent une tâche secondaire et terne. C'est dommage !

Problème récurrent dans le libre.
Et à cette heure on n'est pas encore vendredi, donc pas de troll du vendeur d'ail.

Mais anecdote.
Il y a "quelques" années, j'ai passé une année scolaire pas très loin de la frontière avec l'Écosse. Et je me suis bien amusé. Pour un tp ou un mini-projet, que le programme fonctionne est l'essentiel pour des étudiants français. Là-bas, c'était 50% de la note. Les autres 50% : la documentation livrée.
Cela change la donne, de la même manière que beaucoup de programmeurs devraient être obligés d'utiliser les logiciels qu'ils ont programmés pendant quelques mois. Mais bon… c'était il y a quelques années, et maintenant les programmeurs peuvent encore plus facilement se retrancher derrière les délais et le manque de spécifications (même (et surtout ?) si le client est un grand compte).

[gelinp]

Bonjour,

Il semblerait que le framework tiopf ne soit pas proposé dans la liste des packages ... Est-ce prévu ? A quelle date ? Sinon peut être un autre composant pour gérer un mapping objet avec une base de donnée relationnelle ?

Patrick