Code Librarian enhancements.

[BigChimp]

The external libraries hmmmm. I fill that I'm going to regret adding this. Its a lernaean hydra situation, every library comes with its own dependencies and so on and so forth...... it is going to be a hell to maintain.

Well.... you could just specify one level of dependency - on the main library, say lazautoupdater. If that turns out to need synapse.... well, that's supposedly documented in the lazautoupdater instructions anyway, so you wouldn't need to specify that.
(Unless you're offering to write an fpcup extension that installs all dependencies for a given code snippet for the user )

[minesadorada]

Re: dependencies - I was thinking of something simpler.

If I bring up a snippet that uses code in (for example) Zipper then CL simply displays the fact.  In other words, as the snippet is displayed, the tags attached to the snippet entry are displayed as information only.

The purpose is to ensure that a developer doesn't copy/paste the snippet, and then it doesn't run because of an invisible dependency or some other undeclared incompatibility.  That would undermine CL as a trusted resource.  As a side-benefit, assigning snippet tags would make targeted searching easier for the user.

Probably worth coding in a few spare tags - you are bound to think of more once you start to use them

This talk of Wiki integration, IDE integration a public database and auto-downloading is an exciting prospect to say the least!

I hope the project goes ahead as planned, because I can't wait to use it.  I'm fed up of spending lots of time searching the forum and wiki for obscure bits of code.

Thanks for taking this on, taazz - it's a really worthy project for the community, and I'm willing to help in any way I can.

For instance, I can start a CodeSnippets section in the Wiki if you like - it can be populated while you get coding.  I would need to know your chosen category tree though in order to get started.

[taazz]

well although I can understand th erequest and I'll probably end implementing it personally I see to value in it for pascal snippets. It is far faster to add a uses clause on top of the snippet than to select the depended units and libraries from a list, then again if it is something the community like to see I have no problem adding it, its just an extension to the OS and widget set support. if one is implemented copy paste and change labels is not a big deal.

So I'll add it to my to do list with a lower priority for now and see how things go in the other fronts first.

As for the wiki I have no opinion what so ever at this point, I'm going to first try and implement the 1st level requests (tags, searching, filtering, multi tab interface, in general anything that does not add extra requirements) and then I'm going to look at the 2nd level requests.

Now the hierarchy is open for debate as everything else in this thread having the LCL VCL tags in there to define requirements wil free up some space on the folders for a more generic build lets start with 2 or 3 root categories lets say Algorithms, GUI, LAN-WAN, Graphics, Math and System should get things going and lets see how far the community would like to go with it.