Since I have now updated ct2laz to be able to convert latest CT 6.30+ projects and packages, I would like to discuss first what would be the ideal way to go for ct4laz. The general idea would be to use ct4laz from OPM so I write in this thread, but if you feel more like starting a new thread to avoid polution, please say so. Here is the general concept of ct4laz that I would like to discuss:Avra, I move this to a new thread here. This is specific to your ct4laz repository and not about OPM in general. The replies would be buried to the general comments.
8 ) Automating conversion process is so far successful with ct2laz. However there might be a need in the future to apply patches to some components. I see that you do it with some OPM packages. Do you have it automated in some way?This last point raises my alarms a little bit.
Hello GetMem,
if you remember we had initial discussion about central repo for CodeTyphon components which I would like to call ct4laz:
http://forum.lazarus.freepascal.org/index.php/topic,38514.msg261943.html#msg261943
Since I have now updated ct2laz to be able to convert latest CT 6.30+ projects and packages, I would like to discuss first what would be the ideal way to go for ct4laz. The general idea would be to use ct4laz from OPM so I write in this thread, but if you feel more like starting a new thread to avoid polution, please say so. Here is the general concept of ct4laz that I would like to discuss:
1 ) I would use ct2laz to convert all CT packages and CodeOcean examples (excluding ORCA ones, because of the potential licensing problem)
2 ) I would host everything from conversion process on new ct4laz bitbucket git repo, similar as ct2laz is hosted now
3 ) I am thinking about using one repo for everything, using current directory structure of CT packages and CodeOcean examples. However, I am not yet familiar with registering packages to OPM, so I have to ask if this is a good approach? Once repo is established, one by one CT packages would be added to OPM.
4 ) I would like to host everything from the conversion process, although probably only pl_* packages and related CodeOcean examples are interesting for OPM. They should probably be downloaded together in one shot. Would that be a problem for OPM?
5 ) For clear distinction and giving credits to PilotLogic I would like to keep their pl_ prefix for each package originating from CT. OPM can show some other real name to the user, but I would like to keep their "original" package names. The reason for this are users who, for one reason or another (usually bug fixes or cross platform improvements), need to use original pl_* packages even when Lazarus and OPM provide native ones (ct2laz allows this possibility during the conversion process).
6 ) You already have several CT packages in OPM. I think that they should go into ct4laz and have "original" pl_ prefix in their package name, but I clearly would like to know your opinion on this matter. I would give you write access to ct4laz repo if you want, of course.
7 ) Using Synapse in OPM gave me a headache because of 2 versions. Some packages are using stable and some are using trunk. Trouble comes when I need several packages using different Synapse packages. It gets solved after manual fixing everything to use trunk Synapse, but that would be too much for an average OPM user. It also gives trouble when converting CT packages which use pl_synapse, because I have to tell ct2laz to convert all to trunk OPM Synapse package (stable is too old and not compatible). If I tell ct2laz not to convert pl_synapse then I have to install pl_synapse and that again conflicts with any OPM Synapse already installed. You see the problem. Ideally there would be only one Synapse package in OPM and that would be using Synapse trunk. What do you think about this?
8 ) Automating conversion process is so far successful with ct2laz. However there might be a need in the future to apply patches to some components. I see that you do it with some OPM packages. Do you have it automated in some way?
Any idea or improvement to this imaginary concept is most welcome.
1 ) I would use ct2laz to convert all CT packages and CodeOcean examples (excluding ORCA ones, because of the potential licensing problem)That would be great. Thanks. But we should add to OPM only the packages not available anywhere else. In fact this is what I did until now.
2 ) I would host everything from conversion process on new ct4laz bitbucket git repo, similar as ct2laz is hosted nowBitbucket is perfrectly fine or any other version control system for that matter.
3 ) I am thinking about using one repo for everything, using current directory structure of CT packages and CodeOcean examples. However, I am not yet familiar with registering packages to OPM, so I have to ask if this is a good approach? Once repo is established, one by one CT packages would be added to OPM.After the conversion is complete, every package must be added to OPM manually, I will do this myself, luckily the process is automated, it takes no longer then 1 min. in average for each package.
4 ) I would like to host everything from the conversion process, although probably only pl_* packages and related CodeOcean examples are interesting for OPM. They should probably be downloaded together in one shot. Would that be a problem for OPM?No problem at all. The release cycle of CT packages are slow, when new version of a particular package is avaliable, after a quick conversion it can be added again to OPM.
5 ) For clear distinction and giving credits to PilotLogic I would like to keep their pl_ prefix for each package originating from CT. OPM can show some other real name to the user, but I would like to keep their "original" package names. The reason for this are users who, for one reason or another (usually bug fixes or cross platform improvements), need to use original pl_* packages even when Lazarus and OPM provide native ones (ct2laz allows this possibility during the conversion process).I don't mind adding pl_ prefix to packages, hower we should also add the original developers to the "Author" field(lpk file). I did this for every CT package available in OPM + I also added PilotLogic Software House to give cretids for the conversion, maintanance. I spent a lot of time seraching for original authors, although in most cases a hint is available somewhere in a txt file.
6 ) You already have several CT packages in OPM. I think that they should go into ct4laz and have "original" pl_ prefix in their package name, but I clearly would like to know your opinion on this matter. I would give you write access to ct4laz repo if you want, of course.Yes I converted the packages manually, it was really painful and slow. With CT4Laz the whole process should take much less. Again I have nothing against pl_prefix in the package name.
7 ) Using Synapse in OPM gave me a headache because of 2 versions. Some packages are using stable and some are using trunk. Trouble comes when I need several packages using different Synapse packages. It gets solved after manual fixing everything to use trunk Synapse, but that would be too much for an average OPM user. It also gives trouble when converting CT packages which use pl_synapse, because I have to tell ct2laz to convert all to trunk OPM Synapse package (stable is too old and not compatible). If I tell ct2laz not to convert pl_synapse then I have to install pl_synapse and that again conflicts with any OPM Synapse already installed. You see the problem. Ideally there would be only one Synapse package in OPM and that would be using Synapse trunk. What do you think about this?As Juha mentioned above, the main goal of OPM is to provide released packages. However in the case of synapse I think we can make an exception. The release cycle is so slow that almost six years passed since the latest stable version. I'm gonna fix this issue soon.
8 ) Automating conversion process is so far successful with ct2laz. However there might be a need in the future to apply patches to some components. I see that you do it with some OPM packages. Do you have it automated in some way?This is usually done by the "update feature"(http://wiki.freepascal.org/Online_Package_Manager#Update_a_package ). When a package is not maintained or the release cycle is slow I do it myself.
So avra or you will keep up to date all these packages, right?After every major CT release, avra will convert the packages with ct2Laz, I will update them in OPM. The CT release cycle is slow, so it should be no problem. More over not every package is updated with each release.
I say because I think CT people will not do that?This project has nothing to do with CT people. The important thing is to import back the good things from CT or at least this is how I see it.
ct2laz is a great tool to make those CT packages available which don't have a Laz counterpart. But this is a tool for somebody who knows what he is doing. A repository of ready-to-use CT package will cause more trouble than benefits. Instead of this I'd pick those CT-only packages, convert them to Laz and distribute them in OPM. An example is the package "astronomy" which is now in OPM, but originally was a CT-only package.A repository is needed if converted packages need maintenence. Then we are talking about forking instead of only converting. Avra will naturally be the maintainer of that fork. I like the idea, that is how FOSS development works. Copying and modifying code back and forth.
But - this must be clear: All these packages will not be maintained, and I see the future that OPM will end up like CCR: initially lots of enthusiasm, but a few years later, when the excitment has gone, it will just accumulate dead code. What if FPC introduces another code-breaking feature? Or Laz moves functions to other units again? Or code marked as deprecated is finally removed? These things usually are easily fixed, but somebody must do it. Who? Who will take care of the more than hundred packages in OPM when this happens? With CT in there it will be even worse! (well, I am very pessimistic today...)OPM and CCR have a big difference.
Avra, I move this to a new thread here. This is specific to your ct4laz repository and not about OPM in general. The replies would be buried to the general comments.Agreed, thanks!
You don't have to worry. My intention is not forking and maintaining forks. I already use ct2laz to convert CT packages, so I would just put that in a repo to allow general use through OPM for packages that are interesting to others. It would ease access to CT components without using ct2laz. The only 2 packages so far that I see need patching are indy (fix for intentional indy leak, which is already applied in CT version package) and wst (CT version is compilable, unlike author's version although I gave him patches long time ago). I don't know if GetMem will decide to use CT versions, but that would give him maintenance free benefit in this case. I think that in the future CT will move further from Lazarus, and that is the area where I sea automated patching should be applied. I don't find fun to apply same patches all over again by hand, so there is my interest in the topic.Quote from: avra8 ) Automating conversion process is so far successful with ct2laz. However there might be a need in the future to apply patches to some components. I see that you do it with some OPM packages. Do you have it automated in some way?This last point raises my alarms a little bit. The main goal of OPM is to provide released packages. Fixing bugs and applying patches is the duty of package maintainers.
I fear a central repository of all CT packages for usage in Lazarus is a very bad idea and will end up in a terrible mess. I am not talking of these packages which are unique to CT, but of that vast majority which are just copies of Laz packages.I think that GetMem will probably use such repo just for packages not available otherwise, maybe with 1-2 exceptions that will not bring any problems you fear. I myself do not have such problems even after heavy usage. Anyway, I will probably not publish everything in repo simply because currently it would take 1.2GB.
All these packages will not be maintained, and I see the future that OPM will end up like CCR: initially lots of enthusiasm, but a few years later, when the excitment has gone, it will just accumulate dead code.I do not agree. Code will be maintained as much as PilotLogic maintains it. Through all these years PilotLogic managed to do it well. I have nothing to do with it. However if you want a guarantee for the future, there is none - as with many thing in life.
What if FPC introduces another code-breaking feature? Or Laz moves functions to other units again? Or code marked as deprecated is finally removed?This catch-up game exists even without CT involved, so I do not see a problem. There will always be packages that work only with stable version, and some that will work only with trunk. With CT using trunk by default and looking at the history of their updates I think that they adapt much faster then you fear. As for OPM, in worse case it will simply not be able to install package in one of Lazarus versions. Nothing new, and we see it anyway without CT involved at all.
...in the case of synapse I think we can make an exception. The release cycle is so slow that almost six years passed since the latest stable version. I'm gonna fix this issue soon.Thank you very much. I am very happy.
I've seen BGRAControls in CT, they have units that I've removed and replaced with new one (components).Don't worry. OPM will include just CT specific packages.
A repository is needed if converted packages need maintenence. Then we are talking about forking instead of only converting. Avra will naturally be the maintainer of that fork.Well, that will not be a fork in a classic sense. I do not intend to make any significant changes to CT code. I will only make ct4laz because PilotLogic does not provide public repo, and because I want those components to be available to Lazarus users. Maintaining will also not be in a classic sense, since I will just convert CT packages and CodeOcean examples to enable their use in Lazarus. OPM is then a natural choice for their delivery to Lazarus users.
You don't have to worry. My intention is not forking and maintaining forks.Maybe I expressed my meaning poorly. Forking is OK. If you change the code only a little, it is still a fork. My point was that maintaining of the forks must not be done as part of the OPM delivery process. It must be done in a repository somewhere and preferably not by the OPM's maintainer.
... and wst (CT version is compilable, unlike author's version although I gave him patches long time ago).Yes, that should be solved by adding more maintainers for WST. Luckily the sources are in CCR. Everybody who has commit access there can also update WST. Do you have commit access for CCR? You could apply the patches, then we inform Inoussa. He is clearly busy and does not check this forum or even his mailing list often.
The OPM maintenance must be designed to be light.It is light. Everyone can learn in 5 minutes how to add/delete a package. The problem is only I have access to the central repository and this should be changed in the future, so other people can upload packages.
I think we should make committing to CCR more flexible. Maybe it would become more fashionable again. I don't see why somebody should not fix a bug in a component even if he is not the maintainer. Commit rights must be based on some credit of course, they cannot be given to everybody.This is a good idea. CCR worked well in the past, it still works well, but a lot of packages are not maintained.
I fixed the synapse issue.I will check and let you know. Thanks!
If you remember I have notified Inoussa (both by forum and mail) and gave him patches. After a while they were only partially applied and WST could not be compiled in some cases (not checked recently). Patches were not a product of my deeper WST understanding, but a result of comparing original to CT version, which worked well in every Lazarus version I tried. Therefore it is not realistic for me to become a WST maintainer. I prefer to just use CT version of WST (I haven't checked OPM version lately, but I will). Talking about removing maintenance burden from GetMem, it would be more logical to me if CT version will be used for OPM. However, that will be GetMem's decision and for one reason or another he might prefer to continue to maintain his own patched version.Quote... and wst (CT version is compilable, unlike author's version although I gave him patches long time ago).Yes, that should be solved by adding more maintainers for WST. Luckily the sources are in CCR. Everybody who has commit access there can also update WST. Do you have commit access for CCR? You could apply the patches, then we inform Inoussa. He is clearly busy and does not check this forum or even his mailing list often.
If you remember I have notified Inoussa (both by forum and mail) and gave him patches. After a while they were only partially applied and WST could not be compiled in some cases (not checked recently). Patches were not a product of my deeper WST understanding, but a result of comparing original to CT version, which worked well in every Lazarus version I tried. Therefore it is not realistic for me to become a WST maintainer.Ok, "maintainer" was too strong a word. I meant you can apply your changes which make the code compile again.
I don't see any reason why you shoud not apply your valid fixes now.Well, validity is in question here. Patches were only partially applied by the author, and although I asked for the reason - I have never received a reply, so I can only guess that there was something that the author didn't like. Without deeper understanding I can not defend these patches, only PilotLogic could do that (but that is hardly going to happen). I was hoping for the author to fix all compilation issues, but I am still puzzled with only partial fixes appliance without any feedback to reveal the mystery. That is the reason why I am not for changing CCR WST by myself, to avoid more mess. OPM already provides patched WST (I think that GetMem has applied all mentioned CT patches based on my DIFF files, but I use CT version so I would not know that for sure). OPM version is probably fine, and I am only advocating (a little) for CT version that I could host on ct4laz repo to avoid repatching when new version emerges.
Do you have the commit rights for CCR?No, and because of the reasons already described I would not like to patch WST on CCR by my self. Regarding CCR, the first thing I would like to see is to completely delete MultiLog and LuiControls from CCR files, or leave only 1 readme file that would point users to author GIT repos which are maintained, unlike 11 year old files at CCR. That is pretty embarrassing for both components and CCR, and probably the case with some other CCR files. For MultiLog I know personally because I was involved in helping author making it thread safe (file logging), and implementing a TMemoChannel so several threads can write to gui Memo in a thread safe way. I have an impression that nothing of this will ever get into CCR, and even if it did it would be outdated soon, so I see no point to have it in CCR. Especially since they can be found in OPM now.
Checked and works well. Tested with 32-bit 1.8.1+3.0.5 and with latest trunks on Win10. Thank you very much!I fixed the synapse issue.I will check and let you know. Thanks!
CodeOcean\
pl_Abbrevia\
pl_ACS\
pl_AGGPas\
pl_AGGPasVS\
pl_APE\
pl_ASIOVST\
...
typhon\
components\
pl_Abbrevia\
pl_ACS\
pl_AGGPas\
pl_AGGPasVS\
pl_APE\
pl_ASIOVST\
...
For ease of maintenance I would like to keep such directory structure in the ct4laz repo too, so I need to know if that would be a problem for OPM? I see that OPM has some kind of group package that could be used to install both component package and related CodeOcean example dir package at once, but I have to ask before definite directory structure is made in ct4laz.Just a small correction: Orpheus has been added to OPM recently.Thanks for the info 8)
The directory structure from the OPM's point of view is irrelevant.Nice :D
When do you plan to start the conversion process? Once you're done I can do my part in 1-2 days or so.Conversion process is not much time consuming. Testing is. I have a very tight schedule these days so no promises, but I hope pretty soon. ::)
Please mark Orpheus as yellow since it's already in OPM.Done
Speaking of duplicates, pl_barcodes (barcodes package in OPM) is much richer then lazbarcodes (CCR version in OPM), and file comparison reveals the same origin. Compiling both asks for trouble, so I think that only one should stay. Either CT version, or CCR version if someone updates it with CT changes.I once did a few fixes for it, therefore I kind of feel "responsible" for it after its creator has abandoned his child...
As for the new units I'll investigate where they come from and whether their license is suitable.Thanks for looking into this. It is very much appreciated.
The added units belong to TurboPower SysTools. I think it would not be a good idea to mix this with LazBarcodes because LazBarcodes is licensed GPL, and Systools is MPL.Nice catch. Mixing is not good. CT version should probably be avoided in this case. However could you please look into this:
I have a very tight schedule these days so no promises, but I hope pretty soon. ::)I'm also busy lately...no need to hurry.
OPM uses CT Vulkan package. I could not link it to anything from the http://wiki.freepascal.org/Vulkan, so ct2laz will not be able to convert Vulkan projects between Lazarus and CT unless CT version is used in both. It looks like PilotLogic is devoted to 3D (look at pl_Win_DirectX* packages - most are CT unique), so maybe we are on the safe side with CT version here. What do you think? To me CT version looks bigger then anything from the wiki, but someone up to date with the topic should have a word here.It's fine by me. I do not have much experience with CT packages so I leave this issue to you. In the end all I need is a list with orange and red items + the link to the converted packages. :D
@wpOk then. Lazbarcodes has to be replaced with the one from CCR.
I'd vote to use the CCR version within OPM because it's under our control then.
[EDIT]
ok - found them. The added units belong to TurboPower SysTools. I think it would not be a good idea to mix this with LazBarcodes because LazBarcodes is licensed GPL, and Systools is MPL. Maybe it's better to begin a new folder SysTools on CCR (there used to be one according to http://wiki.lazarus.freepascal.org/FpSystools, but it is gone now).
Ok then. Lazbarcodes has to be replaced with the one from CCR.I released the current trunk revision as v1.0.1 (https://sourceforge.net/projects/lazarus-ccr/files/LazBarcodes/lazbarcodes-1.0.1.zip/download); changes are described in my previous post. The update-json is at https://sourceforge.net/projects/lazarus-ccr/files/LazBarcodes/OPM/update_lazbarcodes.json/download
I added TurboPower SysTools as a new project to CCR-trunk; it contains the barcode components (which were copied to pl_BarCodes by CodeTyphon), as well as some math-related units.Thank you so much. :D
I am a bit hesitant because a lot is available already in fcl, lcl etc. I also don't know what to do with the astromony stuff which CodeTyphon has put into the Astronomy package along with other related units from other authors - another mixup. BTW, the author mentioned by OPM is not correct, all the St* unit are by TurboPower.Another nice catch. I would vote for adding the whole SysTools package to OPM (even if some of it's functionality already exists in FCL and LCL). Positive side would be that Delphi projects using it will be converted much easier, and the negative that ct2laz will not be able to automatically convert between such CT and Laz projects. That is a minor issue that could be easily solved manually by the user (it could be automated but I still resist to significantly slow down ct2laz by introducing code parser), and there is not much of such code. I would cover most cases by simple ct2laz conversion mapping of pl_barcodes package to lazbarcodes, and pl_astronomy to SysTools, so only the small CT part would not be mappable directly (SysTools barcodes used in pl_barcodes). Good enough for me. The description of SysTools package could mention astronomy and barcode components, which should be enough for users. Of course, this would all mean that Astronomy package would have to go from OPM. What do you think?
@wpHave you figured out the package contents? What package should I delete from the main repository?
A zip file for OPM will follow when I am sure about the package contents.
I would recommend to delete Astronomy from OPM and to add SysTools and TMoon as separate packages (once they are completed, I will drop a note here, of course)Ok, thanks. I will make the necessary adjustments when you're ready, but it's not urgent at all, so please take you time.
a single unit solarsystems by Zozito Pelegrin. I did not find anything about it yet, it does not seem to belong to a larger library. No words on license.Thank you! This was enough for me to look around. I found it as a mzsystemlib here: https://sourceforge.net/projects/mzsystem/ (very nice solar system OpenGL animated demos, btw).
Does this sound like a good approach to you?Yes. The packages in OPM usually are stable versions(not trunk), although there are a few exceptions like synapse.
Both old and new Cindy are stable, so it' not similar to Synapse. New Cindy requires Lazarus newer then the official one to compile. That's why I think we should stick with old one (until Lazarus 2.0 is released). That way users with both trunk and official Lazarus will be able to compile Cindy.QuoteDoes this sound like a good approach to you?Yes. The packages in OPM usually are stable versions(not trunk), although there are a few exceptions like synapse.
@avraYes, it's a good idea in my opinion. More people use the official version of Lazarus then trunk
Both old and new Cindy are stable, so it' not similar to Synapse. New Cindy requires Lazarus newer then the official one to compile. That's why I think we should stick with old one (until Lazarus 2.0 is released). That way users with both trunk and official Lazarus will be able to compile Cindy.
{...] could you please look into this:The new version 1.0.2 of LazBarCodes on Lazarus-CCR and in the Online-Package-Manager is now under BSD license. Jose Mejuto, the original author of the Lazarus port, agreed on this change.
http://blog.rubypdf.com/2014/07/18/zint-shared-library-change-license-from-gpl-to-bsd/
It looks like zint shared library is now BSD, so maybe LazBarcodes license can be changed also (to be commercial software friendly)? Does LazBarcodes use only zint shared lib or some other part of zint? According to http://wiki.lazarus.freepascal.org/LazBarcodes license is "GPL 3.0 as it is being inherited from the zint source code", so maybe a license switch is possible in this case? Can original author be contacted? Were there any contributors besides yourself?
Too many packages I am working on these days... Uploaded a new spktoolbar zip (v1.0.5) to sourceforge, and updated the update-json.No problem. Thanks for the update, I already see the changes in OPM.
GetMem, now the TurboPower SysTools and TMoon packages are ready for OPMThank you wp. I made the necessary adjustments, everything works well, except for package DelphiMoon the update JSON points to a 2.1.1.0 version, but the lpk is still 2.1.0.0.
everything works well, except for package DelphiMoon the update JSON points to a 2.1.1.0 version, but the lpk is still 2.1.0.0.Ah, the release was already tagged before I made some minor changes - after committing them, I deleted the release and recreated it with the same name. It looks as if the old tags were used. github isn't as easy as many people are saying...
Now there's a version 2.1.2, it should work (hopefully...)Yes, everything is OK now. Thanks. Why you decided to go with github? Sourceforge also worked fine in my opinion. The only annoying thing is, you always have to download the entire CCR, even if you need only a particular package from it. Other then this, it works out of the box in my opinion.
And BTW, I wanted to learn github. Everybody's so anxious about it. But believe me: it's like everywhere - every piece of software has its pros and cons.I agree. I prefer SVN over GIT. I'm not saying SVN is better the GIT...it's just a personal preference.
Point of note: Florian thinks the same, reading the mailing list...
The new version 1.0.2 of LazBarCodes on Lazarus-CCR and in the Online-Package-Manager is now under BSD license. Jose Mejuto, the original author of the Lazarus port, agreed on this change.Thank you for the effort and thank original author for his approval. Now LazBarCodes can be used in closed source software, too. Great!
What is more important is that the OPM license field shows "GPL". I think this is wrong, it should be changed to "LGPL" being the common denominator of both packages.I updated the license info to "LGPL". Thanks.
What is the general opinion about combining different packages into one? Without having checked this explicitly, I suspect that many of the ct packages are like this (I hope this does not open another war against PilotLogic, this is not intended.)From the point of view of one user it might be better to have different packages because he does not need all of the units or because they offer the same stuff (like the moon units in Astronomy), and from the point of view of another user it might be better to have them combined because installation effort is much less.I also vote for separating the packages as much as possible.
Thanks wp. FagComponent is a much more suggestive name then ExGeography in my opinion.Uhm, yes (https://www.urbandictionary.com/define.php?term=Fag) but in a negative way (very expensive typo) :D
Uhm, yes but in a negative way (very expensive typo) :D:D Thanks molly! Edited my previous post. lol
I stumbled across the package ExGeography the name of which and the fact that it is from Pilot Logic reminds me of the "astronomy" issues. Again it is a mixup of two separate sources.You touched something that I was preparing to address. In general, I will avoid such mixed CT packages in ct4laz repo. Who ever needs them will be able to get them with ct2laz tool by hand. I plan to offer in ct4laz only packages where there aren't mixed unknown sources. I do not want to bring any trouble into OPM. I have identified a lot of sources of the CT components (only someone who tried it knows how much of a work that is), and excel file with my findings will follow. Then it will be more clear why some components will be excluded.
CT package: | License: |
pl_aggpas | PUB |
pl_aggpasvs | |
pl_ape | LGPL |
pl_asiovst | GPL/LGPL2/MPL |
pl_cindy | MPL |
pl_geogis | LGPL3 |
pl_graphics32 | MPL/GPL(LnkExc) |
pl_graphics32ext | MPL |
pl_graphics32mg | GPL |
pl_graphics32vpr | MPL |
pl_html5canvas | MIT |
pl_lockbox | GPL/LGPL/MPL |
pl_mapviewer | |
pl_opengl | MPL |
pl_opengles | |
pl_openwire | PUB |
pl_synapsevs | GPL3/LGPL3/MPL |
pl_vulkan | |
pl_win_directx | MPL |
pl_win_directx11 | |
pl_win_directx12 | APACHE2 |
pl_win_directxut | MPL |
pl_win_dspack | MPL |
pl_win_gdi | MPL |
pl_win_midi | MPL |
I have not yet decided what do do with these...pl_exgeographic is the one which I was talking about in reply #54. It consists of FlagComponent which is already distributed by OPM separatey, and PascalTZ which will be added soon. --> you should skip it.
Yes, I remember. I will not include that package for sure. The reason why pl_exgeographic is on that list is that some other units from that package might come into focus later - but to be honest the chance for that is very slim.I have not yet decided what do do with these...pl_exgeographic is the one which I was talking about in reply #54.
Which units? I am pretty sure that FlacComponent and PascalTZ contain all. (There is a "TVplVectorFlagUnit which does not fit into the naming scheme, but this is the same as unit flagcomponent).Yes, I remember. I will not include that package for sure. The reason why pl_exgeographic is on that list is that some other units from that package might come into focus later - but to be honest the chance for that is very slimI have not yet decided what do do with these...pl_exgeographic is the one which I was talking about in reply #54.
Which units? I am pretty sure that FlacComponent and PascalTZ contain all.Well, I was talking from my memory since I remembered that there was something left to check. Now when I look again I see it was just PascalTZ. I checked now and it can be found here (http://wiki.freepascal.org/PascalTZ), so we can mark the whole package as not needed.
GetMem, PascalTZ (the other package which PilotLogic stuffed into the ExGeographic package) is now ready for OPM. Its download location is https://sourceforge.net/projects/lazarus-ccr/files/PascalTZ/PascalTZ-2.1.1.zip/download, the update json is at https://sourceforge.net/projects/lazarus-ccr/files/PascalTZ/OPM/update_pascaltz.json/download).Thank you wp. I added to OPM.
Please be prepared that I did something wrong as usual ;)Somethings wrong with the JSON, because nothing appears in the external column. Please generate the json with OPM(as in the image), then modify "DownloadZipURL" and "Version" if necessary(OPM takes the currently installed version number as default).
I knew something would be wrong. A typo in the package name... This is the new update link: https://sourceforge.net/projects/lazarus-ccr/files/PascalTZ/OPM/update_PascalTZ.json/download.Just updated the link. It works fine now.
This is a preview version of upcoming repo, tested on 32-bit LAZ 1.8.1 + FPC 3.0.5 and running fine on Win10x64. Some testing was also done on Manjaro64 but not as complete and as often as on Windows.Great! Thanks.
I would like you to check if such directory hierarchy is acceptable for OPM or there is something that needs to be changed. There is a \examples\0_libraries directory which will probably be shared by several component packages. I did not yet check which ones need it. Is such shared dir acceptable for OPM? That directory holds libs even for solaris and freebsd. I do not know how many people use those two, so I am in a temptation to delete them. What do you say?Each OPM package has it's own zip file. Ideally the examples, should be in the same folder with the package. OPM extracts all subfolders and files at once. The same is true for libraries. You don't have to change the folder structure if you don't want to, just make sure the dependencies(dll, so, etc...) are specified in the pl_packages_list.xls file. Adding a package to OPM is pretty much automated, the problem is the package description and license info from the lpk file. Unfortunately this has to be done manually. Again a new column in pl_package_list.xls would help, since I'm not familiar with pl_packages. I can manually edit the lpk files.
I was thinking to add pl_chipmunkpas package too, but it's example needs pl_glscene which exists as a Lazarus repo so I do not want to include CT version. At first I wanted to ask you to include gl_scene in OPM, but when I saw that packages and examples from the repo can not compile I made necessary changes and I will contact Lazarus GLScene repo maintainer to include them. Once this is fixed and if you agree to include GLScene into OPM, I will include pl_chipmunkpas. What do you say?Sounds good. After GLScene is fixed and it's not in conflict with other packages I can add pl_chipmunkpas too.
GLScene Lazarus repo: https://sourceforge.net/p/glscene/code/HEAD/tree/branches/GLSceneLCL/
I have also found a clear license violation in pl_exsystem package. It contains TplAppEventsUnit.pas which is almost exact replica of AppEvnts.pas I have in my old D7 (I have just checked and it exists in later versions, too). Probably someone couldn't convert something from Delphi without including it, and PilotLogic just picked it up with the rest without knowing the truth.Can we fix this? Adding the original author? Perhaps contact him/her?
pl_geogis and pl_mapviewer both have a version of TMapViewer. We do not need to include them if someone knows a better version with a repo. Anyone?MapViewer has its own github on https://github.com/maciejkaczkowski/mapviewer; it includes an lpk file. I am not sure if it refers to the original or forked version. In the next days I can have a look at it. GeoGis basically is an earlier version of MapViewer. https://forum.lazarus.freepascal.org/index.php/topic,12674.0.html tells the story how the original MapViewer of GeoGis evolved into MapViewer.
I have also found a clear license violation in pl_exsystem package. It contains TplAppEventsUnit.pas which is almost exact replica of AppEvnts.pas I have in my old D7 (I have just checked and it exists in later versions, too). Probably someone couldn't convert something from Delphi without including it, and PilotLogic just picked it up with the rest without knowing the truth.Delphi's AppEvents contains TApplicationEvents which is the equivalent of Lazarus' TApplicationProperties.
Examples use hard coded relative paths to lib folder, so it would be complex to change this dir structure and keep automation. I will probably keep it, but let's wait and see how many packages actually use lib dir and then decide. Can you use single main dir in OPM for all pl packages with subdirs as in repo zip file to retain such dir structure? If you can then everything should work out of the box.QuoteI would like you to check if such directory hierarchy is acceptable for OPM or there is something that needs to be changed. There is a \examples\0_libraries directory which will probably be shared by several component packages. I did not yet check which ones need it. Is such shared dir acceptable for OPM? That directory holds libs even for solaris and freebsd. I do not know how many people use those two, so I am in a temptation to delete them. What do you say?Each OPM package has it's own zip file. Ideally the examples, should be in the same folder with the package. OPM extracts all subfolders and files at once. The same is true for libraries. You don't have to change the folder structure if you don't want to, just make sure the dependencies(dll, so, etc...) are specified in the pl_packages_list.xls file.
Adding a package to OPM is pretty much automated, the problem is the package description and license info from the lpk file. Unfortunately this has to be done manually. Again a new column in pl_package_list.xls would help, since I'm not familiar with pl_packages. I can manually edit the lpk files.For any package that I could find license info I already put it into excel table. Where I put PUB for license info that means that author has just released it into the open for free without specifying any concrete license. Where there are multiple licenses it means either that whole package has multiple licenses, or that PL has put several components with different licenses into single package. I will see if that can be improved, and add description column.
I have only identified EpikTimer and BOX2D timer in that problematic package, and I can not find any info about other units. I would have told PL about this problem my self, but they locked my forum account when they saw this topic (please anyone do not make a problem out of that since they are a private company and they have the right to do on their own servers what they want - I do not want to start another war). I have just checked and nothing seams to use that unit, but it just does not feel right to me to just delete the unit and include the package since much in it is still not identified. Who really needs that package should use ct2laz and convert it him self. The last thing I want to do is to bring problems to Lazarus.QuoteI have also found a clear license violation in pl_exsystem package. It contains TplAppEventsUnit.pas which is almost exact replica of AppEvnts.pas I have in my old D7 (I have just checked and it exists in later versions, too). Probably someone couldn't convert something from Delphi without including it, and PilotLogic just picked it up with the rest without knowing the truth.Can we fix this? Adding the original author? Perhaps contact him/her?
PS: Adding all the pl packages to OPM should take no longer then 60 minutes.Well, you are much faster then I am. It took me 60 days since this topic was open till a first repo preview. :D
in the meantime install GLScene sources via 'The Dayly SnapShoot' or via SVNI did. Since SF is offline right now I will attach patch for 7112 here. Please take a look.
MapViewer has its own github on https://github.com/maciejkaczkowski/mapviewer; it includes an lpk file. I am not sure if it refers to the original or forked version. In the next days I can have a look at itPlease do. I would be more then happy to delete CT versions from my repo, since only few map sources actually work (probably API change).
According to the mess at least one more person besides me didn't know that. Thanks for sharing.I have also found a clear license violation in pl_exsystem package. It contains TplAppEventsUnit.pas which is almost exact replica of AppEvnts.pas I have in my old D7 (I have just checked and it exists in later versions, too). Probably someone couldn't convert something from Delphi without including it, and PilotLogic just picked it up with the rest without knowing the truth.Delphi's AppEvents contains TApplicationEvents which is the equivalent of Lazarus' TApplicationProperties.
The only little bémol is that some packages (uos, sak) are out-of-date.Thanks for the feedback. I updated the packages.
Please for don't include GLScene Lazarus repo, now. Actually i'm prepare a new big update. The package structure will be a little different.Sure, we can wait. Please take your time.
I'm also planning to do a Zip archive.Thanks.
I can leave the directory structure as it is, OPM can handle it, but there is a small problem with the zip size. Currently is 136 Mb and it will grow in the future.Big zip was just for testing, and I am glad it worked as a test package. I can create many smaller packages, but each will have components and examples dir, and some will have the same 0_libraries dir. That means that each component that needs lib dir will have to download it again. Not nice. Maybe lib dir can be made as a package? What do you think? I did not yet take a look if that would be too much for my current automation status, but if you like the idea I will take a look. Anyway, the general idea would be to have one main dir for all pl packages (call it pl or ct4laz or whatever) and then all components and examples go to that dir. If this idea is fine with you, then would you need that main dir to already exist in each zip on my side, or without it?
I can create many smaller packages, but each will have components and examples dirIn my opinion this would be the ideal solution.
Maybe lib dir can be made as a package? What do you think?Good idea! Although I never did a package for libraries before, in theory it should work. In the package options/search path, I would add all library folders like this:
Anyway, the general idea would be to have one main dir for all pl packages (call it pl or ct4laz or whatever) and then all components and examples go to that dir. If this idea is fine with you, then would you need that main dir to already exist in each zip on my side, or without it?Dir structure:
Dir structure:No, sorry. In order for examples to keep working I have to keep it like this:
ct4laz 0_libraries pl_package1 source ... examples pl_package2 source ... examples ... pl_package(n - 1) pl_package(n)
I do not think this is needed at all. Examples have hard coded relative path to a lib file, and they will find what they need if lib dir exists. So a package should just contain whole lib dir. I still have to see if this lib package idea breaks my current automation status. I hope not.QuoteMaybe lib dir can be made as a package? What do you think?Good idea! Although I never did a package for libraries before, in theory it should work. In the package options/search path, I would add all library folders like this:
0_libraries\$(TargetCPU)-$(TargetOS).
If you need anything else from my side, including access to ct4laz repo, please say so.Ok, thanks. Unfortunately I'm very busy at the moment, we should wait 1-2 more weeks before we add pl_ packages to OPM.
4) Regarding MapViewer component which has 2 incarnations in pl_geogis and in pl_mapviewer packages, do we have a better source of this component to include in OPM, or we have to use CT ones?As I wrote some time ago I want to take care of MapViewer. I have access to the author's original repository which turned into pl_geogis. It is working, but has some issues with tiled painting. I will provide it for OPM for sure (unfortunately I am busy with other thing right now). The other package is derived from this one, but I did not investigate in detail so far. It has a dependence on the RGBGraphics package- not sure if this is really needed, and I don't know if tiled painting is better there.
I fear we'll end up in quite some mess here.No. Don't worry. We agreed in the beginning that only packages which do not interfere with Lazarus goes into OPM. If we cannot make AggPas "Lazarus friendly" we better skip it. Users still can download it from avra's repository.
doesn't fpc come with aggpas already? doesn't it include a package for lazarus too already? why not use the windows font library by default in windows instead of freetype and or other libraries?I fear we'll end up in quite some mess here.No. Don't worry. We agreed in the beginning that only packages which do not interfere with Lazarus goes into OPM. If we cannot make AggPas "Lazarus friendly" we better skip it. Users still can download it from avra's repository.
ct4lazLet's hope everything will work out of the box.
components
pl_package1
pl_package2
...
pl_packageN
examples
0_libraries
pl_example1
pl_example2
...
pl_exampleN
@wpDon't hurry, wait until the new package is ready.
Should I change it now or when you're ready with the adaptation?
Anyway, the reason why I am writing this is a question regarding licensing - and I am really no expert here. All authors state in their unit headers that the units are "under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.". In short: "GPL-2 or later". Correct?
I still have MapViewer on my list, it will be based on the original author's (not PilotLogic's) sources and have some improvements by myself. The current state of the port is on CCR (folder lazmapviewer). You'll be notified when it is ready.What is the status of CCR MapViewer? Is it ready for OPM? I am asking because I am in the process of updating ct4laz with current CT components.
pl_0_libs (new)
pl_ape
pl_asiovst
pl_cindy
pl_dwscript (new)
pl_excompress
pl_excontrols
pl_exdatabase
pl_exdesign
pl_graphics32
pl_graphics32ext
pl_graphics32magic (new)
pl_graphics32mg
pl_graphics32vpr
pl_html5canvas
pl_lockbox
pl_opengl
pl_opengles
pl_openwire
pl_pappe (new)
pl_sdl2 (new)
pl_synapsevs
pl_titansound (new)
pl_vampyreimaging
pl_vulkan
pl_win_directx
pl_win_directx11
pl_win_directx12
pl_win_directxut
pl_win_dspack
pl_win_gdi
pl_win_midi
px_aggpas
px_aggpasvs
px_cmdrunner (new)
px_exgeographic (new)
px_gaiagis (new)
px_geogis (new)
px_mapviewer
px_opengladv (new)
px_shapes (new)
px_titanscript (new)
px_tsmbios (new)
Compile package pl_DWScript 6.7.1: Exit code 1, Errors: 4I didn't know that it was ported (http://wiki.freepascal.org/DelphiWebScript), so better to leave it out of ct4laz.
dwsDataContext.pas(80,19) Error: No matching implementation for interface method "_AddRef:LongInt; CDecl;" found
dwsDataContext.pas(80,19) Error: No matching implementation for interface method "_Release:LongInt; CDecl;" found
dwsDataContext.pas(80,19) Error: No matching implementation for interface method "_AddRef:LongInt; CDecl;" found
dwsDataContext.pas(80,19) Error: No matching implementation for interface method "_Release:LongInt; CDecl;" found
I found not handy behaviour. if i show tooltip, this tooltip hides early.
i cannot read it 50% times. Each 3-4 px mouse moving hides tooltip. Change it to e.g. 15px.
Is this dir change OK for OPM?For OPM is OK, but I don't know if the relative path to the library folder will be the same as in CT.
If you agree, then you could use pl_* components without any change and that could take of some of the burden from you. I also think that cindy in OPM should hold pl_cindy name - to respect it's origin and give credit to Pilot Logic. I hope that's OK with you.Sure, I already used pl_ prefix in the past for CT packages. Cindy was developed by Pilot Logic only? If yes, then giving credit is a must. The issue is, I found many packages, which I thought it was PL only, later it turn out it was developed by somebody else.
Yes this is real issue, people complaining in the mailing list about Linux all the time. A lot of packages don't compile.
All components were tested on 32bit Lazarus 2.0 fixes and both FPC 3.0 and 3.2 fixes running on Win10x64. Linux testing has not been done yet.
Is this related to ct4laz?
Cindy was developed by Pilot Logic only?I doubt that - do they develop any components at all? The "original" Cindy can be found on https://sourceforge.net/projects/tcycomponents/files/. According to the license.txt of these files, the original developer is Júlio MaurÃcio Antunes Piao.
Somehow I did not noticed your post. Can I start to add the packages to OPM?Please don't do that yet. It is only a preview not tested enough. We can call it a V2 release candidate with a call for testers. It is also a discussion of what should end up in OPM and what should be left in ct4laz repo only.
I have managed to keep automation and to change library path from absolute to relative, so it doesn't matter any more. In order for this to work, I had to heavily change ctutils.pp and to introduce library package. It works in all my windows and linux tests of provided examples.QuoteIs this dir change OK for OPM?For OPM is OK, but I don't know if the relative path to the library folder will be the same as in CT.
Cindy was developed by Pilot Logic only? If yes, then giving credit is a must.No, sorry for the confusion. I did not say that Pilot Logic is the author of cindy components. I said that Pilot Logic takes the credit for porting cindy to Lazarus (which was at the time when CT components could be used in laz without any change), so we should respect that and leave pl_cindy name, as is the case with the rest of ct4laz components. I just feel that should be right, nothing else. It is just a proposal, not some kind of a request.
Well, when package uses a Windows unit that is to be expected, right? I don't see that as a problem. What about Mac, FreeBSD or even Solaris users? What should they say? Pilot Logic has improved things a bit by giving most of such packages a intuitive pl_win* prefix, but unfortunately not all packages follow that pattern. What we can do is to populate package info about supported platforms.QuoteAll components were tested on 32bit Lazarus 2.0 fixes and both FPC 3.0 and 3.2 fixes running on Win10x64. Linux testing has not been done yet.Yes this is real issue, people complaining in the mailing list about Linux all the time. A lot of packages don't compile.
I felt it was the case. Maybe Juha should change topic name to just ct4laz to avoid further confusion?QuoteIs this related to ct4laz?No it's related to OPM, a GTK2 specific bug.
Please don't do that yet. It is only a preview not tested enough. We can call it a V2 release candidate with a call for testers. It is also a discussion of what should end up in OPM and what should be left in ct4laz repo only.OK.
I have managed to keep automation and to change library path from absolute to relative, so it doesn't matter any more. In order for this to work, I had to heavily change ctutils.pp and to introduce library package. It works in all my windows and linux tests of provided examples.Great! Thanks. I was a little bit worried about the library folder.
I said that Pilot Logic takes the credit for porting cindy to Lazarus (which was at the time when CT components could be used in laz without any change), so we should respect that and leave pl_cindy name, as is the case with the rest of ct4laz components. I just feel that should be right, nothing else. It is just a proposal, not some kind of a request.In my opinion we can leave pl_cindy, but we should also mention the original author in the description.
Well, when package uses a Windows unit that is to be expected, right?Yes. Especially if in the "supported widgetsets"(OPM tree) is mentioned that win32/win64 is the only supported ws. Even so, users tend to overlook this information and complain about package x not building on platform y. This is not related to CT packages, but to all packages in general.
What we can do is to populate package info about supported platforms.Perhaps we should add the information about supported widgetsets to the hint form(see attached image)? I don't know though if the hint form is used, I did not get any feedback on this one.
Speaking of LPK files, what should we do about them? If I remember you had entered lot of info into them to make package info more relevant and accurate. Should I use your LPK files? It would not be a problem since I have already automated overwriting Pilot Logic original files. LPK files are no exception so that would not bring any extra repeatable work.I did try to locate/mention the original author(s) of a particular package. I also gave credit to Pilot Logic for porting to Lazarus. We can keep those informations, however if in the meantime a new requirement was added by P.L. to a package(this is just an example), how can we sychronize the two information? The automated process also works in this case?
Then name will be pl_cindy, and we mention original author/website with a credit to Pilot Logic for Lazarus port.QuoteI said that Pilot Logic takes the credit for porting cindy to Lazarus (which was at the time when CT components could be used in laz without any change), so we should respect that and leave pl_cindy name, as is the case with the rest of ct4laz components. I just feel that should be right, nothing else. It is just a proposal, not some kind of a request.In my opinion we can leave pl_cindy, but we should also mention the original author in the description.
To be honest I am not a big fun of OPM's hinted info. It's too big and too many times it was on my way when I didn't want it. I would prefer clicking somewhere, but that is not such a big deal and I can live with that. Anyway, here is the complete list of pl_* packages supported platforms and widgets:QuoteWhat we can do is to populate package info about supported platforms.Perhaps we should add the information about supported widgetsets to the hint form(see attached image)? I don't know though if the hint form is used, I did not get any feedback on this one.
No, I do not parse my changed XML file to copy content to PL original one based on some rule. I simply keep a list of my files that will replace PL ones. However there are not that many packages so it is not a problem to do it by hand. That only needs to be done once per ct4laz version. So, is all info you entered contained in your LPK files? If yes, then I can start the mentioned transformations.QuoteSpeaking of LPK files, what should we do about them? If I remember you had entered lot of info into them to make package info more relevant and accurate. Should I use your LPK files? It would not be a problem since I have already automated overwriting Pilot Logic original files. LPK files are no exception so that would not bring any extra repeatable work.I did try to locate/mention the original author(s) of a particular package. I also gave credit to Pilot Logic for porting to Lazarus. We can keep those informations, however if in the meantime a new requirement was added by P.L. to a package(this is just an example), how can we sychronize the two information? The automated process also works in this case?
To be honest I am not a big fun of OPM's hinted info. It's too big and too many times it was on my way when I didn't want it. I would prefer clicking somewhere, but that is not such a big deal and I can live with that.Thanks for the feedback. Luckily the hint window can be disabled in option, so it won't bother you if you don't like it. The supported widgetset is also available in the tree, but is at least two clicks away.
No, I do not parse my changed XML file to copy content to PL original one based on some rule. I simply keep a list of my files that will replace PL ones. However there are not that many packages so it is not a problem to do it by hand. That only needs to be done once per ct4laz version.OK. AFAIK the release cycle of CT is slow. So indeed is not a problem.
So, is all info you entered contained in your LPK files?Yes.
If yes, then I can start the mentioned transformations.Please do.
Anyway, here is the complete list of pl_* packages supported platforms and widgets:Thanks.
https://www.pilotlogic.com/sitejoom/index.php/wiki/85-wiki/ct-packages/198-packages-installation-matrix
Luckily the hint window can be disabled in option, so it won't bother you if you don't like it.I need info more then I dislike the hinted behavior, so I will leave it as it is. It's not that much of a deal.
The supported widgetset is also available in the tree, but is at least two clicks away.If I am a regular user, and I see some yellow exclamation mark next to some of the packages, and if on mouse over I see a hint which says that such package is not tested (or not working) under user's Lazarus/OS/Widgetset combo, then it would be very clear what to expect. That would be ideal, but current situation is also fine. Both ways would need accurate data to be of much use, and that is not as easy to achieve.
pl_0_libs (new)
pl_ape
pl_asiovst
pl_cindy
pl_dwscript (new)
pl_excompress
pl_excontrols
pl_exdatabase
pl_exdesign
pl_graphics32
pl_graphics32ext
pl_graphics32magic (new)
pl_graphics32mg
pl_graphics32vpr
pl_html5canvas
pl_lockbox
pl_opengl
pl_opengles
pl_openwire
pl_pappe (new)
pl_sdl2 (new)
pl_synapsevs
pl_vampyreimaging
pl_vulkan
pl_win_directx
pl_win_directx11
pl_win_directx12
pl_win_directxut
pl_win_dspack
pl_win_gdi
pl_win_midi
px_aggpas
px_aggpasvs
px_cmdrunner (new)
px_gaiagis (new)
px_geogis (new)
px_mapviewer
px_opengladv (new)
px_shapes (new)
px_titanscript (new)
px_titansound (new)
px_tsmbios (new)
All packages converted by @Avra was added to OPM, except pl_cindy and pl_vampyreimaging. The plan is to add the original versions, unfortunately vampyreimaging still not works properly, there is a multiple units conflict(https://sourceforge.net/p/imaginglib). The original Cindy is already in OPM. Any suggestion is welcomed.I will rename pl_vampyreimaging to px_vampyreimaging and leave it in ct4laz repo in case someone still needs it, but exclude it from OPM.
QuoteIf you agree, then you could use pl_* components without any change and that could take of some of the burden from you. I also think that cindy in OPM should hold pl_cindy name - to respect it's origin and give credit to Pilot Logic. I hope that's OK with you.Sure, I already used pl_ prefix in the past for CT packages. Cindy was developed by Pilot Logic only? If yes, then giving credit is a must. The issue is, I found many packages, which I thought it was PL only, later it turn out it was developed by somebody else.
Then name will be pl_cindy, and we mention original author/website with a credit to Pilot Logic for Lazarus port.QuoteI said that Pilot Logic takes the credit for porting cindy to Lazarus (which was at the time when CT components could be used in laz without any change), so we should respect that and leave pl_cindy name, as is the case with the rest of ct4laz components. I just feel that should be right, nothing else. It is just a proposal, not some kind of a request.In my opinion we can leave pl_cindy, but we should also mention the original author in the description.
I still think that OPM cindy should be replaced with pl_cindy, especially since it is updated to latest Delphi version.OK. Fair enough. If there is no objections, I will remove cindy and add pl_cindy from ct4laz repo.
avra, I just noticed that the Pilot Logic package pl_ExControls (taken from OPM) does not compile any more in Laz trunk. This is caused by the removal of the ReadOnly property of TCustomCombobox.If you have fixed the forms then you can send them to me and I will test. If you use trunk then ct2laz is better then ct4laz for some packages. TCustomCombobox problem is probably already fixed in CT (can be checked with ct2laz). I lag behind CT with some packages because CT is much closer to trunk then Lazarus and I am playing a catch up game because I want ct4laz components to be compatible with official Lazarus, so when there is a problem that I can not easily fix I provide older package (not that good if you are after trunk). I plan to update ct4laz at the end of the summer, and focus will be on full FPC 3.2 compatibility while keeping FPC 3.0x working.
I have just checked and it seams that OPM does not deliver my original pl_0_libs and *.dll, *.so and *.dylib files are missing. OPM version has 1MB and my version (https://bitbucket.org/avra/ct4laz/downloads/) has 23MB. How could this happen? Could you please check? When those files are missing, pl_* packages install fine, but lots of examples simply do not work.OPM auto-delete binary files, unless explicitly instructed not to. Apparently I forgot this small detail when I created package pl_0_lib. Sorry for that. Should be fixed now.
p.s. I will start work on ct4laz V3 soon.OK. Thanks.
Thanks! Now all pl_* examples should work.QuoteI have just checked and it seams that OPM does not deliver my original pl_0_libs and *.dll, *.so and *.dylib files are missing. OPM version has 1MB and my version (https://bitbucket.org/avra/ct4laz/downloads/) has 23MB. How could this happen? Could you please check? When those files are missing, pl_* packages install fine, but lots of examples simply do not work.OPM auto-delete binary files, unless explicitly instructed not to. Apparently I forgot this small detail when I created package pl_0_lib. Sorry for that. Should be fixed now.
pl_0_libs
pl_ape
pl_asiovst
pl_cindy
pl_excompress
pl_excontrols
pl_exdatabase
pl_graphics32
pl_graphics32ext
pl_graphics32magic
pl_graphics32mg
pl_graphics32vpr
pl_html5canvas
pl_lockbox
pl_opengl
pl_opengles
pl_pappe
pl_sdl2
pl_synapsevs
pl_usb (NEW)
pl_vampyreimaging
pl_vulkan
pl_win_api (NEW)
pl_win_directx
pl_win_directx11
pl_win_directx12
pl_win_directxut
pl_win_dspack
pl_win_gdi
pl_win_media (NEW)
pl_win_midi
px_aggpas
px_aggpasvs
px_cmdrunner
px_dwscript (MOVED from pl to px)
px_expatpas (NEW)
px_gaiagis
px_macosmetal (NEW)
px_magicscript (NEW)
px_mapviewer
px_opencl (NEW)
px_opengladv
px_openwire (MOVED from pl to px)
px_shapes
px_titanscript
px_titansound
px_tsmbios
avra, I ask for removal of px_mapviewer because we have LazMapViewer, in OPM already. I compared them, px_mapViewer is the same as our LazMapViewer. After the original authors have left the community I am maintaining this package, and PilotLogic just copies our version to their repository and does the usual renamings which lead so strange confusion: looking at mvmapviewer.pas I see that I am a user of the "Typhon forum https://forum.lazarus.freepascal.org".
The Excel file says "TMapViewer enhanced: OPM version doesn't work with trunk any more (CT version does) https://sourceforge.net/p/roadbook/code/ci/master/tree/mapviewer/, 2019: trunk does not work any more (deprecated after LazMapViewer was added to OPM)"Yes. There were issues in 2019 with pl_mapviewer and trunk. Once you published LazMapViewer, pl_mapviewer became deprecated and I renamed it to px_mapviewer and removed it from OPM (but left it in ct4laz).
Is this still up-to-date? Which "trunk": Laz-trunk or FPC-trunk? And what is "deprecated"?
Maybe this is a left-over from the time before LazMapViewer was available in OPM.
Therefore there is no benefit in duplicating LazMapViewer in ctlaz any more.Ok, then I will remove it also from ct4laz.
Yes, if I download pl_excontrols.zip separately, the resource file is there. If I try to download the whole repository, the resource files are not included(see attachment).
It must have been my .gitignore settings being too restrictive.It also remove some library files from pl_0_lib. :)
Yes, I've seen that and prepared new gitignore but have not been able to test it yet.QuoteIt must have been my .gitignore settings being too restrictive.It also remove some library files from pl_0_lib. :)
Anyways I updated the packages. Everything works out of the box. The only package that failed to install on my system(Lazarus Trunk/FPC 3.2.0) is pl_Win_Media, with the following message:It works on Lazarus 2.0.11. Strange is that pl_Win_Media is unchanged CT package, and CT uses trunks so it should work. At the moment I do not see why it fails since everything in line 287 resides in that same unit so it should compile. I have found in DirectShow9.pas this:
"Media.AMVideo.pas(287,53) Error: Identifier not found "SIZE_PREHEADER""
It works on Lazarus 2.0.11. Strange is that pl_Win_Media is unchanged CT package, and CT uses trunks so it should work. At the moment I do not see why it fails since everything in line 287 resides in that same unit so it should compile. I have found in DirectShow9.pas this:Issue fixed! I updated the package in OPM. Thanks.Could you please test if compilation and demos work if you replace line 287 with this? If it does then I could ifdef it for Laz trunk and fix it that way.
SIZE_PREHEADER = 48; // offset TVideoInfoHeader.bmiHeader
Issue fixed! I updated the package in OPM. Thanks.Nice. Thank you! 8)
Strange. I wanted to make a proper ifdef so I have just checked both FPC 3.2.1 + LazTrunk and FPC 3.2.0 + LazTrunk and there was no SIZE_PREHEADER problem during compilation. LazTrunk is from today (SVN64137).After a few updates it works here too. I restored pl_Win_Media from your repo. Sorry for the noise.
Tested on Win10x64 with 32bit Lazarus, using latest fpcupdeluxe.
QuoteStrange. I wanted to make a proper ifdef so I have just checked both FPC 3.2.1 + LazTrunk and FPC 3.2.0 + LazTrunk and there was no SIZE_PREHEADER problem during compilation. LazTrunk is from today (SVN64137).After a few updates it works here too. I restored pl_Win_Media from your repo. Sorry for the noise.
Tested on Win10x64 with 32bit Lazarus, using latest fpcupdeluxe.
You should remove titansound.Thank you for reporting!
Maybe add a clause that it cannot be used by any product called Code Typhoon ? :DI know you were kidding but, I really wonder if an author could GPL his/her code and add a special provision stating that the code cannot be used/included in CodeTyphoon or any other PilotLogic product under any circumstances (or for that matter any other product/company the author is not pleased with.)
Great work, Avra!Thanks! :)
Perhaps TitanSound could be "fixed" if we, the members of this forum, find out where did they get the source files and write down all the authors and licenses.That's what I tried here: https://bitbucket.org/avra/ct4laz/downloads/pl_packages_list.xls
Might be safer (but not easier) to go back to https://sourceforge.net/projects/delphimpeg/ and convert it to Lazarus.That will be done by someone who needs it.
Maybe add a clause that it cannot be used by any product called Code Typhoon ? :DKidding put aside, I would not go that far (but who knows what might original author decide to do). Anyway, PilotLogic does not respect original license so I do not think that adding something to the license would change anything.
Might be safer (but not easier) to go back to https://sourceforge.net/projects/delphimpeg/ and convert it to Lazarus. Its clearly gpl2 or later. And should remain as such.
Delphi MPEG is just one file in TitanSound. There are other files there, most likely from other projects.As said in mentioned Excel file, examples are taken from http://www.noeska.com/doal/tutorials.aspx
@avra, can you check if possible to get these bgracontrols and don't "fight" with the installation of our bgracontrols?I used ct2laz to download and convert latest CT packages and demos, made few corrections, and prepared pl_bgra* packages for download:
Thankyou avra.You're most welcome ;)