[GH-ISSUE #307] Tracking container focus #148

New issue

Open

opened 2026-03-03 16:22:53 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 16:22:53 +03:00

Owner

Originally created by @markgardner10 on GitHub (May 19, 2021).
Original GitHub issue: https://github.com/mum4k/termdash/issues/307

When you click into a container with the mouse and it gets focus, can other containers poll some event table to track that ?

Im trying to figure out how a container can do some work based on which other container gets focus

Thanks

Originally created by @markgardner10 on GitHub (May 19, 2021). Original GitHub issue: https://github.com/mum4k/termdash/issues/307 When you click into a container with the mouse and it gets focus, can other containers poll some event table to track that ? Im trying to figure out how a container can do some work based on which other container gets focus Thanks

kerem added the

enhancement

label

2026-03-03 16:22:53 +03:00

kerem commented

2026-03-03 16:22:54 +03:00

Author

Owner

@mum4k commented on GitHub (May 20, 2021):

Hi @markgardner10, thank you for reaching out. I believe that the functionality you re describing isn't currently available, but shouldn't be too hard to implement it.

To confirm - you would like to have an event subscriber at a particular container? I.e. something similar to this:

github.com/mum4k/termdash@9ed371362b/termdash.go (L74-L81)

But with an ability to select a specific container by id and with an ability to receive the same events the container is getting (i.e. both keyboard and mouse)?

It would help me if you could describe what this will be used for, so that we can better shape the feature.

@mum4k commented on GitHub (May 20, 2021): Hi @markgardner10, thank you for reaching out. I believe that the functionality you re describing isn't currently available, but shouldn't be too hard to implement it. To confirm - you would like to have an event subscriber at a particular container? I.e. something similar to this: https://github.com/mum4k/termdash/blob/9ed371362bfea7c283f50f8ec783e25e7667491a/termdash.go#L74-L81 But with an ability to select a specific container by id and with an ability to receive the same events the container is getting (i.e. both keyboard and mouse)? It would help me if you could describe what this will be used for, so that we can better shape the feature.

kerem commented

2026-03-03 16:22:54 +03:00

Author

Owner

@markgardner10 commented on GitHub (May 20, 2021):

Best described with a diagram I think

@markgardner10 commented on GitHub (May 20, 2021): Best described with a diagram I think ![Blank diagram](https://user-images.githubusercontent.com/1790846/118910272-1c4d8f80-b91c-11eb-8e7d-192be5e8ee42.png)

kerem commented

2026-03-03 16:22:54 +03:00

Author

Owner

@mum4k commented on GitHub (May 20, 2021):

Thank you, that indeed helps. I have one more question - are you planning to display anything in the "Display log A", "Display log B" and "Display log C" containers?

One solution that comes to mind is to implement a widget that will display what you want (or nothing if that is desired). However this widget will also react to the focus and any keyboard / mouse events in the containers and perform the functionality you describe. Let me know if this sounds doable, if you are going to go in this direction I would give you some additional advice related to deadlock avoidance, since the infrastructure holds a container level lock while the widgets are drawing their content (which is when you can react to focus changes).

You could model this widget closely after the Button widget, which essentially does the same thing. Except the button widget does it when the button is pressed, while your widget would also do it when it receives focus.

If this doesn't sounds like a good idea, we could also add a container level subscriber to events.

@mum4k commented on GitHub (May 20, 2021): Thank you, that indeed helps. I have one more question - are you planning to display anything in the "Display log A", "Display log B" and "Display log C" containers? One solution that comes to mind is to implement a widget that will display what you want (or nothing if that is desired). However this widget will also react to the focus and any keyboard / mouse events in the containers and perform the functionality you describe. Let me know if this sounds doable, if you are going to go in this direction I would give you some additional advice related to deadlock avoidance, since the infrastructure holds a container level lock while the widgets are drawing their content (which is when you can react to focus changes). You could model this widget closely after the [Button](https://github.com/mum4k/termdash/tree/master/widgets/button) widget, which essentially does the same thing. Except the button widget does it when the button is pressed, while your widget would also do it when it receives focus. If this doesn't sounds like a good idea, we could also add a container level subscriber to events.