-
-
Notifications
You must be signed in to change notification settings - Fork 862
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Notification support via libnotify #270
Conversation
ee41add
to
5442d6b
Compare
What happens in the event the 'notification' code is built into the application, but there ends up being no X / GDM or whatever .. like a headless server? Will the notifications just fire & not produce an error - or will some sort of error message somewhere be created/generated? |
The errors are The worst thing I have seen on my system is that on startup the first So on a headless server the worst problem is that the first sync operation is delayed not 45sec but 45+30sec. |
Just tested this via CentOS 7.x When running in monitor mode, and the following log (basically editing a local file via 'vi'):
The last item above I think the whole issue comes from 'monitor' mode wanting to sync 'temporary' files that are created when files are opened localled / being edited whilst 'monitoring' that actual directory.
Readme / man entry says - monitor mode will send notifications about initialization and errors via libnotify to the dbus |
Yes indeed. That comes from the monitor callback where the I will look into this in a different issue, no good reason to do this here.
Yes, as said, successful operation do not trigger a notification.
Yes, and the problem you mention is an actual error and should be reported, only that onedrive should deal with this error in a better way, in the sense that it should not occur in the first place ;-) |
Since you approve, are you fine with merging, should I do it or do you do it? BTW, I don't want to mess with your style, so please let me know what your preferred modus operandi is:
Thanks |
I have been using "squash and merge" so that in the case of most PR's there have been a number of commit's into the PR itself - that way, the commit into master is a single commit - whilst larger, with the Travis CI testing / building and running I have going on, it reduces the risk of a commit causing compilation & execution failure. It would be good to work out how to 'fix' the Travis CI shared key when building (which is why for everyone else's PR x64 build fails) so that when x64 is tested, the application tests I have currently run & execute for everyone as this tests upload / download & cases where bad characters have caused issues in the past.
I dont mind if your doing this - the code has to get at least 1 review so that there is visibility - the more eye's that are on it, it get's improved & developing this is also not my day job either :) |
@abraunegg Concerning the Travis CI shared key stuff, that is not possible: https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions If you don't mind, I will create my development branch in your repository in the future, and create a PR from there. PR from the same repository have access to the env vars and testing should work. I think I will
that way travis works. Another thing concerning travis: why did you go for travis-ci.com? There is a limited number of builds as far as I see. OTOH, on travis-ci.org all is free for OSS projects. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
No description provided.