From Newsgroup: comp.lang.tcl

This one took me some time to get arround a big problem of "tk
sysnotify" on Window systems.

See https://github.com/Meshparts/sysnotify/tree/main for details.

I hope someone can test this and give me some feedback.

The actual problem, is that Windows has a display time of 7 seconds for
any notification. (could be that there is a setting for this)

Maybe other OS also have this notification behavior too, in which case sysnotify package could have a larger use.

If you are using the inbuild "tk sysnotify" to create notifications at
any speed dictated by your code, you will soon have same issue I had:

You will get a stack of N messages, delayed by 7 seconds each.

Say your application sends 10 notifications every 3 seconds.
After 30 seconds your application has finished, but Windows will need 70 seconds to finish processing the stack of 10 notifications.
So the user will keep getting notifications 40 seconds after your
application has long finished.

The new package "sysnotify" implements optimal managment for system notifications, in order to avoid stacking of notification, when the notifications are sent faster than the limit imposed by the operating
system.

Best regards
Alex
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 30.09.2025 um 22:16 schrieb meshparts:

This one took me some time to get arround a big problem of "tk
sysnotify" on Window systems.

See https://github.com/Meshparts/sysnotify/tree/main for details.

I hope someone can test this and give me some feedback.

The actual problem, is that Windows has a display time of 7 seconds for
any notification. (could be that there is a setting for this)

Maybe other OS also have this notification behavior too, in which case sysnotify package could have a larger use.

If you are using the inbuild "tk sysnotify" to create notifications at
any speed dictated by your code, you will soon have same issue I had:

You will get a stack of N messages, delayed by 7 seconds each.

Say your application sends 10 notifications every 3 seconds.
After 30 seconds your application has finished, but Windows will need 70 seconds to finish processing the stack of 10 notifications.
So the user will keep getting notifications 40 seconds after your application has long finished.

The new package "sysnotify" implements optimal managment for system notifications, in order to avoid stacking of notification, when the notifications are sent faster than the limit imposed by the operating system.

Best regards
Alex

There are two small issues I'm aware of with current implementation:

First issue: Messages should be sent with a small delay of e.g. 100ms.
If not, the stack will still be build and we get the old behavior back:

after 100 [list ::sysnotify::Send "message 1"]
after 100 [list ::sysnotify::Send "message 2"]
after 100 [list ::sysnotify::Send "message 3"]

Second issue: If an external "after" is used between the messages, the
stack will still be build and we get the old behavior back:

after 100 [list ::sysnotify::Send "message 1"]
after 100
after 100 [list ::sysnotify::Send "message 2"]
after 100
after 100 [list ::sysnotify::Send "message 3"]

Both issues have a cause, that is unclear to me.
Maybe somebody can fix/explain this to me.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On Tue, 30 Sep 2025 22:16:57 +0200
meshparts <alexandru.dadalau@meshparts.de> wrote:

[...]

Say your application sends 10 notifications every 3 seconds.
After 30 seconds your application has finished, but Windows will need 70 seconds to finish processing the stack of 10 notifications.
So the user will keep getting notifications 40 seconds after your application has long finished.

Notifications are meant to be read. That's why they have such delay
before dissapearing.

If you send a notifications every 3 seconds, the user will be very busy
reading them and not doing anything else. This also applies to message
length; the longer they are, the higher the probability that they are
annoying users instead of notifying them.

That's a Bad Design, and you should probably use another approach.
Just because it can be done doesn't mean it should be done.

Regards
--
Emiliano
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.10.2025 um 15:52 schrieb Emiliano:

On Tue, 30 Sep 2025 22:16:57 +0200
meshparts <alexandru.dadalau@meshparts.de> wrote:

[...]

Say your application sends 10 notifications every 3 seconds.
After 30 seconds your application has finished, but Windows will need 70
seconds to finish processing the stack of 10 notifications.
So the user will keep getting notifications 40 seconds after your
application has long finished.

Notifications are meant to be read. That's why they have such delay
before dissapearing.

If you send a notifications every 3 seconds, the user will be very busy reading them and not doing anything else. This also applies to message length; the longer they are, the higher the probability that they are annoying users instead of notifying them.

That's a Bad Design, and you should probably use another approach.
Just because it can be done doesn't mean it should be done.

Regards

I wasn't criticizing the way notifications are implemented in Windows.
I clearly understand the reason why the 7 seconds are needed.

Maybe you didn't understand the meaning of the sysnotify package?

Of course it would be a bad design to post messages every half second or
so to the user.
And that's why I need this package, to avoid this.

The history of this is, that my app already had notification windows,
but they were self created windows, created with Tk floating frames and
so on.
Also, there is an output window, that can be shown or hidden by the user.
The logic of my notication system (prior to tk sysnotify) was this:
1. Log all helpfull messages to the output window.
2. If the output window is hidden, also show the current message in a notification window.
3. Always show the last notification of a couple of seconds.
4. Overwrite content of previous notification window if messages come to
fast.

So the old system makes perfect sense and is good design. No problems there.

With the new "tk sysnotify" I thought: Just replace the call to my self implemented notification window with the new "tk notify" command.

This was literally a change of 2 rows in my code.
Then test it and realize, that the new command cannot cancel, destroy or overwrite the old notifications.

So the sysnotify package tries to correct this by implementing user
friendly management of notifications.

I hope it's clear now.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 30.09.2025 um 22:23 schrieb meshparts:

Am 30.09.2025 um 22:16 schrieb meshparts:

This one took me some time to get arround a big problem of "tk
sysnotify" on Window systems.

See https://github.com/Meshparts/sysnotify/tree/main for details.

I hope someone can test this and give me some feedback.

The actual problem, is that Windows has a display time of 7 seconds
for any notification. (could be that there is a setting for this)

Maybe other OS also have this notification behavior too, in which case
sysnotify package could have a larger use.

If you are using the inbuild "tk sysnotify" to create notifications at
any speed dictated by your code, you will soon have same issue I had:

You will get a stack of N messages, delayed by 7 seconds each.

Say your application sends 10 notifications every 3 seconds.
After 30 seconds your application has finished, but Windows will need
70 seconds to finish processing the stack of 10 notifications.
So the user will keep getting notifications 40 seconds after your
application has long finished.

The new package "sysnotify" implements optimal managment for system
notifications, in order to avoid stacking of notification, when the
notifications are sent faster than the limit imposed by the operating
system.

Best regards
Alex

There are two small issues I'm aware of with current implementation:

First issue: Messages should be sent with a small delay of e.g. 100ms.
If not, the stack will still be build and we get the old behavior back:

after 100 [list ::sysnotify::Send "message 1"]
after 100 [list ::sysnotify::Send "message 2"]
after 100 [list ::sysnotify::Send "message 3"]

Second issue: If an external "after" is used between the messages, the
stack will still be build and we get the old behavior back:

after 100 [list ::sysnotify::Send "message 1"]
after 100
after 100 [list ::sysnotify::Send "message 2"]
after 100
after 100 [list ::sysnotify::Send "message 3"]

Both issues have a cause, that is unclear to me.
Maybe somebody can fix/explain this to me.

Any ideas why an additional after between the "::sysnotify::Send" calls
brakes the code?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 01.10.2025 um 17:13 schrieb meshparts:

Am 30.09.2025 um 22:23 schrieb meshparts:

Am 30.09.2025 um 22:16 schrieb meshparts:

This one took me some time to get arround a big problem of "tk
sysnotify" on Window systems.

See https://github.com/Meshparts/sysnotify/tree/main for details.

I hope someone can test this and give me some feedback.

The actual problem, is that Windows has a display time of 7 seconds
for any notification. (could be that there is a setting for this)

Maybe other OS also have this notification behavior too, in which
case sysnotify package could have a larger use.

If you are using the inbuild "tk sysnotify" to create notifications
at any speed dictated by your code, you will soon have same issue I had: >>>
You will get a stack of N messages, delayed by 7 seconds each.

Say your application sends 10 notifications every 3 seconds.
After 30 seconds your application has finished, but Windows will need
70 seconds to finish processing the stack of 10 notifications.
So the user will keep getting notifications 40 seconds after your
application has long finished.

The new package "sysnotify" implements optimal managment for system
notifications, in order to avoid stacking of notification, when the
notifications are sent faster than the limit imposed by the operating
system.

Best regards
Alex

There are two small issues I'm aware of with current implementation:

First issue: Messages should be sent with a small delay of e.g. 100ms.
If not, the stack will still be build and we get the old behavior back:

after 100 [list ::sysnotify::Send "message 1"]
after 100 [list ::sysnotify::Send "message 2"]
after 100 [list ::sysnotify::Send "message 3"]

Second issue: If an external "after" is used between the messages, the
stack will still be build and we get the old behavior back:

after 100 [list ::sysnotify::Send "message 1"]
after 100
after 100 [list ::sysnotify::Send "message 2"]
after 100
after 100 [list ::sysnotify::Send "message 3"]

Both issues have a cause, that is unclear to me.
Maybe somebody can fix/explain this to me.

Any ideas why an additional after between the "::sysnotify::Send" calls brakes the code?

Please ignore this question.
I realize I had a small bug in my code.
I'll fix it on github.
--- Synchronet 3.21a-Linux NewsLink 1.2