Hello,

some months ago, I wrote a a time-input component, which is oriented on the TDateEdit. Another programmer gave me the idea to integrate it to the LCL. So I add a entry to the bugtracker and attach a patch. http://bugs.freepascal.org/view.php?id=27147

In the bugtracker discussion, Juha Manninen wrotes: "This proposed component from Michael Fuchs competes with TDateTimePicker and is not VCL compatible. As LCL is a VCL compatible library, it logically belongs somewhere else."

It is not a problem for me, to publish this component outside the LCL. I was just surprised, that the development of the LCL has such a strong dependency to the VCL. I understand, that the LCL should have at least all the components of the VCL for compatibility reasons. But what is the problem with new components?

No offense, just curiosity.

Michael

But what is the problem with new components?

No problem with that I guess, but the "competes" part could be. i.e.: there are two competing components which do the same thing (and belongs to the same package: LCL) with one of them is not VCL compatible.

On Tue, Dec 9, 2014 at 11:29 PM, Michael Fuchs <

I think that the problem is that imagine you are a beginner using a library and this library has 5 comboboxes, 7 buttons, 3 different open dialogs .... its just bad design. A library needs only 1 control for each functionality. 1 more is bloat... small is beaultiful is a good design guideline =)

If the functionality is really something useful for most programmers we have no trouble adding things that the VCL doesnt cover. We added TTrayIcon before the VCL for example.

The lazarus-ccr is the place were other lcl-based controls can be placed, we have there SVN, place for hosting releases, etc.

On Wed, Dec 10, 2014 at 9:42 AM, Felipe Monteiro de Carvalho <

I'm still being caught by the selection:
TButton
TToggleBox
TBitBtn
TSpeedButton

But seriously, I typically spend some time in selection between TToggleBox, BitBtn and SpeedButton.

But to the subject - TDateEdit certainly could/should be available as 3d party package. Maybe even as part of Lazarus-CCR.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141210/a4e053cf/attachment.html>

Dmitry Boyarintsev wrote

But to the subject - TDateEdit certainly could/should be available as 3d party package. Maybe even as part of Lazarus-CCR.

TDateEdit is in LCL.
TDateTimePicker could be part of minimal IDE IMO (as is TDateEdit), and I find it confusing that one (TDateTimePicker ) is in CommonControls, the others (TDateEdit and companions) in Misc Tab.

Bart

Michael Fuchs wrote

It is not a problem for me, to publish this component outside the LCL. I was just surprised, that the development of the LCL has such a strong dependency to the VCL.

Maybe I'm not understanding Juha, but I think this is rubbish. It's not that black and white. LCL contains a lot of components not compatible or not existing in the VCL.

But I also understand that they don't want every single component included in the LCL, because it means they will probably end up having to support it. Hence they created the Lazarus-CCR project on SourceForge.

Regards,
- Graeme -

Felipe Monteiro de Carvalho wrote

The lazarus-ccr is the place were other lcl-based controls can be placed, we have there SVN, place for hosting releases, etc.

And a Git repo for many years already. :)

Regards,
- Graeme -

As I understand that: The components in the LCL should be available with all supported widgetsets. An implementation for only one widgetset is not worth of adding it to the LCL, because it would burden the LCL maintainers with the implementation for all other widgetsets.

DoDi

On Thursday, December 11, 2014, Graeme Geldenhuys <

True, LCL must have other useful components, too. I am not really against adding this particular component if it proves to be different enough compared to existing comps. Somebody else must decide that. Still, I have understood LCL should be kept small rather than bloated. It is not meant to cover every possible use case. It is ok to use components from elsewhere.
Suggesting CCR is seen as a punishment. Why? It was made for such components. It supports maintenance of those components well. The author gets commit access and there is a CCR section in bug tracker. Currently most CCR components are poorly maintained but it is the fault of the fleeing authors, not CCR itself.

Michael Fuchs, can you promise to maintain your component, where ever it is placed?

Regards
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141211/d1433426/attachment.html>

On the other hand, it pretty much blocks anyone else to add components to LCL.
Because an author has to introduce a solution for all (or most?) widgetsets by LCL.
With more widgetsets introduced to LCL, it might be next to impossible for some developers.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141211/67066f36/attachment.html>

IMHO the question is, should it be distributed with the Lazarus releases, and therefore be added to the Lazarus SVN. IF so, it does not need to be LCL, there is also LazControls, or the option of a new package.

But the question remains if it should... Sure it is an useful component (though my idea of time-edit would be up/down arrows). There are lots of other useful components. Besides the question of maintenance (if it stops working, and no one maintains/fixes it, then it gets thrown out?), the installer already quite big. And there are still countries where bandwidth is not unlimited.

Even if this was added, what about the many that are not. The fundamental problem is making add-on components more accessible.

If this time-picker was added to the CCR it only highlights the existing problem. There must be a maintainer.
But adding it to the LCL (or main svn) does not change that. Without maintainer still will stop to work eventually. So adding it to the main SVN depends on an existing developer volunteering as maintainer. (and none has yet)

What the CCR need is either one release manager, or every contributor on the CCR doing that them self. Then for every Lazarus release a set of tested source archives could be offered for download, containing the version of each of the packages that works with the release. If maintainers want to add such archives we can probably find a place to upload them all for download. Maybe it is even possible to add them to sourceforge in a separate folder. Then the CCR had the same visibility as the Lazarus releases themself

Juha Manninen wrote

Michael Fuchs, can you promise to maintain your component, where ever it is placed?

Of course.

Michael

[...] Even if this was added, what about the many that are not. The fundamental problem is making add-on components more accessible.

+1

+1
The CCR contains packages with different directory layouts. To make the CCR a repository the packages need to follow some rules. And each package needs some information, e.g. what platforms they support.

Mattias

And it needs a decent index, with up-to-date links. Whenever I've gone looking for something I've had to resort to Google to find where it actually lives.

On Thu, Dec 11, 2014 at 12:31 PM, Mark Morgan Lloyd <

This index? http://wiki.freepascal.org/Using_the_Lazarus-ccr_SVN_repository

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141211/e1a8efe8/attachment.html>

Hans-Peter Diettrich wrote

not worth of adding it to the LCL, because it would burden the LCL maintainers with the implementation for all other widgetsets.

Why would it be widgetset specific? Isn't LCL cross-platform any more? If you implement a new GUI component using LCL, surely it should work on all platforms? That is how fpGUI Toolkit works, and the developer never needs to worry about that.

Regards,
- Graeme -

On Thu, Dec 11, 2014 at 4:13 PM, Graeme Geldenhuys <

I presume there's a difference between LCL and fpGUI. LCL is based on system native controls in the first place, actually a widgetset. fpGUI is custom-drawn.

Thus the base set of LCL controls, should be limited to a small set of system native controls.
fpGUI or MSE doesn't have this limitation.

Adding a really cross-platform control (that's not based on a native control, but only LCL level APIs) is always questionable, since it increases the size of the library. And it might be better to make it a 3d party component.

Even components that are based on native controls are not part of LCL. I.e. OpenGLContext - is a separate package or Printers4Lazarus.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141211/f3b4f972/attachment.html>

Why not leave it to the LCL maintainers, which controls should be added to the LCL, and which not? Provide them good reasons for doing so...

DoDi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141212/fa1c4650/attachment-0001.html>

I've always found CCR to be a hacky and hard to use solution, starting from the requirement to use SVN or Git.

IMO the best solution would be to have a real package manager that can access repositories (with a default one provided by the lazarus devs that should replace the CCR and provide everything in it) from inside Lazarus that can download and install packages. Opening a project file that relies on a package should scan the repositories to see if it is available and ask the user to download it. The user should not need to do anything more than selecting Yes or No there and to install new packages should be done from the Add / Remove packages window that is already there. Basically what Netbeans and Eclipse are already doing for many years now (especially Eclipse).

Personally i have a bunch of Lazarus projects at my site that many of my own programs use. Right now one has to track and download each requirement separately - look at this wiki page
<http://runtimelegend.com/rep/rtworld/wiki?name=Build+and+Prepare+Runtime+World> as an example (it used to be longer before multithreadprocslaz became part of Lazarus itself). One needs to download, build and install four separate packages manually. I could instead provide a repository that can be added in the package manager (and even referenced from my program's project file to be added automatically so the user wont even have to add it manually!) and have Lazarus download and install the required packages.

As things are right now, if something is not part of Lazarus it is a great pain to use it exactly because of all those extra steps required. Other languages and environments have already solved that long time ago and i think Lazarus should also do the same. Using a library should be as pain free as possible and ATM in Lazarus it is hard - with the exception of Windows, it is even harder than C and C++ since in Linux all popular distributions include thousands of ready to use libraries which are available with a single `apt-get` (or the distro's equivalent).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20141212/107ec0b2/attachment.html>

That is a good idea.

Marcos Douglas