pAHKlight - Your Lightweight Guide to AHK libs+classes+tools

[ahk7]

pAHKlight - Your Lightweight Guide to AutoHotkey libraries, classes, functions and tools



Note: this is just to see if there is sufficient interest in setting up and maintaining something like this.
The database currently only has 10 entries to illustrate the usage of pAHKlight and the database (a simple INI file)

A package or module: a software component for accomplishing a particular thing. (wikipedia)

Source: https://github.com/hi5/pAHKlight
Download: https://github.com/hi5/pAHKlight/archive/master.zip

Many programming languages have so called package managers to easily manage the installation of libraries. AutoHotkey lacks such a standard solution at the moment.

pAHKlight is a possible intermediate solution until a more competent system is setup, it is not meant as a real package manager, but its purpose is to help find libraries, classes, functions and tools quickly, especially for those unfamiliar with AutoHotkey.

The pAHKlight script is short and the format for the "package database" is kept very simple so even a novice user should be able to update (both the script and) the database. This will hopefully ensure that both the pAHKlight script and database are kept up to date by posting new additions for the database on the forum or pull requests on Github.

Once you have found a "package" of interest visit the source or discussion page for more detailed information and (usually) instructions how install and apply the "package".

As a reminder you can tick the checkbox in front of a package if you use it and it will remember that for the next time so you can quickly see which packaged you are already using.

Things pAHKlight can not do:

• download, install or update libraries, classes, functions and tools
• check which (versions of) libraries, classes, functions and tools are currently installed

Things pAHKlight should not do:

• replicate the content of a forum by including all posted scripts.

INI Format

The INI format used in pahklightDB.ini has the following structure

Code: Select all

   [Sequential number]
   name=short
   fullname=full
   author=
   type=lib|class|function|tool
   source=URL
   forum=URL
   category=
   ahkversion=
   description=

More details at https://github.com/hi5/pAHKlight

So I'm looking for contributors to prepare INI entries for the "database":

- via this forum thread or in Ask for Help
- via GH pull request

If there is sufficient interest I could transfer the GH repository to the ahkscript organisation so other people can commit to the database as well.

I don't foresee many updates to the pAHKlight script apart from adding the "check for updates" routine so the latest database can be downloaded from the GH repository.

[Ampeter]

AHK really, really, REALLY needs something like what you are doing. I really miss the old Standard Library Collection (you can still find it inside the autohotkey megapack). It had a very informative and easy to use gui and you could launch included examples and browse notes to get a quick idea of what each lib did. Maybe you can use it as an inspiration?



There is also a really comprehensive (and up to date!) compilation of AHK libraries and tools here. It covers everything from ahk classic to ahk2.

Something like this should really be a cornestone of ahk. At the very least it would help with duplicated efforts (often someone codes something that has already been done because they didn't know a library existed!)

[ahk7]

I really miss the old Standard Library Collection ... It had a very informative and easy to use gui and you could launch included examples and browse notes to get a quick idea of what each lib did. Maybe you can use it as an inspiration?

pAHKlight is a very bare bones version of Tuncay's Standard Library Collection script - basically just the descriptions which are fully searchable. Tuncay's script was nice but it is also is way too much work to maintain by including all the files, examples, docs etc. Nobody in their right mind would want to do that again (no offense). Then again, so far nobody seems to be interested in pAHKlight either so I doubt it will go any further then this post

[joedf]

I actually really like this idea, I know that George2 is maintaining a repo "ahk-libs" or something,
Maybe if I talk to him him about it, we could merge something with ahkscript group on githib and setup this lib distribution service thought github, then pull the info directly from there...
I will check on this. I am glad that you brought this up.
Regards

[timeFlies]

I would really like to see this idea come to fruition. But like was said, keep it bare-bones, containing only basic descriptions and links to where libraries/classes can be downloaded (even if it's just a link to the forum page).

If it auto-updated every time it was opened that would be good too.

Edit: And if it could be packaged with AutoHotkey itself, that would pretty much guarantee its success.

Edit: How would you pronounce that? "PAK-lite" is the way I read it.

[joedf]

well ive made an "alpha" version of my idea... right now, im using george2's repo, but in the future it could be put into the official ahkscript github repo. here is a screenshot. right now it's basically a bare-bones Github browser... (it uses the github API). The idea is that there is no more "DataBase" file (sorta), now all we have to do is just, have the libs/repos cloned or forked all into one repo, then the rest, metadata, etc could all be pulled directly from github.
regards

[ahk7]

@joedf: The problem I have with that solution is that the script is no longer simple to maintain (I haven't seen it of course but you may be using httprequests etc which is rather complicated for newbies*) which is one my design goals AND although there is plenty to be found on GH there is far more to be found on the AHK forums and personal websites.

Copying scripts to GH with(out) the Authors consent, knowledge and influence is not a good idea. Some script authors like to retain control over their code and also update it on their preferred location which may be a forum post or personal website (I could name a few important ones here already). So if you start to copy script(s) to GH your are ALWAYS are behind the current version, the author looses control and the user is directed to the "old" version which doesn't do anybody any favours.

I'm not saying your idea is bad - and of course there is nothing stopping you to develop your idea further - but I would not work on it myself or change pAHKlight to go that route. That doesn't mean there couldn't be database entries for material residing in George2 GH repo provided that is the only available resource for a particular package, otherwise it would have to point to the original source.

* re newbies: Say you/I loose interest in this and a new AHK-er wants to maintain my version might be easier to grok compared to a httprequest / com reliant script.

Edit: How would you pronounce that? "PAK-lite" is the way I read it.

Yes. It is a play on words using AHK, package, lightweigth / Packing Light (as in travel light)

[joedf]

You are right. I completely agree... Hmm I think I'll contribute to your idea then.
But, i still think there should be a possible way to have a centralized database of some kind... Hmm
What if library submission were to be done through ahkscript.org directly? All libs could be listed in a single page then each of them could have a forum post like usual... I think if ideas here.. Sad, there has to be a better way, what do think? Any new ideas? (hopefully?)

Regards

[kon]

What if the INI was a page on the wiki? Then everyone could edit it, and you could just copy and paste it into you personal INI file to update it.

[ahk7]

Yes it could be on the Wiki - downloading the Wiki page(s) and parsing them would be quite easy as you can simply have the "database" displayed as a code block which would mean it is plain text which is easy to extract from a downloaded html file. (I just tried to make an example but the Wiki is closed for new pages/editing I think, probably due to spam?)

The drawback I see: if the "database" becomes a bit larger editing the Wiki page will become slow(er)? Then again if it does become large it is relatively easy to split up into several pages for example by limiting each page to 200 entries or so and then move on to the next page - the script can simply download them in sequence to build the local database (pahklightDB.ini).

The central database can still be at GH (the ahkscript organisation - It could be moved over there) or I could allow others to commit to my repository.

Edit: added poll to first post

[joedf]

@kon & ahk7
i say! it's absolutely brilliant!

edit: ps (voted 1 & 2) and may I, with your permission, make a copy/fork in ahkscript/github account? also ive added you the group

[hoppfrosch]

Started testing yesterday - looks already usable. Unless I personally would like to see a "big solution" (like Tuncays or maul.esels), I must admit that these solution need a big maintainance effort - which no one is willing to burden for a long period ... So let's start with this small solution.

The biggest problem I see is to keep the database up to date - either we have central database maintainer(s), or the people would be easily able to update the database version on theit own ...

I have a few suggestions/questions for the beginning:

• Don't use the ini-sections as content of the name column in GUI. Unless there might be several libs/functions/classes which do have the same name (for example "MD5") you cannot have several ini-sections with the same name. Therfore renaming the current key "name" to "fullname" and introduce a "new" key "name", which holds the current section title, might be a better idea.
• It should be avoided to get too many tags; they should be standardized. Different people would use "Regular Expressions" or "RegEx" or even "RE" for the same thing. This makes it difficult to find all RegEx related functionality ... Therefore it might also be a good idea to have a limited list of allowed tags. New tags should only be allowed if they are considered (by the maintainer of the database) to be useful.
• Before adding entries to the database, there should be some quality assurance:
  • Are all required fields filled out? For example commit e1a65a25 does not contain a value for source, forum and tags ....
  • Is the provided data valid? For example: are the provided links reachable? Or: Are all used tags valid? (see suggestion above)
• Enhanced keys/New Keys
  • Allow links in key author (for example author=hoppfrosch (https://github.com/hoppfrosch) or something similar)
  • New key: Validated(?), having a date-timestamp as value. This can be used to identify "old" entries within the database and should be updated by database maintainer from time to time (script-based? Checking validity of links ...)
  • Keys indicating the AHK-compatibility (Version: 1.0.48-1.1.xx-2.x-all, 32bit-64bit-all, UNICODE ...)
• ... (lots of more ideas)

Another idea for "database":
Using a storage place (wiki, github, own subforum ...) where each function/library/... has its own "business card" (On Wiki: page, on github: file, on subforum: thread). Those business-cards should have a standardized contents (required fields to be provided).
Having this as a base, a collector script could iterate over all business cards and generate the database automatically. The "database creator" script might do all the validation checks on the business cards.

I think using github as a storage place for the business cards would be ideal, as it's easily scriptable: Each business card might be a single markdown or json file with several keys and values as contents (as for example the current ini-file has). The database collector use githubs REST-API to retrieve the business cards (including all properties (last updated ...)) and automatically generate the database from them and recommits the database to github. If someone knows some javascript, ahkscript.github.io could be used to host the database as a "comfortable" webpage ... (just fantasizing )

[vasili111]

AHK definitely needs to sort all usermade scripts and functions and make good documentation. But it will not be standard library, it will be collection of scripts and functions. I think AHK also needs real standard library not only collection of scripts.

[joedf]

hmm... yes. All we need is the metadata eg. description, name, links, etc. So, what we really need is a form and have it save it automatically etc..
So technically, a php-webpage will do just fine i think ill start writing one... but i think that it is true that every submission should be revised... before being accepted...

[ahk7]

I think AHK also needs real standard library not only collection of scripts.

Many people discussed it, one person actually did it (Tuncay) and it didn't stick. I don't think the AHK installer itself should include a "standard library" but a central repository in one form or another is nice. This is just the bare bones version that just might get some momentum.

[ahk7]

Started testing yesterday - looks already usable.

Thanks for trying - fixed the empty SKAN md5 entry - got caught up in trying to make sense of the posts on the other forum as they don't look right due to forum upgrade and forgot to delete it before comitting it - I won't make any further additions to the database as we have a nice test sample now to finish the main script and decide on a final format.

The biggest problem I see is to keep the database up to date

Indeed, and in that light your remarks below are interesting but also add additional work which we might do in future but perhaps should not do right now. Lets build a Version 1 database first and see how far it goes - if there is no interest apart from 2-3 people there is no point in putting in a lot of effort.

I have a few suggestions/questions for the beginning:
[*]Don't use the ini-sections as content of the name column in GUI.

Alright, as noted in the documentation in case of a duplicate entry simply add a (serial) number to the name, for example JSON2, JSON3. So what do you suggest to have as section heading instead? A sequential number like Tuncay had?

[*]It should be avoided to get too many tags; they should be standardized.

I was in doubt about the tags, I thought and still am thinking about ditching them. Standardising wouldn't be to difficult and simply checking for allowed tags only is not a problem either. The reason I kept it in for the time being is that I was contemplating to have a treeview next to the listview with the tags so you could click them and have it act as a filter or perhaps a listbox next to the searchbox. Removing them saves people the trouble of comming up with good tags as well.

[*]Before adding entries to the database, there should be some quality assurance:

• Are all required fields filled out?
• Is the provided data valid? For example: are the provided links reachable? Or: Are all used tags valid? (see suggestion above)

Extracting the urls from the database and then using a link checker is not very complicated so could be done at regular intervals.

[*]Enhanced keys/New Keys

• Allow links in key author (for example author=hoppfrosch (https://github.com/hoppfrosch) or something similar)

OK that might be a nice addition, if an url is present a link in the Gui should be made available for the user to click and visit the profile/website of said user.

[*]New key: Validated(?), having a date-timestamp as value. This can be used to identify "old" entries within the database and should be updated by database maintainer from time to time (script-based? Checking validity of links ...)

That might be something worth doing if we'd start to use your cards idea below. Those cards that don't validate are excluded from the main database and marked for Revision/Inspection.

[*]Keys indicating the AHK-compatibility (Version: 1.0.48-1.1.xx-2.x-all, 32bit-64bit-all, UNICODE ...)[/list]

Personally I'm only interested in AHK 1.1+ material, that is why a lot of material from Tuncays collections should no longer be included in pAHKlight (for example the excellent AHK Basic COM library by Sean - there is simply no use for it any longer) - As v2 is still in beta there is a) very little AHK2 specific material and b) once v2 is actually more or less finalised it would simply be a matter of starting a new database with specific v2 material and allowing the user to load the AHK 1.1 database or the v2 database.

If something is specifically 64 bit only you could just as well mention in at the start of the description or in the full name: "MD5 - (64bit)" for example. And a user can of course read the forum or perhaps ask the author to make a ansi+unicode version of something.

Another idea for "database": Using a storage place ... its own "business card"

I think that is actually a nice idea when the database becomes larger. Creating individual records - which should be files I think (just for speed reasons, not on the forum as only one person could edit a post and the Wiki is a bit slow if you start downloading hundreds of pages) - would indeed make it easier to maintain and check. Of course it will be very easy to split the currenty INI database into individual files and then build an automatic validator and database builder script etc.

Thank you for your input so far.

I have the following questions:

1A: Should we keep the tags or ditch them?
1B: If kept they should be standardized as you say, but should they be incorporated in the Gui as search filter either as treeview of listbox?

2: Should we allow Author link in author name as suggested above? + A link in the GUI if we do.

3: What to use as section name instead of the current [name]? Sequential numbers?
[record1]
[record2]
[record3]
etc?

4: Should I add to the following to the main script?
4A: A "Try Google" button which takes the search query and runs Google Custom search

General:

My main idea is still to keep things as simple as possible to get something worthwhile - once it has some momentum expanding the system behind it (indiv. cards, validation, etc) could be done. We can make small helper scripts already (checking format, simple Data entry Gui etc)

[joedf]

1: limit of 5?
2: why not?
3: hmm entry numbers would work I think, same idea like database IDs
4: let's try it out, if it's not worth while...

[hoppfrosch]

1a: I'd like to see them - unless they should be standardized as suggested. In my opinion searching anything is so much easier with PROPER tags
1b: no preference

2: I'm biased - as I suggested this ...

3. No special need for sequential numbers (anything goes). What I meant is: don't use the contents of the section name to display on GUI column name - use the contents of a (new) key "name" to fill the GUI (If we keep the current scheme, using "MD5", "MD5_1", it looks like weighting. At least for me ...)

4. let's try it out, if it's not worth while...

Keys indicating the AHK-compatibility (Version: 1.0.48-1.1.xx-2.x-all, 32bit-64bit-all, UNICODE ...)

I still think its a good idea to introduce this field. It's easy to provide the data at the time a new entry is added to the database - but a pain to do it at a later date. It does not cost to much effort and keeps the doors open ...

thanks for trying - fixed the empty SKAN md5 entry - got caught up in trying to make sense of the posts on the other forum as they don't look right due to forum upgrade and forgot to delete it before comitting it - I won't make any further additions to the database as we have a nice test sample now to finish the main script and decide on a final format.

No need to excuse - errors happen. It only shows the neccessity to do some automatic validating the new entries before adding then to the official database ...

[timeFlies]

1A: Ditch the tags. Having a tonne of fields and what-not to fill out is going beyond the definition of "bare-bones" and is where it gets more difficult to maintain. Instead, require meaningful and succinct descriptions, in which case those tags would be included in the description somewhere anyway.

1B: Keep the UI as it is. I feel that including a tree-view would add little value to pAHKlight in the end.

2: Author link, yes, if one is provided by the author themselves. Otherwise no.

3: What hoppfrosch said.

4: No. Entirely unnecessary and would be one of those features that few people use.

pAHKlight should be kept as light-weight and easy to maintain as possible, functioning only as a searchable list of available tools/functions, etc. without adding a bunch of extra stuff.

Something that occurred to me, however, is a "Last Updated" column, though I'm not sure how well this would be kept up to date. My first instinct is to not include it because of that very reason.

Ultimately, if this is successful, I'd like to see this included with the AHK install itself, though I'm not sure how Lexikos and others would feel about this idea.

[nnnik]

How about "forced" libs.
Let me explain:
I think the GDI+ lib is a library that everybody should have.
Because an massive amount of my own scripts require this one.
It'd be great if everybody had this lib, so it should be downloaded and installed automatically.