If a user swipes up, they will dismiss the notification without doing
its action, but if they touch the notification they will execute its
action.

This is useful when you get a lot of popups or if you (like me) have
your popup notifications decay only after a very very very long time.

I also thing the default delay for notifications should be extremely
long (24hrs), so you can easily see what sms messages you received.

NB: I have not tested on dwm (may need to add an on-touch option there 
too).  

NB2: I also think that this might all go into a hook instead so we can 
let the user control what to do with popups?

---
 configs/appcfg/mako.conf    |  1 +
 scripts/core/sxmo_notifs.sh | 15 +++++++++++----
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/configs/appcfg/mako.conf b/configs/appcfg/mako.conf
index 5b6e9124..14ed91a6 100644
--- a/configs/appcfg/mako.conf
+++ b/configs/appcfg/mako.conf
@@ -5,6 +5,7 @@ text-color=#000000
 border-color=#000000
 layer=overlay
 group-by=app-name
+on-touch=invoke-default-action
 
 [urgency=low]
 default-timeout=10000
diff --git a/scripts/core/sxmo_notifs.sh b/scripts/core/sxmo_notifs.sh
index 62b634c7..e8371a17 100755
--- a/scripts/core/sxmo_notifs.sh
+++ b/scripts/core/sxmo_notifs.sh
@@ -31,10 +31,17 @@ _handle_new_notif_file(){
 	action="$(awk NR==2 "$file")"
 	msg="$(tail -n+3 "$file" | cut -c1-70)"
 
-	if dunstify --action="2,open" "$msg" | grep -q 2; then
-		_clear_notif_group "$group"
-		setsid -f sh -c "$action" > /dev/null 2>&1
-	fi &
+	case "$(dunstify --action="default,Open" "$msg")" in
+		"2")
+			#
+			# _clear_notif_group "$group"
+			#
+			;;
+		"default")
+			_clear_notif_group "$group"
+			setsid -f sh -c "$action" > /dev/null 2>&1
+			;;
+	esac
 }
 
 _notifications_hook() {
-- 
2.45.2

sxmo-utils/patches/test.yml: SUCCESS in 24s

[Do nothing when dismissing notif][0] from [Peter John Hartman][1]

[0]: https://lists.sr.ht/~mil/sxmo-devel/patches/55821
[1]: peterjohnhartman@gmail.com

✓ #1362913 SUCCESS sxmo-utils/patches/test.yml https://builds.sr.ht/~mil/job/1362913

On Tue Nov 5, 2024 at 12:32 PM CET, Peter John Hartman wrote:
> If a user swipes up, they will dismiss the notification without doing
> its action, but if they touch the notification they will execute its
> action.

So if I understand correctly up until now we had no actions when
tapping popups? Then this patch certainly makes sense yes.

> This is useful when you get a lot of popups or if you (like me) have
> your popup notifications decay only after a very very very long time.

> I also thing the default delay for notifications should be extremely
> long (24hrs), so you can easily see what sms messages you received.

Hmm, not sure what I think about a long delay, might get overwhelming
quickly if you get a lot of notifications. I get tons of network up/down
notifications where I'm glad they automatically dissappear fairly
quickly.

> NB: I have not tested on dwm (may need to add an on-touch option there 
> too).  

I suppose for X there is no distinction between mouse and touch input
and it'll work already? But good to test neverhtheless.

> NB2: I also think that this might all go into a hook instead so we can 
> let the user control what to do with popups?

May be yeah

> diff --git a/configs/appcfg/mako.conf b/configs/appcfg/mako.conf
> index 5b6e9124..14ed91a6 100644
> --- a/configs/appcfg/mako.conf
> +++ b/configs/appcfg/mako.conf
> @@ -5,6 +5,7 @@ text-color=#000000
>  border-color=#000000
>  layer=overlay
>  group-by=app-name
> +on-touch=invoke-default-action

Does this mean that touch actions didn't even work before this patch,
even though the logic for handling them was there? Then this patch
certainly makes sense.

> diff --git a/scripts/core/sxmo_notifs.sh b/scripts/core/sxmo_notifs.sh
> index 62b634c7..e8371a17 100755
> --- a/scripts/core/sxmo_notifs.sh
> +++ b/scripts/core/sxmo_notifs.sh
> @@ -31,10 +31,17 @@ _handle_new_notif_file(){
>  	action="$(awk NR=2 "$file")"
>  	msg="$(tail -n+3 "$file" | cut -c1-70)"
>  
> -	if dunstify --action="2,open" "$msg" | grep -q 2; then
> -		_clear_notif_group "$group"
> -		setsid -f sh -c "$action" > /dev/null 2>&1
> -	fi &
> +	case "$(dunstify --action="default,Open" "$msg")" in
> +		"2")
> +			#
> +			# _clear_notif_group "$group"
> +			#
> +			;;
> +		"default")
> +			_clear_notif_group "$group"
> +			setsid -f sh -c "$action" > /dev/null 2>&1
> +			;;
> +	esac

The old version seems asynchronous and the new one synchronous (no &),
is this intentional?

-- 

Maarten van Gompel (proycon)

web: https://proycon.anaproy.nl
gpg: 0x39FE11201A31555C

On Thu, Nov 07, 2024 at 09:29:21PM +0100, Maarten van Gompel wrote:
> On Tue Nov 5, 2024 at 12:32 PM CET, Peter John Hartman wrote:
> > If a user swipes up, they will dismiss the notification without doing
> > its action, but if they touch the notification they will execute its
> > action.
> 
> So if I understand correctly up until now we had no actions when
> tapping popups? Then this patch certainly makes sense yes.

We currently have actions, from what I understand the issue is that they
also get executed when swiping up, not just when tapped.

> > This is useful when you get a lot of popups or if you (like me) have
> > your popup notifications decay only after a very very very long time.
> 
> > I also thing the default delay for notifications should be extremely
> > long (24hrs), so you can easily see what sms messages you received.
> 
> Hmm, not sure what I think about a long delay, might get overwhelming
> quickly if you get a lot of notifications. I get tons of network up/down
> notifications where I'm glad they automatically dissappear fairly
> quickly.

I wonder if we could build better tools for persistent notifications, I
know swaync[1] exists, but haven't tried it. suckless.org/rocks also
lists tiramisu[2] / herbe[3] which sound like they could be wrapped with
a shell script to provide persistent notifications.

1: https://github.com/ErikReider/SwayNotificationCenter
2: https://github.com/Sweets/tiramisu
3: https://github.com/dudik/herbe

> > NB: I have not tested on dwm (may need to add an on-touch option there
> > too).
> 
> I suppose for X there is no distinction between mouse and touch input
> and it'll work already? But good to test neverhtheless.
> 
> > NB2: I also think that this might all go into a hook instead so we can
> > let the user control what to do with popups?
> 
> May be yeah
> 
> > diff --git a/configs/appcfg/mako.conf b/configs/appcfg/mako.conf
> > index 5b6e9124..14ed91a6 100644
> > --- a/configs/appcfg/mako.conf
> > +++ b/configs/appcfg/mako.conf
> > @@ -5,6 +5,7 @@ text-color=#000000
> >  border-color=#000000
> >  layer=overlay
> >  group-by=app-name
> > +on-touch=invoke-default-action
> 
> Does this mean that touch actions didn't even work before this patch,
> even though the logic for handling them was there? Then this patch
> certainly makes sense.
> 
> > diff --git a/scripts/core/sxmo_notifs.sh b/scripts/core/sxmo_notifs.sh
> > index 62b634c7..e8371a17 100755
> > --- a/scripts/core/sxmo_notifs.sh
> > +++ b/scripts/core/sxmo_notifs.sh
> > @@ -31,10 +31,17 @@ _handle_new_notif_file(){
> >  	action="$(awk NR==2 "$file")"
> >  	msg="$(tail -n+3 "$file" | cut -c1-70)"
> >
> > -	if dunstify --action="2,open" "$msg" | grep -q 2; then
> > -		_clear_notif_group "$group"
> > -		setsid -f sh -c "$action" > /dev/null 2>&1
> > -	fi &
> > +	case "$(dunstify --action="default,Open" "$msg")" in
> > +		"2")
> > +			#
> > +			# _clear_notif_group "$group"
> > +			#
> > +			;;
> > +		"default")
> > +			_clear_notif_group "$group"
> > +			setsid -f sh -c "$action" > /dev/null 2>&1
> > +			;;
> > +	esac
> 
> The old version seems asynchronous and the new one synchronous (no &),
> is this intentional?
> 
> --
> 
> Maarten van Gompel (proycon)
> 
> web: https://proycon.anaproy.nl
> gpg: 0x39FE11201A31555C

On Thu, Nov 07, 2024 at 06:59:11PM -0500, Aren wrote:
>On Thu, Nov 07, 2024 at 09:29:21PM +0100, Maarten van Gompel wrote:
>> On Tue Nov 5, 2024 at 12:32 PM CET, Peter John Hartman wrote:
>> > If a user swipes up, they will dismiss the notification without doing
>> > its action, but if they touch the notification they will execute its
>> > action.
>>
>> So if I understand correctly up until now we had no actions when
>> tapping popups? Then this patch certainly makes sense yes.
>
>We currently have actions, from what I understand the issue is that they
>also get executed when swiping up, not just when tapped.

Yeah, that's it.  If you swipe up on a pile of sms notifs, it opens them 
all, which is annoying.

>> > This is useful when you get a lot of popups or if you (like me) 
>> > have
>> > your popup notifications decay only after a very very very long time.
>>
>> > I also thing the default delay for notifications should be extremely
>> > long (24hrs), so you can easily see what sms messages you received.
>>
>> Hmm, not sure what I think about a long delay, might get overwhelming
>> quickly if you get a lot of notifications. I get tons of network up/down
>> notifications where I'm glad they automatically dissappear fairly
>> quickly.
>
>I wonder if we could build better tools for persistent notifications, I
>know swaync[1] exists, but haven't tried it. suckless.org/rocks also
>lists tiramisu[2] / herbe[3] which sound like they could be wrapped with
>a shell script to provide persistent notifications.

We can also utilize the three levels of notifications (low, normal, 
critical): normal for sms / phone calls, low for everything else (except 
what's currently critical).

What I found annoying is unsuspending my phone when its green light is 
on, knowing there's an sms, and then seeing it "flash" briefly in front 
of my eyes before disappearing!  Also, I found our default timeouts too 
slow for a lot of MFA sms codes, at least for me.

I do think a better tool would be better; it'd be nice to flip through 
the notifs for instance and swipe some away but keep others.


--
sic dicit magister P
https://phartman.sites.luc.edu/
GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA  330D B3E6 39C6 E0DB D3D6)

> I wonder if we could build better tools for persistent notifications, I
> know swaync[1] exists, but haven't tried it. suckless.org/rocks also
> lists tiramisu[2] / herbe[3] which sound like they could be wrapped with
> a shell script to provide persistent notifications.

I've tried to design something, but the fact we need to keep
notifications after restarts, and so our need for the action to be
triggered by a third party (the notif monitor), seems incompatible with
the org.freedesktop.Notifications Desktop Specification.

So what do we do with this patch as it stands? I'm inclined to accept it
(for the upcoming release) as it improves the current situation. Or am I
missing something?

We can always go for a better tools for persistant notifications later.

-- 

Maarten van Gompel (proycon)

web: https://proycon.anaproy.nl
gpg: 0x39FE11201A31555C

On Mon, Nov 25, 2024 at 11:36:02PM +0100, Maarten van Gompel wrote:
> So what do we do with this patch as it stands? I'm inclined to accept it
> (for the upcoming release) as it improves the current situation. Or am I
> missing something?
> 
> We can always go for a better tools for persistant notifications later.

Yeah I think merging is the right thing, this is just a bugfix as far as
I understand it.

I should try to reproduce this, I haven't noticed the issue and it might
be a mako bug... the only problem is I'm too lazy to right now.

On Tue Nov 26, 2024 at 3:14 AM CET, Aren wrote:
> Yeah I think merging is the right thing, this is just a bugfix as far as
> I understand it.

Done, merged now!