v1.16.1

[leaanthony]

• RHEL Support
• Fix for GTK > 2.32 - Thanks @fdidron!
• Better typescript generation - Thanks @igogrek
• Better fullscreen handling for MacOS - Thanks @rh12503!

---

This discussion was created from the release v1.16.1.

[igogrek]

Hi @leaanthony I can also add some more logic to the typescript file generation to produce typings with proper input parameters (amount of params with types, without arg names since they can't be got via reflection anyway) and return parameters also typed. Though this will require significantly more code that there is now.
Is that ok?
Currently -t flag isn't even mentioned in the docs and you mentioned this being experimental before, so I'm not sure if this functionality is intended to be further used.

[leaanthony]

Very happy for you to do that. I've got a lot of code for this approach in v2 here so maybe that could be ported? For v2, I've also had a good crack at generating this (plus struct declarations) here. It's very WIP but if we were able to make that work, it would be a game changer. The biggest problem I had was knowing when to stop, EG: you process your main package and discover that you've imported a struct from another package. So you read that and generate TS but that struct imports some of the stdlib. I was thinking either get the developer to generate the structs by name (explicit) or get the developer to list the packages that should be processed (any references outside of those will be typed as any). Glad to have your input! 👍

[igogrek]

Oh so there's so much work done already. Amazing! I would love to try it out and see how it works. I see there's new info regarding this on a wiki https://github.com/wailsapp/wails/wiki/Helping-with-V2 so I'll try to test it out.

For V1 I've already done some more reflection-based stuff but AST parsing is much better approach since it's possible to get method parameter names and such.

I've also played around with AST parsing in V1 trying to get bound methods "automatically" from .Bind calls but it turned out to be rather painful and error prone in many ways. So having some explicit declarations for what you would want to generate typings for is definitely a must.

As for the struct name vs package - I personally think it should be the easiest one to implement on wails side with as less "magic" as possible.
Parsing specific struct names seem to be more difficult for me and can be troublesome if there are multiple packages with same structs, e.g. packages will need to be named, it will be harder to pass specific methods to bind.
So I don't think this is very good: wails ... -t models.MyStruct,api.MyMethod,api.MyOtherMethod

E.g. from my point of view it could even be whole go files being passed as argument.
So I think it would be perfectly fine do do any of: wails ... -t models.go,api.go or wails ... -t structpackage,apipackage etc.