lexikos wrote: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"
lexikos wrote: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.
lexikos wrote: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.
evilC wrote: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.
evilC wrote: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.
guest3456 wrote: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.
evilC wrote: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.
evilC wrote: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.
evilC wrote: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.
evilC wrote: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".