syncthing-gtk
syncthing-gtk copied to clipboard
kozec
Any forks on this?
This has not been maintained in a few years but is a good GUI for Syncthing on Linux.
Are there any forks of it out there that anyone know of?
I took the liberty to open an organization for this, maybe we can maintain a fork there, even if temporary? https://github.com/syncthing-gtk/syncthing-gtk @Rudd-O is invited as an owner.
Ah, but there is also https://salsa.debian.org/debian/syncthing-gtk, no idea how related/changed it is.
Thanks @hrehfeld I think if @kozec is not responding, we should simply use that org. @hrehfeld feel free to merge my pull requests onto your fork of this thing.
Thanks @hrehfeld I think if @kozec is not responding, we should simply use that org. @hrehfeld feel free to merge my pull requests onto your fork of this thing.
:+1:
I directly forked your repo, so everything should be there. Also, you should have an invite as an owner.
Maybe we should ping the debian guys and see what they think?
I have a cleaned up tree of syncthing-gtk here. It's a merge of the version in Debian by @andrewshadura and the @Rudd-O branch. It's flake8 (pep8 + pyflakes) clean and also has a couple of small fixes on top of the code cleanup.
Feel free to build on top it, cleaning the code took a couple of evenings, so you'll save yourself that. I have some further plans with the code, but don't have time for them right now.
Oh, I’m a bit surprised this all happened without anyone telling me 😕
I’m not impressed by this situation. My fork was created ages ago, I gradually worked on these issues, only for my work to be partially re-done and lost.
What do you suggest how we proceed under the assumption that the original maintainer is gone at least temporary?
19 Sep 2022 23:19:25 Andrej Shadura @.***>:
I’m not impressed by this situation. My fork was created ages ago, I gradually worked on these issues, only for my work to be partially re-done and lost.
— Reply to this email directly, view it on GitHub[https://github.com/kozec/syncthing-gtk/issues/591#issuecomment-1251570944], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAATX57MFP4KVPD66IZB5Q3V7DKFDANCNFSM6AAAAAAQIIPSFM]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AAATX5ZTVCDFFUUKUUHXTHTV7DKFDA5CNFSM6AAAAAAQIIPSFOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSKTF2QA.gif]
Well, I tried to maintain a working fork and I actually started some refactoring and UX rework (according to #567), but true, I didn’t work on it for a couple of months as I was busy with other work. So at least I’d expect that Manuel would take my work as a base for his Fedora port and contribute back, and maybe that could become a new upstream for Syncthing GTK. As you may have noticed, I tried to keep the history clean and polish up all patches I took from other forks.
By the way, my assumption is that the original author is not coming back, and, honestly, I’d not be surprised if this repo would be gone any day with all reported issues and other things.
Let's continue with the syncthing forked org and move on from this maintainer. I will be working with that forked branch (which included my changes) from now on.
@Rudd-O, given that you re-implemented most of the work I did in my branch, wouldn’t it make sense to start with mine instead?
https://github.com/syncthing-gtk/syncthing-gtk already has everything plus more fixes than my work alone, and it works fine. Please merge your improvements there! Thank you for your contributions! :-)
Does it? This seems very unfair, having my work thrown out despite it being around for ages.
I think I used your work as a base for mine! Either way both our works would inevitably converge on the same result — pep8 blackened code that works with Python 3.
You didn’t, otherwise you wouldn’t need to port it to Python 3 once again. In any case, porting to Python 3 wasn’t the only thing I did.
Correct, which is why your work is definitely beneficial for the now-active fork of the project.
the aur package for syncthing-gtk-python3 is now pointing to https://github.com/Salamandar/syncthing-gtk . Yet another fork? @Salamandar
@andrewshadura I get your grief, but please don't feel insulted. I simply didn't find your fork earlier (and it seems @Rudd-O did neither); shit happens. I'd really appreciate it if we get some traction maintaining this together, and I don't think work is lost, really.
@hrehfeld @andrewshadura Yes I forked it from salsa because it need one patch for the AUR package, and salsa didn't accept my register request (without explanation), so I couldn't even do a MR on it…
@hrehfeld doing an org on github is a good idea. I'm willing to delete my fork if I'm added to it :D (the repo can have protected master branch, with PR-only merges).
I was actually working on cleaning up the code. There still is a lot of stuff from the python2 era. Also, pushing for gtk4 might be something worth working on.
I was also working on clean-ups, I tried porting to GTK 4, but I was first focusing on getting rid of custom widgets in favour of standard GTK ones. Unfortunately, I wasn’t able to spend much time on it lately.
@hrehfeld, I’ve just compared my fork and the other one, and apart from the fact the history is much cleaner in my version, many important fixes are missing in the one Rudd-O created.
I propose this way forward: I’ll spend some time this week to reconcile the forks and merge Rudd-O’s changes into my more complete fork, then we push it as a main branch into the new repo and make main the default branch. I also have a bunch of work in progress things which I’ll also push there.
Why not work in the Syncthing-GTK organization that Salamandar created?
You mean @hrehfeld I think :) But yes, I agree !
As it looks like the choice of the fork is subject to debate, a "politically correct" way to start this fork would be to take this original repo as base and everyone would make their own pull request on it :p That would be a bit of work to redo the PRs, but at least it wouldn't favorise anyone's work…
My main priority is less favoritism — rather it is to deliver the biggest and most impactful fixes and improvements to the thing that then everyone uses. That means this work would have to be ego-less. An organization seems to me to be the right way to go — even if my code is wholesale thrown out — of course, so long as whatever is published through the org is, in fact, functional.
Furthermore, instead of starting with a monstrous PR, I think it's best if we receive small incremental PRs that fix things as independently as possible, so that we may review them and test them more easily. My 2 cents.