Epicea depends on Morphic
Epicea UI should only be on spec but it depends on Morphic. Check EpMorphFactory
We should kill this class
This is to build items in this list
Good catch :)
I don't know how to do the equivalent in Spec. We will probably lose some of the "cool ui" feel of this presenter when we will remove the morphic dependency. Except if @estebanlm has an idea on how to do the same thing in Spec?
Hello @jecisc I'm guilty of writing this for Epicea!! ~ 10 years ago (and also then did something similar for Rita.., which you know).
I wanted to do a comment to help in re-writing this presenter to be more standard, removing explicit Morphic tricks. Some of the comments may be irrelevant for re-writing, but add context.
The screenshot you attached is good to comment a particularity of this Epicea log browser. I extract this small fragment:
My comments:
- The presenter is called EpLogBrowserPresenter and shows the contents of a EpLog (btw, not always 1:1 with an .ombu file).
- The EpLog calls "log entry" to each item, and they are instances of OmEntry (in Ombu package, that is more low-level than Epicea).
- A change such as a EpPackageAddition is the content of a log entry. But not all log entries have a code change, some can be an IDE event such as "Monticello load".
- A log entry almost always has a parent log entry (the chronological predecessor). The parent can be in the same .ombu file or in another... I tried to hide this in the UI.
- A log entry sometimes has trigger log entries (the "MC load PharoSettings9-tonel.1" is the triggerer of "Package PharoSettings9"). This is why the item for "Package PharoSettings9" begins with a semi-transparent package icon (the icon of the triggerer log entry). The trigger-triggered relationship could be shown in a tree widget, but personally I wanted to see first (on top) in the widget the most recent change. This may be a too arbitrary choice... we could show most recent changes at bottom and then use a Spec tree without this translucent icon.
- The other Morphic tricks are just for using bold text and grayed text or maybe some other color... not sure, maybe it's possible to pass a Text instance to the Spec tree and this text isntance already has TextAttributes that make portions of the text to be bold or grayed. Otherwise, we can just show all as a simple String and no need for those details. Or... use widget columns to show the info.
Regards, Martín