On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba <[email protected]> wrote: > Hi, > > I think I would prefer to not have to think about this choice at all when in > the world menu level. The user interface from the Epicea window already > allows me to switch between current session and all sessions, and usually the > decision of what to look at is based on whether I find what I am looking for > or not. So, rather then asking the user to think about it upfront, I would > prefer to have one command that opens the Epicea window on the current > session and allow the user to dive deeper. This would also imply that we > would have only one command in the menu item. What do you think?
Good point. I had a similar thought earlier. The individual Session Changes window is almost completely embedded in the All Sessions window, so the former seems superfluous. The <Monitor> and <+> buttons would need to be added to the All Sessions window, probably above the "sesssion" pane. Two additional things I think are required to facilitate this... 1. The left-pane of the All Sessions windows needs to update when a new session is created - per <+> button. 2. It would be useful if a new session was created "when the image opened" rather than when a change is made, so that it can be preselected in the left-side pane when a fresh image is opened. But the file shouldn't be created until the first change, for the case like a web service image being invoked multiple times a second. Also one other request, That the current-session be tagged "Current" rather than just "Today". I can log issues if they all sound reasonable. cheers -ben > >> On Dec 20, 2016, at 10:16 PM, stepharong <[email protected]> wrote: >> >> I like the second because it associates the name with the function. >> >> Stef >> >> >> 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] >> >> <Mail Attachment.png> >> >> >> 2. Attach purpose to the name: "Epicea Code Changes" >> >> <Mail Attachment.png> >> >> >> 3. Just "Code Changes" + rephrase children: >> >> <Mail Attachment.png> >> >> >> 4. Flatten >> >> <Mail Attachment.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 <[email protected]> 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 <[email protected]> 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. >> >> >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ > > -- > www.tudorgirba.com > www.feenk.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > >
