I can’t find an option to do so. Please help
I am assuming you enabled it by creating a GUI override folder. To go back to the standard GUI, stop sync thing and delete the GUI override folder.
Where is it located? I am on windows and downloaded the zip, ran exe file and in browser it opened, I changed it to Tech UI and now it opens only and can’t go back. I can’t seem to figure out it out. Moreover there’s no good guide to tell about syncthing working either.
@pragyan, you are correct, there does not seem to be a way to change it back! You need to manually edit your
config.xml to remove the line
<theme>tech-ui</theme> and then restart Syncthing
@calmh, how did this theme make it into production? It changes the GUI, not just the colors…
@pragyan sorry, I didn’t realise this has made it into the production build.
Yeah, it seems that the official builds of v1.13.0 contain the Tech Ui.
This is a mistake, right? The theme is not present if you self-compile from the v1.13.0 tag, and it also does not seem to be included in the Syncthing repository at all.
It is partly a mistake, at least it’s a conceptual mistake to present it as a theme as that is a “trap” that’s hard to get out of.
Stop Syncthing, went in config.xml and change to default, store config.xml and start Synchthing again. That solve it as solution for now.
Where is config.xml located? Its not in the zip.
Please check https://docs.syncthing.net/users/config.html.
The file will likely be located in
%LOCALAPPDATA%\Syncthing (which usually defaults to
I’ve released a 1.13.1 that doesn’t include the tech-ui as a theme, to avoid this problem. Upgrading to that will also restore the default theme if you (inadvertently or otherwise) selected the tech-ui theme.
To access the tech UI in 1.13.1, explicitly browse to
To the larger question of “why was this included at all”, “where is the source” and “why was there no review or PR for it”:
- it’s included as a preview and base for a possibly forthcoming GUI refresh,
- the source is in the
syncthing/tech-uirepo, to where it was moved a while back from it’s original location elsewhere,
- it’s not included in the main repo because we need to consider how to handle the build process,
- there was no review or PR because there was no source change, merely a
cpcommand added to the build server.
I’m 100% convinced that if this becomes the base for a future GUI we need to have the source in the same repo as the rest of Syncthing, for purposes of keeping the GUI in sync with the backend. But it’s also the case that we don’t want to foist a new
npm-based build step on everyone by surprise in a minor release, which is why we’re currently including it sort of on the side, as a dependency.
I do not want to sound overly critical, but…
Should not the full source code be included regardless according to the MPL?
Right now, both the repository and the attached zip file do not match the actual code used in the binary. As such, binaries compiled directly from the source code are different from the released ones. I am no expert when it comes to software licenses though, so please correct me if I am wrong here.
Nevertheless, kind of a side note, but the whole criticism of @Catfriend1 and his fork with quick changes without proper review processes has become somewhat less credible at this point, at least for me.
At this point I have literally no idea what you’re on about. The source is there, in the repo. If you think it’s somehow a license violation to take source from two repos and compile into a binary I wonder if you’ve ever considered dependencies or how any nontrivial sized project is built.
As for your side note, I don’t remember anyone criticising catfriend1 about how they run their fork; they can run it as they please, it’s theirs.
There are two points.
Try to build Syncthing v1.13.x following the official instructions from https://docs.syncthing.net/dev/building.html.
git checkout v1.13.0 go run build.go
The resulting binary does not match the released binary of v1.13.0 (due to missing Tech Ui).
As far as I understand, Catfriend had been criticised for trying to push quick changes to the official repositories before he created the fork. Here, an unreviewed and untested change was distributed to the public.
This was not “quick changes without proper review”. There was 3 of us on a live call who discussed and agreed what and how it will be done, so please step off your soapbox.
Frankly I feel it’s ridiculous and unfair to Catfriend1 to keep bringing up criticism against them, but the situation then was disagreement between them and the syncthing-android maintainers about review process, and as a result they left and forked. I can’t see how that has any bearing whatsoever on this situation.
Regardless of where we put the source (which has zero bearing on anything, least of all the license situation) we would either force everyone to suddenly have a full
npm setup or build without the
tech-ui by default. We chose the latter, yet include it in the binary to have something to experiment with.
As for “untested”, it’s been out in RC form for a month. The rest, what @AudriusButkevicius says.
First of all, I am not going to respond to any insults. Secondly, I guess that this is about a different style of open source development.
My first ever commit to an open source project was to the Linux kernel. If you look at its development, everything is done 100% in the open, and even tiny changes are documented to the extreme.
On the other hand, you have projects like Android or Chromium, which are “open source” in the name, but really all the development is done inside Google and controlled by the Google employees, with little outside input.
I personally strongly prefer the former.
Thank you for the explanation. It makes more sense know. I would still say that such a change should have at least been included in the changelog. I compile all my builds myself, so my RC did not have that UI, and my release builds do not have it either. I actually had to download the official binary specifically to verify the issue stated in this thread.
You all do a really amazing job working on and maintaining ST and I really appreciate not just that you do it but the way you go about it. I really like and appreciate that you have reasoning behind how and why you do things.
That being said, I would have expected the release notes to have mentioned the additional repo being side-loaded and included in the binary. (It was literally the first place I looked when I saw the initial post).
I am sure it wasn’t intended to be intentionally opaque but copying in an additional repo that isn’t referenced in the how to or the source code caused an emotional response of betrayal from me. It is what a nefarious actor might to.
Again, I love your work but I was very surprised by this and thought it worth mentioning.