notification on incoming changes

[norbusan]

This pull request implements notifications when changes are incoming from the cloud.
A new configuration option min_notif_changes has been added, controlling the minimum
number of incoming changes to trigger a desktop notification. If there are less than this
number, no notification will be shown.

[bugz8unny69]

Hi @norbusan, I was reading the original PR about notifications and when it should happen. I was thinking, do we meed a notification? Also, I fear, we moving far away from a re-write? Is that going to happen?

[norbusan]

@LHorace First of all, you do not need to compile in notifications. Actually by default they are not compiled in. Then you can disable them when starting with --disable-notifications. But for those who want them they are there.

Concerning rewrite: I don't know what you are talking about - I don't think any one of us has time and energy to do a complete rewrite.

[bugz8unny69]

Concerning rewrite: I don't know what you are talking about - I don't think any one of us has time and energy to do a complete rewrite.

You didn't know? Why issues are tagged future planning?

[bugz8unny69]

See #313 (comment)

[norbusan]

Future planning and complee rewrite are different things. And your comment I have seen, but I disagree.

[bugz8unny69]

Okay, I just don't understand why not voice it? Anyway, if you guys are not going to do it, I won't expect it nor bother myself worrying about it.

[abraunegg]

@LHorace

You didn't know? Why issues are tagged future planning?

I tag feature requests as 'Future Work - Planning Required' for the simple reason of:

• Requires more thought / white-boarding than I have time for
• Will most likely need some sort of coding & development / change to the code - ie more than 5 mins worth of time & effort

Re a 'complete re-write':

Some aspects of this currently client & how it is fundamentally written, the way it uses classes & functions today does not lend itself well to multi-threading activities. Being able to multi-thread correctly would mean being able to handle parallel uploads / download thus potentially a faster end user experience than today - esp when dealing with many small files.

Certain sections of the client would need to be re-written to support doing this as I have investigated a number of options here on how to do it - it is not a complete re-write per say - but would be a major engineering & testing effort and @norbusan is correct - this is something that there has to be time & energy for.

[bugz8unny69]

Since it's a compile in behavior and you guys worked to make sure it works right. I'll leave it at that

[abraunegg]

Need to build & test .. will do this sometime later today

[abraunegg]

@norbusan
Currently testing this PR, found a new issue - #365

[abraunegg]

@norbusan
Changes look good to me & work well

[norbusan]

Thanks for merging

[lock]

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.