Proposed New GUI API for AutoHotkey v2

[Miguel7]

In a word: Awesome!

Once I found out AHK had object-oriented capabilities, I started writing my scripts that way; and man, it was a huge help! I'm used to OOP from nearly every other language I've ever programmed in, and I find it helps keep things more organized, more flexible and still as simple as possible. And the GUI API is great as-is but I think it would definitely benefit from a switch to OO for the same reasons (organization, flexibility and simplicity). So yeah, I definitely think it's a good move for v2.

As far as it being newbie-friendly or not, I don't think it'll make that big a difference. For example, "Gui.Maximize()" or even "Gui.AddLabel("Username:")" - no question what's going on there. Not to mention, I used OO stuff in languages like JavaScript and VBA long before I knew any OO concepts (or even what OO was ).

Code: Select all

// JavaScript
document.getElementById("someButton").click();
// I had no idea that I was using the document "object" and that it had "methods" called getElementById and click - but I figured out how to make my script work.

Code: Select all

'Visual Basic for Applications (VBA)
Range("A1").Value = "Some string of text"
Range("B1:C1").EntireRow.Delete
'I didn't know I was using the Range "object" or changing its "properties" and calling its "methods" - but I became the Go-To Guy for Excel VBA macros at work.

These may not be the best examples, as they're not AHK and not really great examples of OOP, but when I was a total newbie these were the languages I was learning. I didn't know the jargon, but I was able to learn what to do. And from there, it was really just a matter of practice.

But getting back to AHK, there is one object I would like to see added, that being a "panel" (a container control that can hold other controls or be drawn onto HTML-Canvas style). Examples of this object are Java's "JPanel" and the .Net "WinForms" Panel objects. I'm sure it's been asked before, and idk if it'd be too much to ask, and I'm sure it's been asked before, but it'd sure be great if possible.

But anyway, thanks again for all the hard work you guys put into AHK, and keep up the great work!

[Coco]

Not entirely related to the thread but somehow connected, @fincs, are there similar plans for Menus?

[fincs]

Not entirely related to the thread but somehow connected, @fincs, are there similar plans for Menus?

Indeed is it connected. The logical thing to do is to redesign the Menu system (and make Menus be objects), but that IMO has to wait because the Menu command contains special handling for the Tray icon which may be a good idea to separate into its own Tray set of commands (TraySetMenu, TraySetIcon, TraySetTip, etc). It needs more thought.

[lexikos]

TraySetTip - not to be confused with TrayTip...

[joedf]

Confucius say, too confusing.

[fincs]

Yeah, I hadn't thought of that. What about TrayMenu, TrayIcon, TrayText? Or even TrayToolTip? It is after all a tooltip that is displayed when the mouse is over the Tray icon.

[geek]

I'm very eager for something like this to exist, but I'm also wary of learning it until I'm reasonably sure that it'll either be integrated, or an active fork with it will be maintained

[fincs]

I've updated the OP once again with new binaries that include the latest changes from v2.0-a057-428b040.

[lexikos]

Just thinking about...

Putting aside whether moving to object-oriented APIs is really what's best for the average user, [...]

Is there any built-in functionality or change that would be needed to make this easier to do (in script)?

By "make this easier" I mean to facilitate scripts like AFC, solving these sorts of problems:

[For AFC,] many ugly workarounds had to be used to deal with old-fashioned patterns such as associated variables, g-labels or the way TV_ and SB_ and LV_ functions identify the control they operate on.

For instance, replacing the TV/SB/LV functions with objects. ListView and TreeView being as complex as they are, I think that a shift to an object-oriented API for just those controls would be easier to swallow than for the entire GUI API.

As for associated variables, I've wondered if perhaps controls should just have names. However, the Gui Submit pattern is still sometimes useful. Actually, I think that associated variables aren't a problem as such; there are just a few issues when not using an associated variable, like:

• A_GuiControl returning blank or ambiguous text -- it could return a HWND instead (it probably should, which is why I'm reluctant to add A_GuiControlHwnd in v1).
• GuiControl/GuiControlGet requiring the Gui name to be specified even when given a control HWND -- this is being fixed in the next v1.1.x release.

I'm not sure exactly how g-labels posed a problem, but perhaps the latest test builds provide a solution.

[evilC]

I feel that the GUI should stay basically as it is for now.
With the new changes in the test builds, from what I can tell it appears to be perfectly possible to do usable OOP Guis with a minimum of fuss.
I think AHK will always need simple way of doing GUIs and the present system provides that.
I think we should concentrate on getting decent libraries written, and make the odd tweak to the core code in order to make Guis more easily wrappable in classes.

If/when we decide that wrapping with libraries isn't cutting it any more, we will probably have a better idea of the direction we want to go.

Here is some code from a system I am working on. I haven't fully explored the possibilities and/or limitations yet, but I am really liking the syntax - the same as AHK(For ease of transition), but with objects. If I can wrap all the Gui commands in this way, I think it could be a real winner.

Code: Select all

; An example instance of a CGui class to show how to use it.
Class MyClass extends CWindow {
    __New(){
        ; Call base method of class to create window
        base.__New()
        this.GUI_WIDTH := 200
        ; Start using GUI commands
        this.Gui("Margin",5,5)
        ; Add some text, dont bother storing result
        this.Gui("Add", "Text", "Center xm ym w" this.GUI_WIDTH, "Persistent (Remembered on Reload)")
        
        ; Add an Edit box, store a reference on this
        this.myedit := this.Gui("Add", "Edit","xm yp+20 w" this.GUI_WIDTH,"ChangeMe")
        ; Call custom INI routine to tie this Edit box to a settings value.
        ; This command is likely to be unique to your implementation
        ; It sets the current value of the control to the value from the settings file, and sets up an event to write settings as they change.
        this.myedit.MakePersistent("somename")
        ; Also set a g-label for this Edit box. Note that this is independent of the Persistence system
        this.GuiControl("+g", this.myedit, this.EditChanged)

        ; Add a Button
        this.mybtn := this.Gui("Add","Button","xm yp+30 w" this.GUI_WIDTH,"v Copy v")
        ; Wire up the button
        this.GuiControl("+g", this.mybtn, this.Test)    ; pass object to bind g-label to, and method to bind to
        
        ; Add an edit box, but don't make it persistent
        this.Gui("Add", "Text", "Center xm yp+30 w" this.GUI_WIDTH, "Not Persistent (Lost on Reload)")
        this.myoutput := this.Gui("Add","Edit","xm yp+20 w" this.GUI_WIDTH,"")
        
        ; Add a child window
        ; Use GuiOption method to set parent, so we can pass the object instead of the HWND
        ; Note that we can chain commands.
        this.ChildWindow := new CWindow(this, "-Border").GuiOption("+Parent", this)
        this.ChildWindow.Gui("Add","Text", "Center x0 y40 w" this.GUI_WIDTH, "CHILD GUI")
        this.ChildWindow.Gui("Show", "x2 y150 w" this.GUI_WIDTH " h100")
        
        ; Show the main Gui
        this.Gui("Show", "h260","Class Test")
    }
    
    Test(){
        ; Copy contents of one edit box to another
        this.myoutput.value := this.myedit.value
    }
    
    EditChanged(){
        ; Pull contents of edit box with .value
        this.ToolTip(this.myedit.value, 2000)
    }
}

[fincs]

I'm not sure whether Proposed New GUI API for AutoHotkey v2 covers ListView functions yet.

LV_/TV_/SB_ functions have been directly converted into methods of ListView/TreeView/StatusBar objects.

However, the Gui Submit pattern is still sometimes useful.

Gui Submit is useful in v1.x because the only other way to retrieve the value of a control is using an incredibly clunky GuiControlGet command. Not anymore in my Gui API, since it's a trivial ctrl.Value (and it is a get/set property, meaning it works exactly the same way as a variable).

Actually, I think that associated variables aren't a problem as such

Associated variables are a problem as such, since controls that don't have one are treated as second class controls which are more difficult to manage. It is not possible to bind an object field to a Gui control. It makes no sense to maintain a special purpose variable binding mechanism only for Gui since there already exists a more general purpose mechanism: assigning an object reference to a variable.

I'm not sure exactly how g-labels posed a problem, but perhaps the latest test builds provide a solution.

The latest test builds indeed eased the problem of g-labels, essentially turning them into g-functions.

With the new changes in the test builds, from what I can tell it appears to be perfectly possible to do usable OOP Guis with a minimum of fuss.

Except the fuss is not in any way minimal. You had to write your own 175-lines wrapper library to do away with complexities stemming from control management, Gui handle management, "current Gui" management and event handling.

I think AHK will always need simple way of doing GUIs and the present system provides that.

The main design goal for my proposed Gui API was to be as simple as possible and as equivalent as possible to the old Gui API. I'm not sure if you have read the whole thread, but it is not necessary to write a class in order to use a Gui object. Check out the examples in the OP, none of them use classes. What's even more, object command syntax makes for even "easier" Gui usage. The only time it cannot be used is to receive the control object from gui.AddCtrl. I suppose that could be worked around by reintroducing vVarName and repurposing it to store the reference to the control in the specified variable.

I think we should concentrate on getting decent libraries written

That's a terrible idea. Currently I count at least 3 Gui wrapper libraries. Since people disagree on how they should work, scripts would be written using different wrapper libraries that work in wildly different ways. This would be extremely confusing to people who are trying to understand AutoHotkey code, and would add unnecessary layers of complexity.

[lexikos]

Associated variables are a problem as such, since controls that don't have one are treated as second class controls which are more difficult to manage.

If the premise of your argument is that GuiControlGet is "incredibly clunky", I think I'll have to disagree. You don't need "complex workarounds" for that; you just need a single line for each time you want the value of the control. If there are other issues I haven't already covered, please explain.

It makes no sense to maintain a special purpose variable binding mechanism only for Gui since there already exists a more general purpose mechanism: assigning an object reference to a variable.

Or assigning a HWND to a variable. There's no need to force the object-oriented approach.

Since people disagree on how they should work, [...]

You're right: people disagree on how the GUI API should work. With the forceful way that you express your opinion, it seems that you want to force your idea of "the right API" on everyone by making it built in.

What I want is to identify the problems with the current API before making any final decisions. I am not convinced that a complete paradigm shift is the best solution.

[evilC]

That's a terrible idea. Currently I count at least 3 Gui wrapper libraries. Since people disagree on how they should work, scripts would be written using different wrapper libraries that work in wildly different ways. This would be extremely confusing to people who are trying to understand AutoHotkey code, and would add unnecessary layers of complexity.

3 Gui wrapper libraries is too much?
But we have none (finished) AFAIK that utilize the new function / onmessage binding techniques, which can seriously decrease the complexity of these libraries.

We haven't even fully explored what is possible yet, and already you cry "too much"?

Also, I am against launching v2 with a new GUI.
It would mean that updating existing v1 scripts would become a lot more work.
Give the community some time to port v1 to v2, then change the Gui at a later date if we need to.

[guest3456]

Also, I am against launching v2 with a new GUI.
It would mean that updating existing v1 scripts would become a lot more work.
Give the community some time to port v1 to v2, then change the Gui at a later date if we need to.

the idea of v2 is to introduce the features that would break compatibility with v1

it would be stupid to launch v2, and then break compatibility at v2.5 etc to change Gui

seems both you and fincs have a personal vested interest and are just voicing opinions which favor your self made solutions. but theres nothing wrong with that, especially since this is fincs' thread with his proposed solution anyway

[evilC]

it would be stupid to launch v2, and then break compatibility at v2.5 etc to change Gui

Why?

Most of the changes in v2 are syntactical - cmd, parm, parm changes to parm = func(parm).
In this case, it is not hard to convert a v1 script to a v2 script as you are just copying and pasting some parms around. often, In fact it would quite prob simplify your code (embed commands inside expressions like the rest of your code).
Therefore, if we launch v2 with Gui as-is, then it would be easier to persuade people to move over as the migration path is simple and purely beneficial.

I would not even be against having v2 as syntax fixes, then v3 as a GUI overhaul.

I think making a decision on the direction to take with GUIs when we have the option of having a play and maybe even mocking up some systems (As I and Fincs have done) to see what people like and give them a chance to try it out before a decision is made.

[guest3456]

it would be stupid to launch v2, and then break compatibility at v2.5 etc to change Gui

Why?

for the reason i said in the sentence before. you are already breaking compatibility with the introduction of v2. now you plan to break it again?

[evilC]

Yes.
Why are you proposing two major changes at the same time?

As it stands, for most of the changes in v2, if you want to convert a v1 script to a v2 script, you can go through line by line and follow a simple set of copy and paste operations to convert that line, and the script would have a high chance of working.
In fact, it would quite likely be possible to write some functions like myfunc somecommand(input, ByRef output, optionalparam := "", [...]) such that in order to convert many v1 scripts, all you would need to do would be to include the functions and go through and change cmd, parm, parm to cmd(parm, parm) and it would work with the same parms in the same order and write output to the relevant parm.
Then people have an easy way to tell if a script is a no-brainer to convert. In fact, code could probably be quite easily written to parse a script and swap commands for functions - it's not like commands can be embedded in expressions and be hard to find - they will be sitting there all on their own line - that's the main reason we want them gone.

The easier people can migrate from v1 to v2, the bigger the uptake of v2 will be, and we will still see less fragmentation of the scene, which is already an issue with autohotkey.com / ahkscript.org. v2 is basically about the move to expression syntax - let's not muddy the waters with unnecessary changes to one subsystem (A major one at that) while we are making essential changes to the syntax of the language. Make the important change first, see if it works well, then consider how to approach the subsystem overhaul.

Things like GUIs can be fixed in the short-term through libraries. A fundamental change of parser syntax less so. Let's not force something on the community that could impede the uptake of expression syntax.
This is vital to the health of AHK IMHO - once we lose that nasty mish-mash of languages feeling, AHK will shake of some of the whiff of "Not a proper programming language" that currently lingers around it.

[fincs]

If the premise of your argument is that GuiControlGet is "incredibly clunky", I think I'll have to disagree. You don't need "complex workarounds" for that; you just need a single line for each time you want the value of the control. If there are other issues I haven't already covered, please explain.

Yes.

Code: Select all

GuiControlGet var, myGui:, someControlName
MsgBox %var%
var .= "test"
GuiControl myGui:, someControlName, %var%

; vs

MsgBox %someControlName.Text%
someControlName.Text .= "test"

There's no need to force the object-oriented approach.

There's no reason to maintain an approach that only benefits extremely simple Gui scripts and makes maintaining bigger Gui scripts considerably more difficult. Well-designed object oriented interfaces are not inherently difficult for newcomers to grasp. Besides, as I've said before, my proposed API tries to provide direct translateable counterparts to the current one; meaning simple Gui code will continue looking similarily simple and working in essentially the same way.

With the forceful way that you express your opinion, it seems that you want to force your idea of "the right API" on everyone by making it built in.
(...)
What I want is to identify the problems with the current API before making any final decisions. I am not convinced that a complete paradigm shift is the best solution.

No. My intention is merely trying to defend my idea of a better Gui API, and convince others that it is a sensible thing to include in AutoHotkey v2.
The biggest problem with the current API is that it tries too hard at abstracting management details. Managing multiple Guis is cumbersome and inconsistent since the Gui namespace is completely separate from the normal variable namespace, and it requires either ugly syntax or selection of the "default" Gui for the thread. Writing and managing multi-Gui scripts is not an easy task, and this is demonstrated by several popular scripts including SmartGUI Creator, Pulover's Macro Creator and AHK Studio that unfortunately contain a good amount of Gui-related spaghetti code. The event handling system introduces complexity in the form of a good number of built-in variables that should have been implemented as function parameters (also affecting code & documentation size); moreover, expansions to the Gui system (specifically the Custom control type) have relied on ugly workarounds to fit the current model. Control management is similarily messy, especially in the LV/TV/SB area. The current system of managing multiple LV/TV/SB's or in multiple Guis is not intuitive and also confusing for newcomers. Many if not all of these problems and limitations could be fixed by applying a moderate amount of object-oriented design.

3 Gui wrapper libraries is too much?
But we have none (finished) AFAIK that utilize the new function / onmessage binding techniques, which can seriously decrease the complexity of these libraries.

3 Gui wrapper libraries, at least. More have been made in the past. The changes in the test build indeed decrease complexity, but in the end not by a huge margin due to how the current Gui API inherently works. FYI, it used to be even worse than when AFC was written since referencing controls by HWND did not exist, neither did anonymous Guis exist.

Also, I am against launching v2 with a new GUI.
It would mean that updating existing v1 scripts would become a lot more work.
Give the community some time to port v1 to v2, then change the Gui at a later date if we need to.

Except converting v1.1 to the current form of v2 is already quite a daunting task if the v1.1 code isn't written carefully; and changing the Gui code is trivial compared to other changes.

the idea of v2 is to introduce the features that would break compatibility with v1

it would be stupid to launch v2, and then break compatibility at v2.5 etc to change Gui

Exactly.

In this case, it is not hard to convert a v1 script to a v2 script as you are just copying and pasting some parms around.

The changes are much deeper than that. The semantics/parameters of many commands/functions have changed, e.g. the string functions.

In fact, it would quite likely be possible to write some functions like myfunc somecommand(input, ByRef output, optionalparam := "", [...]) such that in order to convert many v1 scripts, all you would need to do would be to include the functions and go through and change cmd, parm, parm to cmd(parm, parm) and it would work with the same parms in the same order and write output to the relevant parm.

Making a v1 to v2 converter has already been tried, and it didn't go very well. Oh, and this was before many substantial changes were introduced in v2.

v2 is basically about the move to expression syntax

No. In the words of Lexikos, AutoHotkey v2 aims to improve the usability and convenience of the language and command set by sacrificing backward compatibility. This is definitely not restricted to syntax changes. There can be non-syntax changes that improve usability and convenience, such as a Gui API redesign.

AHK will shake of some of the whiff of "Not a proper programming language" that currently lingers around it.

As I see it, the current Gui API probably contributes to that whiff of "Not a proper programming language".

[evilC]

OK, so maybe it wouldn't be as easy as I had hoped to make a converter, but still, I converted a bunch of stuff to v2 not so long ago, and it was as easy as replacing cmds with funcs and scanning through the list of changes to see if I had used anything that had changed, and alter it accordingly.
For example, I mucked around with bits of AHKHID in v2, but if I had to convert all the GUI stuff to a completely new system, it would have been a lot more work. The guts of it was mainly DLL calls, so it was just the example / debug scripts that needed converting basically. By launching v2 with a completely new GUI system, you avoid the chance for us to easily check if stuff like that still works in v2, and address any issues we find.
Same goes for stuff like GDIp. The guts of it are likely to be easy to convert (if needing anything at all), but if the example scripts all use GUIs to report values or demo features, we would need to convert the GUIs to be able to test the libs properly.
If we do come across issues, if the gui system is completely different, for all you know the bug/error could be with the gui conversion instead of the library.

[lexikos]

Yes.

I didn't ask a yes/no question. Your example shows that your syntax is more succinct, but as I said I would, I disagree about the verbosity of the current syntax being an actual problem. Btw, you could have saved a line by using %var%test.

There's no reason to maintain an approach that only benefits extremely simple Gui scripts and makes maintaining bigger Gui scripts considerably more difficult.

Whenever I see "There's no reason", anything that follows loses some amount of credibility. "There's no reason" is never a good argument for a change. There are always costs involved.

The premises of your statement, which you are implying to be fact, are:

• The current approach only benefits extremely simple Gui scripts.
• The current approach makes maintaining bigger Gui scripts considerably more difficult.

Considering both points closely, it seems that it's really the same point expressed two different ways. I've never had much of a problem with the current syntax, so I'm not sure if I can agree that either syntax has much benefit. I think I will have to experiment more with your API.

My intention is merely trying to defend my idea of a better Gui API, and convince others that it is a sensible thing to include in AutoHotkey v2.

Yes, your posts have the tone of one defending his own idea. That doesn't do you any favours as far as I'm concerned. Rather than defending your idea and bashing the current syntax, it would be better to promote your idea.

For instance, the current approach does not make maintaining bigger scripts more difficult; it's exactly as difficult as it's always been. Rather, your approach makes maintaining bigger scripts easier. (Or so you believe.)

the Gui namespace is completely separate from the normal variable namespace, and it requires either ugly syntax or selection of the "default" Gui for the thread.

I don't see those as problems. Functions are also completely separate from the normal variable namespace. As are labels. As are ToolTips. "Ugly" is subjective.

Writing and managing multi-Gui scripts is not an easy task

I disagree. I can't speak for the other tools (since I don't know what they have to do with multi-Gui), but I would think SmartGUI Creator is centred around graphically designing a graphical interface, not necessarily anything to do with multi-Gui.

The event handling system introduces complexity in the form of a good number of built-in variables that should have been implemented as function parameters

I intend to implement function parameters for Gui events in v1, building on the capabilities of the latest test releases. Thanks for bringing it up; I might refer to your API when the time comes.

moreover, expansions to the Gui system (specifically the Custom control type) have relied on ugly workarounds to fit the current model.

I'm guessing what you really mean is that the object oriented approach would make custom controls more self-contained and flexible. That scripts which implement custom controls need "ugly workarounds" to be self-contained, not that the Custom control type itself needed ugly workarounds, since it's extremely simple/limited (by design).

In the words of Lexikos

Those were really Chris' words, paraphrased.

As I see it, the current Gui API probably contributes to that whiff of "Not a proper programming language".

On the other hand, AutoHotkey is not aimed at "proper programmers", and a number of users have said that they found AutoHotkey's GUI API easier to use than others.