Feedback on wiki "GUI Scripting Language" Series

[Geep]

On 11/3/2022 at 5:59 PM, stgatilov said:

In Precedence section, there is discussion about parentheses.
Yes, you can put parentheses in GUI expressions, and rely on normal evaluation order otherwise.

The discussion about macros here might be a bit confusing, because GUI engine has nothing to do with #defines, in fact it does not even see them. Just like in C language, all the directives starting with #sharp are handles by totally separate thing called preprocessor, the GUI parser will see all macro references replaced by whatever they point to, so for the GUI parser it would be just a gigantic expression with two levels of nested parentheses.

I would probably be better to stress this in tutorial, because this understanding of preprocessor as an entirely separate step can help on many occasions.

@stgatilov, just doing a last pass through the pages. For the record, I do need to mention here a concern I noticed earlier.

While the preprocessor directives are indeed best thought of as a separate pass that resolves (e.g., does text substitution) before the main parsing occurs, I don't think that's actually what the source code is doing. As far as I can tell (just static analysis), macros are being parsed and resolved intermixed with other GUI commands. So I've worded things carefully to not claim an actual preprocessor pass.

Edit: Oh, I see I already mentioned all that back in November. Nevermind.

Edited December 27, 2022 by Geep

[Geep]

OK, it's almost the end of the year, and I am officially SO DONE with the GUI Scripting series! Yeah!!! Thanks for all the help, and apologies if I neglected or mangled any points anyone raised.

I hope TDM readers will find it useful at times, and will improve it where it needs it.

[stgatilov]

21 hours ago, Geep said:

While the preprocessor directives are indeed best thought of as a separate pass that resolves (e.g., does text substitution) before the main parsing occurs, I don't think that's actually what the source code is doing. As far as I can tell (just static analysis), macros are being parsed and resolved intermixed with other GUI commands.

That can be considered an optimization: C/C++ compilers most likely do the same today, although the specification is defined in terms of having a separate preprocessing pass.

The main consequence is that the preprocessor does not know anything about GUI language, and GUI language does not know anything about preprocessor, and the information just cannot get from GUI language to preprocessor. The formulation of a separate pass make it obvious, while the exact description of implementation does not.

[datiswous]

I was looking into the documentation for creating a listdef, but there is not enough information in it. It shows how it is done for some sections of the main menu, but it doesn't show you how to list your own data.

Quote

The listDef GUI does not itself populate a list, but relies on associated C++ code to do so, typically with a dynamic list.

I don't see how this page is helpful apart from some sort of historical reference. Or for tdm devs.

[Geep]

1 hour ago, datiswous said:

I don't see how this page is helpful apart from some sort of historical reference. Or for tdm devs.

I agree that listdefs as they are now are not useful to FM authors, because alteration of the C++ source code is needed. If there was some data array that was useful across FMs, then it might justify a collaboration to have C++ support it. For instance, I could imagine a generic fm_data_string_array, with read/write access, that you could associated with any FM-specific listdef. Don't have a clear idea here.

[datiswous]

Ok well, I was looking at the options for having a list of choices, but I decided to look for something else. Choicedef is also not useful in this case.