Standard/User libraries for automatic function inclusion

AutoHotkey Community
Let's help each other out

FAQ

Memberlist

Profile

Standard/User libraries for automatic function inclusion
Goto page Previous 1, 2, 3, 4, 5, 6 Next

AutoHotkey Community Forum Index -> Wish List

View previous topic :: View next topic

What should be the names of the standard- and user-library directories? (Regardless of the name, they are SEPARATE directories in two different locations.)

\Library

10%

[ 2 ]

\Lib

42%

[ 8 ]

\Include

15%

[ 3 ]

\Includes

[ 0 ]

\Functions

[ 0 ]

Different names even though they're in different locations

31%

[ 6 ]

Other

[ 0 ]

Total Votes : 19

Author

Message

foom

Joined: 19 Apr 2006
Posts: 386

Posted: Sun Jun 17, 2007 12:05 pm Post subject:

First of all good to hear that the functions are included recursively.

Now about the vote. IMHO as useless as any other vote before.

I hope

Code:

C:\Program Files\AutoHotkey\Library\

means

Code:

%A_DirOfAHKexe%\Library\

and not

Code:

%A_ProgramFiles%\Library\

because not everyone installs his progs into the A_ProgramFiles folder.

Chris
Site Admin

Joined: 02 Mar 2004
Posts: 10480

Posted: Sun Jun 17, 2007 12:28 pm Post subject:

foom wrote:

I hope [it's] %A_DirOfAHKexe%\Library\

Yes. Even if you don't install AutoHotkey, the stdlib will still work because it will default to the same location as AutoHotkey.exe.

toralf wrote:

I still think StdLib/UserLib is the better naming for the folders.

The problem with those names is that they have very little meaning at-a-glance. Based on site statistics, I think 90% of AutoHotkey users are not regular visitors to the forum. Except for programmers, most people wouldn't even recognize that "lib" is short for "library".

toralf wrote:

Specially for this forum, since it is easier to direct a noob to a specific directory with a unique name.

It should be rare that anyone needs to be directed to the standard library. And it seems just as easy to find when named Library as when named Stdlib.

toralf wrote:

In the initial poll you had StdLib/UserLib as individual options for the poll. IIRC it had the majority of votes.

Some of the voters misunderstood. They thought it was a choice between having only one library and having two. There will always be at least two (though the userlib will typically be empty).

toralf wrote:

Same names might lead to misunderstandings. It is easier to talk about UserLib and StdLib in your posts and the folders on the disc have that same name.

Does anyone else want a new poll? I was planning to release this in a couple days, but we can delay it a day or two to make the right decision.

Thanks.

SKAN

Joined: 26 Dec 2005
Posts: 6264

Posted: Sun Jun 17, 2007 1:15 pm Post subject:

Chris wrote:

toralf wrote:

Same names might lead to misunderstandings. It is easier to talk about UserLib and StdLib in your posts and the folders on the disc have that same name.

Does anyone else want a new poll? I was planning to release this in a couple days, but we can delay it a day or two to make the right decision.

Names do not really matter for me but same names would be confusing.
I am in favour of UserLib / StdLib. If you find it cryptic it can be
Standard Library and Extended Library or anything you deem fit.

Thanks. Smile

corrupt

Joined: 29 Dec 2004
Posts: 2436

Posted: Sun Jun 17, 2007 1:54 pm Post subject:

Chris wrote:

toralf wrote:

]I still think StdLib/UserLib is the better naming for the folders.

I agree but I don't think that Library is much better unfortunately as it doesn't describe it's usage. The name Include, on the other hand, is obvious and although different from #Include since it automatically includes files, does the same thing as #Include. IMHO, it's so obvious that I'm surprised that there's a poll. Honestly though it doesn't really matter that much to me in the end so you could forget about logic completely and call it purple smurf 1 & 2 if you'd like...

Sean

Joined: 12 Feb 2007
Posts: 1397

Posted: Sun Jun 17, 2007 2:02 pm Post subject:

corrupt wrote:

The name Include, on the other hand, is obvious and although different from #Include since it automatically includes files, does the same thing as #Include.

I can't agree more here with corrupt.

Chris
Site Admin

Joined: 02 Mar 2004
Posts: 10480

Posted: Sun Jun 17, 2007 2:50 pm Post subject:

I do like "Include". It's almost preferable to "Library", though library seems slightly more meaningful. However, most voters seem to prefer "Lib" even though there have been few comments about it. To me, Lib seems too esoteric. Wikipedia says, "lib: in computer science, short for library". But most non-programmers probably wouldn't know that.

Laszlo

Joined: 14 Feb 2005
Posts: 4078
Location: Pittsburgh

Posted: Sun Jun 17, 2007 3:00 pm Post subject:

Chris wrote:

In a future version, there will be a way to customize the names and locations -- perhaps via some new directives and some kind of auto-include file that gets included into every script.

Maybe the registry? If keys StdLib/UserLib are not set, use some standard locations, otherwise use the specified directories. Other behaviors of AHK can be controlled via registry entries, too, to be temporarily overridden by command line parameters.

corrupt

Joined: 29 Dec 2004
Posts: 2436

Posted: Sun Jun 17, 2007 3:09 pm Post subject:

Laszlo wrote:

I like the idea except I can see problems with portability. I sometimes run AutoHotkey from a USB drive that's not always connected to the same PC. If I plug in to someone else's PC that has AutoHotkey installed and has the registry entries then functions that I have in the Include directory (or whatever it ends up being named) on the USB drive will be ignored and overridden by the registry entries.

Tuncay

Joined: 07 Nov 2006
Posts: 383
Location: Berlin

Posted: Sun Jun 17, 2007 3:15 pm Post subject:

I agree with corrupt. This could be done with an INI settings file, found in AutoHotkey folder. So, any script run with that AutoHotkey.exe you want, would access to YOUR configuration file.

Titan

Joined: 11 Aug 2004
Posts: 5390
Location: /b/

Posted: Sun Jun 17, 2007 3:35 pm Post subject:

How about having the paths as resource strings which can be changed with a hex editor/Reshacker in the same way AutoHotkeyGUI class names can be changed? _________________

corrupt

Joined: 29 Dec 2004
Posts: 2436

Posted: Sun Jun 17, 2007 3:35 pm Post subject:

Chris wrote:

I do like "Include". It's almost preferable to "Library", though library seems slightly more meaningful.

I don't mind "Library" as a name either (sounds a bit more sophisticated) but, for non-programmers, a Library is a place of reference commonly used to locate documentation on a particular subject or a place to find other literature. The content in this directory would not be for that purpose and would be active content as opposed to reference material. The only similarity it has to a library really is that something is "looked up" but even that isn't 100% accurate since the files aren't being searched. AutoHotkey is only searching for the name of the file. The name Include is already an established name for the action that will be performed. It seems to fit quite well. To have something auto-included in a script then give the file the same name as the function and place it in the Include folder. This has the advantage of simplifying the documentation (possibly just adding a few lines to #Include in the help file) and clearly describing what is taking place.

Laszlo

Joined: 14 Feb 2005
Posts: 4078
Location: Pittsburgh

Posted: Sun Jun 17, 2007 3:36 pm Post subject:

Tuncay wrote:

This could be done with an INI settings file, found in AutoHotkey folder. So, any script run with that AutoHotkey.exe you want, would access to YOUR configuration file.

Yes, it could be better, but it is also slower (needs to open and parse another file). AHK's installer should not overwrite an existing INI file. If there is no INI file, all the documented defaults would be used.

The question is if most of the users would trade an always present delay for the ability to run AHK from a USB stick, with scripts, which even in this case, do not explicitly name their includes. It seems to be a better tradeoff to use the registry, but explicitly name your includes in scripts run from a portable device.

Another alternative was to first search the directory of the script for its includes, maybe followed by %A_ScriptDir%\include. Only after them go search the standard library locations. This provides the largest flexibility.

corrupt

Joined: 29 Dec 2004
Posts: 2436

Posted: Sun Jun 17, 2007 3:37 pm Post subject:

Titan wrote:

How about having the paths as resource strings which can be changed with a hex editor/Reshacker in the same way AutoHotkeyGUI class names can be changed?

Not a bad idea but having to modify the exe file sounds a bit extreme and makes changing the setting very inconvenient. Especially for non-programmers. This would also have to be changed every time there is a new release.

corrupt

Joined: 29 Dec 2004
Posts: 2436

Posted: Sun Jun 17, 2007 3:59 pm Post subject:

Laszlo wrote:

Tuncay wrote:

This could be done with an INI settings file, found in AutoHotkey folder. So, any script run with that AutoHotkey.exe you want, would access to YOUR configuration file.

Another alternative, which I think Chris had mentioned that I think is probably the best solution is with additional options to #Include using <>. I might be overlooking something but there doesn't seem to be any reason to override the Standard Library path. The path being a subdirectory in AutoHotkey.exe's folder seems to be acceptable and still works well for portability. The problem seems to be with the User directory. A simple solution could be something like:

Code:

#Include <%A_ScriptDir%\Include>

where the path between the <> characters gets designated as the User directory to use. This could be convenient to ignore files in the User directory too:

Code:

#Include <> ; ignore User directory

If it is desired to override both paths then maybe something like this:

Code:

#Include <standard-%A_ScriptDir%\standard>
#Include <user->

Titan

Joined: 11 Aug 2004
Posts: 5390
Location: /b/

Posted: Sun Jun 17, 2007 4:26 pm Post subject:

corrupt wrote:

Well the idea is that non-programmers wouldn't even need to change it, otherwise Chris would have a different system. It shouldn't be so difficult to create a post-install macro to hack the exe, just decompress and binary search & replace. Don't forget that you can modify AutoHotkeySC.bin for compiled scripts so it won't be a new concept for many users. Registry is not an option because it breaks portability and INI is simply too slow.
_________________

Display posts from previous:

	AutoHotkey Community Forum Index -> Wish List	All times are GMT Goto page Previous 1, 2, 3, 4, 5, 6 Next
Page 3 of 6

You can post new topics in this forum
You can reply to topics in this forum