- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update] #10241

by StÃ©phane Ducasse

The idea is that we want to reparse everything with gwenael and kick out some strange characters. Stef On Feb 22, 2009, at 8:22 PM, Gary Chambers wrote: > > Evil legacy source code... > I remember such "dodgy" characters (look like withespace)... > > Regards, Gary > ----- Original Message ----- > From: Rob Rothwell > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Sunday, February 22, 2009 3:01 PM > Subject: Re: [Pharo-project] [update] #10241 > > Wow. I bow to the depths of the Squeak neural connections that must > be going on in your brain... > > I can only seem to find stuff like that in procedural languages when > I don't know the system at all. > > Anyway, you are right! All I did was recompile > PluggableTextMorph>>drawOn: and Smallalk condenseChanges ran to > completion. > > I'm not quite sure how to test the Trait problems mentioned at the > beginning of the thread to see if they are fixed by this, though... > > Rob > > On Sun, Feb 22, 2009 at 9:25 AM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > Found it... > > PositionableStream>>#backChunk chokes on parsing the preamble of > PluggableTextMorph>>#drawOn:. String>>#asCharacter is the method that > comes just before #drawOn: in the changes file: > > ---------- > !String methodsFor: 'converting' stamp: 'marcus.denker 2/20/2009 > 20:16' prior: 31206904! > asCharacter > "Answer the receiver's first character, or a strange round > non-ascii > character if none. Idiosyncratic, provisional." > > ^ self size > 0 ifTrue: [self first] ifFalse:[$Â·]! ! > !PluggableTextMorph methodsFor: 'drawing' stamp: 'marcus.denker > 2/20/2009 16:30' prior: 27409324! > drawOn: aCanvas > ---------- > > When parsing #asCharacter, the UTF8 encoder fails with an > errorMalformedInput because it seems to read back to the strange dot > character. > > The question is whether this character should not be used, or whether > parsing is bogus. Looking at #backChunk and related methods, latter > seems possible. Looks a bit fishy with sends to #oldBack, > #oldPeekBack, but also to #back. Damien, can you verify your changes > in these methods? > > As a workaround recompiling PluggableTextMorph>>#drawOn: solves the > problem (because then the source position of this method is moved away > from the asCharacter method). > > > Adrian > ___________________ > http://www.adrian-lienhard.ch/ > > On Feb 22, 2009, at 14:18 , Adrian Lienhard wrote: > > > I'm debugging it right now. > > > > What you see are only secondary symptoms because the debugger cannot > > read the sources anymore because the source pointers have already > > been modified but the sources file is still the old one... > > > > To avoid this and still see the problem, modify #moveChangesTo: to > > not move the source (moveSource: false). > > > > The actual problem seems to be related to UTF8 conversion or stream > > positioning (UTF8TextConverter>>errorMalformedInput). Backlog > > attached. > > > > Adrian > > > > <SqueakDebug.log> > > > > On Feb 22, 2009, at 14:00 , StÃ©phane Ducasse wrote: > > > >> I added a trace in condenseChanges > >> > >> > >> PluggableTabBarMorph > >> PluggableTabButtonMorph > >> PluggableTextAttribute > >> PluggableTextEditorMorph > >> PluggableTextFieldMorph > >> PluggableTextMorph > >> (and is Undeclared) (See is Undeclared) (Unless is Undeclared) > >> (works is Undeclared) (Portions is Undeclared) (Copyright is > >> Undeclared) > >> > >> > >> > >> Stef > >> > >> On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: > >> > >>> I tried > >>> - to recompile the method licenseString on Smalltalk > >>> - remove it completely from the system > >>> > >>> I still get the same problem > >>> > >>> Stef > >>> > >>> On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: > >>> > >>>> Adrian in 10241 when i did Smalltalk condenseChanges > >>>> > >>>> I got a ClassDescription > >>>> > >>>> syntax error on the license > >>>> > >>>> > >>>> " > >>>> use and modification subject to a liberal open source license. > See > >>>> the main Squeak website for details. Unless stated to the > >>>> contrary, > >>>> works submitted for incorporation into or for distribution with > >>>> Squeak > >>>> shall be presumed subject to the same license. > >>>> > >>>> Portions of Squeak are: > >>>> > >>>> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. > >>>> Copyright (c) 1997-2001 Walt Disney Company, and/or > >>>> Copyrighted works of many other contributors. > >>>> All rights reserved. > >>>> ' > >>>> > >>>> " > >>>> > >>>> I think that fixing the condensing is the next key items since > >>>> now we > >>>> cannot work with Moose anymore. The changeset is getting too > >>>> close to > >>>> the limit. > >>>> > >>>> Stef > >>>> > >>>> > >>>> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: > >>>> > >>>>> #10241 > >>>>> > >>>>> Issue 167: > >>>>> - Traits implementation refactoring (no sharing of compiled > >>>>> methods > >>>>> and source) > >>>>> - New tests for Traits MOP > >>>>> > >>>>> > >>>>> Since this changes the handling of sources, the following issues > >>>>> with > >>>>> condensing changes may be resolved: > >>>>> http://code.google.com/p/pharo/issues/detail?id=466 > >>>>> http://code.google.com/p/pharo/issues/detail?id=470 > >>>>> > >>>>> Can somebody check these issues? > >>>>> > >>>>> Adrian > >>>>> ___________________ > >>>>> http://www.adrian-lienhard.ch/ > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > >>>>> project > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > >>> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project________… > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2009

Re: [Pharo-project] SmaCC can't find silence in Sound Library ?!

by Oscar Nierstrasz

I dug a little deeper. The message pops up in SampledSound class>>soundNamed:, which (annoyingly) does a self inform: if the named sound is not found. Further up the stack, TabbedPalette (BookMorph)>>goToPageMorph:transitionSpec:runTransitionScripts: sends self playPageFlipSound: tSpec first where tSpec is #('silence' #none #none), which is the default value defined in TabbedPallete>>transitionSpecFor: Sounds are looked up in the class variable dictionary SoundLibrary which appears to be empty. ScriptLoader>>cleanUpForRelease sets the SoundLibrary to nil. Shouldn't all the sounds listed in SampledSound class>>universalSoundKeys be permanently in the image? Where are they all? - on On Feb 23, 2009, at 14:00, Oscar Nierstrasz wrote: > > Hi, > > I just loaded SmaCC and SmaCCDev into a Pharo image > (pharo0.1-10231dev09.02.1) and tried to start it up. > > When I click on the tabs I get the annoying pop-up message: "silence > not found in the Sound library". > > Has anyone else experienced this? I did not find anything in the list > of issues. > > Shall I add it? Anyone know how to fix it? > > - on > > --- > Prof. Dr. O. Nierstrasz -- Oscar.Nierstrasz(a)iam.unibe.ch > Software Composition Group -- http://www.iam.unibe.ch/~scg > University of Bern -- Tel/Fax +41 31 631.4618/3355 > vcard: http://www.iam.unibe.ch/~oscar/oscarNierstrasz.vcf > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2009

Re: [Pharo-project] Automatic focus on column upon moose enter

by David RÃ¶thlisberger

> Nevetheless, a simple preference for the new OB behaviour will settle the > argument for all in the meantime. Let's move on. OB is getting there in > terms of look and feel now. Right. I added this preference now in the latest version of OB. It's called 'autoFocusForColumn', by default it's activated. David > David, > > Keyboard up/down are events that can be translated into commands, and then > "fired" up the hierarchy. It's been done this way for a long time. Very > few custom components are in actually needed. Think of it as another > incarnation (indeed literally in this case) of the old argument about > composition vs. inheritance. Inheritance is wonderful, but in this case, it > can/should be avoided. Plugging code into the correct places in a framework > will avoid the need for the customized list. That is not to say that the OB > lists are not needed - I do not know enough about them. However, a solid > event/command framework would be hard pressed not to do the same thing, only > better. > > Commands serve a role somewhat like exceptions. The problem/need is noticed > in one area, the message is put in the correct channel and reviewed until > somebody knows what to do with it. The overhead is (Gary - disagree if you > feel the need) not so severe as with exceptions because it is a much more > focused task. > > As an example, control-t for tests: you might also want to fire the same > command from menus. Doing what I advocate makes that trivial. Dolphin does > a great job of this kind of thing, right down to enabling/disabling commands > vs. individual widgets. > > This assumes that OB itself (as a top level component) take a role in making > all of this work. But that's a good thing once you adapt to it. > > In response to an earlier comment you made: there is always another way. > Commands are the preferred one here - trust me. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David > RÃ¶thlisberger > Sent: Friday, February 20, 2009 11:25 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Automatic focus on column upon moose enter > > Hi Bill, > >> Commands are a decoupling that allow the GUI to control how things get >> processed while allowing individual tools to control what happens when >> commands are processed. It's not direct, but it correct. > > I agree with you here. > But see, this change is not really about commands. Alex gave you an example > where > this change is useful in the context of commands. But this was not the > motivating > example for me to do this change, I was not even aware that it could also be > useful > in Alex' scenario involving commands. > The scenario I had in mind does not really employ commands at all, but basic > keyboard > actions like key up, key down (see my first mail in this thread). Maybe you > can look > at those as commands too, but the action they perform is certainly dependent > on the > view in which they are meant to happen. > > So there is more behind this than just "easing" the execution of commands. > > David > > >> ---- >> Wilhelm K. Schwab, Ph.D. >> bschwab AT anest DOT ufl DOT edu >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David >> RÃ¶thlisberger [squeak(a)webcitas.ch] >> Sent: Friday, February 20, 2009 10:33 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Automatic focus on column upon moose enter >> >> Hi Bill, >> >>> but your approach to it is not a small change: you are moving GUI code >>> into the tools, which is bad practice. >> I do not really understand what you mean with "tools" here. >> I moved this code to the Morphic subclass we use to represent pluggable >> lists in OB >> (a subclass of PluggableListMorph), so this is the GUI code used in the >> tool and IMO >> the only place where I could possibly move this GUI code into, namely into >> other GUI >> code. ;) >> >>> Please let Gary help you do this properly. >> Gary actually suggested me to do it like this. As I said, it's really the >> only way to >> realize this change so that it only affects the columns in OB, trust me. >> >> To make the extent of the change clear: What it does is to give the >> columns in >> OB-based browsers the focus whenever the mouse is over them. This only >> affects >> columns, nothing else, in the OB browser, and certainly also no other >> browsers, >> tools, whatsoever not based on OB. >> >> The question that remains is just whether people want a pref to >> enable/disable this >> changed behavior or not, I think. >> I don't have the impression that we need to discuss the implementation of >> this change. >> >> I will answer separately to your other mail. >> >> >> David >> >>> ---- >>> Wilhelm K. Schwab, Ph.D. >>> bschwab AT anest DOT ufl DOT edu >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David >>> RÃ¶thlisberger [squeak(a)webcitas.ch] >>> Sent: Friday, February 20, 2009 9:17 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Automatic focus on column upon moose enter >>> >>> Hi >>> >>>> First of all, I did not authored this change. David did it. I guess >>>> this was a request emanated by a bunch of people. >>> Yes. >>> >>>> Personally, the only reason why I am happy with the auto-focus, is by >>>> pressing Cmd-T to run tests. I find this quite convenient to simply >>>> accept a method, then move the moose to the column and press Cmd-T, >>>> without clicking. >>> yes. >>> Another scenario from Stef: >>> Having a method selected in the method list, going with the mouse button >>> to the first >>> column while having selected the hierarchy button and press key up or >>> down to >>> conveniently browse the same method in super- or subclasses. >>> >>>> Although I do not see a scenario where auto-focus is >>>> a real problem, I do understand that David made an arbitrary decision >>>> without much consultation. Sorry about that. So, what do we do? >>> Well, I did some "consultation" with Gary and Stef. >>> But they left the decision to me, so I "decided" to be it like that for >>> the moment to >>> see how people react. >>> I don't mind to, as Gary suggested, introduce yet another preference >>> (there are >>> already two related to this "auto-focus") saying whether one wants to >>> ignore the >>> mouseClickForKeyboardFocus preference in the browser's columns, although >>> I personally >>> think that such a preference is not needed as I can't imagine that this >>> auto-focus >>> for columns gets into the way too often (if at all). >>> But if people want me to add such a pref, fine by me. >>> >>> I don't think we want to start a much ado about nothing discussion about >>> this small >>> change. ;) >>> >>> David >>> >>>> On 20 Feb 2009, at 14:38, Schwab,Wilhelm K wrote: >>>> >>>>> Alexandre, >>>>> >>>>> Can you give us an explanation or pointer to one? This sounds like >>>>> something that Gary worked hard to stop from happening. I want you >>>>> to have what you want from your image, and I need my future users to >>>>> have what they will demand (loudly<g>). I am also convinced that >>>>> there are things (e.g. mouse wheel input) that should "follow the >>>>> mouse" without affecting keyboard focus, and this might be one of >>>>> them, but referring to focus gives me the idea that keyboard input >>>>> will go to the columns based on mouse position, and that >>>>> (PLEASE!!!!!) needs to be optional - it drives me batty. I type >>>>> quite fast, and if the input goes to what amount to commands instead >>>>> of editing, it can get ugly. >>>>> >>>>> There are some preferences that control behavior like this, and any >>>>> such overrides should be conditional on one being set, or moved into >>>>> the themes, probably as an aspect vs. implied by the theme choice. >>>>> By the latter, I am assuming that you want Motif style mouse/focus >>>>> behavior in any old theme you happen to choose. That's fine, but it >>>>> should be optional or we are taking a step backward in feel. >>>>> >>>>> Bill >>>>> >>>>> >>>>> ---- >>>>> Wilhelm K. Schwab, Ph.D. >>>>> bschwab AT anest DOT ufl DOT edu >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr >>>>> ] On Behalf Of Alexandre Bergel [Alexandre.Bergel(a)inria.fr] >>>>> Sent: Friday, February 20, 2009 5:04 AM >>>>> To: Pharo Development >>>>> Subject: [Pharo-project] Automatic focus on column upon moose enter >>>>> >>>>> David, >>>>> You're a hero! >>>>> Thanks for OB-Enhancements-dr.305 >>>>>

Feb. 23, 2009

[Pharo-project] SmaCC can't find silence in Sound Library ?!

by Oscar Nierstrasz

Hi, I just loaded SmaCC and SmaCCDev into a Pharo image (pharo0.1-10231dev09.02.1) and tried to start it up. When I click on the tabs I get the annoying pop-up message: "silence not found in the Sound library". Has anyone else experienced this? I did not find anything in the list of issues. Shall I add it? Anyone know how to fix it? - on --- Prof. Dr. O. Nierstrasz -- Oscar.Nierstrasz(a)iam.unibe.ch Software Composition Group -- http://www.iam.unibe.ch/~scg University of Bern -- Tel/Fax +41 31 631.4618/3355 vcard: http://www.iam.unibe.ch/~oscar/oscarNierstrasz.vcf

Feb. 23, 2009

[Pharo-project] Font for Pharo

by JÃ©rÃ´me

Hi, I found the Font "Andika Basic"[2] which is an Open Source and Free- Software[1] Unicode-ready font made by the same people who brought us Gentium, the typeface for the nations. I suggest using Andika as the Pharo CI Font since it can be distributed along with Pharo and looks a little bit like Lucida Grande, the Mac-UI-font, but at the same time is more friendly and better readable[3]. According to the Andika Website, Andika is Swahili, which is spoken widely in southeastern regions of the African continent, and means "Write!". Have a look: [2] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=Andika [3] http://minusfreun.de/blog/uploads/Pharo.png JÃ©rÃ´me [1] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=OFL

Feb. 23, 2009

[Pharo-project] suggestion for the category chooser

by StÃ©phane Ducasse

Hi I think that the category chooser could be improved to avoid to have to type twice the category. Right now if I want to create a category I have to know up front whether it exist or not then I have to select new if it does not else if naively I type the new cat the ui tells me well that it is not defined but in such a case I have to retype it. The solution could be remove the fact that for new category we have to press new... when the user enter the category whether it matches or not return the string that the user entered modulo with its matched string in the list. This way as a user I do not have to choose upfront. I want to create a cat I either select on the list or I type and there is one which I can select or I type and there is none in the list so we get a new one the I typed. Stef

Feb. 23, 2009

Re: [Pharo-project] Question about Morphic

by Alexandre Bergel

Thanks Gary, Cheers, Alexandre On 23 Feb 2009, at 12:36, Gary Chambers wrote: > The scroller itself provides the transform morph that deals with > offsetting > within the scrollpane. > Canvases are used in the drawing cycle of morphs so a morph of some > kind > (that implements drawOn: and draws the graphics) should be added to > the > scroller of the scrollpane. The transform morph sets the clipping > rectangle > for drawing its submorphs. > > |window pane m| > window := SystemWindow labelled: 'Mondrian Canvas'. > window model: self. > window extent: 640 @ 480. > pane := ScrollPane new. > m := PolygonMorph new > position: 250@200; > extent: 400@300. > pane scroller addMorph: m. > window > addMorph: pane > frame: (0 @ 0 corner: 1 @ 1). > window openInWorld. > > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, February 22, 2009 12:11 PM > Subject: Re: [Pharo-project] Question about Morphic > > >> 2009/2/22 Alexandre Bergel <alexandre(a)bergel.eu>: >>>> Canvas has the clipping capabilities. >>>> So, you can send a command to render a rectangle (-1000 @ -1000) >>>> corner: (10000 @10000) >>>> but depends on canvas clipping area, it will render only part of >>>> it. >>>> >>>> Also, for displaying morphs withing area with scrolling - use a >>>> TransformMorph to apply clipping & sroll in view. >>>> There are another morphs , ready for use , like ScrollPane >>> >>> I exactly use a ScrollBar. Here is a code excerpt: >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> | window pane | >>> window := SystemWindow labelled: 'Mondrian Canvas'. >>> window model: self. >>> window extent: 640 @ 480. >>> pane := ScrollPane new. >>> >>> canvas := MOCanvas on: self root. >>> pane scroller addMorph: canvas. >>> window >>> addMorph: pane >>> frame: (0 @ 0 corner: 1 @ 1). >>> window openInWorld. >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> MOCanvas is a subclass of Morph that is resized on some point. >>> >>> Apparently, this incantation does not activate this clipping. >>> >> Well, i'm not sure how to use ScrollPane properly.. >> look for examples of it in other morphs. >> >>> Alexandre >>> >>>> >>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 23, 2009

Re: [Pharo-project] Question about Morphic

by Gary Chambers

The scroller itself provides the transform morph that deals with offsetting within the scrollpane. Canvases are used in the drawing cycle of morphs so a morph of some kind (that implements drawOn: and draws the graphics) should be added to the scroller of the scrollpane. The transform morph sets the clipping rectangle for drawing its submorphs. |window pane m| window := SystemWindow labelled: 'Mondrian Canvas'. window model: self. window extent: 640 @ 480. pane := ScrollPane new. m := PolygonMorph new position: 250@200; extent: 400@300. pane scroller addMorph: m. window addMorph: pane frame: (0 @ 0 corner: 1 @ 1). window openInWorld. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 22, 2009 12:11 PM Subject: Re: [Pharo-project] Question about Morphic > 2009/2/22 Alexandre Bergel <alexandre(a)bergel.eu>: >>> Canvas has the clipping capabilities. >>> So, you can send a command to render a rectangle (-1000 @ -1000) >>> corner: (10000 @10000) >>> but depends on canvas clipping area, it will render only part of it. >>> >>> Also, for displaying morphs withing area with scrolling - use a >>> TransformMorph to apply clipping & sroll in view. >>> There are another morphs , ready for use , like ScrollPane >> >> I exactly use a ScrollBar. Here is a code excerpt: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> | window pane | >> window := SystemWindow labelled: 'Mondrian Canvas'. >> window model: self. >> window extent: 640 @ 480. >> pane := ScrollPane new. >> >> canvas := MOCanvas on: self root. >> pane scroller addMorph: canvas. >> window >> addMorph: pane >> frame: (0 @ 0 corner: 1 @ 1). >> window openInWorld. >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> MOCanvas is a subclass of Morph that is resized on some point. >> >> Apparently, this incantation does not activate this clipping. >> > Well, i'm not sure how to use ScrollPane properly.. > look for examples of it in other morphs. > >> Alexandre >> >>> >>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 23, 2009

Re: [Pharo-project] New Pharo-dev based on 10236

by Damien Cassou

On Mon, Feb 23, 2009 at 10:20 AM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > I got an Error: primitive failed in MultiByteFileStream when launching > a fresh 10236dev image. Am I the only one to experience that? No, everyone is concerned. This is a problem with MIME support. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 23, 2009

Re: [Pharo-project] New Pharo-dev based on 10236

by Simon Denier

I got an Error: primitive failed in MultiByteFileStream when launching a fresh 10236dev image. Am I the only one to experience that? On 19 fÃ©vr. 09, at 10:06, Damien Cassou wrote: > http://code.google.com/p/pharo/wiki/Downloads?tm=2 > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Simon

Feb. 23, 2009