Sorry I'm for option 3 like Markus or Sean. Envoyé de mon iPhone
> Le 27 déc. 2016 à 10:49, Martin Dias <[email protected]> a écrit : > > 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/ >
