October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Playground

by phil＠highoctane.be

Well, I am COMPLAINING LOUDLY about this lack of menu entries then. I hate this super shrunk list of entries in the playground and the GT toolset. I love GT, but I hate those damn menus that do not have what I do need (which is give me the full menu where I do use the same options Kilon mentioned). Also, on Cmd-o used to open about all tools, yes, Cmd-o Cmd-p --> Monticello Cmd-o Cmd-w --> Workspace Cmd-o Cmd-b --> Browser etc. Just GTInspect KMCategory allInstances and see the two global shortcuts categories (one for Spotlight, one for the global shortcuts - and yeah, they should have a name displayed other than nil). On my own little Pharo, I've set addtional shortcuts for the Finder, the File Browser etc as these are sorely missing. And GT as well. Cmd-o Cmd-g for opening a Play<g>round. So that I can keep Cmd-o Cmd-w for opening a Workspace and keeping all of its abilities intact (and not feel crippled by those replacements). I actually like Esteban's proposal for Cmd-g as what we do with the playground is "give it a go", which is different from a doIt, which can stay local and not have side effects on the right side. Phil On Fri, Oct 3, 2014 at 8:20 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 02 Oct 2014, at 21:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > On Thu, Oct 2, 2014 at 5:19 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> Is it just me or is the Playground a big step back in the usability of >> Pharo ? >> >> For me its Gui makes no sense. Gone is the right click menu which had >> tons of useful actions now you only get like a few options. The tab thing >> is weird to say the least with the navigation of the tabs being in the >> opposite side (bottom) of the navigation of the internal tabs(top). No more >> right arrow menu for shortcuts and many features that workspace had. >> > > I will concede that the contextual menu is incomplete. We will work on > that. In the meantime, the keybindings work as in the classic workspace. > > > And one needs to take into account that the âpullâ strategy for menu items > is much better than a âpushâ: Instead of adding just everything that was > there, wait till people > get *really* upset and implement it. This proves that they *really* need > it :-) > > In a way we used that strategy *a lot* for Pharoâ¦ we removed so many menu > entries everywhere. Or Settingsâ¦ the amount of settings that I removed, I > guess >100? > > And the fun thing is: nobody ever complained :-) > > But if I would have asked: you can be sure that someone reacts like âI > never used it but now that you tell me, I want to keep itâ. > (this is true for every unused feature. Just remove and wait. Never ask. > If you ask you will have to keep it. People react to removing unused > features as if you would > take something away from them that was just stored securely for bad times, > as if it would be deeply ingrained in our genes or something). > > Marcus >

Oct. 3, 2014

Re: [Pharo-dev] Playground

by Tudor Girba

It is precisely those points that are not so obvious that are important to discover. That is why your feedback is important. Please keep the questions and suggestions coming. Cheers, Doru On Fri, Oct 3, 2014 at 9:00 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > Thanks I will read those and try it in practise this way it will be easier > to me to connect the dots. I was not aware of them, maybe add them to a > chapter to Pharo for the Enterprise to make them more visible , they will > also need to be added to PBE for beginners because many things about this > tool are not obvious. Still a long way till Pharo 4 is release so you have > plenty of time to polish things up. > > â > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 3, 2014

Re: [Pharo-dev] Playground

by kilon alios

Thanks I will read those and try it in practise this way it will be easier to me to connect the dots. I was not aware of them, maybe add them to a chapter to Pharo for the Enterprise to make them more visible , they will also need to be added to PBE for beginners because many things about this tool are not obvious. Still a long way till Pharo 4 is release so you have plenty of time to polish things up. â

Oct. 3, 2014

Re: [Pharo-dev] Cmd-o is not opening a new pane?

by Tudor Girba

On a separate note, I played with another variation of a go icon that would be more specific to Pharo. Would you like this better? [image: Inline image 1] Cheers, Doru On Fri, Oct 3, 2014 at 8:35 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I understand. But, even now, you associated Cmd+i as a window action. Is > it a stretch to see it as a logical action that materializes in different > ways? > > Doru > > On Fri, Oct 3, 2014 at 8:26 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> well, but thatâs something that *now* you cannot do. >> what people will see now is âcmd+i does one thing in playground, and >> other thing in other parts of the system". >> For me, thatâs not coherent, and introduces a level of pain. >> We are still trying to fix the annoying introduced by nautilus because >> commands are different on it than the rest of the systemâ¦ I would like to >> avoid that. >> >> Esteban >> >> On 03 Oct 2014, at 08:17, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> What if you see it like this: Cmd+i inspects. If you can inspect in >> place, you do it, otherwise, you inspect in a new window. I know it would >> require a bit of getting used to, but imagine what will happen when the >> class browser will allow you to inspect in place ... oops, perhaps I should >> have not say it loud :) >> >> Cheers, >> Doru >> >> >> >> On Fri, Oct 3, 2014 at 8:11 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> yes, because it will be "open panel" in playground and "popup an >>> inspector" everyplace else. >>> >>> On Fri, Oct 3, 2014 at 7:47 AM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> Why do you think that the "Cmd+i" option introduces incoherence? >>>> >>>> Doru >>>> >>>> On Thu, Oct 2, 2014 at 11:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com >>>> > wrote: >>>> >>>>> you have to pay attention to other lists other than moose, Alex :) >>>>> nah, seriously: we have been discussing on a remap, because it is >>>>> conflicting with other keybindings we have in pharo (cmd+o+[others]). >>>>> >>>>> For now, we have three proposals: >>>>> >>>>> cmd+e âexecuteâ >>>>> cmd+g âgoâ >>>>> cmd+i, and remap gtinspector to cmd+I >>>>> >>>>> personally I prefer the second one. >>>>> the third one looks like a good idea, but it will introduce an >>>>> incoherence in the system (unless we remap everything, everywhere), so I >>>>> prefer to stick with âcmd+gâ >>>>> >>>>> Esteban >>>>> >>>>> > On 02 Oct 2014, at 23:28, Alexandre Bergel <alexandre.bergel(a)me.com> >>>>> wrote: >>>>> > >>>>> > It does in the moose image. Pity, this is so useful... >>>>> > >>>>> > Cheers, >>>>> > Alexandre >>>>> > -- >>>>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> > Alexandre Bergel http://www.bergel.eu >>>>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 3, 2014

[pharo-project/pharo-core] edb8ca: 40279

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: edb8ca82c14b1d08fb9b7f6fba4e6b7f1297fd52 https://github.com/pharo-project/pharo-core/commit/edb8ca82c14b1d08fb9b7f6f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-03 (Fri, 03 Oct 2014) Changed paths: A Polymorph-Tools-Diff.package/PSMCPatchMorph.class/class/settings/defaultDiffToolsSettingOn_.st R Polymorph-Tools-Diff.package/PSMCPatchMorph.class/class/settings/defaultMonticelloDiffToolsSettingOn_.st M Polymorph-Widgets.package/MorphicUIManager.class/instance/ui requests/openComparisonFrom_to_belongingTo_from_labeled_inWindowLabeled_.st M Refactoring-Core.package/RBRemoveClassRefactoring.class/instance/preconditions/preconditions.st A Refactoring-Tests-Core.package/RBFooLintRuleTest1.class/README.md A Refactoring-Tests-Core.package/RBFooLintRuleTest1.class/definition.st A Refactoring-Tests-Core.package/RBFooLintRuleTest1.class/instance/as yet unclassified/foo.st M Refactoring-Tests-Core.package/RBRemoveClassTest.class/instance/tests/testRemoveClass.st A Refactoring-Tests-Core.package/RBTransformationRuleTest1.class/README.md A Refactoring-Tests-Core.package/RBTransformationRuleTest1.class/definition.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script279.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40279.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Polymorph.package/PolymorphSystemSettings.class/class/morphic/morphicSettingsOn_.st R Settings-Polymorph.package/PolymorphSystemSettings.class/class/morphic/usePolymorphDiffMorph.st R Settings-Polymorph.package/PolymorphSystemSettings.class/class/morphic/usePolymorphDiffMorph_.st Log Message: ----------- 40279 13719 Failing test: RBRemoveClassTest>>#testRemoveClass https://pharo.fogbugz.com/f/cases/13719 14144 unify #usePolymorphDiffMorph and #polymorphDiffToolsUsedByDefault https://pharo.fogbugz.com/f/cases/14144 http://files.pharo.org/image/40/40279.zip

Oct. 3, 2014

[pharo-project/pharo-core]

by GitHub

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

Oct. 3, 2014

Re: [Pharo-dev] Cmd-o is not opening a new pane?

by Tudor Girba

I understand. But, even now, you associated Cmd+i as a window action. Is it a stretch to see it as a logical action that materializes in different ways? Doru On Fri, Oct 3, 2014 at 8:26 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > well, but thatâs something that *now* you cannot do. > what people will see now is âcmd+i does one thing in playground, and other > thing in other parts of the system". > For me, thatâs not coherent, and introduces a level of pain. > We are still trying to fix the annoying introduced by nautilus because > commands are different on it than the rest of the systemâ¦ I would like to > avoid that. > > Esteban > > On 03 Oct 2014, at 08:17, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > What if you see it like this: Cmd+i inspects. If you can inspect in place, > you do it, otherwise, you inspect in a new window. I know it would require > a bit of getting used to, but imagine what will happen when the class > browser will allow you to inspect in place ... oops, perhaps I should have > not say it loud :) > > Cheers, > Doru > > > > On Fri, Oct 3, 2014 at 8:11 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> yes, because it will be "open panel" in playground and "popup an >> inspector" everyplace else. >> >> On Fri, Oct 3, 2014 at 7:47 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Why do you think that the "Cmd+i" option introduces incoherence? >>> >>> Doru >>> >>> On Thu, Oct 2, 2014 at 11:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>>> you have to pay attention to other lists other than moose, Alex :) >>>> nah, seriously: we have been discussing on a remap, because it is >>>> conflicting with other keybindings we have in pharo (cmd+o+[others]). >>>> >>>> For now, we have three proposals: >>>> >>>> cmd+e âexecuteâ >>>> cmd+g âgoâ >>>> cmd+i, and remap gtinspector to cmd+I >>>> >>>> personally I prefer the second one. >>>> the third one looks like a good idea, but it will introduce an >>>> incoherence in the system (unless we remap everything, everywhere), so I >>>> prefer to stick with âcmd+gâ >>>> >>>> Esteban >>>> >>>> > On 02 Oct 2014, at 23:28, Alexandre Bergel <alexandre.bergel(a)me.com> >>>> wrote: >>>> > >>>> > It does in the moose image. Pity, this is so useful... >>>> > >>>> > Cheers, >>>> > Alexandre >>>> > -- >>>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> > Alexandre Bergel http://www.bergel.eu >>>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> > >>>> > >>>> > >>>> > >>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 3, 2014

Re: [Pharo-dev] Cmd-o is not opening a new pane?

by Esteban Lorenzano

well, but thatâs something that *now* you cannot do. what people will see now is âcmd+i does one thing in playground, and other thing in other parts of the system". For me, thatâs not coherent, and introduces a level of pain. We are still trying to fix the annoying introduced by nautilus because commands are different on it than the rest of the systemâ¦ I would like to avoid that. Esteban > On 03 Oct 2014, at 08:17, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > What if you see it like this: Cmd+i inspects. If you can inspect in place, you do it, otherwise, you inspect in a new window. I know it would require a bit of getting used to, but imagine what will happen when the class browser will allow you to inspect in place ... oops, perhaps I should have not say it loud :) > > Cheers, > Doru > > > > On Fri, Oct 3, 2014 at 8:11 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > yes, because it will be "open panel" in playground and "popup an inspector" everyplace else. > > On Fri, Oct 3, 2014 at 7:47 AM, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: > Why do you think that the "Cmd+i" option introduces incoherence? > > Doru > > On Thu, Oct 2, 2014 at 11:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > you have to pay attention to other lists other than moose, Alex :) > nah, seriously: we have been discussing on a remap, because it is conflicting with other keybindings we have in pharo (cmd+o+[others]). > > For now, we have three proposals: > > cmd+e âexecuteâ > cmd+g âgoâ > cmd+i, and remap gtinspector to cmd+I > > personally I prefer the second one. > the third one looks like a good idea, but it will introduce an incoherence in the system (unless we remap everything, everywhere), so I prefer to stick with âcmd+gâ > > Esteban > > > On 02 Oct 2014, at 23:28, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > > > It does in the moose image. Pity, this is so useful... > > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 3, 2014

Re: [Pharo-dev] Playground

by Tudor Girba

What is not clear? For documentation, there are plenty of examples on the humane-assessment.com/blog. Here are some: http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructed http://www.humane-assessment.com/blog/browsing-files-with-gtinspector/ http://www.humane-assessment.com/blog/browsing-files-with-gtinspector-video/ http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… http://www.humane-assessment.com/blog/managing-gtinspector-extensions/ http://www.humane-assessment.com/blog/writing-pillar-books-with-the-gtinspe… http://www.humane-assessment.com/blog/managing-morph-keybindings-with-gtins… http://www.humane-assessment.com/blog/introducing-the-gtplayground/ Or you can search https://www.google.com/search?q=site:humane-assessment.com+gtinspector Doru On Fri, Oct 3, 2014 at 8:18 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > not really but thats ok I will wait for the documentation of it. > > On Fri, Oct 3, 2014 at 8:46 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Kilon, >> >> I think I see where the confusion starts from. So, let's start from the >> basics: >> - the inspector is for inspecting objects, not just classes. >> - every pane shows exactly one object (the one you see in the title of >> the pane). >> - every pane shows multiple presentations of that object as tabs. >> - the two basic presentations are "State" showing the state of the >> object, and "Meta" showing the code related to the object. We could call >> this one "Class", but that can generate confusions in certain edge cases >> when you are inspecting a class object. That is why I chose "Meta", but >> maybe we can find a better one. >> - the "Meta" presentation is meant to offer a way to manipulate or lookup >> the code while being in the context of an object. >> - every tab is defined by the class of the object you are inspecting. For >> example, "State" is defined in Object>>#gtInspectorStateIn:, but any other >> object can define extra tabs. >> - the "Methods" tab that you refer to is such a presentation that is >> specific to the class object. Specifically, you can find it in >> Class>>#gtInspectorMethodsIn:. As the class object is a meta-object, I can >> see how it can easily generate confusion because you have both "Meta" which >> will show you the code of the class side of the class, and "Methods" which >> show you the methods of the class. >> - that is why, I suggest to start getting used with the inspector by >> inspecting "FileSystem workingDirectory". You will see that you get and >> "Items" view that allows you to explore the directory like you do in a more >> classic browser. Then select from the file system a PNG file and you will >> get a "Picture" >> - all these tabs are customizable in that you can define such tabs for >> your own objects easily. >> - so, if you do not like one, you can simply either change it or remove >> it by deleting the corresponding method or removing the annotation from it >> (gtInspectorPresentationOrder:) >> >> Does this make more sense now? >> >> As for the actions, they will come back in some form. >> >> Cheers, >> Doru >> >> >> On Thu, Oct 2, 2014 at 10:34 PM, kilon alios <kilon.alios(a)gmail.com> >> wrote: >> >>> "I will concede that the contextual menu is incomplete. We will work on >>> that. In the meantime, the keybindings work as in the classic workspace. >>> >>> But, what are the many features that the workspace had and you miss?" >>> >>> from right click menu I use -> Copy , Paste , find , browse it, sender >>> of it, implementors of it, references to it,. >>> from down arrow menu I use -> Change title, create window group, >>> previous contents (that last on i see that playground has it) >>> >>> "What do you find weird about "Meta"? >>> I agree that "All ref" should be better explained. >>> But, what do you think these tabs mean?" >>> >>> Meta means nothing to me, maybe you should name it Meta-Class the >>> problem however is that the IDE does not use that naming anywhere else >>> apart from mentioning it in PBE. No idea what all references means, maybe >>> its the instance variables. Is there an aggreement now in Pharo to call the >>> class side of a class a Metaclass ? Its important to decide on these thing >>> on a global scale or else you have confusion. >>> >>> "If so, clicking on an entry, is the correspondent of inspecting that >>> object. In the "State" tab, we also provide self to denote the same object >>> as the one represented in the tab. This was borrowed from the classic >>> inspector, but maybe it is confusing in the context of the new inspector. >>> In any case, if you continue clicking on self, you will indeed get the same >>> object over and over. But, that does not mean that the inspector went in a >>> loop" >>> >>> yes but why allowing the same pane to respawn when clicking self it >>> makes not sense to me. Its also confusing for a begineer. >>> >>> "But, what do you mean by instance side tab?" >>> >>> I assume the instance side of the class is the "methods" tab ? no ? >>> >>> "Which one did you like?" >>> >>> I like the basic idea of trying to extend workspace with much more >>> functionality and uniting all tools like inspector and system browser under >>> one roof. I like also that comments get a new separate tab and that you >>> trying to support pillar. >>> >>> The State name is vague, since state can mean both instance and class >>> variables. >>> >>> "I do not understand this part. Can you explain in more details?" >>> >>> this -> https://www.youtube.com/watch?v=GGJZeajjWGU >>> >>> "It is not different thinking. It is a different use case :). The Meta >>> tab shows the class of the object you inspect. If you inspected a class, >>> then the inspector also provides you a list of its methods. " >>> >>> I am talking about the methods tab which also a confusing name for a >>> tab, what kind of methods ? instance or class . I assume from the existence >>> of Meta that those are instance methods . So why methods tab is not similar >>> to Meta tab ? why it show only the method names and not the class and its >>> inheritance chain and the method source of the method selected from the >>> list of methods exactly as Meta tab is doing ? >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 3, 2014

Re: [Pharo-dev] Playground

by Tudor Girba

:) Doru On Fri, Oct 3, 2014 at 8:20 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 02 Oct 2014, at 21:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > On Thu, Oct 2, 2014 at 5:19 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> Is it just me or is the Playground a big step back in the usability of >> Pharo ? >> >> For me its Gui makes no sense. Gone is the right click menu which had >> tons of useful actions now you only get like a few options. The tab thing >> is weird to say the least with the navigation of the tabs being in the >> opposite side (bottom) of the navigation of the internal tabs(top). No more >> right arrow menu for shortcuts and many features that workspace had. >> > > I will concede that the contextual menu is incomplete. We will work on > that. In the meantime, the keybindings work as in the classic workspace. > > > And one needs to take into account that the âpullâ strategy for menu items > is much better than a âpushâ: Instead of adding just everything that was > there, wait till people > get *really* upset and implement it. This proves that they *really* need > it :-) > > In a way we used that strategy *a lot* for Pharoâ¦ we removed so many menu > entries everywhere. Or Settingsâ¦ the amount of settings that I removed, I > guess >100? > > And the fun thing is: nobody ever complained :-) > > But if I would have asked: you can be sure that someone reacts like âI > never used it but now that you tell me, I want to keep itâ. > (this is true for every unused feature. Just remove and wait. Never ask. > If you ask you will have to keep it. People react to removing unused > features as if you would > take something away from them that was just stored securely for bad times, > as if it would be deeply ingrained in our genes or something). > > Marcus > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 3, 2014