Need a way to call tomo.Stop when all windows have closed #5

Closed
opened 2024-08-13 01:04:42 -06:00 by sashakoshka · 4 comments
Owner

Currently, the pattern is for the application to count how many windows are open. If not done exactly right we get zombie processes. Behaviors of the Application interfaces must return a Window that can be counted by Nasin, which will then call tomo.Stop once no windows are open.

Currently, the pattern is for the application to count how many windows are open. If not done exactly right we get zombie processes. Behaviors of the Application interfaces must return a Window that can be counted by Nasin, which will then call tomo.Stop once no windows are open.
Author
Owner
7da00e990e2ca162c160730357d7fb380c21d0c7
Author
Owner

The current solution is actually bad. What if the application wants to open another window (like middle clicking in a file manager)?

The current solution is actually bad. What if the application wants to open another window (like middle clicking in a file manager)?
Author
Owner

There needs to be some sort of nasin.Manage function that takes in a window, and will return a cookie that unmanages it. The function will increment the window counter when called, and decrement it when the window is closed, then checking if it is zero to call tomo.Stop if need be.

Perhaps instead of accepting a window, it could accept a Manageable interface with an OnClose behavior. This would allow applications to do things like keep a background service running to receive notifications or something like that.

There needs to be some sort of nasin.Manage function that takes in a window, and will return a cookie that unmanages it. The function will increment the window counter when called, and decrement it when the window is closed, then checking if it is zero to call tomo.Stop if need be. Perhaps instead of accepting a window, it could accept a Manageable interface with an OnClose behavior. This would allow applications to do things like keep a background service running to receive notifications or something like that.
Author
Owner

On second thought, the Manageable interface would be a very bad idea. It would be very bug prone in terms of goroutines.

On second thought, the Manageable interface would be a very bad idea. It would be very bug prone in terms of goroutines.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: tomo/nasin#5
No description provided.