- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] [squeak-dev] Xtreams up to date

by mkobetic＠gmail.com

"Hannes Hirzel"<hannes.hirzel(a)gmail.com> wrote: > I worked through it and understood it. I adapted the class names so > that it runs in the current Squeak 4.2 out of the box. In addition I > edited it slightly. I think it could be added as to the PEGParser > class. Maybe somebody else like to check it in addition .... Yes, wrote it with the intent to eventually turn it into documentation for the Parsing package. On VW side we keep these in package comments, that's the most obvious location for it IMO. I'm not convinced that using a class comment on Squeak/Pharo side is a good choice. I would have difficulty myself to pick the class for it, so the chances that a new user will find it are even lower. I'm intrigued by the help facilities that were mentioned on Pharo side quite a bit recently. Is that something people hope to turn into the primary resource for these things ? Sounds like it would be quite easy to package it as that. The package comment are already written using the google wiki syntax, so that they can be directly posted to the google project site. So the help facilities allowing wiki syntax sound particularly attractive. Is this something that could work on Squeak side too, or do we need to do something different there ? In the meantime I intend to at least keep the google project pages up to date. > Additional example: Wiki text parsing > > In the previous mail you mentioned that you'll add the fileout of the class > > PEGWikiGenerator Ah, I got caught up in the arithmetic example and forgot the attachments. They are attached now. Sorry about that. Thanks for the edited version of the example. I'll work on it some more and turn it into a doc page on the site. If we figure out how to package it in Squeak and Pharo so that people can find it easily, I'd be happy to add all the documentation we have on the site. Cheers, Martin

Jan. 24, 2011

Re: [Pharo-project] default styler is shout

by Lukas Renggli

I mean with the old ParagraphEditor. I am not saying that the old ParagraphEditor was better (it had lots of other problems), but the separation between Editor and SmalltalkEditor makes the OB code much more complicated. Also having to send #beStyled is kind of tricky. The previous pull mechanism with #shoutWantsToBeStyled: was much more useful as the model of the editor could decide itself how and if it wanted to be styled. Now the model (or some other new entity inbetween) needs to know the view and update the editor all the time. Lukas On 24 January 2011 08:23, Alain Plantec <alain.plantec(a)free.fr> wrote: > Hi Lukas, > When you say "previously" do you mean with > ParagraphEditor or with previous version of > Editor/TextEditor/SmalltalkEditor ? > Cheers > Alain > > > Le 24/01/2011 16:46, Lukas Renggli a Ã©crit : >> >> Just as an additional comment (don't know if this is related or not): >> >> For OB I had to subclass Editor and duplicate all SmalltalkEditor >> functionality, because the same Morph instance is used different >> contexts. Previously it was very easy to enable and disable syntax >> highlighting and other Smalltalk specific functionality. >> >> Lukas >> >> On 24 January 2011 00:10, Tudor Girba<tudor.girba(a)gmail.com> Â wrote: >>> >>> Hi, >>> >>> I opened a ticket. We should move the discussion there: >>> http://code.google.com/p/pharo/issues/detail?id=3583 >>> >>> Cheers, >>> Doru >>> >>> On 24 Jan 2011, at 08:31, Marcus Denker wrote: >>> >>>> 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. >>>> >>> -- >>> www.tudorgirba.com >>> >>> "In a world where everything is moving ever faster, >>> one might have better chances to win by moving slower." >>> >>> >>> >>> >>> >> >> > > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

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

by pharo＠googlecode.com

Status: Accepted Owner: cy.delau...(a)gmail.com CC: renggli Labels: Milestone-1.2 Type-OB New issue 3589 by cy.delau...(a)gmail.com: ClassComment in OB http://code.google.com/p/pharo/issues/detail?id=3589 in pharo 1.2 looking for a string in source can raise an error if the sring is defined on class comment. Here is the fix :) lukas let us know if this is ok. Stef and Cyrille. Attachments: OBFix.1.cs 831 bytes

Jan. 24, 2011

Re: [Pharo-project] default styler is shout

by Alain Plantec

Hi Lukas, When you say "previously" do you mean with ParagraphEditor or with previous version of Editor/TextEditor/SmalltalkEditor ? Cheers Alain Le 24/01/2011 16:46, Lukas Renggli a Ã©crit : > Just as an additional comment (don't know if this is related or not): > > For OB I had to subclass Editor and duplicate all SmalltalkEditor > functionality, because the same Morph instance is used different > contexts. Previously it was very easy to enable and disable syntax > highlighting and other Smalltalk specific functionality. > > Lukas > > On 24 January 2011 00:10, Tudor Girba<tudor.girba(a)gmail.com> wrote: >> Hi, >> >> I opened a ticket. We should move the discussion there: >> http://code.google.com/p/pharo/issues/detail?id=3583 >> >> Cheers, >> Doru >> >> On 24 Jan 2011, at 08:31, Marcus Denker wrote: >> >>> 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. >>> >> -- >> www.tudorgirba.com >> >> "In a world where everything is moving ever faster, >> one might have better chances to win by moving slower." >> >> >> >> >> > >

Jan. 24, 2011

Re: [Pharo-project] default styler is shout

by Benjamin

I've posted a change this morning when activating styling is just a message (beStyled) to send to a PluggableTextMorph Ben On Jan 24, 2011, at 4:46 PM, Lukas Renggli wrote: > Just as an additional comment (don't know if this is related or not): > > For OB I had to subclass Editor and duplicate all SmalltalkEditor > functionality, because the same Morph instance is used different > contexts. Previously it was very easy to enable and disable syntax > highlighting and other Smalltalk specific functionality. > > Lukas > > On 24 January 2011 00:10, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> I opened a ticket. We should move the discussion there: >> http://code.google.com/p/pharo/issues/detail?id=3583 >> >> Cheers, >> Doru >> >> On 24 Jan 2011, at 08:31, Marcus Denker wrote: >> >>> >>> 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. >>> >> >> -- >> www.tudorgirba.com >> >> "In a world where everything is moving ever faster, >> one might have better chances to win by moving slower." >> >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 24, 2011