14 replies to this topic

[shajul]

Why not include some very useful libraries in the default AHK_L installation? This would make many scripts compatible out of the box, and new script writers wont have to worry about specifying the dependencies.
Also, "Ask for help" can also be simplified, eg. a lot of text/csv queries come up frequently. If TF or other libraries are included, it will be much easier to just show beginners the code required.

Just my thoughts. The individual library authors opinion will also have to be paramount.

Example libraries (in no specific order)(incomplete list for example):GDI+ standard library 1.43 by tic - by tic
argp v3.0 Argument Options Parser - by Tuncay
COM Standard Library, ComUtils when available - by Sean
ini v1.0 - Basic ini string functions - by Tuncay
TF: Text file & Variables/String Library v3.3 - by HugoV
TT() - Full-blown ToolTip Library and Struct() - by HotkeyIt
Command Object function library (conflicts?) - by sinkfaze
Vista Audio Control Functions v2.1 - by Lexikos and many more..

PS: This topic may belong to General Chat (if so, mod please move)

[SoLong&Thx4AllTheFish]

There are two initiatives at the moment:

Ahk Standard Library Collection by Tuncay
<!-- m -->http://www.autohotke... ... ght=stdlib<!-- m -->

SALT - Standard AutoHotkey Library Transfer by a few ahk members
<!-- m -->http://www.autohotke... ... light=salt<!-- m -->
and <!-- m -->http://code.google.com/p/salt<!-- m -->
(seems halted for the time being)

Discussion (one of a few threads)
<!-- m -->http://www.autohotke... ... ght=stdlib<!-- m -->

[shajul]

Thanks a lot for taking your time to show me SALT. Great initiative indeed.

Ahk Standard Library Collection by Tuncay

This does not yet support AHK_L.

[Tuncay]

What sort of support do you mean, just the missing libraries? Yes, I have omitted all Ahk_L stuff yet. But the script to explore the database is itself compatible with Ahk_L.

[fincs]

This is all very funny because myself I was thinking of a packaging format for StdLib libraries. Here's what I've thought:[*:19nf6j84]Packages (which are 7z archives renamed to .ahkp) contain a manifest.json file, a Lib/ folder and (optionally) a Doc/ folder.
[*:19nf6j84]The contents of the Lib folder are copied to %A_MyDocuments%/AutoHotkey/Lib.
[*:19nf6j84]The contents of the Doc folder are copied to somewhere else, like %A_MyDocuments%/AutoHotkey/Lib/Doc/<package-name>.Here are some manifest examples (the third one is of a yet-unreleased library!):

{
	"longname": "ComDispatch",
	"shortname": "ComDispatch",
	"author": "fincs and Lexikos",
	"description": "ComDispatch allows an AutoHotkey script to create an IDispatch COM object. This object can then be passed to VBScript or JavaScript, allowing it to call functions defined in AutoHotkey.",
	"version": "1.0",
	"forum": 66559,
	"links": [
		{ "name": "Documentation", "file": "docu.chm" }
	]
}

{
	"longname": "Vista Audio Control Functions",
	"shortname": "VA.ahk",
	"author": "Lexikos",
	"description": "VA provides Windows Vista and 7-compatible alternatives to some SoundSet/SoundGet subcommands, as well as some additional features that SoundSet/SoundGet do not support.",
	"version": "2.1",
	"forum": 23792,
	"links": [
		{ "name": "Documentation", "file": "VA.html" }
	]
}

{
	"longname": "Progress Dialog",
	"shortname": "ProgressDlg",
	"updateurl": "ahkp://www.autohotkey.net/~fincs/packs/ProgressDlg",
	"author": "fincs",
	"description": "Wrapper around the Windows built-in progress dialog.",
	"version": "1.0",
	"links": [
		{ "name": "Documentation", "file": "docu.chm" },
		{ "name": "Example", "file": "Example.ahk" }
	]
}

I plan on not supporting AHK_Basic at all.
Feel free to suggest anything.

[SoLong&Thx4AllTheFish]

@fincs: why not work on salt?

Edit: the problem with packages is that not everyone will use your specified format for distribution (I wouldn't for example as I can't be bothered, my fault I know so take no offense)

[fincs]

I personally feel Salt is too complex for its intended usage and doesn't reuse existing services. Most libs (if not all) only consist of some files that are copied to the Lib folder and some documentation. As for providing a hosting service, there's already ahk.net. Packages could be uploaded to a special "packages" folder which autohotkey.net would index and provide a search service. Installation and management of StdLib packages would be done by a simple AutoHotkey script.

As for making packages, the beforementioned utility would also have a wizard to make them.

If there isn't a standarized distribution format, it's impossible to make a StdLib management system.

[SoLong&Thx4AllTheFish]

If you haven't already read the discussion I linked to above for some background info, salt would at least have some quality control before being accepted, as I understand your above post everyone would be able to create a stdlib entry so to speak.

Edit: dR also posted a demo script where a forum post could be used as an entry, many stdlib items are only posted as code in a (top) post / thread in the forum.

[Tuncay]

These are similar thoughts.

Why not INI?

My first question is, why not use INI as meta format? XML is too hard to implement to fully support it. JSON is easier and nice. But INI is the most easy and known format, with good support in every area. Someone could decide todo anything with the meta data format and then INI is the best choice in my eyes. It is the only format recognized by native AHK commands. Another format is not needed (unless takes full advantage of the format).

Comparison JSON VS INI

JSON:

{
   "longname": "Vista Audio Control Functions",
   "shortname": "VA.ahk",
   "author": "Lexikos",
   "description": "VA provides Windows Vista and 7-compatible alternatives to some SoundSet/SoundGet subcommands, as well as some additional features that SoundSet/SoundGet do not support.",
   "version": "2.1",
   "forum": 23792,
   "links": [
      { "name": "Documentation", "file": "VA.html" }
   ]
}

Same information in ini format.
INI:

[AHKLIB]
longname=Vista Audio Control Functions
description=VA provides Windows Vista and 7-compatible alternatives to some SoundSet/SoundGet subcommands, as well as some additional features that SoundSet/SoundGet do not support.
version=2.1
author=Lexikos
forum=23792
shortname=VA.ahk
links=Documentation: VA.html

Why ZIP?

Next, I would suggest to use standard .zip format, instead any special program. I use 7zip and highly recommend others, its not that I would not like it. But this way, you do not force anyone to use any program. The one or two bytes (ok, in fact some more ) you save are not worth doing it.

It is well thought out. That day I created my library collection I was at same consideration and choosed not to bug anyone with any program. Again, standard ZIP is natively implemented in Windows and all packer and unpacker understands it. Even programming languages like Python have standard libraries supporting ZIP only (just as an example).

On my side, I see a need to copy the documentation too. And for some more data information in the meta file, look into my collection. You may find some useful ideas. In example I miss some information about the dependency or requirements, if there is one. And what about the license of each script? Some licenses requires the copy of the license text too. Very important in my eyes. No respect the license is not an option to me.

[fincs]

@Tuncay: thanks for your input.

Why not INI?

INI doesn't support multiple levels of information, and as such implementing "complex" things such as the link list would be cumbersome. Multiple lines of text in an entry is also a no-no. There's also the parsing speed and code size: IniRead is slow as it opens and closes the file (no in-memory operations!) every time it is used. Some INI parsing libs already exist, but they're no match to poly's (very) elegant json.ahk library.
As for ease of use, your point is invalid as the JSON would be automatically generated by the wizard. Also, you wouldn't need to run the wizard everytime you wanted to release a new version of the library because the options and info you chose would be saved to a file.

Why not ZIP?

ZIP could also be a choice. But anyway, the package manager would include a copy of command line 7zip (or even a DLL) for both extracting and creating packages, so it's again an invalid point.

On my side, I see a need to copy the documentation too. And for some more data information in the meta file, look into my collection. You may find some useful ideas. In example I miss some information about the dependency or requirements, if there is one. And what about the license of each script? Some licenses requires the copy of the license text too. Very important in my eyes. No respect the license is not an option to me.

Maybe you missed it, but my current format supports documentation (and examples, basically anything in the Doc folder).
I had dependency support in my notes, but those libraries had no dependencies at all so you didn't see it at all
As for licenses, some licenses (GPL, LGPL, BSD, etc) could be hardcoded into the package manager, and if you wanted to use a different license the full license text would be embedded into the manifest or a separate file (*.ahkp.license). This part still needs some thought.

EDIT: And of course, thanks for your sterling effort to collect the forum's StdLib libraries.