September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] MethodName is now Finder

by Gary Chambers

Very nice! Regards, Gary ----- Original Message ----- From: Benjamin Van Ryseghem To: pharo-project(a)lists.gforge.inria.fr Sent: Saturday, September 18, 2010 5:45 PM Subject: [Pharo-project] MethodName is now Finder Hello everyone ^^ After a week in ESUG and thanks to Alain and Tobias, I've improved the Finder tool :) To test it, you have to download : Gofer new squeaksource: 'PharoTaskForces'; package: 'NullTextStyler'; load Gofer new squeaksource: 'PharoTaskForces'; package: 'DialogItemsChooser'; load and the last but not the least : Gofer new squeaksource: 'PharoTaskForces'; package: 'Finder'; load It works only on Pharo 1.2 and you will probably have an error due to an issue about PluggableTextMorph : http://code.google.com/p/pharo/issues/detail?id=2973 To open it, just click World >> Tools >> Finder Ben ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

[Pharo-project] VM Plugins internal vs external

by Torsten Bergmann

>From what i know, it has more to do with having smaller sized vm's, than >with efficiency reasons. Yes, and with security. Thats why FFI is external. If you remove it all code (downloaded or not) can only use built in primitives and its not possible to call OS API's and harm your computer. Bye T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Sept. 20, 2010

Re: [Pharo-project] UI states

by Gary Chambers

Well, that'd be a big overhaul. May as well do something compatible with CSS3 perhaps? Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, September 16, 2010 10:53 PM Subject: Re: [Pharo-project] UI states > 2010/9/16 Gary Chambers <gazzaguru2(a)btinternet.com>: >> I might be nice for the appearance of all controls, windows etc. to >> adhere >> to a standard set of UI states as identified: >> >> Enabled >> Enabled Mouse over >> Enabled Mouse down inside >> Enabled Mouse down outside (*) >> >> Enabled Selected >> Enabled Selected Mouse over >> Enabled Selected Mouse down inside >> Enabled Selected Mouse down outside (*) >> >> Disabled >> Disabled Mouse over (*) >> Disabled Mouse down inside (*) >> Disabled Mouse down outside (*) >> >> Disabled Selected >> Disabled Selected Mouse over (*) >> Disabled Selected Mouse down inside (*) >> Disabled Selected Mouse down outside (*) >> >> And repeat for additional "inactive" (non-primary/top window) >> >> >> (*) indicates a nice to have, rather than strictly necessary... >> >> Thoughts appreciated beforehand. Anything missing, suggestions for >> fallback >> (don't want to have to do all for everything)?... >> >> Perhpas worth a tutorial/help/etc. for those making new widgets. >> >> >> I'm sure I discussed this with Igor before, but not sure I had a >> response. >> > > We discussed a lot before, so i am also not sure if we touched this > topic before :) > > My own (1 year old) idea about states is different. > In short: a widget state is better to describe not by a set of flags > (disabled/enabled, mouse over/out etc etc), > but with stack of modes, where topmost mode (on stack) having a > greater preference above those which follow. > > Then you can easily control the widget appearance depending on modes. > An example. > > By default, you rendering a button using blue color. > When mouse is over it, you render it with light-blue color. > When button is disabled, you render it with gray color, regardless if > mouse over or not over it. > > From the above description, its easy to compose a right stack of > modes, which affecting the widget appearance: > > initially, a stack is empty( we assume default mode on stack) > > - default mode (blue background) > > when mouse enters a widget, you simply pushing a new mode on widget's > mode stack: > > - mouse over(light-blue) > - default mode (blue background) > > and when it leaves, in response to such event, you simply removing the > corresponding mode from stack: > > - default mode (blue background) > > But one things with disabled dome, that you want a 'disabled mode' to > be always on top of the mode stack, > regardless of any other modes, which means that you likely don't wanna > have: > > > - mouse over(light-blue) > - disabled(gray) > - default mode (blue background) > > but always want > > - disabled(gray) > - mouse over(light-blue) > ... > - default mode (blue background) > > so, a color, attached to it is always takes a preference. > To deal with this, we need just one more rule: each mode having a > priority , or (weight), > and a simple rule, that when you pushing a mode with lower priority > than currently on top of the stack, > you insert it after the mode of highest priority you met, so then, > when you have it like following: > > > - disabled(100) > - default (0) > > and mouse enters the widget, you making a 'mouseover' mode to have >0 > but < 100 priority value, > so it is always pushed after disabled. > > - disabled(100) > - mouseover(1) > - default (0) > > in addition to that, in my experimental project, i can attach any > attribute to mode(s), so it is more like > a set of css rules (a:hover, a:link ...) , so i can even say that in > disabled mode i don't even want to react on > a mouse enter/leave events so i don't need to be bothered by using > priorities, because mouseover mode is > never get pushed on mode stack. > > The next thing, what i'd like to tell more about modes and styles: > to render a widget, i start looking for some property (like background > color) along the mode stack. > And if topmost mode does not defining it, then i going down the stack > and querying this property for next mode. > Then finally, if its defined nowhere, it goes down to default mode, > where it should answer a default value. > > In this way i have a quite flexible way to define a styles. I can > change a various properties for one mode, but leave the rest > untouched. > More on top of that, i am even can modify a property value(s), > returned by mode with sits down the stack.. but i think this is too > much > for this mail. > I just wanted to show you how much more flexibility you can get by > using this model :) > > >> Regards, Gary >> >> _______________________________________________ >> 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

Sept. 20, 2010

Re: [Pharo-project] VM Plugins internal vs external

by Fernando olivero

>From what i know, it has more to do with having smaller sized vm's, than with efficiency reasons. On Sep 20, 2010, at 9:38 AM, Noury Bouraqadi wrote: > Hi, > > What is the difference between internal and external plugins in the VM? > > Noury > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

[Pharo-project] OT: Transistor-level Simulation of the 6502 CPU in JavaScript

by Pavel Krivanek

See http://visual6502.org/JSSim/index.html Cheers, -- Pavel

Sept. 20, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Alexander LazareviÄ

Hi Stef, this is a tricky thing to do from _within_ Morphic, because even if you avoid progress notification completely during recompilation by doing something like this in a workspace [ ClassBuilder beSilent: true. Morph subclass: #BorderedMorph instanceVariableNames: 'borderWidth borderColor borderStyle' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Kernel'. ] ensure: [ ClassBuilder beSilent: false] the recompilation will succeed, but you'll end up with an error from the TextMorph (or subclass of it) of the workspace you've "done" this code in, because it is also a subclass of BorderedMorph.You can ignore the debugger or wrap that code in an error handler that just does a resume, but yes ... it's not ideal. Alex 2010/9/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > hi guys > > I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. > So we should really have a way to specify silent ui action. > Does anybody have an idea how I could do that? > > Â Â Â Â [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] cog vm and copy/paste

by John M McIntosh

No, since maybe the menu handling goes back in some day. On 2010-09-20, at 1:13 AM, Norbert Hartl wrote: > Thanks John, > > good to know. Would it be easy to remove the menu if there is no native handling available? > > Norbert > > > > Am 20.09.2010 um 06:32 schrieb John M McIntosh <johnmci(a)smalltalkconsulting.com>: > >> There is no mac menu plugin, therefore no interface to the mac menu system. So instead of a AppleCmd-C being recognized as a menu event and turned into a synthetic character event for use by the event queue in the smalltalk as a AppleCmd-C, we see the AppleCmd-C in the Objective-C keyboard handler and push that up as a character event. >> >> On 2010-09-19, at 6:37 AM, Norbert Hartl wrote: >> >>> >>> On 19.09.2010, at 14:25, StÃ©phane Ducasse wrote: >>> >>>> I started today using cog vm. I just downloaded the ones from Eliots site: Cog.app.tgz. I'm using it along with a 12142 core image. With this combination I don't have copy&paste. The menu is there but items are greyed out. Keyboard shortcuts don't work as well. >>>>> >>>>> Any hints on this? >>>> >>>> may be there something that changed again with the mac hst menu >>>> have a look to see if you can reinitialize them. >>> >>> Don't know exactly how. I checked the vm from John. It is working with keyboard shortcuts but the menus aren't active. Doing >>> >>> HostSystemMenus default hostSystemProxy >>> >>> gives me a debugger with >>> >>> primGetMenuHandle: failed >>> >>> I don't know enough to see what is going wrong here. >>> >>> Norbert >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 20, 2010

Re: [Pharo-project] cog vm and copy/paste

by Norbert Hartl

Thanks John, good to know. Would it be easy to remove the menu if there is no native handling available? Norbert Am 20.09.2010 um 06:32 schrieb John M McIntosh <johnmci(a)smalltalkconsulting.com >: > There is no mac menu plugin, therefore no interface to the mac menu > system. So instead of a AppleCmd-C being recognized as a menu event > and turned into a synthetic character event for use by the event > queue in the smalltalk as a AppleCmd-C, we see the AppleCmd-C in > the Objective-C keyboard handler and push that up as a character > event. > > On 2010-09-19, at 6:37 AM, Norbert Hartl wrote: > >> >> On 19.09.2010, at 14:25, StÃ©phane Ducasse wrote: >> >>> I started today using cog vm. I just downloaded the ones from >>> Eliots site: Cog.app.tgz. I'm using it along with a 12142 core >>> image. With this combination I don't have copy&paste. The menu is >>> there but items are greyed out. Keyboard shortcuts don't work as >>> well. >>>> >>>> Any hints on this? >>> >>> may be there something that changed again with the mac hst menu >>> have a look to see if you can reinitialize them. >> >> Don't know exactly how. I checked the vm from John. It is working >> with keyboard shortcuts but the menus aren't active. Doing >> >> HostSystemMenus default hostSystemProxy >> >> gives me a debugger with >> >> primGetMenuHandle: failed >> >> I don't know enough to see what is going wrong here. >> >> Norbert >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > === > === > ===================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > === > === > ===================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

Re: [Pharo-project] Some thoughts...

by Fernando olivero

I can help for the MAC vm implementation. Thanks Igor! Fernando On Sep 17, 2010, at 8:28 PM, Igor Stasenko wrote: > once i get home, i'll start working on it. both mac and linux > implementations is quite similar. > but i need help building VM & testing it on mac, since i don't have mac > > On 17 September 2010 02:29, Fernando olivero <fernando.olivero(a)usi.ch> wrote: >> lets get it working on the mac too please! >> >> On Sep 16, 2010, at 9:23 PM, Igor Stasenko wrote: >> >>> Amen :) >>> >>> >>> >>> On 15 September 2010 12:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> nativeBoost too :) >>>> >>>> Stef >>>> >>>> On Sep 15, 2010, at 11:08 AM, Tudor Girba wrote: >>>> >>>>> Indeed, this sounds really exciting. >>>>> >>>>> Doru >>>>> >>>>> >>>>> On 14 Sep 2010, at 17:59, StÃ©phane Ducasse wrote: >>>>> >>>>>> thanks alex :) >>>>>> We will.... >>>>>> >>>>>> Stef >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I really would like to see projects like Opal and Ocean happening. Even though I may not have the time to directly contribute to them, they are important and I will use them. I am struggling these days to instrument the whole Pharo image and this is not easy. I am eagerly waiting for Opal. I got burned in the past with networks. >>>>>>> >>>>>>> So, please continue... >>>>>>> >>>>>>> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Yesterday is a fact. >>>>> Tomorrow is a possibility. >>>>> Today is a challenge." >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > 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

Sept. 20, 2010

Re: [Pharo-project] Morphic

by Fernando olivero

> > I tried (one of these felt very satisfying): > * Morph>>on:send:to:, which sounded good, but never got called > * intercepting Morph>>processEvent:using: (which I was told was not a good idea) > * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). > * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass. If you use NewTextMorph it becomes trivial, because it uses Announcements to announce editions, enter and escape. | m newTextMorph | SmalltalkEditor initialize. TextEditor initialize. Editor initialize. m := Morph new. m class compile:'changeColor self fillStyle: Color random. self extent: self submorphs anyOne extent . self changed'; compile: 'rollbackMorphClass self delete . self class removeSelector: #changeColor; removeSelector: #rollbackMorphClass. '. newTextMorph := NewTextMorph new. newTextMorph padding: 0 ; borderWidth: 0 ; fillStyle: Color transparent ; onEscapeSend: #rollbackMorphClass to: m; onAcceptSend: #changeColor to: m; onEditionSend:#changeColor to: m ; readOnly: false ; announcesEditions: true; autoFit: true . m addMorph: newTextMorph; perform: #changeColor ; openInWorld.

Sept. 20, 2010