I don't like the extra menu. I think going three levels in a menu should only be done for thing used rarely. Feels awkward very time. Do we have three cases wirh epicea?
- this session meaning all changed since start of the image? - last session/aborted session the last session that did not finished because of unexpected image stop. This should open automatically which does not work in current pharo6 - all other sessions In this situation when the aborted session opens automatically it means I deliberately open epicea through the menu for other reasons. In this case I'm with Doru that it should be a single menu entry which opens epicea and someone can choose there what to see. In case of list display this session will be the top most entry anyway so it can be discussed if it is important to separate this session and the others really. Norbert > Am 20.12.2016 um 17:17 schrieb Martin Dias <tinchod...@gmail.com>: > > Hi all, > > One point of Ben's feedback is how Epicea code changes tool is presented in > the World Menu. Below you can see the current state + 3 options to discuss it. > > > 1. "Epicea" main entry > "Session Changes" + "All Changes" children [current > state] > > > > > 2. Attach purpose to the name: "Epicea Code Changes" > > <Epicea Code Changes.png> > > > 3. Just "Code Changes" + rephrase children: > > > > > 4. Flatten > > <Flatten.png> > > > > Reminder: In World Menu > Help > Help Browser > Epicea you can find a > description of the tool and it's model. > > Cheers. > Martin > >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias <tinchod...@gmail.com> wrote: >> Hello Ben, >> >> About discussion points in 2 (a, b and c): I agree with your arguments... >> somebody that just moved from Pharo 5 to 6 and crashed an image will look >> for a "Recover lost changes" in the menu and can have a problem to discover >> it the replacement in a World->Tools->Epicea->... entry. >> >> Then, as a first step we could flatten the 2 menu entries and then at least >> anybody will easily find an entry related to changes in World->Tools. >> >> Second, we could try to merge both Epicea GUIs into one (suggestions are >> welcome). >> >> I still have to read more in detail the remaining of your report to answer. >> Anyway, thanks a lot for it. >> >> Cheers, >> Martin >> >> >>> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman <b...@openinworld.com> wrote: >>> 1. Created fresh Pharo image (build 60269) >>> >>> >>> 2. Opened World > Tools > Epicea > All changes >>> >>> Points for discussion... >>> >>> a. How many submenu items are expected for Epicea? Can we push the >>> current ones up so the Tools menu remains a flat menu. >>> >>> b. Do we need the two current menu items? "Current session" is >>> encompassed by "All changes"? What expectations do people have of how >>> often they'll use the former rather than the latter? >>> >>> c. When people move from Pharo 5 to Pharo 6 and in a panic want to >>> "recover changes" for a crashed image, they'll be looking for that >>> familiar feature name, not a new app name. Could the app name be left >>> out or placed in brackets "Changes (Epicea)". >>> >>> btw, the interface looks really slick! nice work. >>> >>> >>> 3. Opened World > System Browser. >>> >>> 4. Added package AAA >>> All Changes window - no dynamic change. >>> On <refresh>, still no change, i.e. no sessions >>> #New All Changes window - not visible, no sessions. >>> >>> 5. Added class AA. >>> All Changes window - no dynamic change. >>> On <refresh>, shows new session with AAA & AA. >>> >>> 5. Added method... >>> AA>a >>> ^'something' >>> Prompted for author, entered 'BenComan' >>> All Changes window with session selected - dynamic update showing AA>>a. >>> >>> 6. Added package BBB. >>> All Changes window - no dynamic update. >>> On <refresh>, BBB still not visible in session. >>> >>> 7. Added class A to package AAA. >>> All Changes window - dynamic update showing A. >>> On <refresh>, BBB still not visible in session. >>> >>> 8. Added class BB to package BBB. >>> All Changes window - dynamic update showing BBB & BB. >>> >>> a. Package creation event seems not handled properly, being only >>> pushed through when a class is created in it. >>> >>> b. Since there is a dynamic update for class and method >>> modifications, could the session creation also dynamically update it >>> UI. >>> >>> ----------- >>> 9. Killed the vm from command line >>> $ ps -ef | grep pharo >>> $ kill 29349 >>> Restarted Pharo image >>> >>> 10. World > Tools > Epica > All changes. >>> Authorship is inconsistent: >>> * AAA and AA have blank author >>> * AA>>a, A, BBB, B have author 'BenComan'. >>> >>> a. I understand this follows on from Author not being requested until >>> the first method was defined. Did the old changes track the author of >>> packages and classes at all? >>> >>> b. Since Epicea can track package and class authors, can we trigger >>> the author prompt earlier for them? >>> >>> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB >>> and did <Apply Changes>. >>> Prompted for author. Entered 'DrWho' >>> Existing All Changes window - no change >>> New All Changes window - shows new session with all six changes. >>> Authorship is a little inconsistent: >>> * AAA and AA have author 'Unknown'. >>> * AA>>a, A, BBB, B have blank author. >>> >>> 12. Killed the vm from command line >>> $ ps -ef | grep pharo >>> $ kill 30696 >>> Restarted Pharo image >>> >>> 13. World > Tools > Epica > All changes. >>> Authorship is a little inconsistent: >>> First session >>> * AAA and AA have blank author >>> * AA>>a, A, BBB, B have author 'BenComan'. >>> Second session >>> * AAA and AA have blank author >>> * AA>>a, A, BBB, B have author 'DrWho'. >>> >>> a. Epicea changes are reapplied as the current author. This seems a >>> semantic change from Pharo 5 where changes were reapplied as their >>> original author. Is this accidental or by design? Can we have some >>> community discussion on this point (I don't remember seeing any)? >>> >>> cheers -ben >>> >>> P.S. I'll wait to see what arises out of discussion before creating any >>> issues. >>> >> >
