How to contribute to the WebGUI code?

I didn’t know much about Go, only that’s a programming language :wink: And i didn’t want to learn Go, because i love Python and won’t leave :wink:

I have a few skills in JavaScript/HTML etc. So i can make some contribution in the WebGUI… But how?

Exist there a way, that i simply test own modification in the WebGUI? e.g.: git clone the github repro and put “/gui/” files beside the binary?

I moved 11 posts to a new topic: Issues rebuilding syncthing for GUI development (deprecated)

In v0.8.10+, a developer environment variable can be set to point to a folder containing the GUI assets. When set, syncthing will load the GUI from there instead of built in.

STGUIASSETS=~/someDir/gui syncthing

Before filing a pull request, please run ./ assets to rebuild the compiled-in assets file. This requires having Go 1.2+ installed. If you absolutely cannot (Windows only, is a bash script), just mention it in the pull request and I’ll do so for you.

Cool! Can’t wait of the next release :wink:

When you will have some more time you could check package for flexible assets embedding.

I will just quote description:

What does it do?

The first thing go.rice does is finding the correct absolute path for your resource files. Say you are executing go binary in your home directory, but your html-files are located in $GOPATH/src/yourApplication/html-files. go.rice will lookup the correct path for that directory (relative to the location of yourApplication). The only thing you have to do is include the resources using rice.FindBox("html-files").

This only works when the source is available to the machine executing the binary. Which is always the case when the binary was installed with go get or go install. It might occur that you wish to simply provide a binary, without source. The rice tool analyses source code and finds call’s to rice.FindBox(..) and adds the required directories to the executable binary. There are several methods to add these resources. You can ‘embed’ by generating go source code, or append the resource to the executable as zip file. In both cases go.rice will detect the embedded or appended resources and load those, instead of looking up files from disk.

Not sure what the advantage compared to the current system would be? Rather it seems to be less flexible than what I do now.

Will make project go get-able without need to commit regenerated assets every time they changed,

Other idea: maybe you could make that Syncthing binary will look for folder gui in the same directory it is stored (you can use for that). If folder gui is not found use compiled in assets, but if it find gui folder then use files from that folder. That way you do not need to use env variable.

But the resulting binary will only work while you still have the source code in the same place on disk, creating a subtle WTF when you try to deploy it somewhere else. To have the assets included in the binary you still need to generate them with the “rice” tool (that you also need to install).

I don’t think setting an environment variable to override the gui assets is too onerous. Having the gui work differently just depending where you happen to be standing when you start syncthing would also be a surprise for some people, I’m sure.

OK, thank you for your time.