Syncthing-gtk - GUI for syncthing - now with inotify support

Announce
26

kozec, after a lot of messing about I managed to get a first RPM going, though there are a few draw-backs…

  • It only works when building on the local machine and the resulting RPM is only for the current architecture (in my case x86_64).
  • It does NOT build on the openSUSE Build Service (OBS). I tried setting up a repo but the build bombs with some error near the end in regard to a syntax error in the .desktop file, and since openSUSE doesn’t seem to give a rats ass about providing a meaningful documentation I won’t bother (if the OBS build would work it would spit out i586 and x86_64 RPMS in the “Home” project repo).

Now …

I whipped the stuff I did into a file on copy.com

The file contains the readily built x86_64 RPM for openSUSE 13.2 as well as as .sh file to run the build (having run “sudo zypper install rpm-build” prior to launching the script is a must) along with the required spec file - it’s meant for version 0.5 ONLY! Also, if you compare the “Requires” to the “Depends” of Andrew’s DEB please know that the “gir1.2*” libraries do NOT exist in openSUSE, but that doesn’t seem to keep syncthing-gtk from working. Also, the fancy tar extracting and tar creating I do in the build script is necessary … the -gui in the directory name of the tarball doesn’t really go very well with the -gtk project name, that’s why I need to extract to rename the directory to wrap it up into a new tarball … otherwise the build would bomb (yet again).

If you, kozec, or someone knows how to fix the OBS problem up (it’s complaining about the icon resource in the .desktop file) so it can be built on the OBS I’m more than willing to maintain a repo - for now I had enough of the RPM idiocy. If the exact error message the OBS throws needs to be known I happily provide a log.

27

I am sorry to interrupt your discussion.

@kozec : You mention that you now support inotify.

I think it was not supported by syncthing yet and I am also telling people so. eq: #989. Should I rather tell people to use your syncthing-gui?

28

I still suffers from the same issues which were big enough that it is still not part of the normal syncthing. Which is the default kernel limits on OS X/BSD only allowing to watch 256 files/directories at one time: http://git-annex.branchable.com/bugs/Issue_on_OSX_with_some_system_limits/

29

@BJay Thanks, I should still have OBS account somewhere, so I’ll check that error. Having OBS to do all packaging work would be nice.

@bigbear2nd It’s exactly as @AudriusButkevicius says, inotify works, but only within it’s own limits. It’s possible to increase limit and it is possible to enable inotify only for repositories where it matters, but it’s still limited thing.

But I’m not aware of any better way to do filesystem monitoring, so it’s probably as good as it can get.

30

[quote=“BJay, post:26, topic:709”] It does NOT build on the openSUSE Build Service (OBS). [/quote]I have to admit, it was exactly as bad as you described it. But not impossible. Here are working RMPs in OBS.

Problem is syncthing dependency. Althought there apparently is syncthing package in OpenSUSE, it’s probably not part of default repo and package installer will not find it. Is there any way how to reference syncthing package, or user will always have to install that dependency manually?

31

The syncthing package on the OBS is a user project; see openSUSE package for Syncthing as an example.

However, depending on “syncthing” is actually an option for your consideration:

  • if you want to depend on a 3rd party packaged RPM you can go that route and hope that the package is updated in a somewhat timely manner whenever a new version is released.

  • You could use the “first run” wizard to put the binary into /usr/bin yourself if you find a way to put the file there with elevated rights (only root can write to /usr/bin, so you would need to find a way to elevate for binary install/update). The syncthing binary doesn’t require anything extra; everything is statically linked into it (a very good practice in this case).

  • You could go the “per user” route. In this case it would be best to find a suitable place for dropping the binary to (i.e. check if $HOME/bin exists … if yes, drop it there - if not, create the directory and drop it there … that way you at least follow a somewhat official way to have a binary in the user directory “sorted out and properly placed”) and have it launched it through your UI (either when the user starts it up or when it loads upon logging in to the session because its set to autostart).

I would run with either the 2nd or 3rd option if I would be you. Why? Well…

The “syncthing” package is actually meant for “daemonized startup on boot”. This means: A user using the package will most likely not have any use for your UI and instead use the web UI because it is either running on a server server where there’s no X11 or on a totally headless system. “Joe Average” will most likely use it in his user context anyway, so dropping the binary into the user directory is a safe bet in this scenario.

I think there’s also a way to declare a “Conflicts” in a RPM spec file if you want to “clash” on purpose with the “synthing” package - to avoid having a system-launched instance and your user instance at the same time.

Anyhow, great to see you resolved the problem that prevented the OBS packaging going through. Will add your OBS project as a repo to my system. In the meantime I actually found out that SUSE is hiding the documentation on openbuiidservice.org (the link on the build.opensuse.org site isn’t really obvious nor does it stand out that one can find the documentation there - structuring and organizing things isn’t a particular strength of the SUSE lot).

EDIT: Added your OBS home project as a repo and installed it (I “broke” the dependency with syncthing because I already had the binary in $HOME/bin and the config.json was already all set from my packaging attempt).

One thing to note that you should point out: When adding your home project as a repo (the “zypper” way) it will not be auto-refreshed by default. If you publish an update it therefore won’t reach the user. To receive updates as you publish them one needs to run…

sudo zypper modifyrepo -r <repo url>

…once, after adding the repo, to enable “auto-refresh” and stay up-to-date.

32

I ended up going by route #3. Existing ST packages are already out of date and unless there is same way how to let OBS to build packages automatically, I’m not going to keep and update additional…

But Syncthing-GTK can connect to daemonized instance (instance started by rc script) or just launch /usr/bin/sycnthing installed from package, so there is no need to make it conflicting. Also, downloading binaries to ~/bin is probably best solution on OpenSUSE, but completely crazy idea in general :slight_smile:

33

It’s not as whacked of an idea as you may think it is.

While the $HOME/bin directory is not exactly defined in the LSB standard (which no one follows really anyway), it’s a well accepted solution to put “user binaries”, only runable by the corresponding user, into the home directory for quite a while now. EDIT: Of course only for as long as the binary/script can make due with user privileges and not require elevated rights to run. /EDIT

In openSUSE there’s actually a empty bin directory sitting in the user home by default, in Ubuntu/Debian (and derivates thereof) it’s not there by default but the bashrc (global one in /etc and the dot file in the user home) contains a check to add it to the path if it exists.

The LSB compliant way would be, of course, to properly base files under /usr or /usr/local (though /usr/local became somewhat unpopular) or /usr/sbin (daemon binaries for example), though that would leave you again with the problem of having to spawn a child process with elevated rights to put/update a file at that filesystem locations.

While it may look kinda weird to place a binary in $HOME/bin it’s not “against guidelines”; and let me tell you that I have a ton of shell/python/perl scripts as well as real binaries sitting in my bin directory.

The only valid complaint might be that it’s “unusual” or “not best practice”, but then show me a Linux desktop system (meaning: used in the same likes as a Windows box) where there are really several users logged in at once. The default internal syncthing UI at 127.0.0.1 would then become a problem (clashing for local IP:Port) when launched concurrently from several user accounts on the very same machine, unless syncthing has a “sanity check” to spread out on the ports on 127.0.0.1 automatically (i.e. first instance at 8080, second one on 8081 and so on - haven’t checked if there’s a handler in syncthing to resolve that on-the-fly); that’s when a daemonized launch in the likes of “for $user in $launch_for_users” would be the way to go so you can pre-define the config for each daemon process).

If someone complains refer them to me - I’ll handle it. :wink:

34

[quote=“BJay, post:33, topic:709”] The default internal syncthing UI at 127.0.0.1 would then become a problem (clashing for local IP:Port) when launched concurrently from several user accounts on the very same machine, unless syncthing has a “sanity check” to spread out on the ports on 127.0.0.1 automatically (i.e. first instance at 8080, second one on 8081 and so on - haven’t checked if there’s a handler in syncthing to resolve that on-the-fly); that’s when a daemonized launch in the likes of “for $user in $launch_for_users” would be the way to go so you can pre-define the config for each daemon process). [/quote]Actually, 1st run wizard in ST-GTK checks for this and sets HTTP to first unused port >= 8080, so there shouldn’t be any clash even in multiuser or multiuser+systemwide daemon environment. But it’s true that I can’t remember seeing machine running multiple desktop sessions in this century :smile:

35

For a change of pace, bugreport for the Windows version (0.5.1)…

Bug: On Windows 7 and Windows 8, using the native Windows decorations, the Syncthing-GTK window is always placed on top/left of the screen and slightly out of the screen. Doesn’t happen when using the internal window decoration, in that case the windows is pixel-perfect aligned with the top/left of the screen (that’s what I tend to use to “unify” the look between Linux and Windows).

Repropduce: Just restore the Syncthing GTK window from the tray icon.

Bug: “Anon Data Collection” doesn’t stick on Windows. The checkmark remains checked at all times. Unchecking and restarting Syncthing GTK shows it checked again.

Reproduce: Try to uncheck the anonymous data submit option and either go back into the pref screen or restart and go back into the pref screen … will show as checked.

Bug: For whatever reason I can’t figure out the “repo” (left side) and “host” (top/right where there’s also the status of the annouce server shown) section within the main windows is always collapsed. On Linux, the repo and the host are always expanded.

Reproduce: Just open the Syncthing GTK window and all “panes” inside the window should be collapsed.

Bug: Shortcut (in the “Start Menu”) is created with the wrong icon resource path. Syncthing GTK installs into “C:\Program Files (x86)” on 64-Bit Windows Editions. The path to the icon resource in the shortcut reads “%ProgramFiles%\SyncthingGTK\icons\st-logo-128.ico” (that would be the case for a x64 program) where it should actually be “%ProgramFiles(x86)%\SyncthingGTK\icons\st-logo-128.ico”. I think that’s the installers fault - it needs to differentiate between 32-Bit and 64-Bit OS versions.

Reproduce: Right-click the Syncthing GTK shortcut -> Properties -> Change Icon. Throws an error message about the .ico not being found due to wrong path.

36

There is an issue tracker on github :wink: Let’s keep the forum tidy.

37

Feel free to delete the posts bothering you. That being said … I don’t have a Github account so the option to post to the issue tracker is kinda outta reach - I’m running in-house Git servers, so “then go and create an account” is also out of question as I have no use for “cloud source repos”.

38

Lots of people who don’t push code have GitHub accounts, for the purpose of filing bugs or otherwise. You don’t have to, for sure, but it’s the common way to make a note of a problem and make sure it’s not forgotten.

I don’t think Audrius is particularly worried about polluting the forum, so there’ll be no deleting of posts. But a bug report in the middle of a forum thread does run the risk of being missed or forgotten, now matter how well everyone intends otherwise.

And if nothing else it’s annoying to push a commit to solve “post #35 in that forum thread #709 on discourse from last year” instead of “fixes #1234”.

1 Like
39

Thank you for reporting. I created the bug reports for you on github:

40

Oh god, man is afk for 3 days and this happens O.o

Asking on github will not work, I guess, so @BJay, can you please check if window position gets saved to registry? It should be stored in User/Software/Syncthing GTK/window_position_0 and window_position_1 every time when window disappears (and reused when window gets mapped back). Only problem I can imagine in this is some sort of crazy multi-monitor configuration where window position gets to negative values…

And question #2, I’m not sure what do you mean by this:

All boxes should be collapsed when app starts…

41

Well, the Synthing-GTK windows consists of two areas. Left side (the repos) and right side (host overview and peer list below).

On Linux the “Default” repo on the left side as well as the “Host” on the right side (the area where you see the RAM/CPU/DL/UL/Announce/Version stats) is always expanded, on Windows all items are collapsed.

I actually find having the “Default” repo and the hosts stats expanded quite useful … doesn’t really bother me that the other repos and peers are collapsed.

So, while you say that all items should be collapsed the Linux version doesn’t seem to obey you. :wink:

42

[quote=“BJay, post:41, topic:709”] The values exist under the given registry path (on W7 and W8.1) and read:

window_position_0 == 9window_position_1 == awindow_position_size == 2 [/quote]Can you, please, move window somewhere towards bottom-right corner, close it there and refresh regedit? Just to check if values are getting changed, preferably to some big numbers.

43

Okay, I managed to get rid of the “window misplacement” by updating my Nvidia driver (to the latest-and-greatest “game ready” release), but now I see a totally different “bug” (?)…

Firstly, the values get saved:

Moved the window around, quit Syncthing-GTK, looked into regedit

use_old_header = 0x0
window_position_0 = 0x310
window_position_1 = 0x1b5
window_position_size = 0x2

Started it again, enabled “Traditional”, moved the window again, quit Syncthing-GTK, looked into regedit

use_old_header = 0x1
window_position_0 = 0x237
window_position_1 = 0x5c
window_position_size = 0x2

BUT … upon firing it up again the “old” decoration doesn’t show up!

See this screenshot

Look at the main window behind the “UI Settings” - that’s the “Linux/GTK style decoration” (and I swear that I did quit it after setting “use_old_header” and start it anew).

I uninstalled Syncthing-GTK, cleared out the registry, re-installed from scratch, and ran the test again with the same result you see in the screenshot - while “use_old_header” is enabled the window shows the other way around. Am still not entirely sure that it’s a bug, but I think I better leave it to you to rule it out.

EDIT: I’m tempted to believe the decoration issue could be a Windows bug because… when I open/hide the Syncthing-GTK window it randomly shows with the top left/right corner of the main window being edges instead of rounded corners. I’d say this looks like dwm messing up compositing the window; Windows (Vista/7/8.x) has a history with GTK/Glade based applications having issues.

I guess when I have a some time to spare I’ll try to get a C# based port rolling so you have a native Windows version (especially now that Microsoft is giving away Visual Studio as a “Community Edition” that’s en-par feature-wise with VS Pro) - if that idea is fine with you. /EDIT

44

I’m afraid I got lost at that part where window misplaceament bug was caused by graphics driver O.o I mean, I of course don’t doubt you, but I really can’t see how that could be related…

Porting python-based Syncthing-GTK to C# is probably more impossible that doing same for c-based GTK, but if you are for such task, it will surely help to much more people than just me :slight_smile:

But use_old_header being ignored sounds like bug, I’ll look into it.

//edit: And since you probably don’t watch issues list on git, startup menu icon, non-expanded boxes and not sticking anon data collection checkbox bugs are solved in latest release. Thanks for reporting :smile:

45

[quote=“kozec, post:44, topic:709”] I’m afraid I got lost at that part where window misplaceament bug was caused by graphics driver O.o I mean, I of course don’t doubt you, but I really can’t see how that could be related…[/QUOTE]

Well, it also affected HexChat (IRC Client that also uses GTK) on Windows - the window was also restored to the very top/left (and slightly off-screen) … with the latest Nvidia driver that oddity is gone. Sorry for the “false positive” bug.

Yea, I know that this is no “simple port from Python” but a re-implementation from scratch by trying to make the interface look exactly the same (that’s the tricky part; unless I’m mistaken I don’t think there’s any foundation class that would allow for rounded screen borders).

Anyhow, once the christmas insanity is over I’ll sit down and start coding so we have a first test build by mid/end January.

I guess it would be also easier for you if you could focus on one version instead of trying to untie the “multi-platform” knot. Though, the only thing I don’t plan on doing is making a Metrocalypse tile happen. I develop with “Visual Studio for Windows Desktop”.

Roger that.

No problem man, it’s always fun tinkering around with the knobs and wheels to maybe find a bug. :wink: