- Pharo-dev - lists.pharo.org

Re: [Pharo-project] What about a little rename in MouseEvent?

by Guillermo Polito

And if you swap mouse buttons, you are replacing left button by right button ;). I open a ticket. On Mon, Jan 24, 2011 at 7:51 AM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > I agree with the original proposal, because MouseEvents denote the > physical action performed by the user on the hardware, which evidently > has a left, a middle and a right section. Regardless of the action > Morphic associates with each click, #select, #menu, etc... > > Fernando > > On Mon, Jan 24, 2011 at 10:33 AM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > > > On 24 Jan 2011, at 08:25, Marcus Denker wrote: > > > >> On Jan 24, 2011, at 5:39 AM, Guillermo Polito wrote: > >> > >>> I hate yellowButtonPressed and redButtonPressed and blueButtonPressed > messages. > >>> > >>> Why not lefClick, rightClick and "middleClick"? > >>> > >> > >> Yes. > >> > >> Back in the days, the color buttons where "holy cows". You just could > not even suggest to > >> change it. > >> > >> For me, after 13 years of Squeak and later Pharo, I still have no clue > which color means what... > >> they have no meaning. There is no green button on my mouse. > >> > >> Marcus > > > > #select, #menu and #extra ? > > > > Then again, touch UI is different again. > > > > Sven > > > > > > > > > >

Jan. 24, 2011

Re: [Pharo-project] Issue 3545 in pharo: FEATURE: Multiple Worlds

by pharo＠googlecode.com

Comment #7 on issue 3545 by sean.p.d...(a)gmail.com: FEATURE: Multiple Worlds http://code.google.com/p/pharo/issues/detail?id=3545 the changeset also includes a class comment for WorldManager that wasn't in the original SLICE

Jan. 24, 2011

Re: [Pharo-project] Issue 3545 in pharo: FEATURE: Multiple Worlds

by pharo＠googlecode.com

Comment #6 on issue 3545 by sean.p.d...(a)gmail.com: FEATURE: Multiple Worlds http://code.google.com/p/pharo/issues/detail?id=3545 I collected the changes into a changeset so people can play with it in 1.1.1. Maybe it'd be easier to integrate also. Attachments: MultipleWorlds.2.cs 3.5 KB

Jan. 24, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by Fernando Olivero

I agree with the original proposal, because MouseEvents denote the physical action performed by the user on the hardware, which evidently has a left, a middle and a right section. Regardless of the action Morphic associates with each click, #select, #menu, etc... Fernando On Mon, Jan 24, 2011 at 10:33 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 24 Jan 2011, at 08:25, Marcus Denker wrote: > >> On Jan 24, 2011, at 5:39 AM, Guillermo Polito wrote: >> >>> I hate yellowButtonPressed and redButtonPressed and blueButtonPressed messages. >>> >>> Why not lefClick, rightClick and "middleClick"? >>> >> >> Yes. >> >> Back in the days, the color buttons where "holy cows". You just could not even suggest to >> change it. >> >> For me, after 13 years of Squeak and later Pharo, I still have no clue which color means what... >> they have no meaning. There is no green button on my mouse. >> >> Â Â Â Marcus > > #select, #menu and #extra ? > > Then again, touch UI is different again. > > Sven > > > >

Jan. 24, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by Nicolas Cellier

Don't take me wrong. I perfectly agree that colors have no meaning. They had once upon a time on the dorado, but we don't care. What I say is that there is a level of indirection between physical button and semantic buttons: (left, middle, right) -> logical buttons (whatever you call them) -> semantic buttons (operate, menu, extra) So either you keep the logical indirection, or you remove it. If you keep it, the naming is not that obvious and has to be abstract. So the colours are not a bad choice from this POV. Call it alpha, beta gamma if you will, but then you are changing things just for the sake of changing. If you remove the indirection, then you have to wonder if you don't loose something, and that was the meaning behind my post. I don't have the answer to this one, but you have to think of it. It's a bit boring to explain one's joke, sorry for that ;). Nicolas 2011/1/24 Marcus Denker <marcus.denker(a)inria.fr>: > > On Jan 24, 2011, at 9:36 AM, Nicolas Cellier wrote: > >> Sure, we got the right to change historical code. >> >> But beware, naming actions with physical button positioncould be misleading... >> ... it does not take into account the logical indirection. >> >> We could as well use intention revealing names like selectButton >> operateButton haloButton... >> .. Err, no more halo in Pharo, these names are prematurely frozen and >> don't take future evolutions into account. >> >> Oh, we need some more neutral naming scheme, but for sure, something >> less colorfull that these childish st-80 and e toys. >> I suggest you use whiteButton greyButton blackButton, or maybe >> paleBlueButton, lightCyanButton to be more inline with an aqua theme > > *no* Colors have no *meaning* in this context. I can not even tell you the > three colors we have now. And not at all which is supposed to be the middle one. > > Colors for buttons make no sense *at all* if your buttons have no colors. > > Â Â Â Â Marcus > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Jan. 24, 2011

[Pharo-project] Issue 3585 in pharo: UIManager>>grafPort

by pharo＠googlecode.com

Status: Started Owner: siguc...(a)gmail.com New issue 3585 by siguc...(a)gmail.com: UIManager>>grafPort http://code.google.com/p/pharo/issues/detail?id=3585 This is strange use pattern: bitBlt := UIManager default grafPort used by Character/display scanners of paragraphs. Conceptually, paragraph should ask a canvas (where it will be drawn on) for providing a graph port, not UIManager, which is too high level for such kind of queries. I suggest to deprecate usage of #grafPort and remove grafPort from UIManager protocol.

Jan. 24, 2011

[Pharo-project] Issue 3584 in pharo: ToDo: remove DisplayText class

by pharo＠googlecode.com

Status: Started Owner: siguc...(a)gmail.com New issue 3584 by siguc...(a)gmail.com: ToDo: remove DisplayText class http://code.google.com/p/pharo/issues/detail?id=3584 DisplayText used for converting strings and text into forms, which then can be used to blit on other forms. It used sparsely, mostly in order to display simple text in number of old examples. In system there are already plenty of ways to display text, without using an intermediate string->form conversion, which is DisplayText. Ultimately, we should always use canvas(es) to display text, not forms or low-level DisplayObject(s). See MorphicUIManager>>#composeFormFor: in subclasses

Jan. 24, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #5 on issue 3583 by Benjamin...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 With this change set, by default a PluggableTextMorph doesn't style, but with beStyled, you make it style again. It only works with the latest version of shout where PluggableShoutMorph is deprecated. Then we will have to fix tools which needs styling Attachments: FixPluggableTextMorph.1.cs 4.5 KB

Jan. 24, 2011

Re: [Pharo-project] Hapao for Test coverage!

by Marcus Denker

On Thu, Jan 20, 2011 at 6:41 PM, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: > Hello all, > > We are happy to introduce you Hapao, an innovative test coverage tool which > gives you an intuitive graphical representation to visually assess the > quality of the coverage. > > For more information and download you can visit us at: > http://hapao.dcc.uchile.cl/ > Of course, all feedback is always welcome :) > Very nice! One small thing: the dialog selecting the packages at the beginning should label the button "continue"", not "terminate" (which sounds like cancel to me). I added a blog post: http://pharo-project.org/news -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

Jan. 24, 2011

Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes

by pharo＠googlecode.com

Comment #4 on issue 3583 by tudor.gi...(a)gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 You can set it simply by #styler:. But, the question is where should this decision be taken.

Jan. 24, 2011