63 replies to this topic

[Chris]

Most of us want AutoHotkey to continue to grow in features and usability. However, the project's goals have become too numerous and ambitious for me to manage on my own. By volunteering your time and expertise, you can accelerate development and improve the site's quality. Here are the things most needed:
[*:31s4escp]Script Reviewer: Categorize and/or score the scripts and functions posted in the forum. Publish and maintain the results in the wiki or in some other site. If you're not comfortable scoring the quality/usefulness of each script, just the categorization alone would be a big help. Jon's Catalogue of All Scripts is a great starting point. As Ace_NoOne said, While searching the forums, I often stumble across many highly useful scripts and functions... However, these resources are often hard to find...
[*:31s4escp]Standard Library: Collect scripts and functions for the "standard library", which is planned to be distributed with the program for use with #Include. Work with the original author (if possible) to test and document each function.
[*:31s4escp]Integration with Editors: Maintain the installation scripts for PSPad and other editors so that syntax highlighting and other features continue to work as new versions of each editor are released.
[*:31s4escp]Recommended Editor: (Update: SciTE4AutoHotkey v2 is now available.) Implement strong syntax highlighting and utility integration (such as Intellisense) in a free editor such as SciTE or PSPad. That editor could then become the recommended editor to be mentioned prominently on the site (and possibly distributed with AutoHotkey). It's likely that 80% of users either do not know that syntax highlighting exists for AutoHotkey, or believe it's more complicated than it's worth to install it.
[*:31s4escp]New macro recorder: Create a replacement for AutoScriptWriter that has more capabilities and better multi-language support. There are some ideas in the topic An update for AutoScriptWriter.
[*:31s4escp]Wiki: Participate in the Wiki, such as by creating more tutorials.
[*:31s4escp]C and C++ Developers: Design ideas and code are always welcome, especially ones central to the missions of AutoHotkey (automation, hotkeys, and GUI). For other ideas, see Planned Features.
[*:31s4escp]Other areas: If you have an expertise in another area that would benefit the project or the community, don't hestitate to mention it.If you wish to volunteer for any of these things, please post here, or e-mail <!-- e --><a href="mailto:[email protected]">[email protected]</a><!-- e -->.

[Moderator note - de-promoted from sticky status - MacroMan!]

[toralf]

I will continue to work (if accepted) on:
- Integration with Editors: In my case PSPad. A new version of my install script is coming up. With simpler interface (most options are hidden, but are available).
- Recommended Editor: I still have to finish up the Toolbar, I hope it will become a very useful and easy to customize utility. As for a distro with AHK, I guess we should talk to Jon (author of PSPad). But maybe an install script that downloads the editor and installs it would be sufficient.

And a few notes to the other:
- For the Standard Lib, I might have some functions. But this is not my main focus, and I'm sure otheres are more into these things.
- For the Script Review: I guess it will be hard to manage such a list in this forum or in the wiki. Especially when it comes to rate the scripts.

[PhiLho]

But maybe an install script that downloads the editor and installs it would be sufficient.

I agree. Whatever the "official" editor is chosen, I don't want to have to download it whenever I update AHK. I don't want to download it at all, except as a separate download, out of curiosity...

Standard Lib: I have a file of useful code snippets were I collect tips found (or given) on this forum. Most is probably of general interest.
Now, to contribute to this lib, we need to have some hints on what is wanted.

Some suggestions: DllCall helpers with base Unicode handling (DllCallStruct.ahk, BinaryEncodingDecoding.ahk), binary read/write of files (BinReadWrite.ahk, ReadWriteUnicodeText.ahk), advanced clipboard code (SetClipboardData.ahk, ShowClipboardImage.ahk), to name only some of the include files I made for myself and others.

[majkinetor]

IMO most important should be standard library as it extends ahk functionality.

I think we should create simulation of namespaces and some tutorials of how to write "isolated" scripts. I created one such page at wiki that lives in API namespace. So, when you see missing API_XXX functions in my scripts you know where to go to take it. There should be math, string, web, process and other namespaces released on the wiki

One problem with wiki is that you can't make people download the file but he always need to copy/paste it. It would be nice to change wiki pages or create some template that will extract the code section in given template and offer "save as" dialog with addopted name. For instance, here would be nice to have "save as" button that will offer saving as API_Draw.ahk. I guess this can possible be done via JS, but I am not sure.

I also suggest Wiki to be main working grounds for new scripts and tutorials as cooperation can exist there. Possibly some template can be created for script catalog.

[PhiLho]

I agree, the Wiki is under used, including by me...
No need for special button for downloading. After all, we already copy/paste in the forum, or download code hosted elsewhere, often on AutoHotkey.net.
The only problem with the later solution is that code is then proprietary, ie. cannot be improved by somebody else.
Perhaps Titan can create a public AutoHotkey.net account?
The other problem is that it has to be moderated, some people could abuse it.

[Thalon]

@Scriptwriter
I would have to spend little time to add keyboard-handling (so buttons & keyboard is included). But I will not find the time actually to add support for more controls.
I've set a reminder-termin to me, so I'll post it at the weekend...

Thalon

[majkinetor]

The problem with copy/paste will become more pronounced as more people are involved.

Imagine this scenario: 20 namespaces exist that are updated frequently by the users. So at any day you would have to download some changed includable script again and save it localy as new scripts might use newer versions of includable scripts. If many scripts are changed frequently you will have to copy/paste every script again very often....

Much better mechanism it use some kinf of automatic updater for "standard library". This can be achieved in following way:

There should be standard in creating wiki pages witch contain includable scripts of standard library. That way, parser script can be created that will update local copy parsing the html page. Simple bounding comment may be enough, or single <pre> section. Regular expressions in AHK can do the rest in easy parser script that will have list of all wiki pages containing standard library and that will save them localy mimicing "file structure" on the wiki.


That can be realtively easy created with no extra effort, just standard needs to be addopted first.

[PhiLho]

There is a risk with such "standard" library on a Wiki: anybody can change it. It is nice, but risky, one can find a function name isn't explicit and change it. Result: all scripts depending on it are broken...

[majkinetor]

Well, thats theory, in practice I doubt such things will happen.

Also, I guess there can be some protection mechanism on wiki to prevent such scenario. Library changes can be discussed here then allowed. If library is changed by persoanl initiative not discussed on the forum, we can return back the changes. Library additions are not script breaking but those should also be discussed for the sake of library sophistication and organisation.


After all, wikipedia functions well and yet, the same things you mention apply to it.

[Chris]

Thanks for the replies.

I will continue to work (if accepted) on:
- Integration with Editors: In my case PSPad. A new version of my install script is coming up. With simpler interface (most options are hidden, but are available).

Thanks. I've been meaning to switch to PSPad as my main editor, but haven't yet made the time to do so.

But maybe an install script that downloads the editor and installs it would be sufficient.

I agree. Whatever the "official" editor is chosen, I don't want to have to download it whenever I update AHK. I don't want to download it at all, except as a separate download, out of curiosity...

If the recommended editor turns out to be something rather large, I agree that it should be an optional download via: 1) Optional, larger version of the installer; or 2) The installer could download and install it if you choose that option during installation; or 3) A separate download, but has easy, hassle-free setup so that casual/new users of syntax highlighting (like me) can get started with it quickly.

Standard Lib: I have a file of useful code snippets were I collect tips found (or given) on this forum. Most is probably of general interest.
Now, to contribute to this lib, we need to have some hints on what is wanted.

Anything that's useful to a lot of people: Database interfaces, text manipulation functions, encryption, new GUI controls (like Shimanov's custom hotkey control, which otherwise will probably stay buried in the forum, largely forgotten), etc.

Of particular interest are substitutes for planned features that haven't yet been implemented, or features that aren't quite important enough to be built-in but are still high in demand.

Some suggestions: DllCall helpers with base Unicode handling (DllCallStruct.ahk, BinaryEncodingDecoding.ahk), binary read/write of files (BinReadWrite.ahk, ReadWriteUnicodeText.ahk), advanced clipboard code (SetClipboardData.ahk, ShowClipboardImage.ahk), to name only some of the include files I made for myself and others.

Those sound like good candidates. The problem is that they need someone willing to test, document, and package them up in a semi-professional way.

Thanks.

[JSLover]

I've been meaning to switch to PSPad as my main editor...

...what is your current main editor? I use Notepad2, but it don't support AHK syntax...or the ability to add support for it...but the source code is available & I've been meaning to dig into it. I told it to highlight .ahk files with the C# (C pound {no I don't pronounce it the other way}) highlighter & it works somewhat, but it highlights C# keywords when those keywords mean nothing in AHK...but it highlights my comments so it works for me. It's the best-looking Notepad Replacement...as soon as I downloaded it I started hacking it into shape...it now look about 100% like normal Notepad & it uses the Scintilla Editing component & does stuff I wanted Notepad to do...in any case it's a great lightweight editor, but I've been looking for a real coding editor...last time I checked out PSPad it had horrid word wrap bugs...I think those are fixed now, so I need to give it another shot...

[*:uki9qu42]Standard Library

...I'm hoping my Base.ahi gets in the standard lib...I have alot more potential functions I haven't compiled into it yet tho...one of which is gonna be a super-Debug() function...debug scripts in any way imaginable...ok, not line-by-line step thru, but normal AHK code can't do that...but I mean debug to Tooltip, MsgBox (boring, not accurate), File, Gui Edit Field...

Speaking of the standard lib can we have Reference only include/mode...I think it would help, since people can include at the top & it not affect the auto-execute section...among the other suggested benefits of that mode...

[Chris]

I'm still using metapad just from habit. Thanks for the info about Notepad2.

can we have Reference only include/mode...I think it would help, since people can include at the top & it not affect the auto-execute section...among the other suggested benefits of that mode...

Maybe, but I don't wish to work on any features that support the standard library until we have one or more serious volunteers to populate it (or I make time to do so myself).

Thanks.

[JSLover]

When we adopt some naming scheme you can fix it to obay the rules.

[*:2vq754c2]You don't make the rules
[*:2vq754c2]I name my functions the only way necessary...you prefix all your API-converted functions with API_* but why would you expect someone to need API_SomeFunc AND SomeFunc...you should just dump the Windows API functions into AHK without a prefix...Base.ahi will have some or alot of Windows API functions with no prefix...

Standard library will need to have adequate naming schme.

...I do agree here, but my switch/case functions are...1) only until real switch/case gets implemented...2) naming them JSLover_switch/JSLover_case is overkill...I fully expect/hope that a future version of AutoHotkey WILL break that part of Base.ahi, at which time I will delete it...the only other thing currently in Base.ahi is my A_Screen[Width|Height]WA() workaround...I actually want builtin vars A_ScreenWidthWA/A_ScreenHeightWA...or perhaps A_Screen[Left|Top|Right/Width|Bottom/Height]WA...so yes, some stuff might need a prefix, but not everything...oh ok, my d() & deref()...deref, well derefs vars...what name should I give it?...how many other people need to reinvent my wheel?...d() dumps vars in varname(<varcontents>) format, for easy debugging...it's meant to have a short name...& people can still use d as a var...

[Thalon]

I've taken up the ScriptWriter and got good results yesterday evening in a short test. I've to spend some more time on it before posting a new version.


Another idea that came up to my mind last friday was a coordinated translation of the helpfile in other languages.
In the german forum there are a lot of users with english-problems and this takes much time to support.

So I wrote a little tool on sunday that is able to translate a CHM if feed with the correct translation-data and checks differences between help-versions.
The problem at this system is that the data has to be collected at a central place. Maybe it is done via email to a volunteer, but the best solution would be to have a CVS for it

My program does it this way:
1) It extracts the HTM-Files of the CHM (including the needed project file)
2) You enter the parts to translate and the translated sentences into it (saved as associated in a ini-file)
3) Press the "Translate"-Button and it replaces all existing data
4) Recompile a CHM with changed sources

5) If a new version of help is there, just extract it and press the "compare"-button to show the new parts in help-file (this would not be necessessary with CVS).

Or do you have any ideas how to solve this best? AGU will test it (maybe) this week, but the problem exists that all translated data will have to be merged by himself (of course, some merges can be done automatically, but many of them have to be manual).

Should I open a new topic for it?

Thalon