January 2011 - Pharo-dev - lists.pharo.org

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

by Dale Henrichs

On 01/24/2011 01:07 PM, Tudor Girba wrote: > Hi Lukas, > > On 24 Jan 2011, at 15:57, Lukas Renggli wrote: > >>> My main current question is what are the reasons for OBInteractionRequest to subclass Notification? >> >> To be able to perform user interactions anywhere without having a >> global OBPlatform instance, and without having to pass OBPlatform in >> or store OBPlatform anywhere. There can be multiple UI platforms >> active at the same time and they can even change over the lifetime of >> a single browser window. > > I am not sure I understand. Why did it have to be a subclass of Notification? Would it not be enough to have it as a subclass of Object? > > Cheers, > Doru Doru, They are subclasses of Notification so that exception handlers can be used to intercept the notification and do something different than prompt the user for the request ... the defaultAction of the exception triggers the UI to prompt the user with an appropriate dialog box... Dale

Jan. 24, 2011

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

by StÃ©phane Ducasse

tx On Jan 23, 2011, at 11:07 PM, Ricardo Moran wrote: > 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> > > > > <BalloonCanvas-linetowidthcolor.st>

Jan. 24, 2011

Re: [Pharo-project] collapsing panes

by Tudor Girba

Hi Gary, On 24 Jan 2011, at 16:16, Gary Chambers wrote: > Hi, > I don't think the layouts can be merged, as such, as they have very different > approaches. > > With the TableLayout, it is possible to assign "weights" to each spaceFill > section to get what you want, I think. (see #spaceFillWeight:) I tried to use it, but I get no effect when I use it in your example. Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I doing wrong? | container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2| morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red)) hResizing: #spaceFill; vResizing: #spaceFill. morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue)) hResizing: #spaceFill; vResizing: #spaceFill; spaceFillWeight: 10. morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow)) hResizing: #spaceFill; vResizing: #spaceFill. ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true. ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true. ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded: true. sp1 := EdgeGripMorph new target: ex1; edgeName: #bottom; vResizing: #rigid; extent: 24 @ ProportionalSplitterMorph splitterWidth; on: #mouseDown send: #expandedSizingRigid to: ex1. sp2 := EdgeGripMorph new target: ex2; edgeName: #bottom; vResizing: #rigid; extent: 24 @ ProportionalSplitterMorph splitterWidth; on: #mouseDown send: #expandedSizingRigid to: ex2. container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}. container cellInset: 0. container extent: 400@400. container openInWindow. Cheers, Doru > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, January 24, 2011 2:32 PM > Subject: Re: [Pharo-project] collapsing panes > > > Thanks a lot, Gary! I gave it a try and it does go in the wanted direction. > > Now, the next question. I see that you are using a TableLayout. Is there a way to specify a proportion (like in the proportional layout?) for the initial extent of the inner panes? > > If yes, then I suppose we could merge the two layouts into one. > > Cheers, > Doru > > > On 24 Jan 2011, at 14:51, Benjamin wrote: > >> I love that :) >> It could be very useful ^^ >> >> >> Ben >> >> On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote: >> >>> Tricky... >>> Just an experiment, but try the following after filing in attached change set. >>> Can make the re-proportioning explicit and maybe fix things to constrain to >>> the owner morph if interested... >>> >>> >>> | container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2| >>> morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red)) >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue)) >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow)) >>> hResizing: #spaceFill; >>> vResizing: #spaceFill. >>> ex1 := (UITheme builder newExpander: 'Red' for: morph1) >>> expanded: true. >>> ex2 := (UITheme builder newExpander: 'Blue' for: morph2) >>> expanded: true. >>> ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) >>> expanded: true. >>> sp1 := EdgeGripMorph new >>> target: ex1; >>> edgeName: #bottom; >>> vResizing: #rigid; >>> extent: 24 @ ProportionalSplitterMorph splitterWidth; >>> on: #mouseDown send: #expandedSizingRigid to: ex1. >>> sp2 := EdgeGripMorph new >>> target: ex2; >>> edgeName: #bottom; >>> vResizing: #rigid; >>> extent: 24 @ ProportionalSplitterMorph splitterWidth; >>> on: #mouseDown send: #expandedSizingRigid to: ex2. >>> container := UITheme builder newColumn: { >>> ex1. >>> sp1. >>> ex2. >>> sp2. >>> ex3}. >>> container cellInset: 0. >>> container extent: 400@400. >>> container openInWindow. >>> >>> >>> >>> Have a play/fun. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Friday, January 21, 2011 11:18 PM >>> Subject: [Pharo-project] collapsing panes >>> >>> >>> Hi, >>> >>> I have a question about how to obtain an effect similar to minimizing a pane in Eclipse. Let's consider the example from below. I have a ProportionalLayout because I want to fill the entire space and be able to resize the inside panes. Now, I would also like to have some way of collapsing one of the panes and have the rest resize to fill the rest of the space. It's a bit like I would need some part of a behavior from the TableLayout. >>> >>> Can anyone provide me with some hints in this direction? Do I need to create a new Layout? >>> >>> | container morph1 morph2 morph3 window | >>> container := PanelMorph new. >>> morph1 := PanelMorph new fillStyle: (SolidFillStyle color: Color red). >>> morph2 := PanelMorph new fillStyle: (SolidFillStyle color: Color blue). >>> morph3 := PanelMorph new fillStyle: (SolidFillStyle color: Color yellow). >>> container changeProportionalLayout. >>> container addMorph: morph1 fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0.33)). >>> container addMorph: morph2 fullFrame: (LayoutFrame fractions: (0 @ 0.33 corner: 1 @ 0.66)). >>> container addMorph: morph3 fullFrame: (LayoutFrame fractions: (0 @ 0.66 corner: 1 @ 1)). >>> container addPaneSplitters. >>> container fillStyle: (SolidFillStyle color: Color yellow). >>> container extent: 400@400. >>> container openInWindow. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >>> <ExpanderTweak.1.cs> >> >> > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > > > -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

Jan. 24, 2011

Re: [Pharo-project] collapsing panes

by StÃ©phane Ducasse

Yes we want more and a class to encapsulate that logic. Stef On Jan 24, 2011, at 2:51 PM, Benjamin wrote: > I love that :) > It could be very useful ^^ > > > Ben > > On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote: > >> Tricky... >> Just an experiment, but try the following after filing in attached change set. >> Can make the re-proportioning explicit and maybe fix things to constrain to >> the owner morph if interested... >> >> >> | container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2| >> morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red)) >> hResizing: #spaceFill; >> vResizing: #spaceFill. >> morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue)) >> hResizing: #spaceFill; >> vResizing: #spaceFill. >> morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow)) >> hResizing: #spaceFill; >> vResizing: #spaceFill. >> ex1 := (UITheme builder newExpander: 'Red' for: morph1) >> expanded: true. >> ex2 := (UITheme builder newExpander: 'Blue' for: morph2) >> expanded: true. >> ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) >> expanded: true. >> sp1 := EdgeGripMorph new >> target: ex1; >> edgeName: #bottom; >> vResizing: #rigid; >> extent: 24 @ ProportionalSplitterMorph splitterWidth; >> on: #mouseDown send: #expandedSizingRigid to: ex1. >> sp2 := EdgeGripMorph new >> target: ex2; >> edgeName: #bottom; >> vResizing: #rigid; >> extent: 24 @ ProportionalSplitterMorph splitterWidth; >> on: #mouseDown send: #expandedSizingRigid to: ex2. >> container := UITheme builder newColumn: { >> ex1. >> sp1. >> ex2. >> sp2. >> ex3}. >> container cellInset: 0. >> container extent: 400@400. >> container openInWindow. >> >> >> >> Have a play/fun. >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >> To: "Pharo-project(a)lists.gforge.inria.fr Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Friday, January 21, 2011 11:18 PM >> Subject: [Pharo-project] collapsing panes >> >> >> Hi, >> >> I have a question about how to obtain an effect similar to minimizing a pane in Eclipse. Let's consider the example from below. I have a ProportionalLayout because I want to fill the entire space and be able to resize the inside panes. Now, I would also like to have some way of collapsing one of the panes and have the rest resize to fill the rest of the space. It's a bit like I would need some part of a behavior from the TableLayout. >> >> Can anyone provide me with some hints in this direction? Do I need to create a new Layout? >> >> | container morph1 morph2 morph3 window | >> container := PanelMorph new. >> morph1 := PanelMorph new fillStyle: (SolidFillStyle color: Color red). >> morph2 := PanelMorph new fillStyle: (SolidFillStyle color: Color blue). >> morph3 := PanelMorph new fillStyle: (SolidFillStyle color: Color yellow). >> container changeProportionalLayout. >> container addMorph: morph1 fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 0.33)). >> container addMorph: morph2 fullFrame: (LayoutFrame fractions: (0 @ 0.33 corner: 1 @ 0.66)). >> container addMorph: morph3 fullFrame: (LayoutFrame fractions: (0 @ 0.66 corner: 1 @ 1)). >> container addPaneSplitters. >> container fillStyle: (SolidFillStyle color: Color yellow). >> container extent: 400@400. >> container openInWindow. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> <ExpanderTweak.1.cs> > >

Jan. 24, 2011

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

by Tudor Girba

Hi Lukas, On 24 Jan 2011, at 15:57, Lukas Renggli wrote: >> My main current question is what are the reasons for OBInteractionRequest to subclass Notification? > > To be able to perform user interactions anywhere without having a > global OBPlatform instance, and without having to pass OBPlatform in > or store OBPlatform anywhere. There can be multiple UI platforms > active at the same time and they can even change over the lifetime of > a single browser window. I am not sure I understand. Why did it have to be a subclass of Notification? Would it not be enough to have it as a subclass of Object? Cheers, Doru > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

Jan. 24, 2011

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

by Nicolas Cellier

2011/1/24 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Mon, Jan 24, 2011 at 10:22 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Exactly : logicalRight can be different than physicalRight. >> If you tell me this distinction is useless, then I'll ask you to >> consider touch screen and other modern input devices. >> That's why I ask this community to reformulate and think. > > Mmm, maybe we can work in little steps.Â I think that renaming is a good > first step for a refactor.Â To refactor code you need to understand it, and > the colors makes me not to understand it. > IMO, the correct order is: 1) understand current implementation 2) refactor At least, after this lengthy thread, pretty all has been said about red/yellow/blue buttons and I wish I don't hear anymore anyone pretending he does not understand. The summary is: The logical squeak^H^H^H^H^H^Hpharo pointing input device is a mouse with 3 buttons named red yellow and blue by historical reference to Xerox Dorado machine (insert ref here). In smalltalk-80, - the red button (originally on the left) was generally used for selection; - the yellow button (originally on the middle) was generally used for contextual operation on the selection (via a pop up menu); - the blue button (originally on the right) was generally used for operation on the window (via another pop up menu). Due to hardware differences from one machine to another (presence of one, two or three buttons), and native OS feel differences (for example, the button used for contextual pop up menu is the right button rather than the middle in Microsoft windows), a level of indirection is kept to insulate this logical level from physical level. The mapping from physical buttons to logical buttons is programmable. On mouses with less than 3 buttons, other buttons can be emulated with combinations of modifier keys. Depending on user preferences, the mapping middle=yellow,right=blue can be swapped, the default being to adhere to native OS conventions (at least it should !). Where exactly this mapping happens (VM and/or image) and how to program it still has to be documented, but hey, you got the grounds ;) >> >> Then you'll can argue at will whether the logical level shall be named >> #right #logicalRight or #blue, I don't care. > > Then we can change it again. > It all depends if the changes are on a private kernel API or a public API exposed to third party packages. In later case we'd better not gratuitously raise the burden on early Pharo adopters. >> >> For newer kind of events (gestures), we have a more difficult dilemna: >> emulate the feel or use native OS facilities... >> The question is of same nature as native look. >> Even if we choose to rely on OS, we have to think of cross platform >> portability and ways to emulate missing capabilities. >> In other words, I doubt we can afford the elimination of a level of >> indirection. >> >> Maybe it's time to refactor indeed, but please, bring up your brain >> one level above this colour naming battle. >> Don't replay battles of the past, turn toward the future. > > Oh, that was no my intention.Â I didn't even know of past battles before > this thread.Â I was only tired of unmeaningful colors. > Please, don't turn the discussion like that, I didn't mean that :S. > > Guille > Marcus suggested this was previously a Squeak taboo :) I didn't mean to inhibit changes or discourage you, sorry if I did. All I want is that this kind of decision be rationalized rather than randomized. It's better to think of next steps in advance rather than step back from a dead end, isn't it? Nicolas >> >> Nicolas >> >> 2011/1/24 Geert Claes <geert.wl.claes(a)gmail.com>: >> > >> > >> > Guillermo Polito wrote: >> >> >> >> I hate yellowButtonPressed and redButtonPressed and blueButtonPressed >> >> messages. >> >> >> >> Why not lefClick, rightClick and "middleClick"? >> >> >> > >> > I agree that the meaning of the colors is no longer useful, although >> > "hate" >> > is maybe a bit harsh :) >> > >> > Surely this has already been addressed in other environments? >> > http://api.jquery.com/mousedown api.jquery.com/mousedown Â for example >> > also >> > refers to the left, middle and right button. >> > >> > Even Apple's multi-touch "magic-mouse" talks about left and right-clicks >> > (which is ironic as they have long resisted to even add a second button) >> > ... >> > but also mouse events for the "360Â° scroll", "Screen zoom" and >> > "two-finger >> > swipe". >> > -- >> > View this message in context: >> > http://forum.world.st/What-about-a-little-rename-in-MouseEvent-tp3233363p32… >> > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >> > >> > >

Jan. 24, 2011

Re: [Pharo-project] Pharo on the iPhone

by Alexandre Bergel

Unfortunately, my resources are scarce. iPhone are not really spread in Chile. I haven't seen a student having one. Is it possible to make DrGeo available on iTune? Cheers, Alexandre On 22 Jan 2011, at 05:21, Hilaire Fernandes wrote: > Check with Bert, Bert help me to make working DrGeo on the iPhone, he > integrates some changes in the Pharo image for that. I will check that > in a few week. One aspect we have to do, is to produce a Pharo theme > mathcing the iPhone/iPAD UI guideline. I have not yet started the effort > on that department, but we could collaborate on that topic. > > Hilaire > > Le 21/01/2011 02:10, Alexandre Bergel a Ã©crit : >> Hi! >> >> iPhone 4 is amazing. It will be even better with Pharo inside. Is there a way to install it? >> >> Cheers, >> Alexandre >> >> NB: my device is non jailbreaked. >> > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by Dale Henrichs

On 01/22/2011 12:37 AM, StÃ©phane Ducasse wrote: > I think that a stupid numbering like the one we have now is not so bad, you do not want to force > the tools to read all the metadata inside the files. > I think that we have many more places where we should improve: UI, network layer, Filesystem..... I tend to agree, but... > > So with a simple fix in the tools to follow a pattern we can get a good impact. > So what is the right pattern so that Gofer and Metacello are happy? Upon closer examination of the Metacello code, I see that for sorting and comparison operations, Metacello pretty much follows the Gofer sorting scheme (separate methods for wider range of comparison operators)... The departure from Gofer comes in how Metacello matches a package name to a working copy... So in the end if you make Gofer happy you make Metacello happy. Pharo/Gofer parses the package file name looking for the following pattern" packageName, '-', author, '.', branch, '.', counter and Squeak/GemStone parses the package file name with this pattern: packageName, '-', 'author', '.', counter In Squeak/GemStone, the author is allowed to contain '.' and in Pharo a '.' in the author name causes the characters following the '.' to be interpreted as a branch names and in the sorting scheme for Gofer branches have precedence over the counter....which is why Igor's seeing the "wrong sort order in Gofer". In the Squeak/GemStone pattern, branches were indicated by a '.' in the packageName: packageName, '.', branch, '-', author, '.', branch, '.', counter To see examples just look at the old Seaside package names...Nothing about this ever made it into the code, but when I asked Avi way back when .. that is what he told me and I've been using it for years In terms of trying to get Metacello to run on multiple platforms, Pharo naming scheme is a headache, because Squeak/Gemstone allows '.' in author names and Gofer parses them as branch names leading to subtle problems as we've seen Personally, I have never seen a package in the wild that uses the Pharo 'branch' naming scheme...I have just seen problems caused by the 'branch' naming scheme. The RepositoryInspector itself uses the meta information when it sorts so it doesn't use the package name at all and in Igor's case, CMakeVMMaker-EstebanLorenzano.15 is an ancestor of CMakeVMMaker-Igor.Stasenko.16 and shows CMakeVMMaker-Igor.Stasenko.16 as the latest version, which means that the tools are inconsistent... My opinion is that the 'branch' naming scheme just causes problems and isn't in common use so I wouldn't mind seeing it dropped. Without the Pharo-style branch naming scheme a simple-minded sort based on the counter usually matches the actual ancestry... With that said I have seen projects with package naming conventions that don't include author names and don't have counters, so the naming schemes for packages is just a mess...without digging in and using the actual ancestry meta information, we are guaranteed to have inconsistencies no matter what we do... Dale

Jan. 24, 2011

Re: [Pharo-project] for coral

by Marcus Denker

On Jan 22, 2011, at 9:19 AM, Marcus Denker wrote: > > On Jan 22, 2011, at 9:15 AM, StÃ©phane Ducasse wrote: > >> We should: >> >> - use this list >> - have a plan > > Item 1: Hudson Project for Coral. https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Coral/ It does not yet run the tests (it should, but somehow it does not... strange) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 24, 2011

Re: [Pharo-project] Issue 3589 in pharo: ClassComment in OB

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3589 by cy.delau...(a)gmail.com: ClassComment in OB http://code.google.com/p/pharo/issues/detail?id=3589 (No comment was entered for this change.)

Jan. 24, 2011