Lazarus
Installation => General => Topic started by: eny on August 17, 2009, 07:44:37 pm
-
Because of this bug (http://bugs.freepascal.org/view.php?id=14371) I downloaded the latest SVN version and tried reproducing it.
Reproducting and confirming the bug worked.
But to my horror I discovered that a package wouldn't compile anymore. What happened?
PWindowInfo (in Win32proc.pp) was renamed to PWin32WindowInfo.
WT* >:( (one-Mississippi, two-Mississippi.....)
Making these kind of dramatic changes in between versions creates a maintenance nightmare (hell, there hasn't even been a minor version number change: 0.9.27 from June 2009 doesn't have this 'feature').
Design 'decisions' like this are a great way to get rid of all these pesky Lazarus users.
PEBKAC (http://en.wikipedia.org/wiki/PEBKAC)! Who need's users anyway...
In the end it it appeared to be 2 changes (i.e. procedure call renames) that I managed to make myself in the lclextensions package.
Nevertheless, one get's very nervous when things suddenly stop working.
This doesn't help the Lazarus adoptation process...
-
I havent' to much of an answer. But I checked the SVN log entry
12/07/2009 05:27:59
win32: rename TWindowInfo -> TWin32WindowInfo, GetWindowInfo -> GetWin32WindowInfo, etc because of conflict with winapi functions and structures
So there was some reason...
as for "there hasn't even been a minor version number change: 0.9.27 from June 2009 doesn't have this 'feature"
0.9.27 is not a released version, the last released version was 0.9.26.2, the next one will be 0.9.28
So the change you mention will be between those 2 versions, and hence there will at least be a change in the version number (even so I do understand this is the lesser of the issues you have with this whole thing)
0.9.27 is a kind of place holder version for the development version. every day several changes are committed, overall between to releases there will be several 1000 commits. it is not possible to give each of them a new version
-
I understand where the change is coming from.
But Lazarus has somewhat of a critical mass I would say.
So breaking backwards compatibility like this will make people, well, nervous.
Especially because 0.9.27-xxxxx is miles ahead of 0.9.26.
The silver lining is that the latest version has a fix for the open directory dialog :D
-
TWindowInfo was and TWin32WindowInfo is some internal widgetset structure which shouldn't be used in lcl/user applications.
Using internal structures in your own code is at your own risk. They may change without any notice or backward compatible solution.
-
I never use 'internal' procedures.
But there were used in the lclextensions package that are a prerequisite for VirtualStringTree. And that I do use.
In fact, the availability of this component is one of the main reasons to use Lazarus.
-
maybe the lcl extentions should be integrated into the lcl
-
maybe the lcl extentions should be integrated into the lcl
I vote for this.
lcl extensions is a "must have" when porting from Delphi to LCL.
-
maybe the lcl extentions should be integrated into the lcl
About two weeks before I tried to use the new VirtualTrees package on Windows CE, which depends on LCLExtensions (and MULTILOG). If I remember rightly I even can't compile a simple test project because of missing identifiers used in the LCLExtensions package. And yes, I used the latest svn snapshots.
Greetings,
Björn
-
Made a bugreport for this so I won't forget
http://bugs.freepascal.org/view.php?id=14792
-
About two weeks before I tried to use the new VirtualTrees package on Windows CE, which depends on LCLExtensions (and MULTILOG). If I remember rightly I even can't compile a simple test project because of missing identifiers used in the LCLExtensions package. And yes, I used the latest svn snapshots.
Greetings,
Björn
Which widgetset/OS ? I'm using it with qt on windows,linux and mac and it works ok.
-
Which widgetset/OS ? I'm using it with qt on windows,linux and mac and it works ok.
Take a closer look at my post ;).
Greetings,
Björn
-
Yes ... see CE now :)
-
Finally I took some time to look at the package and decided not to add it for the following reasons:
function CreateBitmapMask:
First, creating a mask is already part of TRasterImage.
Second, some implementations are empty
function DirectMaskBlt:
Comment says it all, this is a stripped version of LCL.StretchMaskBlt
I see no reason to add duplicate code.
function OptimalPixelFormat:
This always should be pfDevice, if not then there is something else wrong.
function OSSupportsUTF16:
this is an OS function not a widgetset function, so it doesn't belong here
This flag shouldn't be needed anyway, the LCL is always utf8, when dealing with OS functions, use the proper SysXXX conversion routines
-
Well, those functions aren't "something special" for LCL, mainly but for delphi compatibility AFAIK, so I would propose delphi extensions as package then, instead of out-of-lazarus-repo svn.
Maybe we can ask Luiz to add it to lazarus-ccr ?
-
Oops, I forgot about the more interesting delphicompat.pas
Reopened
-
Hi,
To understand the meaning of this package is necessary to know the history behind it.
When i started the (new) port of VirtualTreeView, a 30kb piece of code that explores at maximum Delphi/winapi, i decided initially to remove the minimum of code necessary to make work so i wrote DelphiCompat that is simply a wrapper around winapi functions that does not exist (at that time) in LCL. This makes possible to get working under win32 faster.
As soon as i started to port to Gtk i found some bugs and started implementing the missing functions or creating workarounds. So there's a reason for each one:
OptimalPixelFormat: VTV requires 32bit bitmaps (pf32bit) to do alpha blending. But under Gtk is not possible to BitBlt a pf32bit bitmap on a 24bit or 16bit screen (http://bugs.freepascal.org/view.php?id=8553). This is my solution to not loose the alpha blending on not 32bit screens under win32 (pfDevice <> pf32bit) and at the same time working on non win32.
Also i found that some LCL features were not implemented yet like creating a mask for a bitmap so the reason for CreateBitmapMask (it would have the benefit of being a one pass process but there are some technical reasons why it can't be a generic approach). Now that is implemented in LCL i switched the code that was using it use TBitmap.Mask instead.
Even some LCL equivalents to winapi was not working correctly even in win32, so the reason for DrawFrameEdge (already fixed). This same function until recently was crashing on gtk (http://bugs.freepascal.org/view.php?id=9234). Some other functions were added or fixed in LCL at the mean time like FrameRect and *MapMode
OSSupportsUTF16 is used in ATBinHEX that cannot be converted to UTF-8. I don't remember where is used exactly.
DirectMaskBlt is just an win32 specific performance optimization where i know in advance that is not necessary to check the alpha channel.
All those limitations were reported to LCL. See http://bugs.freepascal.org/view_all_set.php?type=1&temporary=y&reporter_id=34
In summary this package is intended to give to developers that are porting code from Delphi (mostly me) a bridge to get the port done while the bug/feature is not fixed/implemented in LCL and to slowly replace the functions too win32 specific by LCL ones.
I never intended to create a full working library so did not ask for merging into LCL or advertised much.
-
Hi,
To understand the meaning of this package is necessary to know the history behind it.
When i started the (new) port of VirtualTreeView, a 30kb piece of code that explores at maximum Delphi/winapi, i decided initially to remove the minimum of code necessary to make work so i wrote DelphiCompat that is simply a wrapper around winapi functions that does not exist (at that time) in LCL. This makes possible to get working under win32 faster.
This is exact the reason why I added the winapi functions when porting SynEdit. I'll add those missing functions.
As soon as i started to port to Gtk i found some bugs and started implementing the missing functions or creating workarounds. So there's a reason for each one:
OptimalPixelFormat: VTV requires 32bit bitmaps (pf32bit) to do alpha blending. But under Gtk is not possible to BitBlt a pf32bit bitmap on a 24bit or 16bit screen (http://bugs.freepascal.org/view.php?id=8553). This is my solution to not loose the alpha blending on not 32bit screens under win32 (pfDevice <> pf32bit) and at the same time working on non win32.
It is only a temp solution, the final solution will be alpha support on gtk too, so this is not really needed.
Also i found that some LCL features were not implemented yet like creating a mask for a bitmap so the reason for CreateBitmapMask (it would have the benefit of being a one pass process but there are some technical reasons why it can't be a generic approach). Now that is implemented in LCL i switched the code that was using it use TBitmap.Mask instead.
:)
Even some LCL equivalents to winapi was not working correctly even in win32, so the reason for DrawFrameEdge (already fixed). This same function until recently was crashing on gtk (http://bugs.freepascal.org/view.php?id=9234). Some other functions were added or fixed in LCL at the mean time like FrameRect and *MapMode
I'll skip those
OSSupportsUTF16 is used in ATBinHEX that cannot be converted to UTF-8. I don't remember where is used exactly.
It is more that this is not a widgetset issue, but an OS issue.
DirectMaskBlt is just an win32 specific performance optimization where i know in advance that is not necessary to check the alpha channel.
I don't like to maintain duplicate code. But I might "enhance" the DC so it knows it has a alpha channel or not.
All those limitations were reported to LCL. See http://bugs.freepascal.org/view_all_set.php?type=1&temporary=y&reporter_id=34
In summary this package is intended to give to developers that are porting code from Delphi (mostly me) a bridge to get the port done while the bug/feature is not fixed/implemented in LCL and to slowly replace the functions too win32 specific by LCL ones.
I don't question the package, I see its needs. But the problem is that it hooks into some LCL internals, so as soon as they are changed ppl will get errors. Thats a second reason I want to add it to the LCL
-
I'll add those missing functions.
If you mean add all DelphiCompat functions to LCL be aware that some functions are too win32 specific or the implementation is not doable like ImageList_DragShowNolock or CopyImage. Those are a temporary solution while the component switches to LCL solutions. BTW: many of that functions are not used anymore in VTV.
It is only a temp solution, the final solution will be alpha support on gtk too, so this is not really needed.
True.
Many Delphi controls use this approach to do alpha blending and even when alpha blending is implemented in LCL this will give the dev some time before he(she) switches to the LCL approach.
BTW: i implemented basic alpha blending (filling a rect with an alpha color) in gtk, gtk2 and qt. This should really be an valuable addition to LCLExt or LCL itself but the problem i face here is that the win32 code is licensed under MPL so incompatible with LCLExt or LCL.
-
I'll add those missing functions.
If you mean add all DelphiCompat functions to LCL be aware that some functions are too win32 specific or the implementation is not doable like ImageList_DragShowNolock or CopyImage. Those are a temporary solution while the component switches to LCL solutions. BTW: many of that functions are not used anymore in VTV.
It's not my first time ;)
And I'll add most of them one by one
It is only a temp solution, the final solution will be alpha support on gtk too, so this is not really needed.
True.
Many Delphi controls use this approach to do alpha blending and even when alpha blending is implemented in LCL this will give the dev some time before he(she) switches to the LCL approach.
BTW: i implemented basic alpha blending (filling a rect with an alpha color) in gtk, gtk2 and qt. This should really be an valuable addition to LCLExt or LCL itself but the problem i face here is that the win32 code is licensed under MPL so incompatible with LCLExt or LCL.
In this case I try to go native
-
Luiz, the actual state for virtual treeview new from svn in lazarus ccr is not compile. Can it be because theres part of your code inside lazarus trunk? I dont know if i must install your package or wait it is inside lazarus.
TIA