- Pharo-dev - lists.pharo.org

Re: [squeak-dev] Re: [Pharo-project] Alien FFI
by John M McIntosh Nov. 24, 2008

Nov. 24, 2008

On 24-Nov-08, at 6:37 AM, David Pennell wrote: > John, > > Its probably worthwhile to find a place to post Eliot's > documentation files for Alien. > > -david Documentation files and a start on a wiki page is at: http://wiki.squeak.org/squeak/6100 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

[Pharo-project] Event rewrite
by Michael Rueger Nov. 24, 2008

Nov. 24, 2008

Hi all, after wrapping the current implementation which I test and packaged in the experimental polymorph image I tried to install it in the newest Pharo image and it doesn't work (freezes). Anyone a suggestion what might have changed in the area of event handling or process management? I started going through the different classes but maybe somebody has a hint where to look? As reward there will be no more EventSensor and EventTicklerProcess :-) Thanks Michael

6 34

Re: [squeak-dev] Re: [Pharo-project] Alien FFI
by John M McIntosh Nov. 24, 2008

Nov. 24, 2008

Ok, well asAlien seems to be used as conversion methods to ensure a passed object is an alien. What would you like to do instead? I'll integrate the primitive Error code changes this week and do any clean up. If you would like to suggest which variable bindings can be deleted I'll correct that. On 24-Nov-08, at 9:49 AM, Vassili Bykov wrote: > On Mon, Nov 24, 2008 at 12:13 AM, John M McIntosh > <johnmci(a)smalltalkconsulting.com> wrote: >> I would suggest someone with an eye towards "Compiler, CompileMethod, >> ParseNode" carefully look at the changes in "Alien-Core" to ensure >> I've not >> trashed some important part of the Pharo Compiler or Traits. I >> can't say if >> the changes are destructive or passive? > > Many of those have to do with primitive errorCode support, and it > would be nice to categorize them separately. I didn't look closely, > but those that have to do with variable bindings are likely to be > irrelevant. > > And sorry, but adding #asAlien to True, False and UndefinedObject is > just wrong. Nor should have it been in String from the start. > > Cheers, > > --Vassili > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

Re: [Pharo-project] HostWindows rewrite
by Bill Schwab Nov. 24, 2008

Nov. 24, 2008

I agree: it would be useful to control host windows in some way, whether as described below, or via Wx, etc. The native windows/controls have their uses, though they are not (IMHO) the panacea that many believe them to be. So, it would be very nice to be able to mix native and emulated GUI elements. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> antony.blakey(a)gmail.com 11/9/2008 4:35 PM >>> On 09/11/2008, at 10:17 PM, Igor Stasenko wrote: > What you'll never see in new plugin: > - native widgets support or any kind of dealing with native widgets/ > controls. Notwithstanding this, IMO a really good feature would be the ability to create and manage native views within windows, where e.g. a Morph could be 'backed' by a native view. This feature alone is enough to later allow native controls (such as WebKit) to mix with 'light' controls with correct z-ordering/clipping/event handling etc. Of course one could retrofit such a feature, but using native views from the start would encourage any Morphic mods (or other widget set) to use native views and hence be ready for better integration. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] 10164 Image freezing
by StÃ©phane Ducasse Nov. 24, 2008

Nov. 24, 2008

Hi all I loaded OB shout ecompletion and we were apply coding with damien. And the image froze (deeply) when we redefined a class. So the thread changes may be a problem. Stef

4 8

[Pharo-project] ob list?
by Esteban Lorenzano Nov. 24, 2008

Nov. 24, 2008

Hi, Does anybody knows if there is a OB specific discussion list? I'm having some issues with latest OBPackageBrowser implementation (OBTreeColumn) and I want to discuss/understand the implementation... Thanks, Esteban

2 1

[Pharo-project] How to set the color of a gradient button ?
by Hilaire Fernandes Nov. 24, 2008

Nov. 24, 2008

On button created with polymorph, like btn := self newButtonFor: self action: #openFinish label: 'J''ai fini !' help: 'Presse ce bouton lorsque tu as fini l''exercice'. ^ btn onColor: Color green muchLighter offColor: Color gray Changing the color does not work as expected. There are a couple of metod to change the color but none are working. Hilaire -- http://blog.ofset.org/hilaire

2 1

[Pharo-project] Polymorph in Pharo
by Torsten Bergmann Nov. 24, 2008

Nov. 24, 2008

The ScriptLoader 665 MCZ in the pharo inbox (which is based on 664 from Marcus) adds a simple load script to load the Polymorph UI framework into pharo. There is no need to patch MC as described in http://wiki.squeak.org/squeak/6005 sine an exception handler is used to surpress the progress bar. It's best to close most windows before evaluating the script but in most cases it just works. Thanks to Gary for the nice UI! When to expect an XP like look ;) Have fun, Torsten -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL fÃ¼r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

6 6

[Pharo-project] Alien FFI
by Torsten Bergmann Nov. 24, 2008

Nov. 24, 2008

There is now a squeaksource project for Alien - the new FFI. See http://www.squeaksource.com/Alien.html -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL fÃ¼r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

5 6

[Pharo-project] Host window events
by Igor Stasenko Nov. 24, 2008

Nov. 24, 2008

Hello list, i managed to build a new host windows plugin which currently including - window management - event handling - display/draw support The difference between old plugin, that for each host window an image always keeping own instance of HostWindow and provides an easy and fast way to translate a window hanlde (reported in events) to a corresponding HostWindow instance. A plugin, instead of operating with a raw OS window handles, keeping own list of open windows and lets language side operate with index in that list. Now, since all window handles is ordered and start counting from 0 , all we need is to keep a WeakArray and that array at: windowHandle can return us the corresponding HostWindow instance. This will allow to direct event handling to a proper HostWindow instance. That's where the fun begins. But! A host window is not a Form or DisplayScreen. It having a simple primitive which , like in old plugin, allows to blit a portion of form to a host window surface. Also, a plugin generates events to notify image about different things like window dimensions has changed or portion of screen need to be redrawn. What i would like to ask, is how to wire Form (or some DisplayScreen subclass) with HostWindow. Obviously, a HostWindow acts as backend , and don't needs to know anything about who wants to draw on it or listen for events. I need an advice , how to bind couple of events, which HostWindow should handle, and report them further to something which controls what to draw in it. Current 'interesting' number of events is quite small: - a window size has changed (and Form/DisplayScreen need to resync with new size, obviously) - a portion of window should be updated/redrawn (and Form/DisplayScreen needs to repaint the damaged region, obviously) there, of course will be more, but first things first :) What you think is the best way for reporting such events? -- Best regards, Igor Stasenko AKA sig.

4 13