feat(scion-rcp): introduce microfrontend view API #78
Conversation
| * the listener that will receive the focus-within events, not null | ||
| * @return a disposable that can be used to dispose the listener registration | ||
| */ | ||
| IDisposable onFocusWithin(FocusWithinListener listener); |
There was a problem hiding this comment.
I<Disposable, but FocusWithinListener
Do we stick to the I-prefix only for internal interfaces? Or not at all. I am not sure really... we haven't created the coding guidelines yet.
There was a problem hiding this comment.
Well, yeah, we do not seem to apply this I... interface naming pattern, consistently. I just looked at the names of the other classes 'close to' the implementation, e.g., there is a LoadListener where I defined the FocusWithinListener. I can change it, if you wish.
There was a problem hiding this comment.
Naah, lets rather force the creation of the guidelines, then clean up all in one commit.
| @Override | ||
| public void setSelection(final ISelection selection) { | ||
| this.currentSelection = selection; | ||
| // TODO: Should we only fire a selection changed event if the selection has actually changed? How to compare selections? |
There was a problem hiding this comment.
I think it should "fire" always, but consumers are responsible to decide to process the event or not.
I think in RCP there is also this ".doit" attribute. With that I think you are able to decide as event-source whether the event should be fired or not.
ruadrian
force-pushed
the
feature/aruc/mark-microfrontend-view-editor-parts-2
branch
from
fcc585a
to
46c38a0
Compare
* Allow listening to focus-within events * Supply a selection provider for integration with the Eclipse selection service * Allow identifying microfrontend views, externally
ruadrian
force-pushed
the
feature/aruc/mark-microfrontend-view-editor-parts-2
branch
from
46c38a0
to
010f1a2
Compare
iachelini
deleted the
feature/aruc/mark-microfrontend-view-editor-parts-2
branch
Review: gilles.iachelini@sbb.ch