You are aware that angularjs (!= angular) is discuntionued? Of course you can update it to the latest release from last year, but it wont receive any updates after.
Yes I’m aware. I don’t see a lot of value in upgrading AngularJS. Upgrading AngularJS to Angular is something I can also do, but I can’t do both the Angular upgrade AND the bootstrap upgrade because that is simply too much at once. I rather work on one thing, bring it to the users and when that is done, start on the next thing.
So my endgame is to help you guys and the userbase by creating something cool in a relative short timeframe with new tech. These long forum talks is not what I joined in for, but it’s important because we have to be on the same line right. If I’m spending days on development in Bootstrap 5 to see it getting dropped in a PR at the end because “we want to support IE”, I’m not happy hope you guys understand that.
So what I’m looking for now is a GO or NO GO. I want to spent some days in it and show you guys more what I have in mind. The maintainers can give feedback during this proces or even decide to drop the whole design I create if the maintainers don’t like it, no worries. When it’s more finished, we can do some beta testing and search bugs. However… I need to be sure you guys approve the bootstrap 5 strategy AND the strategy to upgrade the existing UI. There is no point of upgrading to bootstrap 5 if the PR is not making a chance to get merged to begin with.
To be honest, I think making the code maintainable/composable is of more value than upgrading some css stuff.
I’d take a plaintext ui that has sensible component abstractions and makes it possible to add new features without risking breaking everything, over some css upgrades that keep a single massive type-less js blob.
Ok fair point. I’m assuming you are referring to the upgrade of AngularJS to Angular? Problem here is that since Angular 13 the support for IE is dropped. Latest version is Angular 15.@tomasz86 said he rather not drop support and I’m not going to work with Angular 13 so I don’t think this upgrade is something I can work on.
AngularJS is the very backbone of the current GUI. If you replace it, isn’t the process essentially equal to rewriting the GUI from scratch? If you do manage to do it and the new version is significantly better (e.g. using modular components instead of one large JS script to handle everything, etc.), then why not take the @imsodin’s suggestion about keeping the old GUI around?
This would allow to utilise the newer technologies while also not leaving behind those who can’t use them (for whatever reason). I can probably even offer to keep working on the old GUI myself (= mostly make sure that it still functions) if there’s need for that in the future.
It doesn’t really matter if you look at it as a new UI done from scratch or just a big change of the current one. If necessary the old one could still be shipped alongside the new one either way.
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.
If I’m spending days on development in Bootstrap 5 to see it getting dropped in a PR at the end because “we want to support IE”, I’m not happy hope you guys understand that.