Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking container focus #307

Open
markgardner10 opened this issue May 19, 2021 · 3 comments
Open

Tracking container focus #307

markgardner10 opened this issue May 19, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@markgardner10
Copy link

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

@mum4k
Copy link
Owner

mum4k commented 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:

termdash/termdash.go

Lines 74 to 81 in 9ed3713

// KeyboardSubscriber registers a subscriber for Keyboard events. Each
// keyboard event is forwarded to the container and the registered subscriber.
// The provided function must be thread-safe.
func KeyboardSubscriber(f func(*terminalapi.Keyboard)) Option {
return option(func(td *termdash) {
td.keyboardSubscriber = f
})
}

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 mum4k added the enhancement New feature or request label May 20, 2021
@markgardner10
Copy link
Author

Best described with a diagram I think

Blank diagram

@mum4k
Copy link
Owner

mum4k commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants