February 2009 - Pharo-dev - lists.pharo.org

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

by Adrian Lienhard

I attached to the report a changeset that should fix the problem http://code.google.com/p/pharo/issues/list?updated=599 It makes the Beep sound, which is still in the image, being played if the requested sound name does not exist. Adrian On Feb 23, 2009, at 16:33 , Adrian Lienhard wrote: > I would just remove the inform: to ignore playing a sound that does > not exist. > I don't think one really needs sound to work with SmaCC ;) > >> Shouldn't all the sounds listed in SampledSound >> class>>universalSoundKeys be permanently in the image? >> >> Where are they all? > > > We removed the sound samples from the image to spare memory. Hence, > #universalSoundKeys should be updated. > > I created http://code.google.com/p/pharo/issues/detail?id=599 > > Adrian > > > On Feb 23, 2009, at 16:21 , StÃ©phane Ducasse wrote: > >> one idea would be save a sound in 3.9 and reload it in this version. >> >> stef >> >> On Feb 23, 2009, at 2:00 PM, 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 >>> >> >> >> _______________________________________________ >> 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 Adrian Lienhard

I would just remove the inform: to ignore playing a sound that does not exist. I don't think one really needs sound to work with SmaCC ;) > Shouldn't all the sounds listed in SampledSound > class>>universalSoundKeys be permanently in the image? > > Where are they all? We removed the sound samples from the image to spare memory. Hence, #universalSoundKeys should be updated. I created http://code.google.com/p/pharo/issues/detail?id=599 Adrian On Feb 23, 2009, at 16:21 , StÃ©phane Ducasse wrote: > one idea would be save a sound in 3.9 and reload it in this version. > > stef > > On Feb 23, 2009, at 2:00 PM, 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 >> > > > _______________________________________________ > 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 StÃ©phane Ducasse

one idea would be save a sound in 3.9 and reload it in this version. stef On Feb 23, 2009, at 2:00 PM, 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

[Pharo-project] Which Mondrian ?

by CÃ©drick BÃ©ler

Hi, As I need to draw a PERT diagram, I decided to give Mondrian a try. I had a version (ported by Lukas [1]) used in OB which I started to use and read doc (code doc :) ). And I saw that Alexandre (Bergel) is working on improving another version [2]. So, which one to use (knowing that I use OB) ? I think there are differences... Thanks -- CÃ©drick [1] http://source.lukas-renggli.ch/mondrian [2] http://www.squeaksource.com/Mondrian

Feb. 23, 2009

Re: [Pharo-project] Font for Pharo

by StÃ©phane Ducasse

thanks for the link and information! Stef On Feb 23, 2009, at 1:33 PM, JÃ©rÃ´me wrote: > 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 > _______________________________________________ > 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] Just downloaded pharo

by StÃ©phane Ducasse

Yes I want that too santaIgor :) Stef On Feb 23, 2009, at 7:20 AM, Igor Stasenko wrote: > 2009/2/23 Michael Rueger <m.rueger(a)acm.org>: >> Igor Stasenko wrote: >> >>> Indeed. It is difficult, but possible :) >>> I want to refactor VM code to make all windowing stuff be >>> exclusively >>> driven from language side. >>> So, when you run: >>> squeak -headless myimage.image >>> >>> and -headless flag is handled not by VM itself, but by language >>> side. >>> So, you can ignore such flag, or can honor it - all is in your >>> hands. >> >> Well, while you are at it ;-) everything related to display, input >> and >> clipboard should be moved out of the core VM into plugins so one >> could >> build a truely headless VM e.g. for running scripts. >> > exactly, that's my point. > In a longer perspective, i'd also would like to be able to build VM as > a library, > so one can embed it into own project. > >> Michael >> >> _______________________________________________ >> 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] [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