AutoHotkey Community

Great!

Only now I see this! Please add me: cyruz-git

Add me pls - evilC

Both of you have been invited. Don't forget to make yourself a public member!

http://ahkscript.org/boards/viewtopic.p ... =936#p6888

GeekDude wrote:Both of you have been invited. Don't forget to make yourself a public member!

http://ahkscript.org/boards/viewtopic.p ... =936#p6888

Thank you! Done

Kudos to GeekDude
Thanks, I cant do it from my phone !

Is there anybody who "moderates" the ahkscript-organization on github?

Even as there are only a little more than a dozen repositories, it already starts to get disorganized and confusing.
* There are different functional categories the repositories belong to: AHK-Scripts, Forum-Modifications, Documentation and misc tools (like sublime editor addon) - all of them unordered and not clearly dedicated to a category
* There are repositories which were once applied as placeholders - but never got any contents (https://github.com/ahkscript/international)
* no clear naming convention
* unsufficent description of repositories

All of these contribute to the complexity of the ahkscript-organization on github.

It's a pity that github does not offer the posibility to better organize the repositories within an organization (no Tags, no folders .... ) - the only way to get the repos organized is to have multiple organizations (as far as I understood)

I would like to see "this" better organized, to make the grade of "promote the use of AutoHotkey." (as claimed on the ahkscript-organization startpage) - I would like to see this done soon to keep the work low ...

What do you think about introducing more "AHKScript"-related github organizations (for example ahkscript-docu, ahkscript-forum, ahkscript-tools) to get the repositories better organized? (or do you have any other ideas?)

Yes, I have to agree somewhat.
I certainly think either breaking it down to separate groups or having some kind of naming convention would make sense.

I am a little wary of changing project names though, as that might break people's includes (well it may break the way I do mine - an include file in the AHK lib folder with like #include path\to\github\repo\script.ahk)

Another idea: Maybe http://ahkscript.github.io/ can be used to offer a better organized access to the repositories (by offering a page with the repositories categorized and or tagged - linking to the repositories ...)

@hoppfrosch: won't that suffer the same fate as all "other" attempts e.g. lack of structure, no interest to maintain it. Should pAHKlight be transferred to ahkscript? Would it help?

Guest wrote:@hoppfrosch: won't that suffer the same fate as all "other" attempts e.g. lack of structure, no interest to maintain it. Should pAHKlight be transferred to ahkscript? Would it help?

That's what I'm also afraid of .... I don't think transferring pAHKLIght would solve those basic problems.

hoppfrosch wrote: What do you think about introducing more "AHKScript"-related github organizations (for example ahkscript-docu, ahkscript-forum, ahkscript-tools) to get the repositories better organized? (or do you have any other ideas?)

recently there has been a bunch of new repositories created in the 'ahkscript' github account. these codebases should be on people's personal accounts, not on the 'ahkscript' account.

There is a new repo here https://github.com/ahkscript/AutoHotkey-Editors

The information here http://ahkscript.org/docs/commands/Edit.htm#Editors is outdated and links to non-functioning threads (due to loss of ahk . net data)

The documentation could link to this repo - details in the readme - feel free to create issues or add links/editors/etc.

I'm working on at least one install script by way of example.

just as a notice, that I am aware of the issue hoppfrosch mentionned.
I will to get this resolved hopefully tomorrow. We'll see.

not to pick on evilC, but does anyone else think that all of his recent repositories should be hosted on his personal github account? his stuff is no doubt useful, but if everyone posts their personal scripts to the organization account, it will just get out of control. doesn't seem like thats the proper place for them. jmho

I have checked a few of the things he posted.
https://github.com/ahkscript/WinStructs - A good Idea.
https://github.com/ahkscript/AHK-SizeOf-Checker - I'd personally remove this.

In the last week or so, I have started numerous repos, it is true.

However, everything I added to ahkscript is not every project I created or updated - I have another 20 projects of my own, I just happen to have been very prolific recently.

The rule of thumb I have been using is that if I feel the project is not purely my own pet thing, but something I feel belongs to the community, I add it to AHKscript.

WinStructs very much fits that bill. Only one project needs to exist that decodes windows structures. There is no other lib to do this (AFAIK) than _Struct, and nobody else had started a _Struct definition library, so it made sense for the community as a whole to be able to push updates of their own accord.

AHK-SizeOf-Checker is essentially a unit test suite for WinStructs and _Struct. It belongs wherever WinStructs belongs.

AHK-EXE-Swapper IMHO belongs as a community thing - it is essentially the flip side of the coin to AHK2Exe.

I also pushed AHK-vJoy-Library, as the bulk of this code was not written by me, I was just maintaining it. It has since been superseded by my new CvJoyInterface, so I thought the legacy code should belong to AHKscript.

AHK-SizeOf-Check may fit better as part of the WinStructs repo, in a sub-folder or something.

AHK-EXE-Swapper is something that 99% of people who use AHK will never find themselves needing. That being said, it's rather annoying to have to run a program whenever you want to change exes, and may very well mess with more dynamically-written scripts that are already running.

I'd suggest making it a script pre-processor that you set as the shell association for .ahk files. It'd quickly check the top of the script for a "shebang" telling it which version of AHK to use, and if omitted uses the default. Then it'd actually run the script through that AHK version. That way, dynamic scripts that use A_AhkPath will still function correctly, you'd be able to have the script specify its own version, and there'd be a comment in the source file that says what version. It'd be a win-win-win situation, that'd work out of the box with the notepad++ RunMe plugin and (as far as I can tell by source snooping) AHK Studio. I'm not sure about S4AHK, but I'd assume it'd work with it too.

Here's what i suggest :

- put "size-of" into WinStructs
- put "AHK-vJoy-Library" and other Legacy code into a "ahkscript/legacy" repo
- AHK-EXE-Swapper is nice... not sure of the verdict here... Love GeekDude's idea of a #!Shebang
- "AHK-Studio" not sure...
- "Boost-ahk", "international" and "libcrypt.ahk" were planned too far ahead... Mark for deletion.

AHK Studio is on, and will likely remain on maestrith's github.

I'm not sure what Boost-AHK and international are for, exactly, but libcrypt looks like a great I'dea. I think it'd work out as a general to/from repo, with short functions for converting to/from things like Base64, and URI/URL, HTML, ROT13, etc. Mind if I put some functions in it?