G'day all,

Just for information I've attached some patches I apply to my local tree and use in an application I'm working on.

These are not any form of an example of how to write good code, they are gross hacks that have "evolved" as lazarus has evolved over the last 9 months or so and I adapt them as required as the code changes under me. If anyone finds any of the bits useful, I'm more than happy to clean them up and work with the relative authors to make them acceptable to the general code base. Conversely, I've maintained them in my own tree for 9 months and I'm happy to keep doing so.

I'm also very open to suggestions as to how I might achieve my desired results without having to hack the codebase.

laz-find.patch :
This adds an extra checkbox and set member to the find/replace dialogs to allow selection of "entire scope" as a search parameter.

laz-synpatch-005.patch
This is a gross hack, but it allows clicking *anywhere* on the grey fold line in the gutter to fold that particular level of routine. I have some procedures that are very long and it's nice to be able to click on that line from the bottom of the procedure and have it fold up on me.

laz-synpatch-007.patch
This is another gross hack, but in a highlighter I've written I use this to enable me to ensure the remainder of a line is painted in the right background colour. Synedit calls this "GetLineRemainder" routine (if assigned in the highlighter) to get the colour the remainder of the line is to be painted after it has finished painting all its tokens. Without this I was getting odd line remainders when I scrolled often. With this I get perfection every time.

laz-synpatch-008.patch
And the final gross hack. I store the folded status of each open file in my overall project file. The easy way for me to do this is in a sequential comma delimited list of line numbers that are folded. This routine "DumpFolds" gives me a string which is a comma delimited list of all the lines that are folded. Then when I reload the project I can simply fold those lines in reverse order to get precisely the folds I had previously.

On another note, recent work by Martin Friebe and Paul Ishenin has rendered three other gross hacks I've had in my tree irrelevant :)

Regards,
Brad

2009/5/20 Brad Campbell :

laz-find.patch : This adds an extra checkbox and set member to the find/replace dialogs to allow selection of "entire scope" as a search parameter.

I am confused. Is "Origin/Entire scope" setting on the same dialog not sufficient? Also, the patch is CRLF-damaged.

laz-synpatch-008.patch And the final gross hack. I store the folded status of each open file in my overall project file.

This is IMO a good idea.

Which "Origin/Entire scope" option? There is an option for that on the Lazarus find dialog, but it's not there on the dialog in the component menu you drop onto a form.

Interesting on the CRLF though, are you using windows? All my patches / source are formatted for Linux.

I like it, it's been quite handy. The implementation is a bit of a hack. The last incarnation passed an array of int and I encoded it and write it out in my application. Doing it this way required far less conversion but it's not very neat.

Sorry, I mistakenly thought you are changing IDE find dialog, not LCL one. BTW, I think it makes sense to port features form IDE to LCL dialog and then use it in the IDE.

Interesting on the CRLF though, are you using windows?

I do -- this is why I am used to notice such issues ;-)

All my patches /source are formatted for Linux.

laz-find.patch replaces finddlgunit.lfm and replacedlgunit.lfm files with CR-LF versions. This is the reason for the large size of the patch.

Alexander Klenin wrote

Sorry, I mistakenly thought you are changing IDE find dialog, not LCL one. BTW, I think it makes sense to port features form IDE to LCL dialog and then use it in the IDE.

I've looked into that in several places, but licensing becomes an issue. The LCL is LGPL with the exception clause, while the IDE seems to be generally GPL.

Brad

I've looked into that in several places, but licensing becomes an issue. The LCL is LGPL with the exception clause, while the IDE seems to be generally GPL.

Software licenses apply to whatever is the subject of a specific license contract. The contract can specify different license models for groups of files, as can be seen in lazarus/COPYING.txt.

A source file can be licensed under multiple models, in different license contracts. A source file without a license or copyright notice is *not* in the public domain, it can *not* be used in any way without a separate licencse agreement.

I see no problem with licensing e.g. the Find dialog under GPL when used in building the IDE, and under LGPL when used in other applications as part of the LCL.

DoDi

Hans-Peter Diettrich wrote

I see no problem with licensing e.g. the Find dialog under GPL when used in building the IDE, and under LGPL when used in other applications as part of the LCL.

Sure, but who has the right to make this decision? And generally, GPL requires derived works to be GPL also. Usually, IDE depends on LCL and not vice versa, so this is not a problem. But if enough code migrated from IDE to LCL,
that would IMHO make the latter derived work...

Hans-Peter Diettrich wrote

I see no problem with licensing e.g. the Find dialog under GPL when used in building the IDE, and under LGPL when used in other applications as part of the LCL.

I agree with you, but that call is up to the author(s) of that particular component.

I have read the licensing something like this :

"We provide the lcl licensed similarly to the fpc rtl to encourage use in projects of all kinds and we provide an extent of Delphi compatible functionality to accommodate this use, but we put an incredible amount of work into the specialised components of the ide and we the authors feel that it should be licensed GPL as a result."

I can't argue with this logic and if I were a major contributor to the IDE I'd want my license terms honoured also.

Now, I've cleaned up the CR/LF damage in my find patch and submitted it to the patch tracker for comment. If it gets included then I win, and if not then I'll continue to maintain it out of tree for my own use. Either way I still have the LCL to build on and therefore I'm way ahead of the game.

Brad

Zitat von Brad Campbell :

Yes. We, the authors, can change the moving code
from the IDE to LCL is not a big problem.

Speaking for myself, GPL was chosen for the IDE and codetools, because I don't want to see some closed source IDE fork.

I think these are interesting idea. I had not yet the time to inspect the quality of the code.

Mattias

We also could ask, who has the right to refuse such a decision.

In the first place it's the author of some file, who can act however he likes. For a work with multiple contributors, all contributors must agree about a decision - in theory. In practice a common project will restrict the decisions of the contributors, so that no single contributor can block further development by a veto.

For source files dedicated to the Lazarus project, or to some project with multiple contributors in general, I'd assume an consent of all contributors, that the project management stuff is entitled to license all contributions to that project, in the spirit of the project ("fair use").

When the spirit of the choosen license models (GPL/LGPL) shall guarantee the free use and further development of the project, that freedom also should apply to decisions that are not against this spirit. IOW: no single contributor should be allowed to deny his consent to a decision of the community of contributors, unless his rights on his contribution are affected in an intolerable way ("unfair" use).

[German law specifies both a "community of authors" (? 8 UrhG: Miturheber), which contribute to a common work, and a "combined work" (? 9 UrhG: Urheber verbundener Werke). In both cases the authors act as a community, and no author can deny his consent to the decisions of the community of authors (unless exacting demand, something like "fair use"). cum grano salis, IANAL]

And generally, GPL requires derived works to be GPL also.

A work, derived from the Lazarus IDE, has to be licensed under the terms of the Lazarus IDE. When the IDE license is GPL, the derived work also must be licensed under GPL.

Usually, IDE depends on LCL and not vice versa, so this is not a problem. But if enough code migrated from IDE to LCL, that would IMHO make the latter derived work...

IMO not. Derived work is a different work, based on parts of some other work. The Lazarus project depends on FPC, but not on itself. The Lazarus IDE and LCL will stay Lazarus IDE and LCL, not affected by decisions about what particular files shall be considered as exclusive parts of the IDE or of the LCL. Such an "exclusive" assignment to a Lazarus sub-project may be subject to later changes, at the discretion of the community of authors.

Moving files from an IDE directory into a LCL directory will affect the users, which then are allowed to use the files according to the LCL license (LGPL), as stated in COPYING.txt. Only the authors are allowed to move files in this way, with such consequences, and only when the spirit of the project is obeyed (fair use).

DoDi