Proposed New GUI API for AutoHotkey v2

Discuss the future of the AutoHotkey language
lexikos
Posts: 7196
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Proposed New GUI API for AutoHotkey v2

Post by lexikos » 13 Aug 2014, 20:04

...it does appear that canvases do exist in some form in some windows APIs.
There's a difference between APIs which exist on Windows and THE Windows (Win32) API. AutoHotkey uses just plain Win32. WinForms and such are built on top of Win32.

What I mean is that your request doesn't make sense without also adding scrolling support. I'm not against that, but don't value it enough to do it myself.

If a script manually implements scroll bars, they aren't necessarily tied to control positioning.
As a side note, is there any way that AHK's built-in commands can be "overridden"?
For example, declaring a function WinMove() seems to override the built in WinMove(), but I can find no equivalent of base.WinMove() to call the underlying function.
Your example shows that yes, it can be overridden, but you are asking the wrong question. No, you cannot call the original function. base. currently only has special meaning inside classes, but I'll consider changing it to work the way you're suggesting (or some alternative).

User avatar
evilC
Posts: 4791
Joined: 27 Feb 2014, 12:30

Re: Proposed New GUI API for AutoHotkey v2

Post by evilC » 14 Aug 2014, 12:12

lexikos wrote:If a script manually implements scroll bars, they aren't necessarily tied to control positioning.
I am not quite sure what you mean here.
I was referring to implementations of scrollbars for GUIs (rather than controls) - is there a case where a GUI would have scrollbars enabled (+0x300000 passed to Gui Create) but these scrollbars would not be used to scroll the canvas?
lexikos wrote:Your example shows that yes, it can be overridden, but you are asking the wrong question. No, you cannot call the original function. base. currently only has special meaning inside classes, but I'll consider changing it to work the way you're suggesting (or some alternative).
That would be appreciated :)

lexikos
Posts: 7196
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Proposed New GUI API for AutoHotkey v2

Post by lexikos » 15 Aug 2014, 02:29

evilC wrote:is there a case where a GUI would have scrollbars enabled (+0x300000 passed to Gui Create) but these scrollbars would not be used to scroll the canvas?
Do you want me to make one? Scroll bars can be used for whatever you want, since they don't move the controls around by themselves. As an example, the scroll bar could control custom rendering of a game board or some other visual thing, while leaving other controls in fixed positions.

If scrolling support was built in and you enabled it via the built-in option, then it would make sense for the Gui controls to compensate for scrolled coordinates.

User avatar
evilC
Posts: 4791
Joined: 27 Feb 2014, 12:30

Re: Proposed New GUI API for AutoHotkey v2

Post by evilC » 15 Aug 2014, 06:49

I have to disagree there.
There is a very definite convention in windows - if scrollbars are visible for a section of a GUI, then when you manipulate a scrollbar, the user will expect everything in a box defined by the bounds of the scrollbars to scroll - draw horizontal lines from the top and bottom of the vertical scrollbar and vertical lines from the left and right of the horizontal scrollbar - when you manipulate the scrollbar, everything inside the box defined by those lines should scroll. The user may not know that it is a separate child GUI, but it is.
The only exception to that rule would be a floating tool palette, but the most likely way you would accomplish this would be to make the tool palette a child of the outermost window instead of the scrolling sub-window, and set the z-order to be above that of the scrolling sub-window. Either that or the tool palette would be outside of the scrolling section, and thus not a child of it.

This is borne out by the fact that the ScrollWindow(x, y, HWND) DLL call scrolls everything that is a child of the specified HWND by the number of pixels defined by the nPos property returned by GetScrollInfo(HWND, bar) for that Hwnd.

lexikos
Posts: 7196
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Proposed New GUI API for AutoHotkey v2

Post by lexikos » 15 Aug 2014, 18:43

And yet, Windows doesn't compensate for scrolling. You cannot deny the possibility that the scroll bars could be used for something else; they have been, and the Win32 API is clearly designed to allow it.

Do you really want us to half-implement scrolling? As an optional built-in feature, it would be so much easier for users (not that there are likely more than a handful who need it) and would be less likely to cause unwanted behaviour. In any case, I'm not implementing either in the foreseeable future (unless someone else does the work).

I was going to suggest that you simply create a sub-GUI to fit all controls, and move that sub-GUI around inside the main scrollable GUI. The controls would be placed relative to the sub-GUI. However, I think there's a limit to how large a window can be. It may be worth a try anyway.
The only exception to that rule would be a floating tool palette,
You are, quite simply, mistaken. There are as many exceptions as there are creative programmers. There are also quite a lot of programs you've never seen.

User avatar
fincs
Posts: 505
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

Post by fincs » 16 Sep 2014, 05:54

I've updated the binaries in the OP after rebasing my changes on top of v2-a051. Note that many internal ABI changes were made by lexikos in a050, and I may have screwed something up.

EDIT: OK, a051 it is now. Please redownload.
fincs
Windows 10 x64 Build 18362 | AMD Ryzen 7 3700X with 32 GB of RAM | AutoHotkey v1.1.31.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]

User avatar
fincs
Posts: 505
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

Post by fincs » 20 Sep 2014, 14:26

I've updated the binaries in the OP. Changes:
  • Rebased on top of v2-a054.
  • The Value property for multi-select ListBoxes now returns an array instead of a pipe-delimited string of items.
  • It is now possible to pass an array to ListView, Tab, DDL, ComboBox, and ListBox controls instead of a pipe-delimited string. Careful: ctrl.Value := ["list", "of", "items"] replaces the list of items instead of appending (unlike ctrl.Value := "list|of|items"). A future test build will add a separate ctrl.Append() method and will make them consistent for both arrays and pipe-delimited strings.
  • It is now possible to enumerate the controls in a Gui through for hwnd,ctrlObj in gui.
Bonus experimental feature (which may or may not be removed in a future test build):
Spoiler
fincs
Windows 10 x64 Build 18362 | AMD Ryzen 7 3700X with 32 GB of RAM | AutoHotkey v1.1.31.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]

guest3456
Posts: 3163
Joined: 09 Oct 2013, 10:31

Re: Proposed New GUI API for AutoHotkey v2

Post by guest3456 » 20 Sep 2014, 17:01

fincs wrote:
toralf wrote:Do you plan to keep the old command style available in v2 or would this be a replacement?
This proposed design is intended as a replacement. As such, and in order not to alienate current AHK users, I designed it so that it stays as similar/parallel as possible as the old Gui API. Converting code to use the new Gui API is literally a matter of doing some minor tweaks to each line that uses a Gui command/function. Almost everything has a 1:1 correspondence.
I'm not a fan of removing the existing Gui commands. Obviously using the gui objects that you've designed is a step forward. But is there a way to make it more seamless?

Currently, v2 allows you to call commands with function syntax. So both of these work:

Code: Select all

;command syntax
Gui, Add, Text,, Please enter your name:
Gui, Add, Edit, vName
Gui, Show

;function syntax
Gui("Add", "Text", "", "Please enter your name:")
Gui("Add", "Edit", "vName")
Gui("Show")
The function syntax does some checking for a command that has an output var as the first parameter. If so, then that param is removed from the func param list and instead it becomes the return value for the function. Since the Gui commands have no return value, is it possible somehow return your new object? Perhaps only using the New subcommand? Something like, "To use the new OOP Gui's, call the Gui, New command, but use the function syntax. The return value will be a new Gui Object. Like so:"

Code: Select all

;command syntax
Gui, New

;function syntax
gui_obj := Gui("New")
The gui_obj var will contain your new Gui Object type, similar to how we have File/Func/ComObject's. Then we can use all of your existing Gui Object methods on it.

I guess on second look after rereading, this is simply the same as your GuiCreate() func. So maybe my suggestion is to simply add your func (or rename it to GuiObjCreate()) and keep all the Gui commands as is. This allows all existing v1 gui scripts to work while still adding your new functionality

Just my opinion, and I have no idea how feasible it is.


User avatar
fincs
Posts: 505
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

Post by fincs » 20 Sep 2014, 17:26

guest3456 wrote:So maybe my suggestion is to simply add your func (or rename it to GuiObjCreate()) and keep all the Gui commands as is. This allows all existing v1 gui scripts to work while still adding your new functionality
You are missing the point of AutoHotkey v2: breaking compatibility with v1.x to enhance language usability and remove unintuitive backwards-compatibility behaviour. As I've already stated before in my posts, IMO the whole v1.x Gui system is extremely outdated and clunky (since it was designed before AutoHotkey had objects). It would be an unjustifiable shame and disgrace to keep it as-is in v2 (even if there would be an alternative interface, which would just be redundant then). Therefore this is my attempt at fixing it and making it more modern, easier to use and more flexible; in line with v2's mission.
fincs
Windows 10 x64 Build 18362 | AMD Ryzen 7 3700X with 32 GB of RAM | AutoHotkey v1.1.31.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]

guest3456
Posts: 3163
Joined: 09 Oct 2013, 10:31

Re: Proposed New GUI API for AutoHotkey v2

Post by guest3456 » 20 Sep 2014, 18:31

fincs wrote:
guest3456 wrote:So maybe my suggestion is to simply add your func (or rename it to GuiObjCreate()) and keep all the Gui commands as is. This allows all existing v1 gui scripts to work while still adding your new functionality
You are missing the point of AutoHotkey v2: breaking compatibility with v1.x to enhance language usability and remove unintuitive backwards-compatibility behaviour. As I've already stated before in my posts, IMO the whole v1.x Gui system is extremely outdated and clunky (since it was designed before AutoHotkey had objects). It would be an unjustifiable shame and disgrace to keep it as-is in v2 (even if there would be an alternative interface, which would just be redundant then). Therefore this is my attempt at fixing it and making it more modern, easier to use and more flexible; in line with v2's mission.
The whole command syntax itself is outdated and clunky. I hate it. User "just me" isn't a fan either. But Lexikos has decided to keep it in v2. Why are you not proposing the removal of command syntax entirely? It fits all of your same descriptions of the Gui syntax. Command syntax is completely redundant now that they can all be called as functions, amirite? Functions are more modern, easier to use, and more flexible. Perhaps you should do that, and we can have AHK_F to go along with AHK_L and AHK_H. More choices!

The File Object was introduced, and you could make a case that it makes things easier than the FileRead, FileAppend, Loop, Read commands as well. Should those be removed now that we have a File object? We now have (command in function syntax:) FileRead() as well as File.Read() (file obj method). Redundant..

Look, I don't disagree that the existing Gui syntax is clumsy. Of course it is. I don't think anyone will argue that. My opinion is simply to leave the existing commands so that existing Gui code from v1 works. I don't know what Lexikos' goals are. What do you make of his earlier clarification? Why did he feel the need to make that post? If he wanted to go gung ho and break compatibility left and right then why is command syntax still in? Perhaps there is some desire (as toralf mentioned) against AHKv2 becoming like AutoIt and breaking everything. Perhaps its to allow users to migrate to v2 with as smooth as a transition that is possible, while only breaking compatibility when absolutely necessary to improve the usability and reduce confusion.

Just my opinions


User avatar
fincs
Posts: 505
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

Post by fincs » 20 Sep 2014, 18:46

guest3456 wrote:The whole command syntax itself is outdated and clunky.
No. Command syntax is more readable in certain cases (such as passing literal strings/numbers while discarding the return value). In fact, object command syntax was introduced recently in order to allow users to call object methods using command syntax. Command syntax is far from outdated - it can even be considered as one of the signature features of AutoHotkey.
guest3456 wrote:The File Object was introduced, and you could make a case that it makes things easier than the FileRead, FileAppend, Loop, Read commands as well. Should those be removed now that we have a File object? We now have (command in function syntax:) FileRead() as well as File.Read() (file obj method). Redundant..
You're wrong here too. The older file commands can be thought of as being convenient abbreviations for doing typical operations on files (read whole, append text, parse line by line). The file object is intended to be used for more general/arbitrary file operations.
guest3456 wrote:What do you make of his earlier clarification?
You're taking that statement out of context, before I had even attempted implementing it myself. Lexikos has never rejected redesigning the Gui system. If all, he's observing how this turns out; although I wouldn't put any words in his mouth.
guest3456 wrote:Perhaps its to allow users to migrate to v2 with as smooth as a transition that is possible, while only breaking compatibility when absolutely necessary to improve the usability.
This makes no sense. Breaking compatibility is breaking compatibility. v2 has already made many breaking changes for consistency and purity purposes and is certainly not using your proposed 'minimum breakage' approach. We do not want any sort of features let in for backwards compatibility purposes. Maintaining two sets of more or less equifunctional interfaces for Guis is stupid (especially since they conflict in many ways such as event handling or even the names of certain parameters/options)
fincs
Windows 10 x64 Build 18362 | AMD Ryzen 7 3700X with 32 GB of RAM | AutoHotkey v1.1.31.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]

guest3456
Posts: 3163
Joined: 09 Oct 2013, 10:31

Re: Proposed New GUI API for AutoHotkey v2

Post by guest3456 » 20 Sep 2014, 19:11

fincs wrote: No. Command syntax is more readable in certain cases (such as passing literal strings/numbers while discarding the return value).
That's certainly a subjective opinion. And, are we talking about readability or usability? Anyway, I tend to agree with 'just me'. I reckon that his co-workers not even giving AHK a chance is probably a common occurance, but obv I have no proof of that. IMO for anyone that has ever attempted to write any type of computer program, Command syntax is very 'clunky'. I will be happy if all of v2 docs are rewritten to only use function syntax.
fincs wrote:Lexikos has never rejected redesigning the Gui system.
I am not against a redesign either. I think you've done a good job.
fincs wrote: This makes no sense. Breaking compatibility is breaking compatibility. v2 has already made many breaking changes for consistency and purity purposes and is certainly not using your proposed 'minimum breakage' approach. Maintaining two sets of more or less equifunctional interfaces for Guis is stupid (especially since they conflict in many ways such as event handling or even the names of certain parameters/options)
Lol yet v2 has retained Command syntax, "maintaining two sets of more or less equifunctional interfaces", and your only justification for this is: readability "in certain cases". Surely then by that logic this "is stupid" just the same, and it should be a candidate for removal and breaking of compatibility from v1, given its clunkiness.

I have not proposed any 'minimum breakage' approach. I have just attempted to understand the vision and goals of Lexikos and Chris. I have no idea if its possible to refactor some of the code so that you don't have to duplicate implementations across the two interfaces. But the File object duplicates some functionality so..

Anyway, you can do whatever you want. I will use whatever works for me while it works for me. As I said, its just my opinion. I'll bow out now and leave these decisions to you guys.


Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
GitHub: cocobelgica

Re: Proposed New GUI API for AutoHotkey v2

Post by Coco » 21 Sep 2014, 01:09

I understand where guest3456 is coming from, I've been writing "hybrid"(works on both v1.1+ and v2, can't think of a better term) scripts for a while now and I am aware that by the time this new GUI API is implemented I will have to create/rewrite v2-specific versions of those scripts, which I am totally fine with. I assume guest3456 is working on some "hybrid" script(s) as well or I may be wrong. There are a couple of workaround for the user that I can think of: write a v2 version for your scripts that employs GUI commands or come up with a temporary wrapper which would be something like:

Code: Select all

Gui(cmd, args*)
{
	static GuiCreate := A_AhkVersion >= "2" ? Func("GuiCreate") : ""
}

GuiControl(args*)
{
	
}

GuiControlGet(args*)
{

}

Gui New ; won't trigger runtime error on v2
The former is the better option of course since I reckon one would only need to change the GUI command parts of the scripts. Both requires some work on the dev's part but if you really need the script or if you think users will find it useful then a little sacrifice is required. Or you can compile or ship it using a specific AHK version. Unless there's a better solution out there...

Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
GitHub: cocobelgica

Re: Proposed New GUI API for AutoHotkey v2

Post by Coco » 21 Sep 2014, 01:53

fincs wrote:It is now possible to enumerate the controls in a Gui through for hwnd,ctrlObj in gui.
Are the controls enumerated in the order the same as the z-order? Since hwnd are integer keys.

User avatar
fincs
Posts: 505
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

Post by fincs » 21 Sep 2014, 04:30

Coco wrote: I've been writing "hybrid"(works on both v1.1+ and v2, can't think of a better term) scripts for a while now and I am aware that by the time this new GUI API is implemented I will have to create/rewrite v2-specific versions of those scripts, which I am totally fine with.
v2 has yet to diverge even more from v1.x, and writing 'hybrid' scripts will be getting harder and harder (if not impossible). IMO it's a waste of time for complex scripts. (However if the changes necessary to run a particular script on both v2 and v1.x are really small, then meh why not.)
Coco wrote:Are the controls enumerated in the order the same as the z-order? Since hwnd are integer keys.
They are enumerated in the order you added them to the Gui.
fincs
Windows 10 x64 Build 18362 | AMD Ryzen 7 3700X with 32 GB of RAM | AutoHotkey v1.1.31.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]

Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
GitHub: cocobelgica

Re: Proposed New GUI API for AutoHotkey v2

Post by Coco » 21 Sep 2014, 04:42

fincs wrote:v2 has yet to diverge even more from v1.x, and writing 'hybrid' scripts will be getting harder and harder (if not impossible).
Well, this new Gui API is definitely one of those major compatibility breaker.
fincs wrote:They are enumerated in the order you added them to the Gui.
Is this how WinGet, ControlList ... works as well?
fincs wrote:It is now possible to pass an array to ListView, Tab, DDL, ComboBox, and ListBox
How do I specify the pre-selected item?

User avatar
fincs
Posts: 505
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

Post by fincs » 21 Sep 2014, 04:46

Coco wrote:Is this how WinGet, ControlList ... works as well?
I don't know. What I can tell you is that I chose to implement it that way because it was the easiest: I just iterate over the internal control array.
Coco wrote:How do I specify the pre-selected item?
Same way as always, with the Choose option.
fincs
Windows 10 x64 Build 18362 | AMD Ryzen 7 3700X with 32 GB of RAM | AutoHotkey v1.1.31.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]

Coco
Posts: 771
Joined: 29 Sep 2013, 20:37
GitHub: cocobelgica

Re: Proposed New GUI API for AutoHotkey v2

Post by Coco » 21 Sep 2014, 04:49

fincs wrote:Same way as always, with the Choose option.
Totally forgot about that, I've gotten used to the double pipe(||) approach. Thanks :)

guest3456
Posts: 3163
Joined: 09 Oct 2013, 10:31

Re: Proposed New GUI API for AutoHotkey v2

Post by guest3456 » 21 Sep 2014, 23:34

Coco wrote:I understand where guest3456 is coming from, I've been writing "hybrid"(works on both v1.1+ and v2, can't think of a better term) scripts for a while now and I am aware that by the time this new GUI API is implemented I will have to create/rewrite v2-specific versions of those scripts, which I am totally fine with. I assume guest3456 is working on some "hybrid" script(s) as well or I may be wrong.
Yes I plan to do stuff like this. I just find it funny that the same logic used as reasoning for removing the Gui commands conveniently isn't applicable to all commands. Despite the only defensive given being: "readability in certain cases". So this new proposal calls for users to still be able to use Commands to do everything in v2, EXCEPT create Guis. To create Guis, users are now forced to learn OOP usage. Gotcha

But when someone has a personal vested interest in the matter, biases are inevitable. Just like my interest I guess.


User avatar
fincs
Posts: 505
Joined: 30 Sep 2013, 14:17
GitHub: fincs
Location: Seville, Spain
Contact:

Re: Proposed New GUI API for AutoHotkey v2

Post by fincs » 12 Oct 2014, 06:33

I've updated again the binaries in the OP to include the latest v2.0-a056 changes.
fincs
Windows 10 x64 Build 18362 | AMD Ryzen 7 3700X with 32 GB of RAM | AutoHotkey v1.1.31.01
Get SciTE4AutoHotkey v3.0.06.01 - [My project list]

Post Reply

Return to “AutoHotkey v2 Development”