- Pharo-dev - lists.pharo.org

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

by pharo＠googlecode.com

Status: Accepted Owner: tudor.gi...(a)gmail.com Labels: Type-Patch Milestone-1.2 Importance-High New 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 In the latest Morphic version, the default styler of the PluggableTextMorph is given by: useDefaultStyler "This should be changed to a proper registry but as long as there is only shout this will do" Smalltalk globals at: #SHTextStylerST80 ifPresent: [ :stylerClass | self styler: (stylerClass new view: self) ] ifAbsent: [ self styler: ( NullTextStyler new view: self) ] Thus, if Shout is loaded, you will get it in all text morphs by default. Given that TextMorph should be general and be used in all sorts of contexts, the default behavior should be the original: useDefaultStyler "This should be changed to a proper registry but as long as there is only shout this will do" self styler: (NullTextStyler new view: self; yourself).

Jan. 24, 2011

Re: [Pharo-project] doc on ob requests and commands

by Tudor Girba

Thanks, Lukas. I did read the comments. I understand why Commands and Requests are first class entities, and what they do individually. In Glamour, we have Actions which are similar to OB Commands. However, now we do not have explicit Requests, and I wanted to learn from OB. My main current question is what are the reasons for OBInteractionRequest to subclass Notification? Cheers, Doru On 23 Jan 2011, at 23:34, Lukas Renggli wrote: >> I am browsing OB to understand the design of the Requests and the commands. In particular, I am interested to understand why OBRequests are Notifications and how they link with the commands. >> >> Is there anywhere I can read about it? > > Please check the class comments of OBInteractionRequest and subclasses. > > "OBInteractionRequest is an abstract superclass for notifications that > request some interaction with the user. It's useful for catching such > notifications in an exception handler, while allowing other > notifications to operate normally." > > So all these requests are interacting in some way with the user, e.g. > they open a new browser, they close a browser, they refresh a browser, > they show a specific dialog, they change the mouse cursor, etc. And > depending on the current view these requests are handled differently. > In OB-Morphic the respective morphic actions are performed, in OB-Web > the request is serialized to JSON and performed on the client side, > ... and in the tests the events are silently captured and verified > using assertions. > > OBCommand is something entirely different. It represents the > first-class actions (menu items, buttons) in a browser. The only way > an OBCommand can interact with the user and for example request > additional information is through OBInteractionRequests that might be > triggered at any point. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Being happy is a matter of choice."

Jan. 24, 2011

Re: [Pharo-project] default styler is shout

by Marcus Denker

On Jan 24, 2011, at 2:19 AM, Guillermo Polito wrote: > But that imperfect solution won't be a good solution either, since we are not going to have shout styler anywhere :). > So how is that solved in1.1? We need, for 1.2, just a *usable* compromise. Then we can iterate in 1.3 Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 24, 2011

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

by Marcus Denker

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 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 24, 2011

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

by Guillermo Polito

I hate yellowButtonPressed and redButtonPressed and blueButtonPressed messages. Why not lefClick, rightClick and "middleClick"? Cheers, Guille

Jan. 24, 2011

Re: [Pharo-project] Deprecations and Hudson

by Guillermo Polito

Sweet :) Thanks! On Sun, Jan 23, 2011 at 3:46 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, Jan 23, 2011 at 7:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 23 January 2011 13:51, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >> > On 23.01.2011 12:05, Marcus Denker wrote: >> > >> > On Jan 23, 2011, at 11:27 AM, Marcus Denker wrote: >> > >> > ((Smalltalk at: #ConfigurationOfPharo) project lastVersion) perform: >> > #silently: with: true; perform: #load.Deprecation raiseWarning: true. >> > >> > >> > This way, the build image can be always build and then at runtime, the >> user >> > will see the popups. >> > >> > Marcus, please, let me know if you change this becasue I need it to fix >> a >> > problem with Metacello. >> > >> >> I am making the non-interactive classes for handling this. >> Image could detect if it runs non-interactive, and so, it will pass >> deprecation warnings, instead of raising dialog message. >> >> >> > great. Even better :) > Now, my only advice is: the final image that the use download should have > the flag in true, and the build should not cancel because of deprecations. > > Cheers > > mariano > > >> > done. >> > >> > Ok, so it breaks the build when running tests. I removed turning on >> > Deprecation warnings >> > (last line) >> > lets see. >> > >> > >> > -- >> > Marcus Denker -- http://www.marcusdenker.de >> > INRIA Lille -- Nord Europe. Team RMoD. >> > >> > I'd suggest using Deprecation>>#deprecationsWhile: >> > That way you can report them in Hudson, so they are easier to fix. >> > >> > Cheers, >> > Henry >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >

Jan. 24, 2011

Re: [Pharo-project] default styler is shout

by Guillermo Polito

But that imperfect solution won't be a good solution either, since we are not going to have shout styler anywhere :). On Sun, Jan 23, 2011 at 4:47 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hi, > > We need the imperfect, intermediate solution that is good enough for people > to live with > in 1.2. > > On Jan 22, 2011, at 4:25 PM, Tudor Girba wrote: > > > Hi, > > > > In the latest Morphic version, the default styler of the > PluggableTextMorph is given by: > > useDefaultStyler > > "This should be changed to a proper registry but as long as there > is only shout this will do" > > > > Smalltalk globals > > at: #SHTextStylerST80 > > ifPresent: [ :stylerClass | self styler: (stylerClass new > view: self) ] > > ifAbsent: [ self styler: ( NullTextStyler new view: self) > ] > > > > Thus, if Shout is loaded, you will get it in all text morphs by default. > Given that TextMorph should be general and be used in all sorts of contexts, > the default behavior should be the original: > > > > useDefaultStyler > > "This should be changed to a proper registry but as long as there > is only shout this will do" > > > > self styler: (NullTextStyler new view: self; yourself). > > > > > > What do you say? > > > > Cheers, > > Doru > > > > -- > > www.tudorgirba.com > > > > "We are all great at making mistakes." > > > > > > > > > > > > > > > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Jan. 24, 2011

Re: [Pharo-project] doc on ob requests and commands

by Lukas Renggli

> I am browsing OB to understand the design of the Requests and the commands. In particular, I am interested to understand why OBRequests are Notifications and how they link with the commands. > > Is there anywhere I can read about it? Please check the class comments of OBInteractionRequest and subclasses. "OBInteractionRequest is an abstract superclass for notifications that request some interaction with the user. It's useful for catching such notifications in an exception handler, while allowing other notifications to operate normally." So all these requests are interacting in some way with the user, e.g. they open a new browser, they close a browser, they refresh a browser, they show a specific dialog, they change the mouse cursor, etc. And depending on the current view these requests are handled differently. In OB-Morphic the respective morphic actions are performed, in OB-Web the request is serialized to JSON and performed on the client side, ... and in the tests the events are silently captured and verified using assertions. OBCommand is something entirely different. It represents the first-class actions (menu items, buttons) in a browser. The only way an OBCommand can interact with the user and for example request additional information is through OBInteractionRequests that might be triggered at any point. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 23, 2011

[Pharo-project] doc on ob requests and commands

by Tudor Girba

Hi, I am browsing OB to understand the design of the Requests and the commands. In particular, I am interested to understand why OBRequests are Notifications and how they link with the commands. Is there anywhere I can read about it? Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish."

Jan. 23, 2011

Re: [Pharo-project] Graphics with Anti-Aliasing

by Ricardo Moran

Yes, just load the attached file. Cheers Richo On Sun, Jan 23, 2011 at 6:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > ricardo could you send the code (squeak version) around so that we can try? > > Stef > > On Jan 23, 2011, at 9:13 PM, Ricardo Moran wrote: > > > Mmmm... maybe it is platform related. I really don't know. I'm on Windows > XP. > > > > Pharo version: Pharo1.2rc1 of 18 January 2011 update 12311 > > Squeak version: Squeak4.2alpha of 4 January 2011 update 10854 > > Vm version: Squeak3.10.2 of ''5 June 2008'' [latest update: #7179] > > > > On Sun, Jan 23, 2011 at 5:00 PM, Udo Schneider < > udo.schneider(a)homeaddress.de> wrote: > > Hi Richo, > > > > could you tell me which Image/VM/OS you where using? > > > > On my System (Mac OS X 10.6.6) Pharo 1.1 and Squeak 4.1 on Cog VM (r2349) > and regular VM (4.2.5beta1U) both show no antialiasing (image attached) > > > > Is this maybe somehow platform/plugin related? > > > > Best Regards, > > > > Udo > > > > > > > > On 23.01.11 20:28, Ricardo Moran wrote: > > Hi Udo, > > > > Out of curiosity, I executed your code in Squeak and the antialiasing > > works there. Debugging a little, I found a difference in > > BalloonCanvas>>#line:to:width:color:. If you update Pharo's > > implementation with Squeak's one it works in Pharo as well. > > There might be other differences so you might look into that. > > > > I hope this helps. > > Richo > > > > On Sun, Jan 23, 2011 at 4:09 PM, Udo Schneider > > <udo.schneider(a)homeaddress.de > > <mailto:udo.schneider@homeaddress.de>> wrote: > > > > All, > > > > I'm using the following code. IMHO the line is jagged ... but maybe > > I'm doing something wrong: > > > > form := Form extent: 640@480 depth: 32. > > "form fillWhite." > > canvas := BalloonCanvas on: form. > > canvas aaLevel: 4. > > canvas line: 0@0 to: 640@480 color: Color red. > > morph := ImageMorph new. > > morph image: form. > > morph openCenteredInWorld. > > "morph abandon." > > > > CU. > > > > Udo > > > > > > > > On 22.01.11 15:37, Udo Schneider wrote: > > > > All, > > > > does somebody has a pointer to a graphics lib/framework/engine > > for Pharo > > which works with Anti-Aliasing. > > > > My first tests with Balloon2D were disappointing (maybe I'm doing > > something wrong). But even setting aaLevel does not seem to > > bring any > > result. I.e. the line drawing code falls back to superclass code > > which > > simply draws the same jagged lines like always. > > > > Any pointers? > > > > CU, > > > > Udo > > > > > > > > > > > > > > > > > > > > <aatest.PNG> > > >

Jan. 23, 2011