SyncTrayzor: Windows host for Syncthing. Installer, auto-start, built-in browser, tray icon, folder watcher, and more


(David Rimmer) #142

When I right-click on the trazor icon in the system tray, it usually takes around 5 seconds for the context menu to appear and a further 5 seconds from hitting restore for the window to appear.

OK, it’s only a minor inconvenience, but am I the only one to get this behaviour?

I use the task scheduler to start it (v1.0.18) 10 miinutes after logon, so it runs below-normal priority. However, CPU% is low.

Any ideas?


(Antony Male) #143

How much RAM does your machine have, and how much is in use when you right-click the tray icon? My suspicion is that Windows has decided to move SyncTrayzor out into swap space to free up some RAM (which is a completely sensible thing to do), and is then having to swap it back into RAM (maybe shifting something else out first) before it can respond to that click event…


(David Rimmer) #144

4GiB mem, 47% phys mem in use. 4 sec for context menu, further 5 sec for stzr window, further 10 sec for st to appear.


(Michael Jephcote) #145

I have the same issue, I’ve described this before SyncTrayzor: Windows host for Syncthing. Installer, auto-start, built-in browser, tray icon, folder watcher, and more


(Antony Male) #146

Apologies - I’ve been busy elsewhere recently.

What’s interesting from your screenshot is that SyncTrayzor is reading pagefile.sys. This implies that Windows decided you weren’t using SyncTrayzor, and moved it out into your pagefile in order to free up some RAM. The 4 second delay, then, is Windows going “Oh shit”, and loading everything back into RAM. If you tried the context menu again, straight afterwards, I’d wager it would be very quick, as everything’s already in RAM.

Likewise, I’ll bet the 5 second delay is still .NET’s UI framework being loaded into RAM.

The 10 second delay is likely a combination of the embedded browser being loaded (possibly even from disk, if this is the first time you’ve opened SyncTrayzor since your computer started), and SyncThing waking up enough to respond to our HTTP requests. Again, subsequent loads should be a lot faster.

Even if I knew of a way to stop SyncTrayzor from being moved out to the pagefile, I wouldn’t want to do it: SyncTrayzor does use a reasonable amount of memory (heck, it contains a web browser), and keeping it permanently in RAM even though it’s not in use 99.99% of the time is hardly a nice thing to do.


(David Rimmer) #147

I took the screen shot before I right-clicked the icon. So Windows seems to be predicting my right click! Strange.

True.

SyncTrayzor can remain effectively inactive for many hours - well beyond the patience of windows to remember it’s both in memory and on disk. Now this is just a thought, feel free to debunk it or say it’s not worth the effort. Perhaps stz (do you have an official abbreviation for SyncTrayzor for the lazy?) could exit to a small stub designed to speed the appearance of the context menu, loading the main program to process it. It’s only the delay before being able to select from the context menu that matters (did I right-click the icon?, better try again…)


(Antony Male) #148

Yeah, that would be the ideal. It would mean I could completely unload the browser when SyncTrayzor isn’t active (at the moment I can only partially unload it).

Unfortunately, it’s a pretty large chunk of work. Syncthing would need to be hosted from within the process which owns the tray icon, so I’d have to change a lot of stuff in the GUI process to use IPC to deal with Syncthing. There’s probably a fair bit of complexity around rewriting the different close to tray / minimize to tray stuff, and the update mechanism would be split cleanly down the middle as well (updates happen in the background, with a tray notification, a dialog notification, and ways of triggering updates from the GUI). I’d estimate it at 4-5 man-days.

Not insurmountable by any means, but don’t expect it any time soon! SyncTrayzor’s written in my free time, which amounts to my lunch break, and there’s a reasonable amount of stuff on the backlog already.


(Antony Male) #149

Out of interest, you can watch “Hard Faults/sec” in the “Memory” tab as you open SyncTrayzor / its tray context menu. Mine got up to 26 as it was pulled in from the paging file!


(David Rimmer) #150

Fair enough. :smile:


(David Rimmer) #151

Mine got up to 65! [Here’s a little video of it happening][1]

Is it feasible to improve locality of reference to reduce the number of pages needed at any one time? [1]: https://www.youtube.com/watch?v=FbppCEFOgBs


(Antony Male) #152

OK, so you’re seeing a few seconds each to load the context menu and then the main window, while the majority of the time is spent waiting for Syncthing’s GUI to load? After I’ve got the next release out, I’ll take some time to take a hard look at what’s going on.


(David Rimmer) #153

Thank you.

Yes, it’s just as you say.

In my view, it’s the first wait (for the context menu) that matters most. In this one, the user is waiting to select from the menu. In the other two, he is just waiting for something to appear on the screen - he has done all he needs to do right away and can do something else while waiting (read an email?..)

Waiting for the context menu forces him just to wait - far more frustrating.


(Antony Male) #154

That context menu is also going to be the hardest one to dig into - there’s exactly none of my code between the click event happening and the context menu appearing. I had a look at the code that does run, and there’s not very much of it either - it’s all native winapi stuff. I honestly don’t think there’s anything I can do here (I tested some other applications and they all took about the same amount of time), but I’ll take a closer look.


(Urza) #155

Contgratulation on the new version of Synctrayzor with the dropbox-like popup window. Looks good.


(Antony Male) #156

Thanks! I’m aware there will almost certainly be another iteration or two before this functionality is properly polished, but thought I’d get a version out there and get some feedback. In other words, any feedback gratefully appreciated! The discussion is in


(Michael Jephcote) #157

WHatever you do, please don’t change the current behaviour of opening the files location with the file selected when you click on it from within the popup window or if you do make it customisable within the settings. I much prefer this to automatically opening the file!

Great work


(Antony Male) #158

Yeah I’m not sure what exactly to do with this behaviour. I’m glad you found you could click items - I didn’t think it was that obvious, and would be open to ways of making it more obvious.

Also, currently clicking a deleted file doesn’t do anything, and I’m not sure whether it does. We also don’t show what folder a file’s in…

Thanks! :smile:


(Michael Jephcote) #159

Yeah it would probably help if:

  • You show the folder directory
  • Highlight items on hover with the native Windows colour
  • Grey out deleted items
  • When hovering over the time show the actual time/date in a tooltip or always show it next to the human time
  • Possibly change the title of the popup to Sync Overview?

Also would like:

  • Hover over the tray icon to show a tooltip of the current transfer speeds
  • The transfer notification balloon to show the file that’s just transferred

(Antony Male) #160

I couldn’t find a nice place to fit that in! I don’t want to take up too much vertical height with each item, and an item’s name might be very long so I don’t want to add anything to that row…

Yep, worth doing I think.

Now that’s a good idea.

Yep, nice idea.

Maybe

Heh sure. This tray icon is fast becoming extremely multifunctional (different things done on single click, double click, right click, hover, etc). Not sure how much more I want to cram in…

Now that I can’t do. The balloon notifications show when a folder has finished syncing: that is, Syncthing has told us that it was in the Syncing state (blue on the GUI), and is now in a different state.

This means that the balloon is shown when we’ve finished uploading our index to another device, which means it catches the case where we want to know when a file has uploaded (ish).

Syncthing only tells us the names of files that it downloads. We get these names through a different mechanism, which gives us all the info we need to display the new ‘transfers’ window.

Now I could change the balloon to only show downloads (and never indicate a potential upload), but that doesn’t feel right.

Also, if I display every file that’s downloaded in a balloon, the user is going to be swamped with balloons if they’re synchronizing a lot of stuff, which I’d rather avoid if possible…


(Michael Jephcote) #161

Would be very beneficial for our users, lots of them edit the same spread sheets but cannot edit at the same time. These spread sheets contain lots and lots of data so they need to wait until the other user has finished making changes before opening it and doing their changes so as not to cause a conflict as it takes too long to merge differences.

I think add these in addition to the Folder Sync Complete notifications and have a setting to turn them off or on (default off)