Well, 1.4 was new when this topic started, now more than year ago, there are new features in trunk, it's time to tag a new release.
Ok, I just quoted something without looking at the dates. The latest version would be used of course.
Anyway, I believe that it would not be to difficult to make one-way conversion (as a part of Delphi convertor), for usable formats.
Here is what I mean: as VCL's Format property allows strange formats, for example MM-hh:yyyy/MM - month appears twice, hour between month and year, three different separators are used - this much freedom in formatting is not allowed here, so the convertor can recognize that we have month then year in date, then hour in time, also convertor will recognise that lower case h means 12-hour format, then the convertor will ignore the second apperance of month and we can get something like "mm-yyyy hh AM".
In future the converter may be able to do things like that. Some missing feature in LCL component is OK though, and it can be implemented later.
Of course I have no objection to this. I never liked adding my initials as prefix. I only put it in front of the control name because I thought that LCL developers might one day wrap native windows control (as VCL does), so that I should leave TDateTimePicker name free for them.
Ok, this is a valid point. In Delphi this component is a COM control wrapper. Such wrappers are nasty. I looked at the TCoolbar wrapper and uhhh, it is bad, and they never got it working properly at design time.
Binding complex components to native widgets is difficult because of all the differences, even without the COM control challenge.
IMO the right way is to make a practically custom drawn version for such controls as I did with TCoolbar. Your TDateTimePicker would fit there, too.
Other issue is which components should be included in LCL and which should be kept in external repositories like CCR.
LCL is meant to be more or less VCL compatible. TDateTimePicker matches that rule.
Other useful but non-VCL components are a grey area. For example the Industrial library (Led etc.) that I added is useful and does not compete with other LCL components. Yet, there are many other libs that fill the same criteria. Should they all be included? No, then we would compete directly with CodeTyphon.
The right solution instead is to make installation of external components as easy as possible. There is some pre-alpha code (Aarre) but nothing functional. I think it should be derived from fppkg somehow. Volunteers would be needed here, too, like for many other tasks.
I believe the Industrial lib will be moved to CCR once the installation from there is easy.
So, a rule of thumb is that a component should go to LCL only if it is VCL compatible or it is needed by Lazarus IDE itself.
Avishai, TCalendarLite does not fulfill those requirements. The goal however is to make downloading and installing such components easier.