April 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 3.0] #30057

by Marcus Denker

30057 ----- 10365 #mustBeBooleanIn: should not raise error https://pharo.fogbugz.com/f/cases/10365 (not yet complete and turned off, we will slowly complete it) 10345 Build menus in SyntaxError the same way like in Workspace https://pharo.fogbugz.com/f/cases/10345 10380 DNU in RBCondition>>canUnderstand:in: https://pharo.fogbugz.com/f/cases/10380 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1077 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Refactoring-Core-MarcusDenke… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Settings-Compiler-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/OpalCompiler-Tests-MarcusDen… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/OpalCompiler-Core-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1373

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Norbert Hartl

Am 24.04.2013 um 10:42 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > On Apr 24, 2013, at 10:30 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 24.04.2013 um 10:00 schrieb Goubier Thierry <thierry.goubier(a)cea.fr>: >> >>>> Maybe we can make a destination between two cases: >>>> >>>> 1) cursor is placed somewhere. Here people are interested in >>>> suggestions. The context menu like it is now makes sense >>>> (I would add one entry for the suggestions, in addition to the >>>> shortcut) >>>> >>>> 2) The user *selected* something explicitly. Here I think we should show >>>> a modified context menu that only has those things >>>> the make sense on the selection. Nobody want to "Debug it" a >>>> variable, or "print it" a syntactically invalid selection... >>> >>> Hum, this one looks cool. The default action menu is quite long (debugIt, exploreIt, etc...) and making it shorter is a nice touch. >> >> Yes, but unfortunately it doesn't work that way most of the time for the unexperienced.. Learning a UI means knowing where things are. A changing context menu mostly leads to confusion because you struggle finding things you saw before. Those things only make sense if you're already comfortable with the UI and the environment. I think that is one reason we menu entries are often just greyed out. This way you have the orientation because the menu is of the same shape and by seeing greyed out stuff you can immediately learn that some menu entries do not make sense in this context. >> Maybe the way it can work is to have this as an option. First grey out things and the expert can switch them off to make disabled entries invisible. >> > But aren't *context* menus named like that because they depend on the context? It doesn't help much if you use a term consistently if the thing _the term describes_ doesn't work out at the end. And according to wikipedia they were called pop-up menus in smalltalk :) > If I get a context menu for a class or a method in the panes above, they are different, too. I didn't mean that there is only one menu in the system and it has to look the same everywhere. I just wanted to note that there are things to take care of when building menu logic. Norbert

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Gisela Decuzzi

I can add the entrance in Nautilus menu today, I didn't think in that and it can be cool. I want to put some contextual information about the selection. I think that on Friday I can make the slice. 2013/4/24 Goubier Thierry <thierry.goubier(a)cea.fr> > Le 24/04/2013 10:29, Norbert Hartl a Ã©crit : > >> >> Am 24.04.2013 um 10:00 schrieb Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr**>>: >> >> >> Maybe we can make a destination between two cases: >>>> >>>> 1) cursor is placed somewhere. Here people are interested in >>>> suggestions. The context menu like it is now makes sense >>>> (I would add one entry for the suggestions, in addition to the >>>> shortcut) >>>> >>>> 2) The user *selected* something explicitly. Here I think we should show >>>> a modified context menu that only has those things >>>> the make sense on the selection. Nobody want to "Debug it" a >>>> variable, or "print it" a syntactically invalid selection... >>>> >>> >>> Hum, this one looks cool. The default action menu is quite long >>> (debugIt, exploreIt, etc...) and making it shorter is a nice touch. >>> >> >> Yes, but unfortunately it doesn't work that way most of the time for the >> unexperienced.. Learning a UI means knowing where things are. A changing >> context menu mostly leads to confusion because you struggle finding >> things you saw before. Those things only make sense if you're already >> comfortable with the UI and the environment. I think that is one reason >> we menu entries are often just greyed out. This way you have the >> orientation because the menu is of the same shape and by seeing greyed >> out stuff you can immediately learn that some menu entries do not make >> sense in this context. >> > > Yes. You're right for that, however, the issue is that the base menu is > too long from an UI point of view (no more than 7 +/-2 elements). The > minimum you get on a code pane (when you build the menu yourself properly, > as I do for the AltBrowser) is 12 commands: (accept, cancel, undo, redo, > cut, copy, paste, do it, print it, inspect it, explore it, debug it) with > the last five greyed out if you haven't selected anything. > > It looks hard to decrease to a more reasonable number - especially the > five ways of executing some selection. > > Suggestions are very much selection or cursor dependent; and there will be > a lot of them, so greying out will be unmanageable. I don't think that > having a menu long and deep, with just a few entries non-greyed out, will > be usable. And given that the suggestions are selection/cursor based, > guessing when a greyed entry will activate itself will be an interesting > exercise for a newcomer :) > > > Maybe the way it can work is to have this as an option. First grey out >> things and the expert can switch them off to make disabled entries >> invisible. >> > > Or have a suggestions submenu which restrict changing entries to a subset > of the menu: Main, essential items are few and fixed; changing things are > restricted to a specific submenu. > > > But then I'm far from being an UI/UX expert. >> > > Me neither. I worked in that field a long time ago, but that's all. > > Thierry > > Norbert >> > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Goubier Thierry

Le 24/04/2013 10:29, Norbert Hartl a Ã©crit : > > Am 24.04.2013 um 10:00 schrieb Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>>: > >>> Maybe we can make a destination between two cases: >>> >>> 1) cursor is placed somewhere. Here people are interested in >>> suggestions. The context menu like it is now makes sense >>> (I would add one entry for the suggestions, in addition to the >>> shortcut) >>> >>> 2) The user *selected* something explicitly. Here I think we should show >>> a modified context menu that only has those things >>> the make sense on the selection. Nobody want to "Debug it" a >>> variable, or "print it" a syntactically invalid selection... >> >> Hum, this one looks cool. The default action menu is quite long >> (debugIt, exploreIt, etc...) and making it shorter is a nice touch. > > Yes, but unfortunately it doesn't work that way most of the time for the > unexperienced.. Learning a UI means knowing where things are. A changing > context menu mostly leads to confusion because you struggle finding > things you saw before. Those things only make sense if you're already > comfortable with the UI and the environment. I think that is one reason > we menu entries are often just greyed out. This way you have the > orientation because the menu is of the same shape and by seeing greyed > out stuff you can immediately learn that some menu entries do not make > sense in this context. Yes. You're right for that, however, the issue is that the base menu is too long from an UI point of view (no more than 7 +/-2 elements). The minimum you get on a code pane (when you build the menu yourself properly, as I do for the AltBrowser) is 12 commands: (accept, cancel, undo, redo, cut, copy, paste, do it, print it, inspect it, explore it, debug it) with the last five greyed out if you haven't selected anything. It looks hard to decrease to a more reasonable number - especially the five ways of executing some selection. Suggestions are very much selection or cursor dependent; and there will be a lot of them, so greying out will be unmanageable. I don't think that having a menu long and deep, with just a few entries non-greyed out, will be usable. And given that the suggestions are selection/cursor based, guessing when a greyed entry will activate itself will be an interesting exercise for a newcomer :) > Maybe the way it can work is to have this as an option. First grey out > things and the expert can switch them off to make disabled entries > invisible. Or have a suggestions submenu which restrict changing entries to a subset of the menu: Main, essential items are few and fixed; changing things are restricted to a specific submenu. > But then I'm far from being an UI/UX expert. Me neither. I worked in that field a long time ago, but that's all. Thierry > Norbert -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Marcus Denker

On Apr 24, 2013, at 10:30 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 24.04.2013 um 10:00 schrieb Goubier Thierry <thierry.goubier(a)cea.fr>: > >>> Maybe we can make a destination between two cases: >>> >>> 1) cursor is placed somewhere. Here people are interested in >>> suggestions. The context menu like it is now makes sense >>> (I would add one entry for the suggestions, in addition to the >>> shortcut) >>> >>> 2) The user *selected* something explicitly. Here I think we should show >>> a modified context menu that only has those things >>> the make sense on the selection. Nobody want to "Debug it" a >>> variable, or "print it" a syntactically invalid selection... >> >> Hum, this one looks cool. The default action menu is quite long (debugIt, exploreIt, etc...) and making it shorter is a nice touch. > > Yes, but unfortunately it doesn't work that way most of the time for the unexperienced.. Learning a UI means knowing where things are. A changing context menu mostly leads to confusion because you struggle finding things you saw before. Those things only make sense if you're already comfortable with the UI and the environment. I think that is one reason we menu entries are often just greyed out. This way you have the orientation because the menu is of the same shape and by seeing greyed out stuff you can immediately learn that some menu entries do not make sense in this context. > Maybe the way it can work is to have this as an option. First grey out things and the expert can switch them off to make disabled entries invisible. > But aren't *context* menus named like that because they depend on the context? If I get a context menu for a class or a method in the panes above, they are different, too. Marcus

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Norbert Hartl

Am 24.04.2013 um 10:00 schrieb Goubier Thierry <thierry.goubier(a)cea.fr>: >> Maybe we can make a destination between two cases: >> >> 1) cursor is placed somewhere. Here people are interested in >> suggestions. The context menu like it is now makes sense >> (I would add one entry for the suggestions, in addition to the >> shortcut) >> >> 2) The user *selected* something explicitly. Here I think we should show >> a modified context menu that only has those things >> the make sense on the selection. Nobody want to "Debug it" a >> variable, or "print it" a syntactically invalid selection... > > Hum, this one looks cool. The default action menu is quite long (debugIt, exploreIt, etc...) and making it shorter is a nice touch. Yes, but unfortunately it doesn't work that way most of the time for the unexperienced.. Learning a UI means knowing where things are. A changing context menu mostly leads to confusion because you struggle finding things you saw before. Those things only make sense if you're already comfortable with the UI and the environment. I think that is one reason we menu entries are often just greyed out. This way you have the orientation because the menu is of the same shape and by seeing greyed out stuff you can immediately learn that some menu entries do not make sense in this context. Maybe the way it can work is to have this as an option. First grey out things and the expert can switch them off to make disabled entries invisible. But then I'm far from being an UI/UX expert. Norbert

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by stephane ducasse

What would be good is that when we get the sender/implementor is to get - the name of the entity as first entry in the menu - get the entity selected in the text. blockClosureValue: aBlockClosure message: aMessage |newMessage| newMessage := Message selector: #valueWithArguments: arguments: (Array with: aMessage arguments). ^self blockClosureValueWithArguments: aBlockClosure message: newMessage when I'm on selector: it works I get selector:arguments: now when I'm #valueWithArgurments it does not What would be cool is to have a way to select the enclosing expression but you know it:) When can we push that into 3.0 Stef > Hello! After some work I think that Smart Suggestions it's ready to have some real feedback to continue growing up :) > > What is it? > The idea it's to have suggestions based in the text selected or the cursor position. > Actually there are suggestions for: > - Temporary/Instance/Class Variable > - Class > - Method (when you are in the selector) > - Source (multiple lines) > - Message > > How to install it? > Gofer it > smalltalkhubUser: 'gisela' > project: 'SmartSuggestions'; > package: 'SmartSuggestions'; > load. > > Some screen shots: (to activate de menu the shortcut es Ctrl + t for windows or unix and Command + t for mac) > <Method.png> > <ClassVariable.png> > <Message.png> > > > How to define a new action? > It's easy to define your own action only use the pragma in your custom method and make sure to retunr an instance of SugsSuggestion, examples in SugsSuggestionFactory are categorized by the selection. > > > If you have some comments I will be very happy to heard about, I have removed the actions form nautilus menu, because it was to much visual noise (at least for me) if you want to add it, only uncoment the pragma in: #SugsMenuBuilder>>addSuggestionToSourceCodeMenu: > > ps: It could appear a DNU when fetching the suggestions for a class variable the description and solution are in https://pharo.fogbugz.com/default.asp?10380#75204

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Goubier Thierry

Le 24/04/2013 09:22, Marcus Denker a Ã©crit : > > On Apr 24, 2013, at 1:18 AM, Gisela Decuzzi <giseladecuzzi(a)gmail.com > <mailto:giseladecuzzi@gmail.com>> wrote: > >> Hello! After some work I think that Smart Suggestions it's ready to >> have some real feedback to continue growing up :) >> >> What is it? >> The idea it's to have suggestions based in the text selected or the >> cursor position. >> Actually there are suggestions for: >> - Temporary/Instance/Class Variable >> - Class >> - Method (when you are in the selector) >> - Source (multiple lines) >> - Message >> > > Nice! > >> >> If you have some comments I will be very happy to heard about, I have >> removed the actions form nautilus menu, because it was to much visual >> noise (at least for me) if you want to add it, only uncoment the >> pragma in: #SugsMenuBuilder>>addSuggestionToSourceCodeMenu: >> > > Maybe we can make a destination between two cases: > > 1) cursor is placed somewhere. Here people are interested in > suggestions. The context menu like it is now makes sense > (I would add one entry for the suggestions, in addition to the > shortcut) > > 2) The user *selected* something explicitly. Here I think we should show > a modified context menu that only has those things > the make sense on the selection. Nobody want to "Debug it" a > variable, or "print it" a syntactically invalid selection... Hum, this one looks cool. The default action menu is quite long (debugIt, exploreIt, etc...) and making it shorter is a nice touch. > > Marcus > Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by stephane ducasse

+ 1 Interfaces are a cool concept and we should use them and adhere to them conceptually > I am tempted to deprecate #definesMethod: and just rename it to canUnderstand: (and fix all senders) > This way the RB model for code would be one step closer to normal classes and methods.

April 24, 2013

Re: [Pharo-project] Smart Suggestion Version 1

by Marcus Denker

On Apr 24, 2013, at 1:18 AM, Gisela Decuzzi <giseladecuzzi(a)gmail.com> wrote: > Hello! After some work I think that Smart Suggestions it's ready to have some real feedback to continue growing up :) > > What is it? > The idea it's to have suggestions based in the text selected or the cursor position. > Actually there are suggestions for: > - Temporary/Instance/Class Variable > - Class > - Method (when you are in the selector) > - Source (multiple lines) > - Message > Nice! > > If you have some comments I will be very happy to heard about, I have removed the actions form nautilus menu, because it was to much visual noise (at least for me) if you want to add it, only uncoment the pragma in: #SugsMenuBuilder>>addSuggestionToSourceCodeMenu: > Maybe we can make a destination between two cases: 1) cursor is placed somewhere. Here people are interested in suggestions. The context menu like it is now makes sense (I would add one entry for the suggestions, in addition to the shortcut) 2) The user *selected* something explicitly. Here I think we should show a modified context menu that only has those things the make sense on the selection. Nobody want to "Debug it" a variable, or "print it" a syntactically invalid selection... > ps: It could appear a DNU when fetching the suggestions for a class variable the description and solution are in https://pharo.fogbugz.com/default.asp?10380#75204 I am tempted to deprecate #definesMethod: and just rename it to canUnderstand: (and fix all senders) This way the RB model for code would be one step closer to normal classes and methods. The real plan of course is to unify *all* meta models for code and just use Ring. The RBMethod/RBClass hierarchy is one of the candidates for that, PseudoClass and PseudoMethod the other. (I am sure there are eve more). Marcus

April 24, 2013