- Pharo-dev - lists.pharo.org

[Pharo-project] Diff tools

by Torsten Bergmann

Hi Gary, the diff tools are really great. One feature I miss from Eclipse - when one clicks on one of the small rectangles (in the gradient area beside the srollbar) the editor in eclipse jumps to the according change (adapting the scroll bar). Maybe it is simple to add... Thanks Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Feb. 10, 2010

Re: [Pharo-project] Force the focus of a panel for start to listen keypress events.

by Gary Chambers

There are a few methods involved in making this happen and some will vary depending on how you want things to look like... #takesKeyboardFocus (should return true) #handlesKeyboard: event (should return true or true for specific keys required #keyStroke: event "Process keys navigation." self navigationKey: event (calls Polymorph navigation key handling) #keyboardFocusChange: aBoolean "The message is sent to a morph when its keyboard focus changes. Update for focus feedback." self focusChanged (update focus indication rendering) #drawSubmorphsOn: aCanvas "Display submorphs back to front. Draw the focus here since we are using inset bounds for the focus rectangle." super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [self drawKeyboardFocusOn: aCanvas] (draw keyboard focus indication using theme defaults, guess you may omit this and just do your "selection" thing in #keyboardFocusChange:) Hope this helps! Regards, Gary ----- Original Message ----- From: "nullPointer" <epicfan(a)gmail.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 09, 2010 10:23 PM Subject: [Pharo-project] Force the focus of a panel for start to listen keypress events. > > Well, I decided let the optimization and threads load for later, my > knowledge > is poor, and see that very complicated :| > > Now my main problem is the navigation through cells of grid. All cells > have > a "value control" (currently a label) where is viewed the value data. I > need > when a TAB key is pressed the current cell pass to next cell. > > My question: > > -How I can "focus" morph (the cell) for begin to listen the key presses > events? that morph is really only a PanelMorph subclass. Really I > understand > than need the behavior of list widgets or textboxes for that cell, force > the > focus of some way. > > Regards and thanks for the answers. > -- > View this message in context: > http://n4.nabble.com/Conseils-for-develop-a-grid-tp1299737p1475136.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2010

Re: [Pharo-project] OpenGL in pharo?

by Fernando olivero

Hola Javier, on top of AlienOpenGL , which is just an interface to OpenGL, i've built a 3d framework with better abstractions called Lumiere. (http://www.inf.usi.ch/phd/olivero/LumierePage.html (A little bit outdated...i've added a couple of more things recently..) In this paper that we presented at the last ESUG/IWST 09 , with also did brief survey of OpenGL in smalltalk. (www.esug.org/data/ESUG2009/IWST/iwst09_submission_6.pd) If there's a plugin for AlienFFI for Linux i'm not sure. But have you tried the FFI binding of OGL of Croquet? That one works in Linux. Look in squeaksource, because i remember someone decoupled the OGL wrapper from Croquet and put it there. I dont know if June ( for visual works) works in linux, but you could take a look of it. Saludos, Fernando On Feb 10, 2010, at 3:01 AM, Javier PimÃ¡s wrote: > Hi, I've been browsing the different ways to use OpenGL in pharo and squeak. Here is a log of the results: > > 1 - Baloon3D - It looks like a layer on which squeaksource.com/OpenGL stands, so to use opengl you load balloon3d, then opengl and if you have the Balloon3dPlugin available then you can use OpenGL. This seems to include code dated from 2007/before. It loads fine in Squeak but in pharo I get many errors (load balloon3d-all in pharo1.0 rc2). > > 2 - GLMorphic - It uses FFI, so no plugin is needed, but it seems to be programmed only for windows, and I'm working in linux now. > > 3 - AlienOpenGL - It uses the new Alien FFI, which is only available in Mac platform. > > So, the question is: is there any way to play with OpenGL in pharo on linux platform ? > > Regards, > Javier. > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > <ATT00001..txt>

Feb. 10, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Luc Fabresse

Ok done in Kernel-LucFabresse.578 (PharoInbox). BlockContext>>fixTemps and BlockClosure>>fixTemps have been deprecated. Issue: http://code.google.com/p/pharo/issues/detail?id=1947 Luc 2010/2/9 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> >> >> 2010/2/9 Eliot Miranda <eliot.miranda(a)gmail.com> >> >> >>> >>> 2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> >>>> >>>> 2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> >>>> >>>> Hi all, >>>>> >>>>> I wonder why BlockContext>>fixTemps is still in PharoCore. >>>>> I guess that it should be removed, isn't it? >>>>> >>>> >>>> I would like to remove them. >>>> >>>> >>>>> It has only one sender. >>>>> >>>> >>>> Yes, in the core ;) But the problem is that Seaside (I think only >>>> 2.8.4 as 3.0 seems to fixed that) or KomHttpServer are still using it. >>>> >>>> Of course, we can just remove it and assume that those external packages >>>> should be fixed to run on Pharo. Squeak trunk also has closures...so.. >>>> >>>> >>>>> Morever, should the BlockContext class be removed too? >>>>> >>>> >>>> I would like, too. The only problem is the "compatibility". What maybe >>>> can be done is to remove the class but do something like >>>> >>>> Smalltalk at: #BlockContext put: #BlockClosure >>>> >>> >>> I think this is a really bad idea. Imagine loading something that adds >>> functionality to BlockContext that simply makes no sense in BlockClosure or >>> breaks when compiled on BlockClosure. Best live with the differences and >>> upgrade than introduce a horrible hack that pretends to do >>> backwards-compatibility but actually confuses the hell out of people. >>> >>> >> :( So...what do you recommend us Eliot ? >> > > Leave BlockContext there for now. Port functionality in BlockContext to > BlockClosure as required. In a few months (or perhaps even now) mark > BlockClosure>>fixTemps and BlockContext protocol as deprecated so that uses > of fixTemps and BlockContext generate warnings e.g. in the Transcript. In a > few years get rid of BlockContext. > > > Right now all we're talking about is having a null implementation of > fixTemps in BlockClosure. Marking this deprecated seems to be adequate. Or > am I not understanding your concerns? > > Later on, in synchrony with Squeak and eToys I would like us to consider > whether it is worth-while collapsing ContextPart and MethodContext into a > single class called something like Context or SmalltalkExecutionContext or > ExecutionContext or ThisContext. > > >> >> HTH >>> >>> >>>> >>>> But I have no idea the impact of this.... >>>> >>> >>> which is one really good reason /not/ to do it :) >>> >> >> ahahhaha that's true :) >> >> >>> >>> best >>> Eliot >>> >>>> >>>> >>>>> >>>>> Depending on answers, I will write a bug report. >>>>> >>>>> Luc >>>>> >>>>> _______________________________________________ >>>>> 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. 10, 2010

[Pharo-project] OpenGL in pharo?

by Javier PimÃ¡s

Hi, I've been browsing the different ways to use OpenGL in pharo and squeak. Here is a log of the results: 1 - Baloon3D - It looks like a layer on which squeaksource.com/OpenGLstands, so to use opengl you load balloon3d, then opengl and if you have the Balloon3dPlugin available then you can use OpenGL. This seems to include code dated from 2007/before. It loads fine in Squeak but in pharo I get many errors (load balloon3d-all in pharo1.0 rc2). 2 - GLMorphic - It uses FFI, so no plugin is needed, but it seems to be programmed only for windows, and I'm working in linux now. 3 - AlienOpenGL - It uses the new Alien FFI, which is only available in Mac platform. So, the question is: is there any way to play with OpenGL in pharo on linux platform ? Regards, Javier. -- Javier PimÃ¡s Ciudad de Buenos Aires

Feb. 10, 2010

[Pharo-project] Force the focus of a panel for start to listen key press events.

by nullPointer

Well, I decided let the optimization and threads load for later, my knowledge is poor, and see that very complicated :| Now my main problem is the navigation through cells of grid. All cells have a "value control" (currently a label) where is viewed the value data. I need when a TAB key is pressed the current cell pass to next cell. My question: -How I can "focus" morph (the cell) for begin to listen the key presses events? that morph is really only a PanelMorph subclass. Really I understand than need the behavior of list widgets or textboxes for that cell, force the focus of some way. Regards and thanks for the answers. -- View this message in context: http://n4.nabble.com/Conseils-for-develop-a-grid-tp1299737p1475136.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Eliot Miranda

2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/2/9 Eliot Miranda <eliot.miranda(a)gmail.com> > > >> >> 2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> >>> >>> 2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> >>> >>> Hi all, >>>> >>>> I wonder why BlockContext>>fixTemps is still in PharoCore. >>>> I guess that it should be removed, isn't it? >>>> >>> >>> I would like to remove them. >>> >>> >>>> It has only one sender. >>>> >>> >>> Yes, in the core ;) But the problem is that Seaside (I think only 2.8.4 >>> as 3.0 seems to fixed that) or KomHttpServer are still using it. >>> >>> Of course, we can just remove it and assume that those external packages >>> should be fixed to run on Pharo. Squeak trunk also has closures...so.. >>> >>> >>>> Morever, should the BlockContext class be removed too? >>>> >>> >>> I would like, too. The only problem is the "compatibility". What maybe >>> can be done is to remove the class but do something like >>> >>> Smalltalk at: #BlockContext put: #BlockClosure >>> >> >> I think this is a really bad idea. Imagine loading something that adds >> functionality to BlockContext that simply makes no sense in BlockClosure or >> breaks when compiled on BlockClosure. Best live with the differences and >> upgrade than introduce a horrible hack that pretends to do >> backwards-compatibility but actually confuses the hell out of people. >> >> > :( So...what do you recommend us Eliot ? > Leave BlockContext there for now. Port functionality in BlockContext to BlockClosure as required. In a few months (or perhaps even now) mark BlockClosure>>fixTemps and BlockContext protocol as deprecated so that uses of fixTemps and BlockContext generate warnings e.g. in the Transcript. In a few years get rid of BlockContext. Right now all we're talking about is having a null implementation of fixTemps in BlockClosure. Marking this deprecated seems to be adequate. Or am I not understanding your concerns? Later on, in synchrony with Squeak and eToys I would like us to consider whether it is worth-while collapsing ContextPart and MethodContext into a single class called something like Context or SmalltalkExecutionContext or ExecutionContext or ThisContext. > > HTH >> >> >>> >>> But I have no idea the impact of this.... >>> >> >> which is one really good reason /not/ to do it :) >> > > ahahhaha that's true :) > > >> >> best >> Eliot >> >>> >>> >>>> >>>> Depending on answers, I will write a bug report. >>>> >>>> Luc >>>> >>>> _______________________________________________ >>>> 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. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Mariano Martinez Peck

2010/2/9 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > > >> >> 2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> >> >> Hi all, >>> >>> I wonder why BlockContext>>fixTemps is still in PharoCore. >>> I guess that it should be removed, isn't it? >>> >> >> I would like to remove them. >> >> >>> It has only one sender. >>> >> >> Yes, in the core ;) But the problem is that Seaside (I think only 2.8.4 >> as 3.0 seems to fixed that) or KomHttpServer are still using it. >> >> Of course, we can just remove it and assume that those external packages >> should be fixed to run on Pharo. Squeak trunk also has closures...so.. >> >> >>> Morever, should the BlockContext class be removed too? >>> >> >> I would like, too. The only problem is the "compatibility". What maybe can >> be done is to remove the class but do something like >> >> Smalltalk at: #BlockContext put: #BlockClosure >> > > I think this is a really bad idea. Imagine loading something that adds > functionality to BlockContext that simply makes no sense in BlockClosure or > breaks when compiled on BlockClosure. Best live with the differences and > upgrade than introduce a horrible hack that pretends to do > backwards-compatibility but actually confuses the hell out of people. > > :( So...what do you recommend us Eliot ? HTH > > >> >> But I have no idea the impact of this.... >> > > which is one really good reason /not/ to do it :) > ahahhaha that's true :) > > best > Eliot > >> >> >>> >>> Depending on answers, I will write a bug report. >>> >>> Luc >>> >>> _______________________________________________ >>> 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. 9, 2010

[Pharo-project] [update 1.1] #11199

by StÃ©phane Ducasse

11199 ----- - Issue 1927: SocketStream>>peekFor: fixes. - Issue 1925: expected: requires a string not a block

Feb. 9, 2010

[Pharo-project] [update 1.1] #11198

by StÃ©phane Ducasse

11198 ----- - Issue 1935: MenuMorph enhancement - Deprecated fasterKeys.

Feb. 9, 2010