- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] World Menu associated mouse click

by Dimitris Chloupis

Or you could end up making everything easy to customize and allow the user to decide what is best for him or her. After all this a big reason why tools like vim and emacs are so popular. Fortunately we see a move of Pharo away of hard coded stuff. On Tue, Aug 18, 2015 at 12:40 AM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > On Mon, Aug 17, 2015 at 9:15 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> If you are not ready to get out of your comfort zone , you wont be using >> Smalltalk. Sure change it to left click, but in the end it wont make much >> of a difference. Smalltalk is for a specific kind of people that are >> looking for a fresh approach to coding. For everyone else there is like a >> ton of languages that recycle old recipes and keep things familiar. >> > > Unless, of course, the red button was chosen out of convenience since Mac > had only one mouse button. (This is just my guess.) > But importantly there's difference between "keeping things familiar with > the universe (other OS/langs/...)" and "being internally consistent" > (every menu except for the world menu is opened with right/yellow button). > > Now the great thing about Pharo is that everything can change if it makes > sense. :) >

Aug. 17, 2015

Re: [Pharo-dev] World Menu associated mouse click

by Peter UhnÃ¡k

On Mon, Aug 17, 2015 at 9:15 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > If you are not ready to get out of your comfort zone , you wont be using > Smalltalk. Sure change it to left click, but in the end it wont make much > of a difference. Smalltalk is for a specific kind of people that are > looking for a fresh approach to coding. For everyone else there is like a > ton of languages that recycle old recipes and keep things familiar. > Unless, of course, the red button was chosen out of convenience since Mac had only one mouse button. (This is just my guess.) But importantly there's difference between "keeping things familiar with the universe (other OS/langs/...)" and "being internally consistent" (every menu except for the world menu is opened with right/yellow button). Now the great thing about Pharo is that everything can change if it makes sense. :)

Aug. 17, 2015

Re: [Pharo-dev] Ctrl key on Windows

by Nicolai Hess

2015-08-17 21:16 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > First, Thanks Nicolai :) > > I was testing the latest windows VM In my gf's machine to see the fix of > Nicolai to the Ctrl+friends. > > For those who do not know, before, the windows (and unix, and mac too) VMs > mapped some Ctrl+key combinations to another one simulating emacs/terminal > shortcuts. For example: > > Ctrl+a => Ctrl home > Ctrl+d => Ctrl end > > The problem of this, is that the image never received a Ctrl+a event, and > thus, Ctrl+a and Ctrl+home were not distinguishable. > > Nicolai did a fix in the Windows VM for this and I'm glad to see that most > of the keys that did not work before now work. I tested it by disabling the > global shortcuts and using the following script: > > w := SystemWindow new. > > ($a to: $z) do: [ :k| > w bindKeyCombination: k ctrl toAction: [ :a :b :c | UIManager default > inform: c asString ]]. > > w addMorphBack: TextMorph new. > w openInWorld. > > Using that I saw however that the Ctrl+m combination does not reach my > handler and there are no global handlers for it. The event does however > arrive to the image (checked using the InputEventFetcher). > > Then I have two questions for the world: > > - Does anyone have an idea of who may be catching the Ctrl+m? > - What do we have to do to bless the latest Windows VM as stable? > > Guille > Hi Guille, the problem with my fix for ctrl+a vs. ctrl+home is, that we do not get ctrl+space keystrokes anymore :( But I know how to fix this. The problem with ctrl+m is that it does not generate a keychar-Event, only keyup and keydown (similar ctrl+<somenumber> or ctrl+tab), it is recognized as a keyevent but only keychar-events are used as keystrokes.

Aug. 17, 2015

Ctrl key on Windows

by Guillermo Polito

First, Thanks Nicolai :) I was testing the latest windows VM In my gf's machine to see the fix of Nicolai to the Ctrl+friends. For those who do not know, before, the windows (and unix, and mac too) VMs mapped some Ctrl+key combinations to another one simulating emacs/terminal shortcuts. For example: Ctrl+a => Ctrl home Ctrl+d => Ctrl end The problem of this, is that the image never received a Ctrl+a event, and thus, Ctrl+a and Ctrl+home were not distinguishable. Nicolai did a fix in the Windows VM for this and I'm glad to see that most of the keys that did not work before now work. I tested it by disabling the global shortcuts and using the following script: w := SystemWindow new. ($a to: $z) do: [ :k| w bindKeyCombination: k ctrl toAction: [ :a :b :c | UIManager default inform: c asString ]]. w addMorphBack: TextMorph new. w openInWorld. Using that I saw however that the Ctrl+m combination does not reach my handler and there are no global handlers for it. The event does however arrive to the image (checked using the InputEventFetcher). Then I have two questions for the world: - Does anyone have an idea of who may be catching the Ctrl+m? - What do we have to do to bless the latest Windows VM as stable? Guille

Aug. 17, 2015

Re: [Pharo-dev] World Menu associated mouse click

by Dimitris Chloupis

If you are not ready to get out of your comfort zone , you wont be using Smalltalk. Sure change it to left click, but in the end it wont make much of a difference. Smalltalk is for a specific kind of people that are looking for a fresh approach to coding. For everyone else there is like a ton of languages that recycle old recipes and keep things familiar. On Mon, Aug 17, 2015 at 7:19 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Btw in Bloc this has already been changed. > > On Mon, Aug 17, 2015 at 4:14 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-08-17 16:07 GMT+02:00 Blondeau Vincent < >> vincent.blondeau(a)worldline.com>: >> >>> Hi, >>> >>> There is a setting to have this consistence (deactivated by default): >>> Appearance>Desktop>Invert right click on world menu in Linux and Windows >>> >>> By the way, the buttons are not inverted under Mac (conventional). >>> >>> I agree that the context click should open the world menu by default.. >>> >> >> +1 >> >> >>> >>> Cheers, >>> Vincent >>> >>> -----Message d'origine----- >>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >>> Ben Coman >>> EnvoyÃ© : lundi 17 aoÃ»t 2015 15:52 >>> Ã : Pharo Development List >>> Objet : [Pharo-dev] World Menu associated mouse click >>> >>> A while back on reddit someone complained about the World Menu being >>> associated with left-mouse-click. I have come to agree. The World Menu >>> provides the actions available in the context of the World, i.e. >>> the World's context-menu - but its not invoked by the usual convention >>> for context menus, which is the right-mouse-click. >>> >>> By way of example, in a fresh image and open one Playground. >>> >>> * First right-click the Playground. Up comes the Playground's >>> context-menu as expected per industry wide conventions. >>> >>> * Then right-click the background. Doh! Its not consistent, thats not >>> the World's context-menu. "WTH is that?" says a newbie in surprise. >>> (Btw, who uses that list of open windows ? I *never* do and might >>> suggest that function be moved to a meta-mouse-click.) >>> >>> So can we discuss changing the World Menu to be invoked by the >>> context-click (i.e. right-click) ? >>> >>> cheers -ben >>> >>> >>> >>> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã >>> l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par >>> le secret professionnel. Si vous recevez ce message par erreur, merci d'en >>> avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du >>> message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de >>> Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien >>> que les meilleurs efforts soient faits pour maintenir cette transmission >>> exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et >>> sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant >>> d'un virus transmis. >>> >>> This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive this >>> e-mail in error, please notify the sender immediately and destroy it. As >>> its integrity cannot be secured on the Internet, the Worldline liability >>> cannot be triggered for the message content. Although the sender endeavours >>> to maintain a computer virus-free network, the sender does not warrant that >>> this transmission is virus-free and will not be liable for any damages >>> resulting from any virus transmitted. >>> >> >> >

Aug. 17, 2015

Re: [Pharo-dev] Error in plugin AddSubscribers (View)

by Bernardo Ezequiel Contreras

me too. On Mon, Aug 17, 2015 at 6:48 AM, Ben Coman <btc(a)openinworld.com> wrote: > Anyone else getting this error when viewing a case in Fogbugz > > "Error in plugin AddSubscribers (View)" > > e.g. https://pharo.fogbugz.com/default.asp?16192 > > cheer s-ben > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Aug. 17, 2015

Re: [Pharo-dev] Error in plugin AddSubscribers (View)

by stepharo

me too :) Le 17/8/15 11:48, Ben Coman a Ã©crit : > Anyone else getting this error when viewing a case in Fogbugz > > "Error in plugin AddSubscribers (View)" > > e.g. https://pharo.fogbugz.com/default.asp?16192 > > cheer s-ben > >

Aug. 17, 2015

Re: [Pharo-dev] Two new critique rules: RBRuleIfNotEmptyDo and RBRuleIfNotNilDo

by stepharo

marcus having rules is the best way to go and potentially create a compatiblity package if necessary. I like rules because they help freeing my mind Stef Le 17/8/15 11:28, Marcus Denker a Ã©crit : > Hi, > > I added two rules: > > RBRuleIfNotNilDo > RBRuleIfNotEmptyDo > > They are finding the uses of > > ifNotEmptyDo: > ifNotEmptyDo: notEmptyBlock ifEmpty: emptyBlock > ifEmpty: emptyBlock ifNotEmptyDo: notEmptyBlock > ifNotNilDo: aBlock > ifNotNilDo: ifNotNilBlock ifNil: nilBlock > ifNil: nilBlock ifNotNilDo: ifNotNilBlock > > In all these cases you can just use the normal version without do: > > In the past there was even yet another one: doIfNotâ¦ we thankfully deprecated > and removed that in the past. > > We kept the Do: variants for compatibility, but the problem is that people nevertheless > use them. All users now were added after we already rewrote once all usersâ¦ > > With the code critique, I hope this will stop. > > (yes, not gravely importantâ¦ but things like that have an impact if you do lots of them) > > Marcus >

Aug. 17, 2015

Re: [Pharo-dev] World Menu associated mouse click

by Peter UhnÃ¡k

Btw in Bloc this has already been changed. On Mon, Aug 17, 2015 at 4:14 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-08-17 16:07 GMT+02:00 Blondeau Vincent < > vincent.blondeau(a)worldline.com>: > >> Hi, >> >> There is a setting to have this consistence (deactivated by default): >> Appearance>Desktop>Invert right click on world menu in Linux and Windows >> >> By the way, the buttons are not inverted under Mac (conventional). >> >> I agree that the context click should open the world menu by default.. >> > > +1 > > >> >> Cheers, >> Vincent >> >> -----Message d'origine----- >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Ben Coman >> EnvoyÃ© : lundi 17 aoÃ»t 2015 15:52 >> Ã : Pharo Development List >> Objet : [Pharo-dev] World Menu associated mouse click >> >> A while back on reddit someone complained about the World Menu being >> associated with left-mouse-click. I have come to agree. The World Menu >> provides the actions available in the context of the World, i.e. >> the World's context-menu - but its not invoked by the usual convention >> for context menus, which is the right-mouse-click. >> >> By way of example, in a fresh image and open one Playground. >> >> * First right-click the Playground. Up comes the Playground's >> context-menu as expected per industry wide conventions. >> >> * Then right-click the background. Doh! Its not consistent, thats not the >> World's context-menu. "WTH is that?" says a newbie in surprise. >> (Btw, who uses that list of open windows ? I *never* do and might suggest >> that function be moved to a meta-mouse-click.) >> >> So can we discuss changing the World Menu to be invoked by the >> context-click (i.e. right-click) ? >> >> cheers -ben >> >> >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its integrity cannot be secured on the Internet, the Worldline liability >> cannot be triggered for the message content. Although the sender endeavours >> to maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> > >

Aug. 17, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 17, 2015