Make notifications from current contact configurable

[cycneuramus]

This commit removed the possibility of receiving desktop notifications for messages from the current contact. Would it be possible to make this a configurable option?

In my current workflow, scli sits on a separate virtual desktop, and I rely on notifications to know when to read new messages. If I'm in an ongoing conversation, or would like to leave a given contact open while I switch to another virtual desktop, I now have to adopt the clunky workaround of first tabbing out to the contact list and pressing G + Enter to focus my oldest conversation (the one least likely to receive a new message) in order to make sure I will receive a notification when someone sends a message in the conversation I am interested in.

[exquo]

Thanks for reporting this! The workaround indeed seems like an extra pain that scli should not require.

The thinking behind that commit was to avoid showing an extra desktop notification when the user is looking at the conversation anyway. However the if sender != current_contact test is clearly too crude to determine where the user is looking :).

I've opened an issue about showing notifications selectively (#109). In the meantime, I think I'll just revert scli to showing desktop notifications for all incoming messages. Seeing an extra notification is less annoying than missing one; or having to jump through extra hoops before switching from scli window.

[isamert]

A workaround (after @exquo reverts the current behavior) would be using the :toggleNotifications command (which I implemented thinking this use-case). If you are annoyed from the notifications while messaging, you would simply do :n (it's an alias for :toggleNotifications) and it disables the notifications. Before going into another desktop you would again do :n to re-enable notifications.

[isamert]

Now that I think of this, :n probably should work with a timeout. If you do :n, it should disable notifications for let's say 5 mins (probably should be configurable, and the default value should be indefinite to keep the old behavior), re-doing :n would reset the timer and enable the notifications again etc.

Related to #109

[exquo]

Oh right, there's also the :toggleNotifications command. Would be a more elegant workaround for this use case, but still a workaround if it needs to be done manually on every window / desktop switch.

Adding an optional timer to that command should be a useful feature too, like "quiet time" :)

[cycneuramus]

Thanks for your response and for the fix—and may I say, what a great job you're doing with this tool. I use it daily and it's awesome.

As a hacky workaround for avoiding needless notifications when scli is in focus, I might just expand my notification script to include an xdotool query as a condition, or something to that effect.

[exquo]

Thanks for kind words :)

If you figure out a general enough solution, please let us know in #109!