Contributing to Wails

[leaanthony]

This discussion is for all information around developing adn contributing to Wails itself. We have many people ask if they can contribute to this project and we are now formalising contribution guidelines.

If you are interested in contributing to the project, or have any questions about developing Wails, please introduce yourself with what area you would like to help out, such as:

• Development
• Fixing bugs
• Testing
• Documentation
• Writing tutorials / guides
• Helping others on the issues + discussions boards

[sidwebworks]

@leaanthony the link to contribution guidelines is broken, lets change it to https://wails.io/docs/next/contributing/introduction

[leaanthony]

Ah thanks! I changed that whole thing from "developing" to "contributing" and a link must have slipped through the net.

[bobg]

Hello! Wails looks slick and I'm considering using it for a couple of projects I'm working on.

Question: the documentation depicts squirreling away a context.Context object in the App struct during the OnStartup callback. But this is an antipattern; see https://github.com/golang/go/wiki/CodeReviewComments#contexts. And it's not necessary: each request to the server has its own context, accessible via the Context method of an http.Request, with a deadline and possibly other information that is specific to that request.

A bound app method would always prefer to have access to that more-relevant context object. Ideally, a method's signature could include an optional leading context.Context, to be populated from the request's context. There is a lot of prior art here; for one example see https://pkg.go.dev/github.com/bobg/mid#JSON.

I poked around the code a bit but don't see where this could be added, offhand. If you point me in the right direction I'll be happy to create a PR. Or does Wails already support this and I'm just not seeing it?

Many thanks in advance.

[leaanthony]

The context you are referring to has nothing to do with server requests - it contains system state. I'm hoping to remove it for Wails v3 as there's a better way to handle that.

[bobg]

Gotcha, thanks! Is there a timeline for v3?

[leaanthony]

No 😀

[Rapix-x]

Hello! 👋

I want to use Wails for some application that I write in my free time. However, it would need support for multiple windows for that. In the discussion regarding this feature (#1480) it was mentioned that the code for application windows needs some refactoring.

Therefore, I would like to contribute to the project by refactoring this particular code and later on contribute the actual feature for supporting multiple windows.

Is that contribution welcome right now or is something else blocking that particular part of being refactored?
If this could be started right now, the contribution guidelines state that everything needs an associated ticket. How does that get created?

Best, Robert 🙂

[leaanthony]

Hi Robert 👋

Thanks for the offer to contribute. This is absolutely something that can be started now. For context, Wails has adopted a "declarative" approach to building applications as can be seen in the Run() command. This trades flexibility for development speed. The aim is to also provide a programmatic API which that trades development speed for flexibility.

The start of this approach can be seen in this PR. The idea behind this is to unpick the functionality in the internal/frontend directory and move it to platform with a more flexible API, whilst maintaining backwards compatibility with Run(). The tray menu PR currently defers to Run() for the main application but the idea is to move that into application and get the current Run() to call that.

In Summary: we need to unpick frontend and split it out into pkg/application, then get the current Run() method to use that for the single window that it currently supports.

I think the API will be something similar to:

	mainWindow := application.NewWindow()
	mainWindow.SetTitle("Hello World")
	mainWindow.Resize(400, 400)
	subWindow := mainWindow.NewWindow()
	subWindow.SetTitle("Sub Window")
	subWindow.Resize(200, 200)
	mainWindow.Show()

So basically all the current Window* runtime methods, but attached to the Window. I'm not currently sure what the relationship should be between parent and child windows vs sibling windows (Can application.NewWindow() be called multiple times?). Also, I'm not 100% on what this all means to eventing. Can all windows see each other's events? How do we identify specific windows from the event messages? And assets.... does each window have their own assets or do they share the main assets bundle but rooted to a different directory? What does that mean for AssetHandler ?

It might be worth branching from the current PR to start with, just be aware that it's in draft and there's some stuff in there that will absolutely break mac builds.

Let me know how I can be any more help 👍

[Rapix-x]

Hey Lea, thanks for the quick response! 🙂

First of all, thanks for all the information. I started looking into the code some days ago, but there are areas that I have not fully comprehended yet. Especially the ones you mentioned around events, how the AssetHandler fits into the picture and also how the platform parts in internal fit together with the code outside, so I will do some more research before outputting some code. 😉

However, when it comes to making proposals, asking more questions and having discussions, what is the modus operandi?
Create the Draft PR and discuss there? Have it all in an issue?

Much thanks in advance!

[Adaendra]

Hi ✋!

I've tested Wails recently and loved it!

I don't know if I will be able to help directly on new features, but I will do my best to help you to translate in French the documentation!

Have a nice day
Maxime

[leaanthony]

Welcome! It's great to have you! 🎉

[Adaendra]

Thanks! 😃

[birdmanmandbir]

Hi ✋!
I want to try wails on some toy project, but the window always re-focus, #1495,
I'd like to add a new option to disable the re-focus and I have already test my idea locally
Question: how can I push my local feature/1495_xxx branch and create a draft pull request? Do I need to fork this repo?

Best, Neil

[leaanthony]

Hey 😃, didn't you fork it to make the branch in the first place?

Usual workflow:

• fork
• make changes to fork
• open PR

👍

[birdmanmandbir]

Thanks! 😊

[BuckeyeCoder]

Hello :) I'm fairly deep into a proof-of-concept project and I'll begin contributing when able.

I noticed the issue mentioned in #2280 a couple weeks ago and I see now that the issue was raised but not fixed. I'm going to look into it but it will be my first time with Docusaurus. I saw the tweet about hating the Docusaurus build times and I am wondering if I should fix #2280 at all since it sounds like you may be switching documentation software? Do you want #2280 fixed regardless?

[BuckeyeCoder]

Ignore the above question. Your instructions in the Community Guide regarding making doc changes with Docusaurus were right on target. It was super simple to submit #2338 to fix #2280

[byteYuFan]

Hi！
Recently, I was thinking about writing a project in Go, and I inadvertently found Wails, so I began to get to know him gradually, I like its design, I will do my best to help you promote it, hope it will be known by more people, and wish you a good day.