Closed zanonmark closed 10 months ago
My guess is that for each event there was once a consideration about whether the event is meant for external observers, or merely for the class (and its sub-classes).
Apparently, the designer thought that reception of focus would most expectably be treated in a highly component-specific manner ... such that no code other than the class or its sub-classes would have access to the necessary innards of the component, anyway.
This is meant to "explain" the mixed state as it is.
If you can convince @mabe02 to make some of the events externally observable, then good for you :-)
Actually I already managed to achieve that in my classes (e.g.: ATable extends Table
), by:
protected LinkedList<AFocusEventListener> focusEventListeners
list,public void addFocusEventListener(AFocusEventListener focusEventListener)
method to fill the previous list, andafterEnterFocus
to invoke those focusEventListeners
.Thanks, MZ
This mainly because of how the library grew organically. There wasn't any big masterplan from the beginning. Some of this is a bit inconsistent, I agree, and sometimes you have to mix inheritance and listeners to get what you need. But functionality-wise it should still have the same functionality. Feel free to submit PRs for master branch with inheritance migrated to listeners.
Hi, and thanks for Lanterna!
One thing I don't understand is: why having some events handled as protected methods e.g.: (
Component
.afterEnterFocus()
) and handled via Listeners in other parts of the package (e.g.:Terminal
.addResizeListener()
, but alsoButton
.addListener()
)? Would it be possible to use Listeners everywhere? Not only for consistency, but also because IMHO they're more flexible.Thanks, MZ