In summary, we want to change the "Epicea" menu entry to: "Epicea Code Changes" (Option 2) --> Stef, Serge
or: "Code Changes" (Option 3) --> Marcus, Sean I do not care a lot. BTW, what about other tools in the same manu such as Komitter and Versionner? Apart from that, many agree on merging Epicea windows in one. --> Doru, Norbert, Denis, Ben Martin On Sat, Dec 24, 2016 at 6:02 AM, <[email protected]> wrote: > I prefer option 2 because Epicea name is not really important and means > nothing for the beginner. What is really important in then world menu is > the function. > > Envoyé de mon iPhone > > Le 24 déc. 2016 à 09:35, stepharong <[email protected]> a écrit : > > On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias <[email protected]> > wrote: > > Ben, yes, please create the issues if you want, and I will try to > implement them soon. I guess if they are mostly UI changes and categorized > to "first impression count" or something like that, they can still be > included in Pharo 6, no? > > > yes > > > One thing to discuss: what do you think about the fact that... > - the "Session changes" displays the changes of multiple log files in the > same list widget (silently concatenated), versus > - the "All changes" way of displaying, where the changes of each log file > are separated. > > That was my main reason to keep two windows by separate. I had the > impression that in some cases > - the user wants to see all changes together and he/she doesn't care in > which log file the changes are written, while in other cases > - the user wants to know the log files and see how are they connected, > because they have some meaning > What do you think of this? > BTW I don't like the file names... hints are welcome to improve it > > Martin > > On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman <[email protected]> wrote: > >> 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." >> > >> > >> > >> > >> > >> >> > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > >
