January 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Epicea user experience report

by Martin Dias

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 <btc(a)openinworld.com> wrote: > On Tue, Dec 27, 2016 at 5:49 PM, Martin Dias <tinchodias(a)gmail.com> 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, <serge.stinckwich(a)gmail.com> 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 <stepharong(a)free.fr> a Ã©crit : > >> > >> On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias <tinchodias(a)gmail.com> > >> 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 <btc(a)openinworld.com> wrote: > >>> > >>> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba <tudor(a)tudorgirba.com> > >>> 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 <stepharong(a)free.fr> > 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 <tinchodias(a)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 <btc(a)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. > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> 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/ > > > > > >

Jan. 11, 2017

Re: [Pharo-dev] [ANN] Pharo Sprint First half 2017

by Marcus Denker

> On 10 Jan 2017, at 15:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 23 Dec 2016, at 15:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> As this year, there will be again âPharo Sprintsâ next year. At these dates we meet (virtual or real) >> to work on boring (or complex) issues together: >> > > â¦. > >> May 26 > > This one we have to change: The 25th is a holiday here and the 26 a âpre allocated free day from the overtime that comes > from having officially a 35h work week but working 38.5 hoursâ where our office is closed. > The idea is to move it one week: Friday, June 2. Marcus

Jan. 10, 2017

Re: [Pharo-dev] [ANN] Pharo Sprint First half 2017

by Marcus Denker

> On 23 Dec 2016, at 15:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > As this year, there will be again âPharo Sprintsâ next year. At these dates we meet (virtual or real) > to work on boring (or complex) issues together: > â¦. > May 26 This one we have to change: The 25th is a holiday here and the 26 a âpre allocated free day from the overtime that comes from having officially a 35h work week but working 38.5 hoursâ where our office is closed. Marcus

Jan. 10, 2017

[pharo-project/pharo-core] 10ad6c: 60342

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 10ad6c88e25fff7be020b03a14786be40cc6308f https://github.com/pharo-project/pharo-core/commit/10ad6c88e25fff7be020b03a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-09 (Mon, 09 Jan 2017) Changed paths: M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/baseline_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60341.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60342.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60341.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60342.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60342 19531 Latest GTTools integration broke the bootstrap https://pharo.fogbugz.com/f/cases/19531 http://files.pharo.org/image/60/60342.zip

Jan. 9, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60342 Home: https://github.com/pharo-project/pharo-core

Jan. 9, 2017

Re: [Pharo-dev] happy and bold new year

by Tudor Girba

Hi, In my opinion, Pharo provides the strongest infrastructure for understanding a system from all technologies I have seen. So, if you say that Pharo is a bit "under featured in, then I think we are not referring to the same thing :). May I ask how you are using the inspector? For example: - do you extend the inspector? - do you construct visualizations about your system in the inspector? - do you write queries about code in the inspector? Cheers, Doru > On Jan 9, 2017, at 3:42 PM, Hilaire <hilaire(a)drgeo.eu> wrote: > > I know this path of understanding code while it is running (inspector or > debugger), but it is still a tedious path, and I feel Pharo is a bit > under featured on that specific department, therefore my question on Moose. > > Hilaire > > > > Le 09/01/2017 Ã 15:09, Tudor Girba a Ã©crit : >> That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when itâs running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far. > > -- > Dr. Geo > http://drgeo.eu > > -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Jan. 9, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60341 Home: https://github.com/pharo-project/pharo-core

Jan. 9, 2017

[pharo-project/pharo-core] ea0552: 60341

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: ea05523c2866a231ada4b126bf58392f4ed0de8f https://github.com/pharo-project/pharo-core/commit/ea05523c2866a231ada4b126… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-09 (Mon, 09 Jan 2017) Changed paths: A Nautilus.package/AbstractNautilusUI.class/instance/button-variables/browseVariableReferences.st A Nautilus.package/AbstractNautilusUI.class/instance/button-variables/browseVariablesButtonAction.st A Nautilus.package/AbstractNautilusUI.class/instance/button-variables/browseVariablesButtonEnabled.st A Nautilus.package/AbstractNautilusUI.class/instance/button-variables/browseVariablesButtonLabel.st A Nautilus.package/AbstractNautilusUI.class/instance/button-variables/browseVariablesButtonState.st A Nautilus.package/AbstractNautilusUI.class/instance/button-variables/buildVariableMenuFor_variablesFrom_menuItemBy_.st A Nautilus.package/AbstractNautilusUI.class/instance/button-variables/variablesMenuEntry_items_in_using_.st R Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/browseVariableReferences.st R Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/browseVariablesButtonAction.st R Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/browseVariablesButtonEnabled.st R Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/browseVariablesButtonLabel.st R Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/browseVariablesButtonState.st R Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/buildVariableMenuFor_variablesFrom_menuItemBy_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60340.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60341.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60340.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60341.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TBehavior.class/instance/accessing method dictionary/localMethodNamed_ifAbsent_.st A Traits.package/TBehavior.class/instance/accessing method dictionary/localMethods.st R Traits.package/TClassDescription.class/instance/filein%2Fout/localMethods.st Log Message: ----------- 60341 19521 localMethods should be moved to TBehavior where localSelectors methods are defined https://pharo.fogbugz.com/f/cases/19521 19528 Split larger variable entries in the Variables menu into submenus https://pharo.fogbugz.com/f/cases/19528 http://files.pharo.org/image/60/60341.zip

Jan. 9, 2017

Re: [Pharo-dev] happy and bold new year

by Hilaire

I know this path of understanding code while it is running (inspector or debugger), but it is still a tedious path, and I feel Pharo is a bit under featured on that specific department, therefore my question on Moose. Hilaire Le 09/01/2017 Ã 15:09, Tudor Girba a Ã©crit : > That is why my advice is to not try too long to understand Pharo code statically because this is not where the power of Pharo is. You are in a much better position to understand a system when itâs running. So, the tools that I use the most are the inspector when I need to understand structural relationships or contracts between objects, and the debugger when I need to understand some algorithmic steps. Even when I look for code structure patterns, I mostly use the inspector because it allows me to query. Then you augment these tools with custom views and you get quite far. -- Dr. Geo http://drgeo.eu

Jan. 9, 2017

Re: [Pharo-dev] [Ann] Calypso system browser

by Bernhard Pieber

No, this is not what I meant. Although it might be a useful variant once there is go back and go forward like in web browsers. For now ClySystemBrowser beDefaultBrowser does what I want. Thanks! Cheers, Bernhard > Am 09.01.2017 um 15:10 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 2017-01-09 13:02 GMT+01:00 Bernhard Pieber <bernhard(a)pieber.com>: > I just played a bit with Calypso. I love the possibility to easily show the inherited methods. I would love to stay in a Calypso browser when I use Cmd-b to browse classes referenced in method source. > > Maybe I misunderstood you. Do you want cmd-b open selected class in same browser window?

Jan. 9, 2017