Fix activation not writing to pipe

[DuBistKomisch]

I noticed this while using node-notifier, which uses the pipe functionality to receive the response. This worked for dismissing and timeout, and for activation via the background callback. However, in the case where the app shortcut isn't installed via snoretoast, there is no background callback registered so we need to rely on the normal activation event handler, which never wrote to the pipe.

I've taken a shot at fixing this by writing the action to the pipe, including the button for click events. I didn't test text entry, it may need another extra value too.

[Araxeus]

This repository is a mirror of a KDE repository. This means that developers are not looking at pull requests created in GitHub, so they probably wont see this pull request
Please see community.kde.org/Infrastructure/Github_Mirror for details on how to contribute to this and other KDE projects.

Mirror of https://invent.kde.org/libraries/snoretoast

[TheOneRing]

I thx for reporting.
The response is indeed not handled correctly.
However I'm not sure the fix is correc.
As I haven't touched the code in a way to long time, I'll first need some time to read my way back into it 😅

[DuBistKomisch]

No worries, let me know if there's anything I can fix up, and if you'd rather me reopen this on the KDE gitlab instead.

[rlaace423]

Waiting for merging :)

Could I get detail information for snoretoast build? I tried cmake it, and open with latest visual studio but didn't work.

[DuBistKomisch]

cmake -A <Win32/x64> -B <build32/build64>
cmake --build <build32/build64> --config <Debug/Release>

(pick one or the other between angle brackets)

This is what's been working for me, with just Visual Studio Build Tools 2019 with the C++ workload.

[rlaace423]

cmake -A <Win32/x64> -B <build32/build64>
cmake --build <build32/build64> --config <Debug/Release>

(pick one or the other between angle brackets)

This is what's been working for me, with just Visual Studio Build Tools 2019 with the C++ workload.

Thank you! I'll try.

[TheOneRing]

I haven't forgotten it... just work.. life and stuff 😅

[smadep]

what's the status of this? I'm waiting for this also in context with issue in node-notifier

[TheOneRing]

I finally had a look, but how to reproduce the initial issue?

If I call snoretoast like this:

SnoreToast.exe -t test -m message -pipename \\.\pipe\foo -id 0 -b Hi;There
action=buttonClicked;notificationId=0;pipe=\\.\pipe\foo;button=Hi;version=0.8.0;
Action: buttonClicked 4


SnoreToast.exe Notification: 1 exited with: 4

Without any I get no buttons at all for the first notification (snoretoast registers its self), the second notification hast the response from above.

If I provide an id that is not installed, I never get any button to click.

[DuBistKomisch]

From memory, you must pass a valid app ID, otherwise Windows refuses to include any controls in the notification at all, for whatever reason.

[TheOneRing]

Ok could you fill in some steps to reproduce?
It only happens when activated from the action center after it initially timed out?

[Araxeus]

Without an appID it works ok, SnoreToast register itself and the response from the pipe on button clicks works as intended

But if you specify a valid appID - the response from button clicks (=which one was clicked) is missing

it appears that data is not being returned over the pipe. None of the pipe's events actually fire when an appID is specified and a button is clicked. SnoreToast does however know the a button has been clicked and the exit code is correct.

Anyways this PR fixes the problem for me

[DuBistKomisch]

1. Call SnoreToast with the -appID, -pipeName and optionally -b flags.
2. Click the notification, or the button in the notification.
3. No activate or button message is received over the pipe.

I know a real AppUserModelID is required for buttons to show up, but I think you might be able to try with the activate case anyway, as long as you pass some string to -appID to reach this code path.

This is basically what is happening in the original downstream issue I ran into mikaelbr/node-notifier#332, where the node library passes those args on the command line and (should) emit pipe messages back to JavaScript.

[abdulghanitech]

Any update guys? This fix will help a lot

[Araxeus]

@TheOneRing Happy new year

Could you give us a present for the new year? merge this fix and release a new version? 🥺

Its been almost a year since this PR was created..

[TheOneRing]

Hm I gave it another look and the main problem now is that if the app is correctly registered we will receive two callbacks.
Once from the systems callback and once from the write here.
So ideally there would be a way to detect whether we are properly installed and then conditionally directly notify using the socket.

For the detection: the first time we run we could use

snoretoast/src/snoretoasts.cpp

Line 546 in 17f88b2

tLog << "Failed to retreive NotificationSettings ensure your appId is registered";

but the calls succeeds the second time its called...
In order to detect whether an app id is registered I tried IApplicationActivationManager->ActivateApplication but it appears that only works with applications installed from the store.

Btw, with this patch it appears that we can only receive a clicked as the buttons are not displayed if the app is not registered.

As snoretoast can be used to install the shortcut, I'd rather suggest that the caller of the app calls -install on startup.
This will then allow the use of notification buttons and text boxes.

PS: to reproduce the issue I used the python example and removed the install step

snoretoast/examples/python/snoretoast.py

Line 46 in 17f88b2

run(["snoretoast", "-install", "Snoretoast Python Example", sys.executable, APP_ID])

[TheOneRing]

The issue is probably fixed on master.
I'll give it some testing with a store app and if things work out there will be a release.

[TheOneRing]

https://binary-factory.kde.org/job/SnoreToast_Nightly_win64/

[Araxeus]

from my small testing using node-notifier - the issue is not fixed in the binaries you posted, while compiling using this patch does fix the issue

[TheOneRing]

In that case please modify the python example in to a minimum reproducible.

[Araxeus]

I think this commit might have fixed the issue:
8502ef0
https://invent.kde.org/libraries/snoretoast/-/commit/8502ef06167b3741c072cf65ba74d4f501600408