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

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

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

by Lukas Renggli

> *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. +1, I don't know the colors either. > Colors for buttons make no sense *at all* if your buttons have no colors. AFAIK, most operating systems number the mouse buttons. - The primary button is what you use to perform actions (typically left mouse button). - The secondary buttons is what you use to open context menu (typically right mouse button). - The third button is the middle button, the fourth button, ... Now I see that numbers are not that far from colors, but at least they have a logical order. I don't like #select, #menu, #extra because I does not make sense in any other context (for example games, or touch applications) than a traditional GUI. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

Re: [Pharo-project] default styler is shout

by Lukas Renggli

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 3588 in pharo: Monticello breaks when trying to load code with syntax errors

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3588 by elpochod...(a)gmail.com: Monticello breaks when trying to load code with syntax errors http://code.google.com/p/pharo/issues/detail?id=3588 Pharo image: Pharo Pharo core version: Pharo1.2rc1/Latest update: #12317 Virtual machine used: 'Squeak3.10.2 of 11 February 2010 [latest update: #9314]' (windows) Steps to reproduce: 1. Monticello browser->+Package named OpenGL 2. +Repository http: www.squeaksource.com/OpenGL 3. Open it, load OpenGL-clk.5.mcz ignoring warning because of missing classes. You get a syntax error because of underscore assignments, but it would fail the same for any syntax error, like assigning to a variable that is a parameter instead of a temporary, or anything that compiled with a previous compiler and doesn't compile anymore. The code can be modified by hand and (should be) accepted with ctrl+s, but then a monticello error is raised. The main thing is to fix the stack trace. Then, an accept/ignore and continue/cancel all button would be even better.

Jan. 24, 2011

Re: [Pharo-project] collapsing panes

by Gary Chambers

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:) 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."

Jan. 24, 2011

Re: [Pharo-project] Tabs and back button in browser?

by Marcus Denker

On Jan 24, 2011, at 2:47 PM, Janko MivÅ¡ek wrote: > Hi Pharoers, > > Are you thinking about introducing tabs and back/forward button, like in > web browsers? > Yes! Have a look at OB2 https://gforge.inria.fr/frs/download.php/27023/PBE-1.0.zip There is a lot of good ideas in David's browser. We need to revisit that work at some point. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 24, 2011