One of the keys to a successful upgrade is to do it incrementally, by running the two frameworks side by side in the same application, and porting AngularJS components to Angular one by one. This makes it possible to upgrade even large and complex applications without disrupting other business, because the work can be done collaboratively and spread over a period of time. The upgrade module in Angular has been designed to make incremental upgrading seamless.
So a typical AngularJS upgrade means simply copy all existing AngularJS code in Angular, and start porting over code step-by-step in multiple PRâs / releases.
Starting from scratch is still a much bigger task with higher risks of never finishing it.
I do estimate this is aprox 4 times as much work as the Bootstrap task I had in mind, since JS has to be rewritten to TS somewhere on the road and unit tested.
Ok guys let me get this baby to Angular. @tomasz86 the idea of keeping the old UI in there sounds good. Maybe give the people who canât run Angular instructions how to use the older version, while making Angluar 15 hybrid the main.
We have release candidates which are released prior to the real release. For more closed testing, i.e. not all users should be exposed to the new thing, weâd need to have the new GUI as a separate selectable âthemeâ.
Iâm skeptical that itâs possible to do a good job by porting the existing GUI component-for-component, but as the famous quote says, those who claim something is impossible shouldnât get in the way of those who are actually doing itâŠ
I liked the architectural design of the new-gui, but I agree that doing a from-scratch rewrite is a (maybe too) large job, hence itâs been stuck in limbo for a little while.
Support for non-current browsers shouldnât be a main concern here, for all the reasons already mentioned.
Yourâre doing charity work so I canât really tell you what to do and what not to do, so do with this whatever you want, or just tell me to shut up.
I would not bother with âmoving this baby to angularâ. This baby has every disease under the sun and nobody wants to look at it. Itâs a single large js file. There is no structure, no types.
I would take the modern ui that already uses modern frameworks, typescript, has skeletons for apis/services etc, upgrade it to latest and greatest of everything (which should be easy) and build on that to bring it to feature parity with the old thing.
Personally, to me, this proposition sounds like a lot less like septic tank diving (digging though a single 5k line file) and actual meaningful development, building things from the ground up.
This baby has every disease under the sun and nobody wants to look at it.
Nice way to explain it. Since Iâm a doctor, I might be able to fix the baby. We can also make a new one but the pregnancy takes a couple of months and maybe the new baby has itâs own imperfections that we have to solve after giving birth as well. Fixing the current baby requires a lot of medicines, but it can still be quicker and along the way we can deprecate / improve things while quickly bringing fixes to the userbase so they will experience improvements as the baby gets healed step-by-step.
Jokes aside, I value your opinion no need to shut up, you also do good work for the project. I think the ball is now on my side, the above topic was helpfull for me thanks everyone for participating. I do have other stuff ofc in my life so might take some weeks before I have something but letâs see, still very much motivated.
Not a dev, but a user⊠I donât have any major problems with the existing GUI, and feel comfortable using itâŠ
I DO get annoyed when people try to change to âNew and Improvedâ just because itâs âCoolâ or adds functionality that is only mildly helpful and forces one to learn a new interface or redo things that were working until the change broke themâŠ
I really hate having âsleek new featuresâ added that change how things work⊠I hate Microsoft on principle, but am particularly annoyed by how every new version of Windows changes the UI, with no benefit if I donât want the new crapâŠ
Same thing even on GNU/Linux - every time they come out with a new improved version of KDE, I have to spend hours figuring out how to turn OFF all the new garbage that I didnât ask for and donât wantâŠ
So put me down as a user that is fine w/ changes under the hood, but does NOT want to see significant changes to the UI that I see in my browserâŠ
Just to remove any potential doubts from @ssgtcookie or anyone else wanting to work on a new/revised GUI: I desire getting new/updated GUI. As long as it improves either maitainability or UX, without making the other worse, I welcome it, regardless of if the UI changes. Backwards compatibility is a concern to me, but not a deal-breaker. Especially given how easy it is to preserve a web UI either within syncthing itself or as a separate project.
(Personal note and completely unrelated, just a reactin to @ex-Gooseriderâs comment above: KDEâs UX improved in huge strides in the past few years - most importantly because it got stabler. Also emacs is my main editor/IDE/⊠- just to defuse any sentiments of âyoung GUI-loving VS code using fools donât know whatâs good anymore nowadaysâ).
Sorry what do you mean exactly with this sentence?
â⊠anyone else wanting to work on a new/revised GUI: I want a new GUI.â?
You mean you donât want to work iterative (agile) but you want to work on a big-bang release (waterfall) and bring all new functionality at once? Both is possible ofcourse.
I have a version running on my localhost currently that runs in hybrid mode (Angular 15 as base but all JS is still running in AngularJS 1.3.20). It works, but there are some changes I want to make to make it ready for a future PR. Got about 8 hours in it currently, I estimate my progress at 25%.
The KDE stuff you talk about I donât fully understand. KDE is a desktop environment right, what has this to do with the web UI exactly? Maybe Iâm missing knowledge on this subject.
What Jakob said. My comment apparently did do pretty much the opposite of itâs actual intention, which is to re-assure you that your contribution is welcome.
The KDE quip was entirely unrelated indeed, just a reaction to the post above me - sorry for the confusion.
Just as a clarification, as the one that brought up KDE, I donât think KDE has any direct relationship w/ Syncthing⊠I was only bringing it up as an example of what I consider to be BREAKING the UI by trying to create ânew and improvedâ features that take a great deal of effort to get rid of in order to get back to what worked⊠I donât want to get more specific than that as it isnât relevant to ST development.
I see the AngularJS $scope is a bit abused by storing data in it, retrieved from the BE. I can imagine this gets heavy for the UI when the data size of $scope increases. Something we can fix with redux later on the road.
Question: how does the RC thing works? Is there a RC branch I can set as target for a PR?
Question: I would like to have some mockdata to see the UI in all itâs glory. Do you guys have that by coincidence?
Current progress: aprox 40%. Current task: testing with the actual syncthing service + wiremock stubbed responses to test if all works ok.
Next up: figure out how to make the ânewâ hybrid UI the default including build script to build the angular production bundle.
Just target main. RC might become a branch, but generally itâs just a release cut directly from main and then thereâs a delay for testing and bug-fixes only until general release (itâs a bit more nuanced but that doesnât really matter). Whether RC is enabled is a setting. So it should be just possible to bundle your UI, but keep using the old one, and then first make it probably completely opt-in (setting, env var, âŠ) and then later enable it for everyone with the RC setting enabled - something like that. I can help with navigating that if desired, first thing is to get it running any way possible
Thereâs no mock data for the current ui. The next-gen-gui does have it I think (and itâs angular too, so maybe re-usable.
Also likely possible to just adapt whatever happens for next-gen-gui.
Hey Guys, i would like to help out with the new GUI. But I am confused on whether i should continue work on the Gui present in next-gen-gui folder or Start a new project. I tried building the next-gen-gui and it threw a bunch of errors at me that i couldnât understand.
Hi, is it possible to publish a rebuilt updated zip? I tried unzipping the one from github Releases which is dated 17 april 2020 but the github project says the project is archived. Is there anywhere an updated tech-ui zip file? Thanks
You need to build yourself adding --with-next-gen-gui to the build command. The Docs explain how to build Syncthing itself (see https://docs.syncthing.net/dev/building).
Do we no longer have any pre-built archives of the new GUI available for download. I know there is a release ZIP in the archived repository as a release. I donât think much has changed really since then, after it moved into the main repo. You could just try and use the v1.0 ZIP release, as described in the README under the main repo subdirectory: syncthing/next-gen-gui/README.md at main · syncthing/syncthing · GitHub
Since Iâm a doctor, I might be able to fix the baby. We can also make a new one but the pregnancy takes a couple of months and maybe the new baby has itâs own imperfections that we have to solve after giving birth as well. Fixing the current baby requires a lot of medicines, but it can still be quicker and along the way we can deprecate / improve things while quickly bringing fixes to the userbase so they will experience improvements as the baby gets healed step-by-step.
