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

Re: [Pharo-project] Issue 5229: Removing the global use of UserInterruptHandler in favor of an inst var in the current Sensor
by Fernando Olivero Feb. 1, 2012

Feb. 1, 2012

Nothing prevents from registering an instance of UserInterruptHandler , outside the Sensor code. But i've noticed that this registering was done in #installEventSensorFramework:, and no reference to the interrupt handler was kept by the Sensor. So made me think that Sensor should keep a reference to it. The question is wether we need a special case for the UserInterruptHandler, i think we should not. By special case i mean, an extra single purpose "Sensor". It could be done more transparently by relying on a single Sensor. Evidence of it is that UserInterruptHandler can be customized for any keystroke, yet the settings are called CmdDotEnabled. Using the new Event-Model, user interrupts can be customized by the client processing the system events, no need to have a special user interrupt handler class. The client would process a normal SystemKeyboardInputEvent, and do whatever it wants in case the keystroke was the current user-interrupt keystroke. For example, in Gaucho : GKeyboard>>keystroke: aGKeystroke â¦. aGKeystroke isUserInterrupt ifTrue:[ userInterface processUserInterrupt ]. ... In Morphic, the HandMorph would have this responsibility. Or we can push this bypassing of the keystroke handling to the SystemEventsAnnouncer. Does it make sense? Fernando On Wed, Feb 1, 2012 at 4:13 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > err... you seems like crossing multiple layers by doing that. > > Because before you were able to have interrupt handler without having a sensor. > Now you cannot have interrupt handler without having sensor installed. > > On 1 February 2012 14:14, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> Please integrate/review this one. >> >> >> In the context of replacing the current event handling mechanism, for >> the new Event-Model using announcements, i found out that the >> UserInterruptHandler is somehow treated as a global. >> >> See >> >> Â InputEventSensor>>installEventSensorFramework: fetcherClass. >> Â Â â¦. >> Â Â "Register the interrupt handler" >> Â Â UserInterruptHandler new registerIn: InputEventFetcher default. >> Â Â â¦â¦. >> >> What if you want to replace the user interrupt handler for another? It >> cant be done transparently. >> >> I've added the userInterruptHandler as an ivar of the current Sensor, >> so when it registers and unregisters, it takes care of registering and >> unregistering its user interrupt handler. >> >> So you can plug different user interrupt handlers to the current sensor. >> >> >> >> >> Fernando >> > > > > -- > Best regards, > Igor Stasenko.

1 0

[Pharo-project] Collection new
by Andrew P. Black Feb. 1, 2012

Feb. 1, 2012

Teaching a class of novices, it's not surprising that someone tried "Collection new". What was surprising is that this got the VM is a loop of some kind, with emergency stack dumps and so on. Here is my reply: > On 30 Jan 2012, at 01:18 , Xingzhi Harry Pan wrote: > >> ...it's pretty innocent: >> Collection new > > > OK. I looked at this. The problem comes when trying to print the collection. Somehow the VM gets confused when trying to do do: ... I'm not quite clear why. > > The quick fix is to change the Collection>>new method to > > self error: 'Collection is an abstract class, and cannot be instantiated' > > However this will break Heap>>new: , which sends super new. It ought to send self basicNew instead. > > These two changes seem to avoid the problem, but I'm waiting to see ... > > Andrew But I don't understand the root cause. Printing eventually sends do:, which is self subclassResponsibility. Why don't we get a clean failure? Andrew

6 8

[Pharo-project] Issue 5229: Removing the global use of UserInterruptHandler in favor of an inst var in the current Sensor
by Fernando Olivero Feb. 1, 2012

Feb. 1, 2012

Please integrate/review this one. In the context of replacing the current event handling mechanism, for the new Event-Model using announcements, i found out that the UserInterruptHandler is somehow treated as a global. See InputEventSensor>>installEventSensorFramework: fetcherClass. â¦. "Register the interrupt handler" UserInterruptHandler new registerIn: InputEventFetcher default. â¦â¦. What if you want to replace the user interrupt handler for another? It cant be done transparently. I've added the userInterruptHandler as an ivar of the current Sensor, so when it registers and unregisters, it takes care of registering and unregistering its user interrupt handler. So you can plug different user interrupt handlers to the current sensor. Fernando

2 1

[Pharo-project] [update 1.4] #14301
by Marcus Denker Feb. 1, 2012

Feb. 1, 2012

14301 ----- Issue 5226: Add 2 methods in Browser API to allow to easily register groups http://code.google.com/p/pharo/issues/detail?id=5226 Issue 5225: Remove PseudoContext http://code.google.com/p/pharo/issues/detail?id=5225 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] a problem with a MorphTreeMorph with headers
by Esteban Lorenzano Feb. 1, 2012

Feb. 1, 2012

Hi, I have a problem for an application I have: I'm displaying a MorphTreeMorph who has a header and some columns, problem is when morph has a horizontal scrollbar and I need to go down, last element on list is covered by horizontal scroll bar and customer can't see his data. I need to solve this, but I don't know how, any help will be really appreciated. (the attached image shows my problem) thanks, Esteban

4 4

[Pharo-project] ODBC suggestion
by Schwab,Wilhelm K Feb. 1, 2012

Feb. 1, 2012

Hello all, For alien/callbacks, it seems I should leave 1.1.1 behind - it's been a very nice release. Migrate (my answer to not losing code) flagged a few methods. One looks like it might be of wide interest: moduleName "Return the name of the module for this library" SmalltalkImage current platformName = 'Win32' ifTrue: [ ^ 'odbc32' ]. SmalltalkImage current platformName = 'unix' ifTrue: [ ^ 'libodbc.so' ]. ^ self error: 'Don''t know the ODBC library name' What do you think? Stef, this is why I don't like putting the module name in the pragmas. Does that make sense? Bill

1 0

Feb. 1, 2012

Hi guys We want to organize a Pharo Conference @ lille around business and companies in May/June 2012. Now we need you to understand what is the best to organize because we have some constraints (like not good access to rooms on saturday). Could you reply to the following questions: Are you planning to attend: Yes No Would you attend two days: Yes No Would you like to present something: Yes No Would you prefer to have (remove the one you do not like) - one friday and one saturday or - two days during the week would be not a problem. Would you like to have Handons: Yes No Business/Experience returns: Yes No What are the following dates that are ok for you? Frid 11- Satur 12 May 2012: Yes No Thur 10- Frid 11 May 2012: Yes No Mond 14- Tuesd 15 May 2012: Yes No Tuesd 15- Wedn 16 May 2012: Yes No Thur 24 - Frid 25 May 2012: Yes No Frid 25- Satur 26 May 2012: Yes No Stef

1 1