Forum > CustomDrawn

Code cleanup at nested procedure SendPaintMessage

<< < (2/2)

lagprogramming:
I understand wp's concerns. None of my patches add confusion to a potential new CustomDrawn maintainer because it was a factor that I've taken care from the very beginning. You won't see functions or procedures renamed, the Windows and QT code that has been copied and not implemented is still there and so on. So, there is no problem in applying that patch.
Regarding a potential new maintainer for CustomDrawn, it's known that the code contains lots of useless text lines, both code and comments. The very first thing a potential new maintainer will do is to clean up that code and that will take a while. The second thing will be to remove the obsolete code for FPC compatibility. Example, CustomDrawn has bugs related to clipping. In order to fix these bugs lcl/lazcanvas.pas needs to be modified too. LazCanvas uses property ClipRegion: TFPCustomRegion for compatibility with FPC 2.6 and DOESN'T use the GetClipRect routine for newer FPC versions. Regarding the FPC version, lcl/lclversion.pas writes that at least 2.4.2 is required, except for wince which supports fpc 2.2.0+ too. I have doubts a new maintainer will write code to fix the clipping bug taking care of FPC compatibility too(I mean writing code that uses the ClipRegion property). And as you can see, lcl/lazcanvas.pas is not in the customdrawn subdirectory, which means it can't be treated as an pre-alpha code. https://forum.lazarus.freepascal.org/index.php/topic,63222.0.html
Those who wait for a new CustomDrawn maintainer should know that it's easier and faster to port an application to msegui or fpgui than to fix the necessary bugs in CustomDrawn.
On the other hand, again I agree with wp that the patches that try to clean up the code won't significantly improve CustomDrawn status. The entire approach has poor results, but not because of me or because of the status of existing CustomDrawn files. Situations like this one were known to appear many years ago when it was proposed to test and use modifications of Fpc and Lazarus, modifications that were not delivered as ordinary diff files. Instead of the common patch/diff applications, a closed source application would have been used. The fact that the application that modifed the files was closed source was considered unacceptable, the benefits being ignored. Now the community uses forks, which at that time was considered something very bad. Also, even linux kernel allows closed source 3rd party addons(drivers). So, even if independent FPC/Lazarus developers would try to make source modifications available to the ordinary Fpc/Lazarus users, those modifications are not easily accessible.
My proposal is to apply the patch as it is, no harm will be done, and I'll try to see if after all these years the community got open to also use closed source software. Adding a new CustomDrawn package in OPM might be another idea.

wp:
Long read, but sorry, I don't understand what you are talking about. What is the issue with GetClipRect? And what does CustomDrawn have to do with close source software?

The real problem is that CustomDrawn at the moment does not have a maintainer, and there's nobody among the currently active developers who knows about the exact status of the project and who understands the details. My impression is that the project is at a very preliminary stage. Any cosmetic change such as removal of unused variables or empty procedures is an unnecessary complication for a future maintainer because it removes information left by its previous maintainer, be it intentional or not. Better be safe than sorry.

lagprogramming:

--- Quote from: wp on May 01, 2023, 11:11:29 am ---Long read, but sorry, I don't understand what you are talking about. What is the issue with GetClipRect? And what does CustomDrawn have to do with close source software?

The real problem is that CustomDrawn at the moment does not have a maintainer, and there's nobody among the currently active developers who knows about the exact status of the project and who understands the details. My impression is that the project is at a very preliminary stage. Any cosmetic change such as removal of unused variables or empty procedures is an unnecessary complication for a future maintainer because it removes information left by its previous maintainer, be it intentional or not. Better be safe than sorry.

--- End quote ---

Should the development of CustomDrawn be stopped because it has no active maintainer!?
Why nobody wants to be the active maintainer, especially considering that it has much more potential than any other WS!?
In order to fix CustomDrawn clipping bugs for example, the file lcl/lazcanvas.pas needs to be fixed too. TLazCanvas Savestate and RestoreState save only the clipping value. ResetCanvasState doesn't work either for obvious reasons when looking at the code. This means that an independent developer can't release his modifications to CustomDrawn as a package in OPM. What else is available!? A diff window in Lazarus and the possibility of forking the entire Lazarus project. I have doubts there is a significant interest in such solutions.
It is expected that CustomDrawn will remain in the same pre-alpha status, at least for a while.

wp:
You are misunderstanding me... I am only against cosmetic changes at this stage. No problem with justified, "real" bugs. Send a patch for the TLazCanvas.SaveState/RestoreState along with a good description why this is a bug, and with a small project to verify it, I'll have a look if I feel competent - well maybe you already did, but I am tired of seeking the forum when we have a bugtracker and you refuse to use it.

Fred vS:

--- Quote from: lagprogramming on May 01, 2023, 07:50:28 am ---...
Those who wait for a new CustomDrawn maintainer should know that it's easier and faster to port an application to msegui or fpgui than to fix the necessary bugs in CustomDrawn.
...

--- End quote ---

Hello.

What is the status of CustomDrawn for Mac OSX (I dont have a Mac to test it) ?
If, by chance, CustomDrawn can produce working applications on last Mac OSX, fpGUI and MSEgui would be very interested to use the CustomDrawn-Mac code to make fpGUI and MSEgui last OSX compatible.

 ;)

Fre;D

Navigation

[0] Message Index

[*] Previous page

Go to full version