FPC compatibility for BGRABitmap

[circular17]

Here are a list of changes for FPC compatibility (in msegui\lib\common\fpccompatibility)

Insert mclasses after Classes in uses clause of:

• fpreadxwd, fpwritepcx, fpwritetga, fpwritexpm, fpwritepnm, fpreadpcx, fpreadgif, fpreadpsd

I suggest to check as well (even if it may not be necessary for BGRABitmap):

• fpread, fpwrite

Following is a list of unit to add. All of them need to be tweaked with mclasses.

Add zipper unit to fpccompatibility folder. It is found in paszlib package of FPC.

Add some units for XML support. They are found in fcl-xml package of FPC:

• xmlread, xmlreader, xmltextreader, xmlwrite

Add units from package fcl-base:

• base64 , bufstream

[fredvs]

Huh, and what about to re-name msefpreadxwd, msefpwritepcx, msefpwritetga, msefpwritexpm, msefpwritepnm, msefpreadpcx, msefpreadgif, msefpreadpsd ?

I must confess that I really dont like to do hacking, changing source and keeping same name.

And what do you think to use all that files from fpc trunk? This because original files given by Martin are not the latest.

[fredvs]

I suggest to check as well (even if it may not be necessary for BGRABitmap): fpread, fpwrite

Sorry but I dont understand, what do you want to check? You are welcome to do a pull-request, maybe it will be easier to understand.

[fredvs]

fpreadxwd, fpwritepcx, fpwritetga, fpwritexpm, fpwritepnm, fpreadpcx, fpreadgif, fpreadpsd

Is it all the fp* files that you need, no others, (because msegui dont need it) ?

[fredvs]

I know it would be much more work for you, but, imho, it would be perfect if in BGRAbitmap code you could use something like:

uses
{$ifdef msegui} msefpreadxwd {$else} fpreadxwd {$endif}, ...

[circular17]

And what do you think to use all that files from fpc trunk? This because original files given by Martin are not the latest.

Well that's the problem with having tweaked units, which version to use.

I would not recommend trunk version but something like the latest stable version maybe?

I suggest to check as well (even if it may not be necessary for BGRABitmap): fpread, fpwrite

Sorry but I dont understand, what do you want to check? You are welcome to do a pull-request, maybe it will be easier to understand.

Well check that they have mclasses after classes in uses clause. If I understand correctly all files in the compatibility folder need have mclasses, otherwise they won't be compatible.

[circular17]

I know it would be much more work for you, but, imho, it would be perfect if in BGRAbitmap code you could use something like:

uses
{$ifdef msegui} msefpreadxwd {$else} fpreadxwd {$endif}, ...

That would be much work indeed. I suggest we try first adding the necessary files and that they are correctly tweaked.

And then think about the options we have:

• renaming them with prefix mse
• OR remove them and use a class bridge if needed

[fredvs]

I would not recommend trunk version but something like the latest stable version maybe?

OK.

Well check that they have mclasses after classes in uses clause. If I understand correctly all files in the compatibility folder need have mclasses, otherwise they won't be compatible.

OK, and what do you think to only give fp files needed by BGRAbitmap? I dont really see the utility for the others, msegui did not implement the use of fp files.

That would be much work indeed. I suggest we try first adding the necessary files and that they are correctly tweaked.

OK, lets begin with that. (But I prefer to not keep original name in tweak units too much time ;-) )

[fredvs]

OR remove them and use a class bridge if needed

Hum, sorry, this one I need to see code to understand what you see.

[fredvs]

OR remove them and use a class bridge if needed

I do not understand how you will do but if you can do something that allows to remove all the fp* files in /fpccompatibility and keep compatibility with msegui+fpc, I will vote for this.

[fredvs]

I am ready to do the conversion for fpimage.pas ---> msefpimage.pas and adapt msegui code for that. It is the only fp** file used by msegui.

But, of course, if even for fpimage.pas your bridge will work, I prefer your bridge.

[fredvs]

It is the only fp** file used by msegui.

No, fake new, others are used: fpreadxpm, fpwritepng, fpwritetiff and many others. It seems also that Martin did not add only mclasses but for some units did change more in code.

Hum, not sure that the bridge would be easy.

[fredvs]

OK, for the game I did rename all fp** needed by msegui with msefp**. And adapt each msegui unit for this.

Tested and works like charm.

Now a other option is to move all that msefp** files fromfpccompatibility/ into a new directory msefpimage/

The big advantage when keeping the mseimage units is that you are independent of fpc package and can change anything without to wait years.

[fredvs]

And to be logical, it should be done also for all others units that are in fpccompatibility/, like dbf_*. Huh, lot of work.

But I am ok to begin with fpimage.

OK, I stop to monopolize.

[circular17]

I feel like it is a bit of a digression to rename units for now. Though that will give you some visibility of the use of FP units on MSEgui.

MSEgui does not need to be independant from FPC as it is compiled with FPC anyway. If for some reason one file in FPC is not updated soon enough, one can replace it. But anyway it is a form of dependency to have copies of FPC.

What was the real reason to have tweaked FPC files? How different are the classes from mclasses?

FPC works on its own, so I am not sure there is anything to fix there. That's why having bridges may be the best option, if it is possible. The idea is that if you use an FPC function that uses a Classes.TStream, and that you have your own modified version of mclasses.TStream, then you can instantiate a bridge, that can take an mclasses.TStream but provide the interface of Classes.TStream. Then everybody is happy, FPC and MSE.

[circular17]

Renaming units make MSEgui even less compatible with programs that rely on FPC stuff. So that's not something to rush.

[fredvs]

What was the real reason to have tweaked FPC files?

I fear it is more complicated than only adding mclasses in units.

For example infpreadjpeg.pas, Marin did change lot of things.

How different are the classes from mclasses?

Maybe check in classes.pas vs mclasses.pas?

[fredvs]

Renaming units make MSEgui even less compatible with programs that rely on FPC stuff.

Ha, why?

But ok, let that for, I fear, a long discussion. Lets begin with what we have.

Like you said, no rush.

[fredvs]

MSEgui does not need to be independant from FPC as it is compiled with FPC anyway.

No, of course, till now MSEgui can only be compiled by fpc, but I was talking only about the units in \fpccompatibility

[fredvs]

IMHO, I fear that the best solution will be:

Using the 2 solutions together.

1) You bridge that add mclasses so people may use the official fpc fpimage package.

2) And rename all the custom fpccompatibility/fp* units into msefp* units.

So people may choose to use or fpimage or msefpimage. And msegui for his own components will use msefpimage.

But in your application, if you prefer to use fpimage , no problemo, your bridge will do it.

[fredvs]

Insert mclasses after Classes in uses clause of: fpreadxwd, fpwritepcx, fpwritetga, fpwritexpm, fpwritepnm, fpreadpcx, fpreadgif, fpreadpsd

Done in commit 15d9161

I suggest to check as well (even if it may not be necessary for BGRABitmap): fpread, fpwrite

Done in commit 15d9161

Following is a list of unit to add. All of them need to be tweaked with mclasses. Add zipper unit to fpccompatibility folder. It is found in paszlib package of FPC. xmlread, xmlreader, xmltextreader, xmlwrite base64 , bufstream

Done in commit 15d9161

Let's begin with this, maybe Bridge and Rename for later.

;-)

[circular17]

Added an issue for the more general discussion https://github.com/mse-org/mseide-msegui/issues/7

[circular17]

Typo in uses clause of base64.pp: the unit name is not cmclasses but mclasses

[rchastain]

Typo in uses clause of base64.pp: the unit name is not cmclasses but mclasses

Hé Fred ! Tu devrais enlever tes moufles pour travailler.

[fredvs]

Hé Fred ! Tu devrais enlever tes moufles pour travailler.

I'd like so much! (But it’s more prudent to keep them until the beast is gone).

Bien vu!

[fredvs]

Fixed in commit 0a7be51

Thanks to note it.

[circular17]

Bon je pense ce sujet est clos en fait.

[fredvs]

Non, j'aurais du voir ton pull request avant de faire le commit.

[circular17]

Chépa, je pense ça change rien si tu fais un commit inverse avant de fusionner.

[fredvs]

Cela fait des années que j'utilise git et il me terrorise toujours autant quand je dois commiter des choses qui ne sont pas de mon propre repository.

Ceci dit, ceci fait, ton pull-request a marché (et m'a bien effrayé quand il a détruit tous les fichiers de fpccompatibility).

;-)

[circular17]

Désolé je ne voulais pas t'effrayer.

Si ça peut te rassurer tu peux toujours récupérer les anciens fichiers si jamais.

Pourquoi tu as peur de commiter sur un dépôt de quelqu'un d'autre ?

[rchastain]

Cher Fred, moi non plus je ne suis pas très à l'aise avec git. Je pense en tout cas qu'il ne faut aller trop vite (et aussi essayer de ne pas faire trop de modifications en même temps, pour que les changements restent lisibles). Ce qui serait bien, peut-être, ce serait d'avoir deux branches, comme pour BGRABitmap. À l'occasion, il faudrait que Johann nous explique comment on fait. Mais bon, nous l'avons suffisamment sollicité pour le moment. :)

[fredvs]

Cher Roland, je pense que nous pourrions faire comme nous avions fait pour Eschecs, ça a bien fonctionné. Donc, bien prévenir avant un pull-request pour qu'il n'y ait pas de commit entre temps. Et c'est vrai que cela va très vite ces derniers jours mais je pense qu'il ne faut pas traîner à ferrer.

Je pense aussi que les modifications de Johan sont très positives et urgentes.

[fredvs]

Pour tout avouer, j'étais très mal à l'aise avec ces fichiers hackés portant le même nom dans /fpccompatibility et la solution de Johan efface tous ces problèmes.

[fredvs]

Pourquoi tu as peur de commiter sur un dépôt de quelqu'un d'autre ?

Parce que si je fait des c...ies, on va me hurler dessus! Si c'est dans mon dépôt, c'est pas grave, je vais arranger cela tout cool.

[circular17]

Hurler est traumatisant pour les oreilles effectivement. Nous préférons qu'il y ait de la bienveillance dans les échanges en toutes circonstances.

Si tu as un doute sur un commit, tu peux peut-être demander à quelqu'un d'autre qui gère le dépôt son avis. Et ainsi vérifier si l'autre personne ne voit pas d'inconvénient.

En tout cas, là nous étions plusieurs et nous nous sommes assuré que cela fonctionnait. C'est important d'avoir au moins une autre personne pour vérifier.

Si après tout cela, on fait une erreur, dans un dépôt on peut toujours revenir en arrière, on a un historique des modifications. La syntaxe de Git peut être compliquée, mais ce qui est sûr c'est que tout est sauvegardé. On peut donc toujours annuler ce qu'on a fait si jamais.

[circular17]

Ce qui serait bien, peut-être, ce serait d'avoir deux branches, comme pour BGRABitmap. À l'occasion, il faudrait que Johann nous explique comment on fait. Mais bon, nous l'avons suffisamment sollicité pour le moment. :)

Deux branches ?

Donc, bien prévenir avant un pull-request pour qu'il n'y ait pas de commit entre temps.

Oui c'est vrai que c'est préférable, autrement on peut avoir à refaire la requête. En l'occurrence, cela ne me gênait pas trop d'avoir à la refaire, et j'étais sûr qu'il n'y aurait pas de modification sur le fichier mclasses.

[rchastain]

Deux branches ?

Ben, dans le dépôt de BGRABitmap, tu as bien une branche master et une branche dev, non ? C'est-à-dire (si j'ai bien compris), tu essaies les nouveautés dans la branch dev, et quand tu es sûr que c'est bon tu exportes dans la branche master. J'ai bon ? Après, "branche" n'est peut-être pas le mot juste... J'ai traduit sauvagement branch. :)

[circular17]

Ahh ok. Oui, effectivement. Ce sont théoriquement deux branches. Cela dit master est plutôt le tronc quoi. Je vous recommande effectivement cette méthode.

En un sens, ma requête de fusion de circular17-msegui est une branche, certes sur une autre dépôt mais ça revient à cela. Je garde les modifs là quoi qu'il arrive sur master de MSEgui.

Pour Fred qui a accès au dépôt, ce serait plus simple qu'il crée une branche, par exemple mse-fred où il essaye des trucs, et quand il est satisfait, il fait une requête de fusion. Et quelqu'un d'autre peut faire une relecture des modifications.

[circular17]

Bon je vais aller au dodo. Bonne soirée (ou bonne nuit) Roland.

[rchastain]

Bon je vais aller au dodo. Bonne soirée (ou bonne nuit) Roland.

À toi aussi ! Merci beaucoup pour ta précieuse contribution.