So, do we want a quick and easy fix or a full coverage -Yes, a readme file is already shown in a memo if it exists. A "Category: xxx" syntax can be added. Later somebody could add a proper readme file for all example projects.
* redesign the GUI
* provide a category system for all examples, maybe in the (compulsory) readme file ?
* Copy the deb/rpm installed example to user space when 'chosen' by the user.That sounds strange. Why should we use Linux distro package system for Lazarus examples?
Thats quite a significant change, I'm not keen to get stared unless there is some indication its the way we really want to go ??The GUI can be improved at the same time while wp or others improve the actual example projects.
I like Online Package Manager tool.Online example projects. Yes, it is a good idea. It could use the same framework with Online Package Manager. Maybe GetMem has an idea.
It would be nice if similar tool would exist for examples (maybe in Help menu of Lazarus).
It would be fast and easy way to get to the examples and easy to point someone to.
And examples could be 'live' - when someone make new example project (or update it), it would be available in this tool.
Maybe some ideas from the actual Example-Screen and OPM.Do you mean ideas for an Online Example Project system?
And help is not Example, and can reference to the example system.Do you mean the Help menu should have entries for example projects, too?
BTW, is the fppkg system for Lazarus too ? OPM is well known in Lazarus, but fppkg more a hidden secret system for IMHO the most user.The design goal was that fppkg supports both FPC and Lazarus code. It does not work well yet. It only has a small set of FPC packages to test with. I don't know more about the technical challenges there.
Yes, you must be able to search by a keyword. In the ExampleProjects , this is often done by enter few letters and you hope to find a project with this word :-)Maybe some ideas from the actual Example-Screen and OPM.Do you mean ideas for an Online Example Project system?
Yes or inserted links to the sample projects. Or the keywords can bypassed from lhelp to the sampleproject manager.QuoteAnd help is not Example, and can reference to the example system.Do you mean the Help menu should have entries for example projects, too?
But to change a well working system to a 'not well working' system, is not a target. And the actual OPM system is stable. So if you want to seperate the samples from Lazarus, you should use a stable base. Actual i think a fast way is to use the technique of OPM and start. On the other side you have to wait for a realy working fppkg system (for Lazarus too). I think fppkg will make a brake through with dynamics packages in the future.QuoteBTW, is the fppkg system for Lazarus too ? OPM is well known in Lazarus, but fppkg more a hidden secret system for IMHO the most user.The design goal was that fppkg supports both FPC and Lazarus code. It does not work well yet. It only has a small set of FPC packages to test with. I don't know more about the technical challenges there.
I like Online Package Manager tool.
It would be nice if similar tool would exist for examples (maybe in Help menu of Lazarus).
QuoteThat sounds strange. Why should we use Linux distro package system for Lazarus examples?Quote* Copy the deb/rpm installed example to user space when 'chosen' by the user.
....
3) Link to a to-be-created Wiki page which lists example category pages
I see a danger in "anyone" being able to load a project on the wiki, we tell the beginners "go look there" and they download a project that does something nasty. Sorry, I see that as quite a serious danger.
You could say the same about any of the existing code (https://wiki.lazarus.freepascal.org/Category:Code) on the Wiki and all the FPC + Lazarus projects (https://wiki.lazarus.freepascal.org/Projects_using_Free_Pascal) linked from the Wiki not to mention all the tutorials, components and libraries also linked from the Wiki.
You could say the same about any of the existing code (https://wiki.lazarus.freepascal.org/Category:Code) on the Wiki and all the FPC + Lazarus projects (https://wiki.lazarus.freepascal.org/Projects_using_Free_Pascal) linked from the Wiki not to mention all the tutorials, components and libraries also linked from the Wiki.
No, I disagree, code pasted in a wiki page or appearing in forum are discrete lumps of viewable code. By definition, its reasonably short and lots of people run their eyes over it. That should not be compared to a zip file that could contain many units, thousands of lines of code, frankly, its not going to be checked.
I am assuming there is a way (and people are happy) to make the wiki allow uploads of zip files ? Or do we need an alternative location. Hmm, gitlab ?
I never advocated a ZIP file - I advocated links to SourceForge et al code repos.Example projects need to be bundled into something and zip is both the Lazarus preferred model and is reasonably cross platform. if not zip, what else would we use ? Contents could just sit as files in a directory on, eg Gitlab, one directory per project but maybe a little harder to manage.
Again, I never advocated either ZIP files or uploading them to the Wiki.No, you did not. And I clearly misread that. But you equally clearly missed my words that "I am definitely not against the idea".
You seem to have setup a straw man just so you could demolish it :)I think that is unfair and uncalled for. It really does not matter where we keep gz/xz/zip/dir contents, if it has access similar to the wiki, its not safe enough. If it has gatekeepers, that can work as long as we can manage the extra load. Its the usual security v. convenience argument, neither SourceForge nor Github/lab would allow unauthenticated uploads anyway.
Because, from what I understand, one of the issues in the bug report is that end users who install Lazarus using deb/rpm/pakman etc end up with it all in Read Only space. Its not a packaging thing, its a ReadOnly issue. So, if they try a build an example project, it cannot write. I, personally always build from source but lots and lots of people install distro packages.A user must be able to compile the code while it is open in the IDE. He may want to modify and debug it, just to learn and experiment.
Category : beginnerYes, both Category and Keywords sound good.
Keywords : buttons, memo
Sorry, Martin. This is not a good idea: It will be an unacceptable burdon to GetMem who handles all the additions to OPM manually. And unless "examples" are separated from "components" in some kind of GUI, components will be buried underneath loads of examples.
Doing it via opm, and the "example window" searching packages, also offers the advance that existing packages (e.g. packages that add new components), can include examples for those components.needs to be taken care off.
Because, from what I understand, one of the issues in the bug report is that end users who install Lazarus using deb/rpm/pakman etc end up with it all in Read Only space. Its not a packaging thing, its a ReadOnly issue. So, if they try a build an example project, it cannot write. I, personally always build from source but lots and lots of people install distro packages.
1) Remove all the examples from the distributions
* Reduces distribution size (I didn't even know there were examples)It's 60 MB, but text only. Compressed maybe 10 MB.
3) Link to a to-be-created Wiki page which lists example category pages
4) Add examples to appropriate yet-to-be-created category pages
5) Example entry in Wiki links to SourceForge/Github/Gitlab for the source for each example
Isn't it possible to have the installer copy the Examples folder after installation to user space?
OK, here is a first cut at a gitlab examples repository
https://gitlab.com/dbannon/fpexamples
In answer to Juha's question, I am certainly willing to be involved but we both know Juha would do a far better job (but good use of his time ?). But we must agree on an approach first. We seem to be a long way from there now.Actually I only promised to work on the window for local example projects, yet I am happy if somebody else does it. Whoever does it, let other people know to prevent duplicate work.
Not sure why the name is "FP..."?It stands for Fine Programing.
- If there is more than one example, GitLab offers "download folder as zix" => so all that is needed is "each example has a folder of its own"
2) "Hello World, I try to imagine a user to whom this is of value...."Its only an example of an example. But new user of a programming language, build system etc looks for Hello World. Its of no earthly use expect allowing to new user to confirm compiler works as expected and binary runs. It takes up no room but there is no commitment to it being there at the end if you find it a problem.
IMHO, this really would need to be a tutorial.
Only problem(s), as pointed out before:
- If you use OPM to get AtSynEdit, then you need a 2nd download for the examples (if indeed the decision is to have examples in a diff repo).
- If you explore the OnlineExamples, and download AtSynEdit-examples, then there must be a dependency to trigger OPM.
.....
Actually I only promised to work on the window for local example projects, yet I am happy if somebody else does it. Whoever does it, let other people know to prevent duplicate work.
For an online project system it makes no sense to store ZIP packages ...Yes, Martin pointed out that Gitlab (unlike Github) allows an interactive user to pull down a directory, converting to zip on the fly, thats excellent.
Sorry, I did not meant to make this about "finding a problem". But rather "pointing out more potential".2) "Hello World, I try to imagine a user to whom this is of value...."Its only an example of an example. But new user of a programming language, build system etc looks for Hello World. Its of no earthly use expect allowing to new user to confirm compiler works as expected and binary runs. It takes up no room but there is no commitment to it being there at the end if you find it a problem.
IMHO, this really would need to be a tutorial.Sure, this model would support a tutorial series, but it would be silly discussing content before the framework is agreed on.
Btw, another point that may be worth considering: translations.Can the actual FPDoc this ?! Because this is the main tool for (Code-) documentation.
Sorry, I did not meant to make this about "finding a problem". But rather "pointing out more potential".
framework and content are somewhat bound together....
- meta-data files will have to be extended too, and once the first version of the "example mgr" is out, meta-data requires backward compatibility.
As pointed out: OPM packages already contain examples. So our meta data, and storage requirements should allow such OPM packages to be recognized.
Well, I guess - ideally - the "example window" (in its new form) will show everything that is (or has) example(s).The model I mention a couple of line up would show -
- installed
- online
- and if our online DB is separated from OPM, then also OPM packages with examples
But in reverse, if a user browses OPM packages, and if they (or some of them) have meta-data about their examples:While an issue for OPM, I'd say yes, I'd also like a filter for "show ones with good docs" but thats getting a bit subjective :-)
- Should then the local OPM browser window, not also allow to filter by "has example" ?
- And if the local OPM browser window, can show "only with example", should then the local OPM browser window not also be able to show the entries from the new example repo?
Especially, since the new example repo could also contain examples for OPM packages. Just examples that have not been bundled with the OPM package itself.)
So, unless we want to exclude OPM packages from having examples (within the example window), it seems to me that the two need to be very closely coupled.
Btw, another point that may be worth considering: translations.
Can the actual FPDoc this ?! Because this is the main tool for (Code-) documentation.My initial though is that fpdoc would be overkill for the faily miminal docs we are planning to use, just a couple of relevant keywords and a sentence or so of what the project demonstrates. But af0815 if you are familiar with fpdoc, could you elaborate ?
It would NOT show OPM examples from packages not installed. And I think that makes sense.Makes sense. In fact, showing examples for packages "not yet even downloaded" would be confusing. (There OPM could be extended, to allow filtering by "has example", but that is off-topic).
I am sort of thinking, given that idea of the Example Unit scanning locally of OPM Examples, that OPM Examples belong in OPM Packages and 'should' comply with the Examples standard we come up with.Well, ideally yes.
As dbannon wrote, the example project system can search projects under the OPM install directory. No other integration is needed.Depends, on how the above is handled.
As the meta files are by definition, quite short, maybe its just having a po directory in the project dir with translated files ? Can the same model support in project po behaviour too ?Good start. Translated files, must not contain "version info", or any info at all, except translated strings. (Other elements could be allowed, but have to be ignored).
Right now I am playing with a brief "technical feasibility" project, just to see if what I imagine works will (given my familiarity is with Github, not Gitlab).
What I am playing with is model where the client (ultimately built into Lazarus) dowloads a master.meta file, checked daily (?) and keeps a cached copy. Suppose when doing its daily checks (or a manual refresh) it also scans the area in .lazarus where OPM packages are and if it finds any recognisable example projects, adds them to its local list ?
As dbannon wrote, the example project system can search projects under the OPM install directory. No other integration is needed.
I realized there must be multiple directories to search from.
One is "examples" under Lazarus tree which is the default now.
The "components" directory must be searched, too. The local packages also include example projects.
Third one is the OPM directory which is known by reading the OPM settings.
Then a user can define more directories.
I suggested local scanning for Examples only for things like the OPM ones. Benefits, solves the Read Only problem, makes for a smaller Lazarus Distribution, people using an older Lazarus can get new Examples - I see several more less easily and quickly described.
I would definitely keep some examples in the distro.+1
Not everyone wants their IDE to go online.
My opinion, too.I would definitely keep some examples in the distro.+1
Not everyone wants their IDE to go online.
And I get the impression from the discussion that the solution will somehow depend on features of GitLab. I think this is not a good idea. What if we once were forced to move away from GitLab? Then the example infrastructure would break away...
IMHO we need at least the ability to specify "required packages" for the example.That is over-engineering and duplicate logic. All the information is already in project/package dependencies.
And probably should at least prepare, to store some info on the packages
- min version (maybe max version too)
- Only required for design.
-- Some packages have separate *Dsgn packages, then the example can run without this (i.e. the package does not need to exist at all, example can be compiled/run without it)
But the user must be told what happens if he does not install it.
-- Other packages have IDE integration and runtime in one package. So even if the user skips installation, the package must exist for compilation.
- Origin of package: Laz-Installer, OPM, unknown
... hopefully just getting cool enough to sleep. Been hot for a few days, yawn !Oh boy! We had -15°C last night here. It is cool enough to sleep. :)
IMHO we need at least the ability to specify "required packages" for the example.That is over-engineering and duplicate logic. All the information is already in project/package dependencies.
And probably should at least prepare, to store some info on the packages
...
I would definitely keep some examples in the distro.
Not everyone wants their IDE to go online. Some are concerned about privacy, ....
...
I would definitely keep some examples in the distro.
Then we have to solve the *nix readonly problem.
... a number of issues> What about "examples" (pure examples, stored in the OE) that require a package?
And I get the impression from the discussion that the solution will somehow depend on features of GitLab.
> I would expect that contributors maintain their own GIT repo. (I guess we start with "git repo" as storage, probably keep it at this, but extension would be an issue for later...)
See earlier discussion with Trev about safety. Suppose I have an example in my own github repo, there is a link in the Lazarus Repo to it. It demonstrates how to read all files on disk into a TStringList. Been there for years. I have too much to drink one night and add a two lines -
for St in STL do deletefile(St);
Or an example that encrypts the user's disk until they find some bitcoin ....
But, a link is safe too. As long as it is to a specific commit by sha1.
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/c8feb2d0e8d72e8145c52b9a0b6055adbdc8344c
This application demonstrates reading the Windows Registery, its Windows Specific .....
Keywords : Buttons Forms Hello
I would suggest rather
Keywords: button TButton form TForm memo TMemo Hello
although I thought most "Hello World" programs used a label rather than a memo?
About the meta data. I would strongly suggest to use either json or xml.
There is pro and contra for both.
OK, a week after my last post here, apparently no interest so I abandone the proposal.I planned to study it but then other things came up. Have you really deleted the whole thing now? No way to test?
I have removed the gitlab demo page, marked the wiki page as abandoned (Trev tells me it cannot be deleted).
I think its a wasted opportunity, we need to make it easier for (especially new) users and easy access to examples would, IMHO, make a big difference.
I planned to study it but then other things came up. Have you really deleted the whole thing now? No way to test?Sorry, I was too impatient !
A branch in GitLab Lazarus sources would be a good fit for such experiment. You could replace the examples window in Tools menu right away there and then fine tune without hurry.
li]I'll copy a user selected project into a dir tree under 'examples' in the Lazarus config dir.Make this directory configurable by the user, like it is in OPM. I have numerous Lazarus installations on my HD, and I'd like to re-use the examples of one installation by another installation for example to check whether sample code is compatible between versions.
Make this directory configurable by the user,....
https://gitlab.com/dbannon/laz_examples
It says 'Page not found'.
You are missing closing single quote in line 154 of unit1.pasThats pretty careless, thanks.
(32480729 was probably old repo number).Indeed, just about to do another commit, trying to break apart the user from Admin content.
Stand alone application is OK,
OK, thats happened when I pushed it all up again. Quite silly ! I will sure fix that.
Oh, and is it possible to delete project1 file from gitlab, it's 25MB binary?
* Am I on the right track ?Yes and no. I don't see how you can be motivated to do much more work on this without closer collaboration with the developers. Why not start from the existing Tools > Example Projects... dialog and improve it?
* Am I correct in excluding all but a few example projects that don't use the Object Inspector ?Certainly. There could be a category in which you place a couple of good examples of non-RAD, code-only utilities, useful for people who are no longer beginners.
* Am I being too ambitious ? Should we leave the Example code where it is and just graft on the metadata somehow ?I think you need to work more closely with the developers, or you risk all your work just being rejected or ignored.
Sorry for the delay, I had some other activities. (*)Serious power tool! Can I rent it? We have a piece of forest in Lithuania (inherited, 7 Ha) Should be right next door across the Baltic :D
(*) I bought a 18" bar (X-Force) and chain (X-Cut) for my Jonsered CS2152 saw and did some lumber jack stuff as the picture proves:
https://drive.google.com/file/d/1sNfKzB-1zmwUl9FWEWv2m3BUts9AXgpG/view
I also bought some forest. It is now or never. I am getting old. When I get very old, I will not be able to work in a forest any more.
Serious power tool! Can I rent it? We have a piece of forest in Lithuania (inherited, 7 Ha) Should be right next door across the Baltic :DWow!
( Now playing "when I'am 64" have to wait till Monday....)
Yeah, thanks Howard. I understand your message.
I felt that this was/is the best approach but that I (or someone) needed to get some partially working model happening to demonstrate its practicality.
Davo
...also master.ex-meta does not pass an online json validator.
each and every caption/text should be a resourcestringI have a few string literals in there that will need converting, most of the GUI content will be done automatically. In the event that someone wants to translate the metadata, my plan is to have a separate files in each directory with a po file like 'es', 'ru' etc. The actual translation would be quite a big job and my guess is it will be quite selective, so the master metadata for each language will probably be mostly English unless someone gets really keen. Code changes to support it is minimal.
TreeView v. ListView.Now, I am not sure about that. A treeview approach will require a user to click to expand each item to view it, the listview requires just a scroll. But I will definitly consider and maybe code up an example ....
Personally I would move it to an external server, but I'm not the one who decides such things. As always things are not black and white, there are pros and cons no matter what solution is chosen.One con of the external server is that examples will change with the Lazarus version (new examples added, deprecated ones removed, some edited due to changes in properties or FPC calling parameters etc). Keeping the examples within the Lazarus distribution makes sure that they always are opened by the correct version.
One con of the external server is that examples will change with the Lazarus version (new examples added, deprecated ones removed, some edited due to changes in properties or FPC calling parameters etc). Keeping the examples within the Lazarus distribution makes sure that they always are opened by the correct version.
It's not yet clear what will happen with the example folder. Personally I would move it to an external server, but I'm not the one who decides such things. As always things are not black and white, there are pros and cons no matter what solution is chosen. Anyways if the example folder remains part of Lazarus, you should reuse the existing Tools->Example projects dialog. If the folder is moved to a server, then the package approach is a far better one. Code moved from IDE to a package, will make Lazarus faster and slimmer, because a large part of the packages are only loaded in the bigide.Don't reuse the existing Tools->Example Projects dialog. It needed a big revamp anyways. Now the revamp will be thorough. Please remove the old GUI when adding the new one.
Why not version the external server examples tree eg using version branches or tags or whatever. Lazarus should know its own version.The same discussion now happens in Lazarus dev list and here, but no problem.
"This example requires Lazarus 2.0.12 or later because it uses BlarBlar"
"This example works with Lazarus 2.0.8 and before if you uncomment the {.$DEFINE OLDLAZARUS}"
OK, I guess a decision made elsewhere ?No decision really. The discussion stalled after few comments. The best way to get things forward is to provide code to test. Let's try to get it into Lazarus trunk which is tested by many people.
Thats OK, no problem. I have a working package already but honestly, thats all down to the package template Getmem sent me, made it trivial. And we could have that working in parallel to existing one, so easy and safe transition. But no problems Juha, I'll fix it.Package is good. I didn't study GetMem's package but the IDE integration at least should use a package. The existing Example Projects dialog is not a package. It can stay there in parallel if you want, but can also be removed.
A more serious problem might be the fact that I cannot, totally dependably, get my https downloader working on MacOS. We cannot depend on the user having installed openssl and the Mac provided one is dodgy (IMHO) in earlier releases of MacOS.I believe it can be sorted out. OPM works in MacOS, right? It can be temporarily broken for MacOS, no problem.
Unless this can be sorted out, Examples on line is looking risky too I am afraid. Sigh...
OK, so you mean the dir (and its contents) must stay in the Laz SRC tree. But not necessarily be used by the new Examples Window ?As long as the directory stays there, it should be used by the new Examples Window.
I really don't understand that one. I do not need to fork Lazarus to make a package, Lazarus already has all the support I need built in, nothing need change in Lazarus at this stage. Except, perhaps, to intercept a user click on the Project Wizard -> View Examples Project.They must be copied under the Components directory at some point. It makes things easier if you already have them in the correct place in your GitLab fork. There will be Makefiles which need help from others etc.
In https://gitlab.com/dbannon/laz_examples/-/tree/main/Utility/pkg you will find a working Package that adds a menu item to the Tools menu, it opens an Examples Window that does most of what we need. Copy the files somewhere and open the lpk file.
I have no idea how to connect that Package to the Project Wizard but as a try out now, its up and running via the Tools Menu.Which Project Wizard you mean? The Project -> New Project dialog?
As long as the directory stays there, it should be used by the new Examples Window.OK, some issues. My version of the Examples Dir has a number of changes, if they are going to be used, we need to decide which of these changes need be pushed up to the fork -
They must be copied under the Components directory at some point...... options page registration ?
Which Project Wizard you mean? The Project -> New Project dialog?Yep, thats what I mean. its caption is "Project Wizard" and it currently has a Button that triggers the current Examples Window. Maybe that can be done with the LazarusIDE variable, it seems to be amazingly flexible.
I'll reverse the directory restructure (because it will confuse the existing Examples Window).Just remove the existing one as I initially suggested. I don't know why you want to keep it there.
Then I will need to make some changes to new Examples Window so that it looks to the examples in the local directory rather than on-line. Easy, I'll use some {$ifdef so we don't loose (yet) the online capability. This solves my MacOS problem too.I think online is the way to go. Supporting both local and online examples would be best.
If, at some later stage, we do decide to go online, the underlying structure will still be there.
Note B - The new Example Window reads things like LazConfigDir from the LazarusIDE variable. Will need to read LazSrcDir. At present it has no options of its own but at least one person has requested the ability to direct downloaded (or copied) Examples to a directory of their choice rather than automatically under LazConfigDir. I assumed this would a small config screen associated with the new Examples Window, to be done later. Is this what you are referring to as "options page registration" ?Yes, a package that integrates in the IDE and needs settings should add a configuration page (or pane) to the global options window, Tools->Options.
Just remove the existing one as I initially suggested. I don't know why you want to keep it there.OK, I'll do a fork, remove existing examples, replace it with my version of that directory and merge. A pull request or a diff file ?
I think online is the way to go. Supporting both local and online examples would be best.Yep, thats what I'll do.
.... settings .... Tools->Options.When you get a chance, yes please. But its not holding me up now.
IdeIntf has an API for it. I can find an example package that already does it later. ToDoList maybe...
What is holding me up right now is I cannot find a way to read the LazarusDirectory from a package. Must be possible but right now, I am considering reading LazConfDir/EnvironmentOptions.xml - and I'll watch to see who laughs !Nobody gonna laugh. You can read LazarusDirectory form EnvironmentOptions.xml like this:
also since the package is running inside the IDE:should be enough.
LazarusDirectory := ExtractFilePath(ParamStr(0));
If the Lazarus executable was rebuild to a different location, because the original location is readonly, this will not be true.The option dialog does the same(IDE/frames/file_options.pas):
The API should have a way to get LazarusDirectory directly. I think it is a missing feature.Yes. LazarusIDE from LazIDEIntf already expose GetPrimaryConfigPath, shouldn't be too difficult to add LazarusDirectory.
Or does it impose some potential problem?No potential problem AFAICS. It's just a getter.
The API should have a way to get LazarusDirectory directly. I think it is a missing feature.
Or does it impose some potential problem?
Ok, ToDoList does not have it. All its settings are on the main GUI form.Quote.... settings .... Tools->Options.When you get a chance, yes please. But its not holding me up now.
IdeIntf has an API for it. I can find an example package that already does it later. ToDoList maybe...
What is holding me up right now is I cannot find a way to read the LazarusDirectory from a package. Must be possible but right now, I am considering reading LazConfDir/EnvironmentOptions.xml - and I'll watch to see who laughs !Can you please add the LazarusDirectory getter. True, it should be in class TIDEEnvironmentOptions which is part of BuildIntf. This setting has no dependency for GUI and may be needed by cmd line tools as well.
Can you please add the LazarusDirectory getter. True, it should be in class TIDEEnvironmentOptions which is part of BuildIntf. This setting has no dependency for GUI and may be needed by cmd line tools as well.
Maybe GetPrimaryConfigPath and GetSecondaryConfigPath should be there, too, but that is another issue.
@davo
It turned out that is already a function named GetParsedLazarusDirectory in EnvironmentOpts. I made it available for packages in trunk/main. Please use it like this:
uses IDEOptionsIntf; var LazarusDirectory: String; begin LazarusDirectory := IDEEnvironmentOptions.GetParsedLazarusDirectory; //... end;
PS: Sorry for the confusion!
Sorry I have been so slow to answer, discovering the joys of CamelCase in a case sensitive OS. Going to have to revisit my Examples list .....
Juha, I have a forked Lazarus gitlab repo, it now contains my worked over ~/examples directory. How do you suggest I submit that 'stage one' to Lazarus, as a pull request or an old school diff file ?I will look at it tomorrow. Today I have other things going on...
But maybe a policy matter ? Its currently called Online Examples (in, eg, the menu item). As its not exclusively OnLine and may never be, is a different name appropriate ? I don't want to call it "New Examples" and at some stage it will be old, any suggestions ?"Example projects" is still very descriptive.
"Example projects" is still very descriptive.
OK, from that I assume that "Stage Two" will have to include removal of the existing Example Window, it already owns "Example projects". I was planning on being a bit more incremental than that, but quite happy to go boots and all.IMO the old Example Window can be removed at the same time the new one is added. Two competing Example Windows will only confuse users.
My fork with the worked over examples is at https://gitlab.com/dbannon/lazarus/-/tree/newexamples, its a branch of my main fork that can track the official one.Sorry but https://gitlab.com/dbannon/lazarus/ does not exist. Under https://gitlab.com/dbannon/ I only see your Laz_Examples project.
OK, the Package now works with the Global Options Window. Not an easy task understanding that I must admit.How am I supposed to test your code if you don't push it?
I will push content up into https://gitlab.com/dbannon/lazarus when we have made some progress with the Examples them selves.
I don't want to make one huge merge, would be a bit scary !Merge into where? The only purpose of your Lazarus fork in Gitlab is to let other people test it. You can do local experiments without forking by just cloning the official Lazarus Gitlab repo. I don't fully understand what is going on.
It will then be easier to strip out existing Examples Window.It can be stripped out any time. I can do it for you if you want. I don't know why you are so attached to it.
It can be stripped out any time. I can do it for you if you want. I don't know why you are so attached to it.
Sigh, we really don't seem to be communicating very well here. I thought I had discussed the model and you were comfortable with it. But obviously not !Yes, I believe there was some work involved. I was eager to see the user experience. Now I pulled you fork and yes, I can see a commit "New Examples Window, old one still exists". I will test it soon ...
The 'dbannon/lazarus/newexamples' branch has all the examples projects in ~/examples cleaned up and metadata added. While two commits it does represent quite a lot of change (and work).
Does it make sense to have screenshot of some example projects? If it does, then you could check for screenshot.png in project directory and show it.Yes, a good idea!
It shows a GUI but no example projects are listed yet.
Shall we apply it to Lazarus trunk (main branch) soon? I will wait for comments from others a while.
Does it make sense to have screenshot of some example projects? If it does, then you could check for screenshot.png in project directory and show it.
Code: [Select]TExampleData.LoadExData - found 0 examples
Lazarus Dir (ie source tree) = /home/dbannon/bin/Lazarus/lazarus-drb/
Lazarus Config Dir = /home/dbannon/bin/LazConfig/lazarus-drb/
Examples Home Dir = /home/dbannon/bin/LazConfig/lazarus-drb/examples_work_dir/
TExampleData.LoadExData - found examples = 1
Lazarus Dir (ie source tree) = ../SW/lazarus/
Lazarus Config Dir = /home/juha/.lazarus/
Examples Home Dir = /home/juha/.lazarus/examples_work_dir/
My Lazarus sources are in ~/SW/lazarus. I start the executable directly from there as "./lazarus &".(Just to be sure, I have just pushed a small change so that the debug statements appear always, not just when there are no projects found. You could 'pull' and re-add the package to the IDE.)It was useful. I test now with my main development repo (instead of your fork), and the GUI finds one example, Beginner/listview. Maube it came from testing your standalone app earlier.
Yes, good idea but maybe not now while the examples are being distributed as part of the Source ? I am thinking of the extra size we would be adding to the source tree, we could double it. But would sure help a user determine if its the project that answers their particular question.True, we must not bloat the distribution more. Instead we should move more examples to an online place.
Lazarus Dir (ie source tree) = /home/dbannon/bin/Lazarus/lazarus-drb/
My version:Code: [Select]Lazarus Dir (ie source tree) = ../SW/lazarus/
My Lazarus sources are in ~/SW/lazarus. I start the executable directly from there as "./lazarus &".
"../SW/lazarus/" is wrong. It should be "../lazarus/" or just "."
Yes, it was a bug in Lazarus code. I fix it in 9f142eef14.OK, so I will definitely need to do some rebasing now :-\
- Projects also from my writable Lazarus source directory are copied to the config dir. They could be compiled in place.Thats intentional. It means that you can have a play with the code, maybe mess it up completely and refresh from the original and start again. Is one of my KPIs.
- The Key Words column for some projects is so wide that the next Path column shifts far away. You cannot even adjust the width manually.Yes, I am not that happy about that, should be able to make it adjustable but not much more can be done as far as I can see. Truncating the keywords seems worse than hiding the path, in practice, no one really needs to see the path anyway. Maybe better to not display it at all ?
- The Category CheckBoxes could all be ON initially. Now they are OFF but all items in the list show anyways.Ah, thats an historical accident, one I should have fixed long ago.
- You could consider using TListViewFilterEdit as a filter control.Hmm, never heard of it before now. Almost no docs. The filtering happens in two separate ways (Category and Keyword) and is performed by the list I maintain in the data unit. I am not sure it can be done in the UI space.
- The source files don't have any license headers. (L)GPL requires such a header.Easily fixed.
Is there a way to download online examples? I guess not yet.Not easily. When you suggested sticking to keeping the examples in the src tree, I concentrated on that approach. The on-line code is in there hidden with some $ifdefs and can be brought back and updated in light of what I know now. But we cannot use httpclient on MacOS to download https files so until that situation improves, I don't see it as a good approach. https://forum.lazarus.freepascal.org/index.php/topic,58392.0.html
OK, so I will definitely need to do some rebasing now :-\Yes, run "git rebase main". Then force push to GitLab.
OK, rebase worked like a charm. I have used it in the past and regretted it (indeed, I tared up my working dir before I started).Regretted because of conflicting commits? Now there is only a small chance for them.
The changes to remove the old Examples Window is not really extensive but it does touch a good number of files. I will rebase frequently from now on ....Your change to lazarus.lpi was not right. You added more lines instead of removing ExampleManager.
Your change to lazarus.lpi was not right. You added more lines instead of removing ExampleManager.Interesting. While I have removed ExampleManger, running a diff against a month old lazarus.lpi indicates that I somehow added ProjectWizardDialog to the lpi file, I did not do so consciously (the local lazarus.lpi is the now current one in my repo, the ~/Downloads/lazarus.lpi is a month old).
I confess I don't always understand the changes that "gitk --all" shows. I attach here a screenshot of how it shows your latest "newexamples" branch. Why are the same commits shown twice? It is not a problem in your commits, I just don't fully understand Git's logic yet.No, neither do I. I think it relates to the rebasing. Looking at some affected files, I see content changes that do not relate to what I did in the first of the each pair of commits. That has to be someone else's commit off in the official branch that appears here during the refresh of the code base.
Other notions: You should remove code straight away instead of commenting it out.Yes, noted. My usual model with a fairly complicated edit is that I comment out code and stamp it with a 'DRB', then I can compile, repeat. Leaving the lines there helps me find related things that might be otherwise left dangling. Then, when I am happy, I grep for the "DRB"s and remove them. In the case you mention, appears I forgot to stamp those lines. :(
CONFLICT (rename/delete): examples/testall.pp deleted in Examples tested, categorised, metadata added, restructured and renamed to components/codetools/codetools.inc in HEAD. Version HEAD of components/codetools/codetools.inc left in tree.
CONFLICT (rename/delete): examples/helloform.pp deleted in Examples tested, categorised, metadata added, restructured and renamed to doceditor/frmabout.pp in HEAD. Version HEAD of doceditor/frmabout.pp left in tree.
Hmm, bad new. Seems I cannot rebase any more.No problem. Moving and modifying files may be a challenge for rebase indeed. I will merge your changes to the official repo through patches.
While I have removed ExampleManger, running a diff against a month old lazarus.lpi indicates that I somehow added ProjectWizardDialog to the lpi file, I did not do so consciously (the local lazarus.lpi is the now current one in my repo, the ~/Downloads/lazarus.lpi is a month old).ProjectWizardDialog was there already. The IDE sometimes adds tags like <ComponentName Value="ProjectWizardDialog"/> etc. for some reason. You can see your own changes easily with gitk.
Gihub has a lot better GUI than Gitlab when it comes to inspecting past commits. Using gitlab, such "what changed when ?" questions need to be answered using git back here at home, on Github, I can browse to the commit and view it directly.)You don't need Gitlab or Gihub GUI for inspecting past commits! There are much better tools for that, especially gitk. It shows a single branch by default and all branches with "gitk --all".
No problem. Moving and modifying files may be a challenge for rebase indeed. I will merge your changes to the official repo through patches.Right, I will remember that. Patches don't take any history with them, much better for this way of working !
Merge requests are not needed. They are clumsy anyways. No modification from my side is possible with them.
....There are much better tools for that, especially gitk.I saw you mention gitk, thought it was a typo ! TCL/TK ? really ?
Congratulations! Your revamped example projects and your new GUI are there now.And thanks for your patience, I have learnt quite a lot. Will now start, time permitting, on the remainder of the examples in the tree. All they will need is an appropriate metadata file added, that should not worry git at all.
One more notion about the GUI: Double-click downloads the selected project but does not open it which is counter-intuitive. A user expects it to open.Agree. I am sure we'll find more problems before this project is finished.
The whole concept of "downloading" a local example project is weird. You should hide the copying process then from a user.
With online examples the word "download" makes sense.
I saw you mention gitk, thought it was a typo ! TCL/TK ? really ?:)
OK, installed, yes it works. But still looks like a TCL/TK app.
I tend to work from the command line where I can and have not looked for a (desktop) git GUI.I don't know whether I like the new structure of the examples folder in the IDE. There is a "top-level" folder "Beginner" which contains all the single mini sample projects that where all in the examples folder of the older version, but now each in its own folder - that's perfect, I like it. But there is also a folder "Components", it contains subfolders for "cell_overflow", "columneditors", "embedded_images", "merged_cells" - all these were contained in a "grid_examples" folder in the old version, and it was clear that all these sample project somehow dealt with the Lazarus grid. This information is lost now. I know that the meta-data of these projects contain the information that they are about grids, but this forces me to use the new example projects windows. So far, I found everything needed from the file system alone. Giving up this feature clearly would be a weakness of the new example system.
Github is pretty good for those situation where a GUI is indicated, examining commits and so on, being on line must be a slower but I have not found that a problem. I'll try gitk for gitlab related things as it seem my {best|only} choice. Thats all good.
OK, now that I know its preferred to generate a patch rather than git merge, I think I will create two branches of my existing gitlab fork, one will show changes to the Package (as mentioned above) and the other will slowly accrue the metadata files in all the examples that exist in directories other than ~/examples
As neither will involve mass renaming of files, rebasing should be safe.
I do not, at present, understand how I would make the new package part of a standard install. I suspect its Makefile and fpcmake stuff ? Not my favorite place to play.
Davo
Github is pretty good for those situation where a GUI is indicated, examining commits and so on, being on line must be a slower but I have not found that a problem. I'll try gitk for gitlab related things as it seem my {best|only} choice. Thats all good.Github and Gitlab are servers. You don't need their web GUI for your development process. I personally use only the bug tracker.
OK, now that I know its preferred to generate a patch rather than git merge, I think I will create two branches of my existing gitlab fork, one will show changes to the Package (as mentioned above) and the other will slowly accrue the metadata files in all the examples that exist in directories other than ~/examplesYou may not need your fork at all soon. I have asked commit rights for you into the official repository. I have duties during the spring and summer and don't want to work as a middle man.
I do not, at present, understand how I would make the new package part of a standard install. I suspect its Makefile and fpcmake stuff ? Not my favorite place to play.We need help with that. Mattias knows the Make systems best.
1. For Unix users, the current system is utterly unworkable if Lazarus has been installed under /usrI am aware of this, but the example subsystem should not force users of other systems in which Lazarus has been installed in a writeable folder (e.g. fpcupdeluxe) to use it. Note that all this is based on an installable package. What if a user does not install the "ExampleProjects" package? He is rather lost regarding examples.
Why have each example in its own directory ?Of coarse, each sample project should be in its own folder. But I don't like all these folders to be at the same level. Before your changes, all the grid examples were inside the equally named subfolder of "examples". This way it was easy to find "all grid" examples at one glance. When this is not possible any more your new example window has a severe problem with scalability.
1. It makes the above possible.
2. Its just plain tidier and allows the beginner to see just what files belong to a given Example.
The prime purpose of these changes was to make it easier for new users. I guess users like yourself were not really considered as needing Examples to be honest.Sure, every effort to make life easier for new users is great. But not every user is a new user. I would not say that I don't need the examples - I am very happy to be able to look how something is solved which I am not familiar with. And on the other hand, I do maintain the examples which are interesting to me and which belong to the components that I maintain. Here the "copy in user space" is useless to me since my fixes are not in version control, and I have extra work to copy it back to git.
I am aware of this (Unix read only issues), but the example subsystem should not force users of other systemsBut the Unix Read Only problem is only one of the reasons that I mentioned. For the "average" user, its a good idea, maybe for you, not so good. But harmful ?
Note that all this is based on an installable package. What if a user does not install the "ExampleProjects" package?Yes, I agree. But I was advised it was 'policy' to use packages where possible. Making Lazarus more modular does make sense.
Is the implication that your examples window supports only the examples distributed with Lazarus?No, the Examples Window searches first the Lazarus source tree then the Lazarus Config dir, that way, picking up any compliant examples that have come in from, eg, OPM. It is my intention to make some metafiles for viable examples I find in, at least the OPM packages I use. Hopefully more.
Before your changes, all the grid examples were inside the equally named subfolder of "examples"...Indeed, some were logically located. Most were not. You obviously feel very strongly about this, I don't so I will restore the ones in ~/examples that I can.
... I do maintain the examples which are interesting to me and which belong to the components that I maintain. Here the "copy in user space" is useless to me since my fixes are not in version control, and I have extra work to copy it back to git.I agree thats a backward step for you specifically. Maybe for others who do maintain some examples. My overall impression was that the examples where, on average, quite unloved. But I wonder if you don't use the example window to find your Example, and I restore the ones important to you, it should be business as usual ?
Sorry for this criticism.....Not at all, I need constructive criticism because I want my contribution to be useful. Yes, my focus is on new users and unashamedly so but we cannot, in that process, make things harder to maintain. So, important that I be told if I am getting off track in any way.
....
In the course of time, I have accumulated many components which I have stored for testing and also as an archive for possible components in programmes.
I therefore regularly search my archive for examples and demos to get an impression of the functionality of the respective component.
... examples have hardly any description, are poorly maintained, possibly still based on old standards...All the example presented in lazarus_3_0 where checked to be functional and have, as a minium, a one liner description. But thats all I am afraid. Very many do have bugs (all software has bugs !) sometimes noted in the description. There is, as you mention, massive room for improvement!
I would be happy to discuss this.Excellent !
Where should I report bugs?
- Listview - anchor right, +10 missing
- Listview, sorting does not work
- Listview, examples from OPM are not found (Win10, Laz3.0)