code looks good to me.
It's not big deal, but neither should be creating it.
Start with a model:
EventLogger>>initialize super initialize. quickList := ListModel new list:#( 'Start' 'BP down' 'BP up' 'End' '***SNAFU***' ); yourself. fileSequence := ... "the log"
Add the attached code. Among the important features are transparent handling of the selection index for the list and having something (following Dolphin, call them presenters) between the model and views (morphs). Models should not know or care about their selection index; the morph/view should do that (in Pharo, the ListPresenter is the natural home for it), and can do so in a way that "just works" for most purposes.
The text presenters have been more trouble than I expected, but they bring with them some very important concepts. Dolphin's ViewResource is looking for a home (whether it will find one is open for bets), and the volley of events between model, view and presenter is starting to appear. Among the important tests (not yet realized as unit tests - sorry) is one model with multiple views; change the model and the views update.
Dolphin's layout managers are very powerful, and while the pieces to make them exist in Pharo, I have yet to master their use. A common trap is to use top-level views when something composable is possible and desirable. I am not yet sure what to do about that.
Bill