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

Re: [Pharo-project] Ann: OmniBrowser stable for 1.4 with RB

by Sven Van Caekenberghe

Ben, On 23 Jan 2012, at 09:41, Sven Van Caekenberghe wrote: > On 23 Jan 2012, at 00:54, Benjamin wrote: > >> Strange, I just tested with the latest 1.4 Pharo (14294) and it works ... >> >> But if you want, there is a Jenkins build for Nautilus (https://ci.lille.inria.fr/pharo/job/Nautilus/) > > This was in a 14293 image, but not a clean one, it had the > > (ConfigurationOfOmniBrowser > project version: #stable) load: #( 'Dev' 'Dev Tests'). > > loaded first. I don't know if that has anything to do with it. > > >> Enjoy, >> >> Ben >> >> On Jan 22, 2012, at 11:49 PM, Sven Van Caekenberghe wrote: >> >>> >>> On 22 Jan 2012, at 22:17, Sven Van Caekenberghe wrote: >>> >>>> And what about Nautilus, I want to try that too. >>>> What would be the best way to load it ? >>> >>> I tried: >>> >>> Gofer new >>> squeaksource: 'Nautilus'; >>> package: 'ConfigurationOfNautilus'; >>> load. >>> >>> ConfigurationOfNautilus loadDefault. >>> >>> Nautilus open >>> >>> gives RBClassEnvironment not found I just tried again: yes, in a clean image Nautilus loads and works without any problems. But doing it in a up to date image with latest OB loaded, it fails. Output on the Transcript seems identical. Any, great browser: it is good to see something new ! Sven

Jan. 23, 2012

[Pharo-project] Redesign of Mouse/Touch/Gestures/Keyboard events neccessary?

by Guido Stepken

Hi! When i look at Apple Hardware Shop i find "Magic Mouse". This cheap mouse has a "surface", hat works like a touch screen, accepts multitouch, 2,3 finger gestures, pressure sensor (over widening fingercontactformsize, like ipad does) scrollwheel emulation, even replaces special 3D input devices, used for CAD. In about one year from now there won't be any classic keyboard/mouse/screen hardware and software available, all OS for desktop will have complex finger/gesture/approach/video sensors tightly integrated into the os. My OS even puts a window in front, when i look at it, i don't even need to move my mouse over or even klick into that hidden window. Furthermore, new OS have received a "multiuseronedesktop" function, where a second, third and forth person might have their own input devices assigned, e.g. several programmers typing in one text window (simultaneous pair programming, no need to handover keyboard) or typing from above, e.g. on Microsofts new touch table, produced by Samsung. 4 Users sitting in front of a table, typing on touch or virtually assigned Bluetooth keyboard, turning windows to show each other. In a few years this will be standard even in schools, at work, in restaurants, people sitting, eating, playing chess or multiuser pong. As i could read, the Pharo chief designers have even removed the turn window angle functionality, that was implemented in squeak, WHY THAT??? Instead i would like to have virtually assigned touch keyboards to turnable windows. New touch tables go up to recognize 60 fingers at the same time. Approach sensors, gyro, video : My mobile has built in such thing. Pretty nice, my phone "sees itself approaching my ear", unlocking the microphone and speaker on incoming phone call. Thats built in in Android 4.0. Approach sensors trigger videoinput to recognize gestures or - like in newer HP and Lenovo notebooks activate powerdown state, when user leaves and reactivates, when user comes back. It can differ between "user reading" and "user absent". Thats already built in, becomes standard soon in all notebooks with windows 8. So far my report of "state of the art of software programming". feel inspired, Guido Stepken

Jan. 23, 2012

Re: [Pharo-project] Rethinking the event's handling in Gaucho/Morphic

by Fernando Olivero

On Mon, Jan 23, 2012 at 11:21 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jan 23, 2012, at 1:18 AM, Fernando Olivero wrote: > >> Hi, in the context of the new UI framework i'm developing for Gaucho, >> i've decided to design the event handling part as follows: >> >> The entry point to the framework is an instance of aGUserInterface , >> which collaborates with a set of peripherals: in the standard case it >> holds a: 1)aGDisplay 2) aGMouse and 3) aGKeyboard. > > Now more time to answer. > Indeed HandMorph looks to me like having too many responsibility > Â Â Â Â - transform low level event into high level > Â Â Â Â - manage the Morphic interaction loops > Â Â Â Â - looks like a cursor > YES! this design favors the sharing of the above responsibilities between the user interface and its peripherals. > >> The GUserInterface listens to VM events, and process them as they arrive. >> >> GUserInterface>>process: aSensorEvent dispatches to either the mouse >> or the keyboard. > > Â Â Â Â in what we are putting in place we use double dispatch because > Â Â Â Â we want to be able to plug new event > >> GKeyboard>>process: distinguishes between keyDown, keyUp, and >> keystrokes, and reacts accordingly. >> GMouse>>process: Â finds the proper reaction depending on the context >> of the mouse. >> >> The keyboard handling logic is quite simple. >> >> The mouse is significantly more complicated, because the mouse events >> produce a different action depending on the current "mode" Â of the >> mouse. I modeled this problem, using the State pattern, depicted by >> the attached FSM. > > > interesting. Indeed it looks to me that using a state pattern should be a nice way to > handle the Morphic logic > > Now I do not understand the arrows to the big Mouse. > When a MouseState reacts to a given event, such the MouseDragging reacting to #up: aDisplayPoint, it sends messages to the Mouse, such as #drop:at:, #clicked:at:, #secondaryclicked:at:. > I like the idea that you dispatch to the peripherals now what we encounter > with igor is that handMorph need to keep the previous system event and modifiers > so is the distribution to Mouse, Keyboard supporting that? yes, the last mouse event needs to be stored, to be able to decode wether the sensor input event is a mouse up or a mouse down . But this is stored by the Mouse.SURELY, we should improve how the VM encodes the OS Event, this shouldn't be needed! . The keyboard doesn't need such mechanism. > Fernando if you have a look at EventModel > we are asking ourselves the following questions: > Â Â Â Â - HostMenu management looks not the way we want (right now it hijacks low level event and produce event to simulate) > Â Â Â Â we are thinking that the HandMorph (or User Interface in your case should be responsible for deciding to publish menu > Â Â Â Â as host menu and host menu should be able to call the same code than default menu. > > Â Â Â Â - We want to look at the API of InputEventSensor (using event but) Â and SystemInputEventAnnouncer (using events!) > Â Â Â Â and check the various users and fix them because we do not want the system to rely on InputEventSensor and its eventBuf > I've looked at the EventModel, quite nice design. I will adapt the design proposed above to it, the only difference is that GUserInterface , GMouse and GKeyboard will process a SystemInputEvent instead of a raw event buffer encoded in an Array. Which will ease and standardize the dispatching amongst the peripherals.

Jan. 23, 2012

Re: [Pharo-project] Rethinking the event's handling in Gaucho/Morphic

by StÃ©phane Ducasse

On Jan 23, 2012, at 1:18 AM, Fernando Olivero wrote: > Hi, in the context of the new UI framework i'm developing for Gaucho, > i've decided to design the event handling part as follows: > > The entry point to the framework is an instance of aGUserInterface , > which collaborates with a set of peripherals: in the standard case it > holds a: 1)aGDisplay 2) aGMouse and 3) aGKeyboard. Now more time to answer. Indeed HandMorph looks to me like having too many responsibility - transform low level event into high level - manage the Morphic interaction loops - looks like a cursor > The GUserInterface listens to VM events, and process them as they arrive. > > GUserInterface>>process: aSensorEvent dispatches to either the mouse > or the keyboard. in what we are putting in place we use double dispatch because we want to be able to plug new event > GKeyboard>>process: distinguishes between keyDown, keyUp, and > keystrokes, and reacts accordingly. > GMouse>>process: finds the proper reaction depending on the context > of the mouse. > > The keyboard handling logic is quite simple. > > The mouse is significantly more complicated, because the mouse events > produce a different action depending on the current "mode" of the > mouse. I modeled this problem, using the State pattern, depicted by > the attached FSM. interesting. Indeed it looks to me that using a state pattern should be a nice way to handle the Morphic logic Now I do not understand the arrows to the big Mouse. > For example: if a #up: 10@10 arrives, and the mouse > is on "dragging mode", would result in the evaluation of the message > GMouse>>dropped: aGShape at: aDisplayPoint. > > The usage of the state pattern, simplifies the coding of the reaction > to each of the mouse events (#up:, #move:, #down:,#secondaryDown:), > according to the mouse's context. And provides a hook for > altering/augmenting the behavior as well. Yes I really want to see that. BTW benjmain should contact you about the eventHndling in Morph because you show me at Edinburgh that you put in place a different way to model them using a kind of strategy pattern. > There's no need to reify the events in the design, events are > generated by the user, encoded by the VM, decoded by the > GUserInterface and dispatched to the proper peripheral device. I like the idea that you dispatch to the peripherals now what we encounter with igor is that handMorph need to keep the previous system event and modifiers so is the distribution to Mouse, Keyboard supporting that? For example, the recent bug in taskList anyModifiersKeyPressed was due to the fact that TaskLIst was asking inputSensor directly and not handMorph and that handMorph did not have the same API. We fixed part of it. (Morphic code should go via HandMorph and not directly to the low level input sensor). > > Other Peripheral devices can be easily be attached, for now i'm > sticking to the standard display, keyboard and three button mouse. > Changes to the VM may still be needed to encode the User actions of > the external device, but in the image would be straightforward to > "plug and unplug" devices. > > I'm interested in hearing your opinions or remarks on the design, or > if i've omitted a state or transition from the FSM. > Fernando if you have a look at EventModel we are asking ourselves the following questions: - HostMenu management looks not the way we want (right now it hijacks low level event and produce event to simulate) we are thinking that the HandMorph (or User Interface in your case should be responsible for deciding to publish menu as host menu and host menu should be able to call the same code than default menu. - We want to look at the API of InputEventSensor (using event but) and SystemInputEventAnnouncer (using events!) and check the various users and fix them because we do not want the system to rely on InputEventSensor and its eventBuf > Thanks in advance, > Fernando > > pd: An intersesting side effect is that i can test low level mouse > actions, such as drag and drop, hovering and unhovering, etc.., > resulting in a more robust framework. > pd: Soon i will release the framework, We should sync because we really want to finish to clean the eventBuf handling so if you can have a look it could help us. We can do a chat if you want. > still working on make it render > with Athens. > <mouseFSM.png>

Jan. 23, 2012

Re: [Pharo-project] [ANN] Spotlight like morph for pharo

by StÃ©phane Ducasse

Send hooks for Morphic? Stef > Hi, > > I want to announce a little tool I made the other day (mainly because Mariano asked for it :) > > Do you remember algernon, that tool who was working in pharo 1.1 and is now obsolete? I used it all the time, and I always missed the ability to open browsers without having to type the class name in a workspace, or open a browser first, then look for the class. > So, I created this: > > Gofer it > squeaksource: 'Spotlight'; > package: 'ConfigurationOfSpotlight'; > load. > ConfigurationOfSpotlight loadBleedingEdge. > > if you press shift+enter, you'll get a "spotlight" like morph, with a simple text input with OCompletion inside... is very simple and I think very useful. Of course it can be enhanced in a lot of ways... but let's here the community opinion first, and see if it worths to keep adding functionality.functionality. > > enjoy, > Esteban > > ps: this is also an example of why I hate morphic so much (bah... current dirty implementation): I had to extend two classes just to change the editor used by a textmorph.... come on!!!!

Jan. 23, 2012

Re: [Pharo-project] Ann: OmniBrowser stable for 1.4 with RB

by Sven Van Caekenberghe

On 23 Jan 2012, at 00:54, Benjamin wrote: > Strange, I just tested with the latest 1.4 Pharo (14294) and it works ... > > But if you want, there is a Jenkins build for Nautilus (https://ci.lille.inria.fr/pharo/job/Nautilus/) This was in a 14293 image, but not a clean one, it had the (ConfigurationOfOmniBrowser project version: #stable) load: #( 'Dev' 'Dev Tests'). loaded first. I don't know if that has anything to do with it. > Enjoy, > > Ben > > On Jan 22, 2012, at 11:49 PM, Sven Van Caekenberghe wrote: > >> >> On 22 Jan 2012, at 22:17, Sven Van Caekenberghe wrote: >> >>> And what about Nautilus, I want to try that too. >>> What would be the best way to load it ? >> >> I tried: >> >> Gofer new >> squeaksource: 'Nautilus'; >> package: 'ConfigurationOfNautilus'; >> load. >> >> ConfigurationOfNautilus loadDefault. >> >> Nautilus open >> >> gives RBClassEnvironment not found. >> >> >

Jan. 23, 2012

Re: [Pharo-project] Rethinking the event's handling in Gaucho/Morphic

by StÃ©phane Ducasse

Hi fernando can you have a look at EventModel on squeak source because we are cleaning the evtbuf and creating systemInputEvent and we will integrate that soon. STef On Jan 23, 2012, at 1:18 AM, Fernando Olivero wrote: > Hi, in the context of the new UI framework i'm developing for Gaucho, > i've decided to design the event handling part as follows: > > The entry point to the framework is an instance of aGUserInterface , > which collaborates with a set of peripherals: in the standard case it > holds a: 1)aGDisplay 2) aGMouse and 3) aGKeyboard. > > The GUserInterface listens to VM events, and process them as they arrive. > > GUserInterface>>process: aSensorEvent dispatches to either the mouse > or the keyboard. > GKeyboard>>process: distinguishes between keyDown, keyUp, and > keystrokes, and reacts accordingly. > GMouse>>process: finds the proper reaction depending on the context > of the mouse. > > The keyboard handling logic is quite simple. > > The mouse is significantly more complicated, because the mouse events > produce a different action depending on the current "mode" of the > mouse. I modeled this problem, using the State pattern, depicted by > the attached FSM. For example: if a #up: 10@10 arrives, and the mouse > is on "dragging mode", would result in the evaluation of the message > GMouse>>dropped: aGShape at: aDisplayPoint. > > The usage of the state pattern, simplifies the coding of the reaction > to each of the mouse events (#up:, #move:, #down:,#secondaryDown:), > according to the mouse's context. And provides a hook for > altering/augmenting the behavior as well. > > There's no need to reify the events in the design, events are > generated by the user, encoded by the VM, decoded by the > GUserInterface and dispatched to the proper peripheral device. > > Other Peripheral devices can be easily be attached, for now i'm > sticking to the standard display, keyboard and three button mouse. > Changes to the VM may still be needed to encode the User actions of > the external device, but in the image would be straightforward to > "plug and unplug" devices. > > I'm interested in hearing your opinions or remarks on the design, or > if i've omitted a state or transition from the FSM. > > Thanks in advance, > Fernando > > pd: An intersesting side effect is that i can test low level mouse > actions, such as drag and drop, hovering and unhovering, etc.., > resulting in a more robust framework. > pd: Soon i will release the framework, still working on make it render > with Athens. > <mouseFSM.png>

Jan. 23, 2012

[Pharo-project] Rethinking the event's handling in Gaucho/Morphic

by Fernando Olivero

Hi, in the context of the new UI framework i'm developing for Gaucho, i've decided to design the event handling part as follows: The entry point to the framework is an instance of aGUserInterface , which collaborates with a set of peripherals: in the standard case it holds a: 1)aGDisplay 2) aGMouse and 3) aGKeyboard. The GUserInterface listens to VM events, and process them as they arrive. GUserInterface>>process: aSensorEvent dispatches to either the mouse or the keyboard. GKeyboard>>process: distinguishes between keyDown, keyUp, and keystrokes, and reacts accordingly. GMouse>>process: finds the proper reaction depending on the context of the mouse. The keyboard handling logic is quite simple. The mouse is significantly more complicated, because the mouse events produce a different action depending on the current "mode" of the mouse. I modeled this problem, using the State pattern, depicted by the attached FSM. For example: if a #up: 10@10 arrives, and the mouse is on "dragging mode", would result in the evaluation of the message GMouse>>dropped: aGShape at: aDisplayPoint. The usage of the state pattern, simplifies the coding of the reaction to each of the mouse events (#up:, #move:, #down:,#secondaryDown:), according to the mouse's context. And provides a hook for altering/augmenting the behavior as well. There's no need to reify the events in the design, events are generated by the user, encoded by the VM, decoded by the GUserInterface and dispatched to the proper peripheral device. Other Peripheral devices can be easily be attached, for now i'm sticking to the standard display, keyboard and three button mouse. Changes to the VM may still be needed to encode the User actions of the external device, but in the image would be straightforward to "plug and unplug" devices. I'm interested in hearing your opinions or remarks on the design, or if i've omitted a state or transition from the FSM. Thanks in advance, Fernando pd: An intersesting side effect is that i can test low level mouse actions, such as drag and drop, hovering and unhovering, etc.., resulting in a more robust framework. pd: Soon i will release the framework, still working on make it render with Athens.

Jan. 23, 2012

Re: [Pharo-project] Ann: OmniBrowser stable for 1.4 with RB

by Benjamin

Strange, I just tested with the latest 1.4 Pharo (14294) and it works ... But if you want, there is a Jenkins build for Nautilus (https://ci.lille.inria.fr/pharo/job/Nautilus/) Enjoy, Ben On Jan 22, 2012, at 11:49 PM, Sven Van Caekenberghe wrote: > > On 22 Jan 2012, at 22:17, Sven Van Caekenberghe wrote: > >> And what about Nautilus, I want to try that too. >> What would be the best way to load it ? > > I tried: > > Gofer new > squeaksource: 'Nautilus'; > package: 'ConfigurationOfNautilus'; > load. > > ConfigurationOfNautilus loadDefault. > > Nautilus open > > gives RBClassEnvironment not found. > >

Jan. 22, 2012

[Pharo-project] [ANN] Spotlight like morph for pharo

by Esteban Lorenzano

Hi, I want to announce a little tool I made the other day (mainly because Mariano asked for it :) Do you remember algernon, that tool who was working in pharo 1.1 and is now obsolete? I used it all the time, and I always missed the ability to open browsers without having to type the class name in a workspace, or open a browser first, then look for the class. So, I created this: Gofer it squeaksource: 'Spotlight'; package: 'ConfigurationOfSpotlight'; load. ConfigurationOfSpotlight loadBleedingEdge. if you press shift+enter, you'll get a "spotlight" like morph, with a simple text input with OCompletion inside... is very simple and I think very useful. Of course it can be enhanced in a lot of ways... but let's here the community opinion first, and see if it worths to keep adding functionality.functionality. enjoy, Esteban ps: this is also an example of why I hate morphic so much (bah... current dirty implementation): I had to extend two classes just to change the editor used by a textmorph.... come on!!!!

Jan. 22, 2012