ct4laz

[avra]

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.

[wp]

No, the memory leak must be fixed, but I cannot focus on this component at the moment. Patches are welcome.

[avra]

Ok, then CT MapViewer components will be excluded from OPM, but I will still provide them in ct4laz repo in case someone needs them.

[avra]

It's upgrade time. Let me present you preview of ct4laz V2. You can find it here: https://bitbucket.org/avra/ct4laz/downloads/.

This is the list of ct4laz V2 packages taken from CodeTyphon 6.70:

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)

All pl_* packages should end up in both OPM and ct4laz repo, while px_* packages should end up only in ct4laz repo and are ment only for the brave ones or desperate ones (you can find explanations for this in Excel file). If you think that some of the pl_* packages for some reason should not end up in OPM, now is the time to say it. Nothing is carved in stone, yet.

Updated spreadsheet with all packages and their licenses, as always can be found at https://bitbucket.org/avra/ct4laz/downloads/pl_packages_list.xls. It can bring light to why some packages have been left out completely, and some (px_* ones) ended up only in repo.

This time I have made all libraries as a package (pl_0_libs). All demos using them have this package in project requirements, so it should ease things a lot. PilotLogic has done a nice job here, and these are the covered platforms: arm-linux, i386-darwin, i386-freebsd, i386-linux, i386-solaris, i386-win32, x86_64-darwin, x86_64-freebsd, x86_64-linux, x86_64-solaris and x86_64-win64. Therefore the pl_0_libs package weights 23MB.

Because of this new pl_0_libs library package I had to change directory structure a little. All components (even px_* ones) are in pl_components dir, and all demos are in pl_examples dir.

@GetMem:
Is this dir change OK for OPM? If I remember well, you said that lot of time was spent to populate proper info in pl_* components. If you were talking about LPK files, then maybe I should copy your LPKs into ct4laz? I have already automated that part in ct4laz (to copy some file over original one), so it should not be much work. 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.

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.

As usual, automating conversion was the easier part, mostly finding what's needed to add to ct2laz CSV file (which I have updated in ct2laz repo) and rerunning ct2laz again and again. The harder part was to make ct4laz compatible with FPC 3.0.x from official Lazarus.

When I catch time, I will put instructions and scripts for anyone who wants to do this from scratch in ct4laz repo.

[avra]

I did some testing on 64bit Lazarus 2.0 fixes and FPC 3.2 fixes in fresh Manjaro VM and these components have issues:

pl_dwscript - compilation error:

Compile package pl_DWScript 6.7.1: Exit code 1, Errors: 4
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 didn't know that it was ported (http://wiki.freepascal.org/DelphiWebScript), so better to leave it out of ct4laz.

pl_sdl2 - only lib load demo works, others show SIGFPE or RunError(200).

pl_titanscript SIGSEGV runtime error - looks like pointer issue.

pl_tsmbios root access is needed for bios demos to work.

pl_vulkan I was not able to test it because of error "Unable to create Vulkan instance". Probably some missing lib issue. It would be good if anyone can help with it.

More testing is needed. Any help would be most appreciated.

[AlexTP]

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.

EDIT
don't hide it if i move mouse inside the same listbox line.

[avra]

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 related to ct4laz?

[balazsszekely]

@avra
Somehow I did not noticed your post. Can I start to add the packages to OPM?

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. 

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.

Yes this is real issue, people complaining in the mailing list about Linux all the time. A lot of packages don't compile.

Is this related to ct4laz?

No it's related to OPM, a GTK2 specific bug.

[AlexTP]

Wrong topic; it was about OPM tooltip in the listbox.

EDIT
It's gtk2.

[wp]

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.

[avra]

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.
 

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.

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.

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.

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.

Yes this is real issue, people complaining in the mailing list about Linux all the time. A lot of packages don't compile.

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.

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.

Is this related to ct4laz?

No it's related to OPM, a GTK2 specific bug.

I felt it was the case. Maybe Juha should change topic name to just ct4laz to avoid further confusion?

[balazsszekely]

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?

[avra]

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.

Then name will be pl_cindy, and we mention original author/website with a credit to Pilot Logic for Lazarus port.

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.

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:
https://www.pilotlogic.com/sitejoom/index.php/wiki/85-wiki/ct-packages/198-packages-installation-matrix

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?

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.

[balazsszekely]

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:
https://www.pilotlogic.com/sitejoom/index.php/wiki/85-wiki/ct-packages/198-packages-installation-matrix

Thanks.

[avra]

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.