I created an entry in fogbugz and had progress: https://pharo.fogbugz.com/f/cases/19534/Unify-Epicea-UIs
Cheers, Martin On Tue, Dec 27, 2016 at 11:20 PM, Ben Coman <[email protected]> wrote: > On Tue, Dec 27, 2016 at 5:49 PM, Martin Dias <[email protected]> wrote: > > 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? > > Option 3 for me. Komitter and Versionner are new tools so are > starting their meme-space from scratch, and also their names reflect > their function. Epicea name is replacing an existing tool and also is > more abstract. > > "Epicea" should still appear in the title bar of the window it pops up > to identify the tool - similar to what Nautilus does. > > cheers -ben > > > > Apart from that, many agree on merging Epicea windows in one. > > --> Doru, Norbert, Denis, Ben > > cool. Now since Pharo 6 is the first release of Epicea, and as UI > rather than fundamenta change, > I hope this can be done as an exception to the feature freeze, so we > get it right from the start. > And so we will need to pay attention to giving it a good workout > leading up to release. > > cheers -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. > > P.S. this sounded like support for option 3 :) ? > > >> > >> 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/ > > > > > >
