First of all, thank you for considering my Gui work to be worth including in v2, despite it not having been updated in two years. I'd like to address some of your comments:
lexikos wrote:Renaming Text to Label. Authors who knew the old name will now have to unlearn it, and what do they gain? Nothing. I guess that fincs believes "Label" to be more fitting, but I disagree. In my opinion, a "label" is generally attached to something else, to identify it, whereas "text" is just text. "Gui Add, Text" just adds text to a Gui. Maybe that text is used as a label, maybe it isn't.
This change was mostly an experiment since other programming languages or frameworks generally call this control "Label" even if it is not attached to any control. WinForms calls it Label
. Qt calls it QLabel
. GTK calls it GtkLabel
. Apple calls it UILabel
. In Tkinter, you use a Label
widget. Wikipedia calls the concept a Label control
. On the other hand, the Win32 control is Static
, and the MFC class is CStatic
. Ultimately, I don't really mind either name, so feel free to change it back.
lexikos wrote:Gui events such as GuiSize have a mandatory "On" prefix. (...)
This was inspired by OnExit
. Without the "On" prefix, the Gui event names would be 'Close', 'Escape', 'Size', 'ContextMenu' and 'DropFiles'. These are very generic words that could cause trouble if the Gui handler class contains a similarly named member. Think of a "contextMenu" field, or a "size" field, or a "Close" method that is called by other parts of the script. On the other hand, you proposed to introduce PrefixPrefix
in order to add a prefix to Gui event handler names. This would effectively solve the issue if On
is removed. Also, I suppose the names of the event getters/setters (e.g. gui.OnClose := Func("somefunc").Bind("Close")
) will keep the On prefix.
lexikos wrote:If the Gui has a function name prefix for events (GuiCreate's third parameter), it is used for all Gui events and all control events. It isn't possible to use the EventSource_EventName naming convention, because the Gui's prefix is used even when a control is the source of the event. By contrast, v1 had +Label for Gui events and control events had no implicit prefix. On the other hand, controls have a single handler for all events (though some controls, like Button, only have one event), so the GuiName_ControlName convention might be more suitable. In the end, I'm not sure what to do about it.
This was mostly preference. I tended to give my control's g-label names the same prefixes I used in their parent Guis, mostly to keep the code somewhat organized. In the case of non-object-based event handling, I guess it's not really necessary to prepend the parent Gui's prefix to the function names; and if the beforementioned Prefix/g option were introduced for (non-control) Gui event handlers, there would be no need whatsoever for a Gui event prefix. Also, I think that the current single-event-handler model for controls somewhat falls apart in the case of complex controls such as ListView, where the same event handler is responsible for absolutely all possible (and unrelated) events that can be triggered in the control. In fact there were so many possible events that a certain group of them have to be explicitly enabled with the AltSubmit option. Perhaps this should be broken up in smaller, single-purpose handlers just like the set of event handlers that Gui themselves have.
lexikos wrote:Gui.AddCtrl(Text, Options) vs Gui Add, Ctrl, Options, Text is bound to cause confusion with users familiar with the old order. Since even fincs expressed doubt about it, I'd guess it should be swapped back. Perhaps Options would be omitted more often than Text, but usually there's at least one option. (...)
Similarly, GuiCreate(Title, Options) is opposite to Gui New, Options, Title. (...)
Currently Gui.Show(Options, Title) is inconsistent with GuiCreate and Gui.AddCtrl. It won't be a problem if those are changed, but does having a Title parameter really make sense in the first place? It did in v1, when a Gui was created automatically (rather than explicitly by Gui New), but now we must always call GuiCreate, which has a Title parameter. Gui.Show can be used to change the title of an existing Gui, but so can Gui.Title, which is more obvious.
The main reason this was changed was that the syntax for specifying just the text and not the option (e.g. btn := gui.AddButton("", "Text")
or gui.AddLabel,, Text
) contained that extra empty parameter that looked ugly. I had always thought that the Text parameter was more used than the Options and thus it should be promoted to be the first parameter. However, it is indeed true that existing users would be confused by the change, so ultimately perhaps it should be changed back in gui.AddCtrl
. But again, if GuiCreate
keeps Title first, it would be inconsistent with it. I agree that gui.Show
should lose its Text parameter since it's redundant.