Great work, and thanks for sharing. It is important for this project to keep gaining momentum, and the more user friendly ways people can use Syncthing, the faster people will begin choosing it over proprietary alternatives and contribute to its improvement.
I look forward to trying it out and learning from your code!
Knowing both your syncthing and syncthing-gtk versions would be helpfull. And, please, try to run syncthing-gtk from terminal and copy error messages here or to pastebin, if there are any.
Gnome-shell probably uses similar non-standard way to display notification icons as Ubuntu/Unity does. I’ll look into it.
It’s there. If daemon is not detected at start and syncthing binary is in path, syncthing-gtk will ask you if you want to start it in background, with checkbox saying “Always start daemon automaticaly” in same dialog.
I’m not quite sure how is that even possible, as both dialogs are using same code…
Settings are saved in ~/.config/syncthing-gtk/config.json, you should be able to set autostart_daemon to true there as workaround. I’ll check where did that checkbox gone in meanwhile.
// edit:
Ok, I found how is that possible… GTK can be funny thing sometimes. You can use that workaround, or just update package to version with fix from AUR.
Is it planned to have some syncthing-gtk specific configuration-manager? As far as I know it has only 2 checkboxes for itself (allways start and allways quit). But when you want to uncheck them again you have to go into the config-file and change it by hand
You mention you’re using Arch. The Arch package has a systemd service file to autostart ST:
sudo systemctl enable syncthing@$USER (to autostart on boot)
sudo systemctl start syncthing@$USER (to start now)
@kozec: Just installed Syncthing GTK 0.5 on Windows (Windows 8.1 x64) and it crashed upon first start.
cx_Freeze: Python error in main script
Traceback (most recent call last):
File "c:\Python27\lib\site-packages\cx_Freeze\initscripts\Console.py, line 27, in <module>
File "scripts/syncthing-gtk-exe.py", line 42, in <module>
File "c:\syncthing-gui\syncthing_gtk\app.py, line 67, in __init__
File "c:\syncthing-gui\syncthing_gtk\configuration.py", line 66, in __init__
File "c:\syncthing-gui\syncthing_gtk\windows.py", line 145, in save
File "c:\syncthing-gui\syncthing_gtk\windows.py", line 155, in _store
Type Error: object of type 'NoneType' has no len()
“NoneType” sounds like as if it is missing something (config file?), therefore it bombs out.
EDIT: Looking at the windows.py in your repo… line 145/155 is right there in the middle of “messing about with the Windows Registry”.
Any ideas what to try to help fix it?
I downloaded the installer from the link at your GItHub repo.
As a value added comment: The HKCU\Syncthing-GTK key got created, and it contains even four entries. Still, keeps on bombing with the exact same error as posted above.
[quote=“BJay, post:18, topic:709”]
Suggestion: Since it just updated 0.10.5 -> .6, dismiss the “Quit” button in the “Syncthing is restarting” window.
[/quote]Yeah, that’s good idea, I already managed to quit by mistake from that window once
[quote=“BJay, post:18, topic:709”]
Now I only need a openSUSE RPM for Gnome and I’m totally satisfied.
[/quote]I can look into into that as well, unless it’s on comparable level of crazyness with making DEBs.
You almost got me with that “Quit” button in the “Restarting” window as well… I was looking at it considering “why would I want to quit it?” and then it went away because Syncthing had already restarted. So… you almost got me there.
As for RPMs … this is the reason why I steered clear of RPM based distros in the past.
Creating a DEB is a piece of cake. Don’t know what problem you have there, I created/modified a metric buttload of them over the years, but we can talk about it. DEBs are only a pain when you deal with “distributing via PPA” (like Andrew does for you in his WebUpd8 PPA) where stuff has to build on Ubuntu’s cloud from source and you can’t simply slap a “hacked together” DEB up there.
Creating a RPM is the ultimate pain in the rear (at least in my opinion). I tried reading up on it to try and make a openSUSE 13.2 RPM out of your binary tar.gz but gave up. While I’m not dumb (only 19 years of “messing about with Linux” under my belly), I refuse to wrap my head around that RPM mumbo jambo when they (Red Hat) can’t even cough up a worthwhile documentation on how to get that stunt done. I never liked that RPM stuff to start with, hence why I ended up preferring DEB based distros.
I mean … really … for a DEB you just make a project directory containing the right folder structure as well as the correct files in “DEBIAN” and then run dpkg-build to wrap it up into a installable package … with RPM I don’t even get to where I have to put that effing spec file. InfiniteFacepalm@RedHat
So, I’m not sure you want to go to the trouble to crack that nut or if there’s some easier way to hack together a RPM I’m totally not aware of (I just came to use openSUSE because it’s the only distro that “somewhat works” - much unlike Ubuntu GNOME where half of the stuff is broken or doesn’t work as expected).
I’d like to use the traditional window header (I’m not on Gnome, so the gtk3-integration isn’t that great)
![[img]/uploads/default/295/a0d6fcad53fb33d5.png[/img]](http://i.imgur.com/eX250tQ.png){kind=link}
![[img]/uploads/default/296/44b56377da964b8a.png[/img]](http://i.imgur.com/RTRgRdC.png){kind=link}
![[img]/uploads/default/297/7037133a71ff47b9.png[/img]](http://i.imgur.com/5swe82V.png){kind=link}
