[Pharo-project] Host window events
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.
Looks like, for Morphic at least, you'll need to treat each host window as a separate World... Given that the worldState handles damaged rectangles etc. Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:06 PM Subject: [Pharo-project] Host window events
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/11/19 Gary Chambers <gazzaguru2@btinternet.com>:
Looks like, for Morphic at least, you'll need to treat each host window as a separate World... Given that the worldState handles damaged rectangles etc.
this is details.. first, i need to have a protocol plug-in a listeners/subscribers, like: hostWindow on: #resize do: [ ... ] or using hostWindow addDependant: subscriber (but dependants protocol can't differentiate the event type :( ) or something else. Any suggestions?
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:06 PM Subject: [Pharo-project] Host window events
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Depends on how you envisage linking morphs in a host window to a particular host window, rather than the "main" World... Assuming that morphs are created in a specific world that has a 1-1 relationship with a host window then the worldState of that world would probably be an appropriate responder to such events. Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:22 PM Subject: Re: [Pharo-project] Host window events
2008/11/19 Gary Chambers <gazzaguru2@btinternet.com>:
Looks like, for Morphic at least, you'll need to treat each host window as a separate World... Given that the worldState handles damaged rectangles etc.
this is details..
first, i need to have a protocol plug-in a listeners/subscribers, like:
hostWindow on: #resize do: [ ... ]
or using
hostWindow addDependant: subscriber (but dependants protocol can't differentiate the event type :( )
or something else. Any suggestions?
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:06 PM Subject: [Pharo-project] Host window events
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/11/19 Gary Chambers <gazzaguru2@btinternet.com>:
Depends on how you envisage linking morphs in a host window to a particular host window, rather than the "main" World...
Assuming that morphs are created in a specific world that has a 1-1 relationship with a host window then the worldState of that world would probably be an appropriate responder to such events.
That's fine. But its only in scope of Morphic. But i want to make a generic interface for HostWindows, which should not rely on any framework which may use them.
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:22 PM Subject: Re: [Pharo-project] Host window events
2008/11/19 Gary Chambers <gazzaguru2@btinternet.com>:
Looks like, for Morphic at least, you'll need to treat each host window as a separate World... Given that the worldState handles damaged rectangles etc.
this is details..
first, i need to have a protocol plug-in a listeners/subscribers, like:
hostWindow on: #resize do: [ ... ]
or using
hostWindow addDependant: subscriber (but dependants protocol can't differentiate the event type :( )
or something else. Any suggestions?
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:06 PM Subject: [Pharo-project] Host window events
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Indeed... carry on with the event mechanism and for Morphic make some separate decisions. As long as the events are sufficient and complete I don't envisiage any problems. Reagards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:40 PM Subject: Re: [Pharo-project] Host window events
2008/11/19 Gary Chambers <gazzaguru2@btinternet.com>:
Depends on how you envisage linking morphs in a host window to a particular host window, rather than the "main" World...
Assuming that morphs are created in a specific world that has a 1-1 relationship with a host window then the worldState of that world would probably be an appropriate responder to such events.
That's fine. But its only in scope of Morphic. But i want to make a generic interface for HostWindows, which should not rely on any framework which may use them.
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:22 PM Subject: Re: [Pharo-project] Host window events
2008/11/19 Gary Chambers <gazzaguru2@btinternet.com>:
Looks like, for Morphic at least, you'll need to treat each host window as a separate World... Given that the worldState handles damaged rectangles etc.
this is details..
first, i need to have a protocol plug-in a listeners/subscribers, like:
hostWindow on: #resize do: [ ... ]
or using
hostWindow addDependant: subscriber (but dependants protocol can't differentiate the event type :( )
or something else. Any suggestions?
Regards, Gary.
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:06 PM Subject: [Pharo-project] Host window events
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.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
My vision, how things should happen , is following: EventSensor checks an event type in it's newly acqured raw event buffer from VM. Then it dispatching an event handling in following way: eventClass := (eventTypes at: (rawEvent at: EventType "1"). event := (eventClass from: rawEvent). "Translate raw event into nice XXXXEvent instance" event handle. "dispatch event" Now, if event type is window event, eventClass would be, lets say HostWindowEvent. And in #handle it does following: hostWindow := self window. hostWindow subscriber handle: self. Here the main question, should HostWindow have a notion of subscriber(s) (as part of its state), or maybe there should be more generic way to wire a subscriber(s) with particular HostWindow instance, but without need in managing subscribers by HostWindow itself.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
It seems, for Morphic, a world is the best mapping to a host window (would subscribe to relevant events). Sadly, a lot of Morphic relies on the "main" world, still, worth investigating. Certainly a *lot* more work to map a SystemWindow to a host window for a general case. As far a Polymorph goes, I'd be happy to adapt to whatever scheme you decide :-) Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 4:52 PM Subject: Re: [Pharo-project] Host window events
My vision, how things should happen , is following:
EventSensor checks an event type in it's newly acqured raw event buffer from VM. Then it dispatching an event handling in following way:
eventClass := (eventTypes at: (rawEvent at: EventType "1"). event := (eventClass from: rawEvent). "Translate raw event into nice XXXXEvent instance" event handle. "dispatch event"
Now, if event type is window event, eventClass would be, lets say HostWindowEvent. And in #handle it does following:
hostWindow := self window. hostWindow subscriber handle: self.
Here the main question, should HostWindow have a notion of subscriber(s) (as part of its state), or maybe there should be more generic way to wire a subscriber(s) with particular HostWindow instance, but without need in managing subscribers by HostWindow itself.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2008/11/19 Gary Chambers <gazzaguru2@btinternet.com>:
It seems, for Morphic, a world is the best mapping to a host window (would subscribe to relevant events).
Sadly, a lot of Morphic relies on the "main" world, still, worth investigating. Certainly a *lot* more work to map a SystemWindow to a host window for a general case.
Yeah, just yesterday, i thought about things like #openInNewHostWindow instead of #openInWorld, but that's really will be tough task :) I'm currently focused on low-level things.
As far a Polymorph goes, I'd be happy to adapt to whatever scheme you decide :-)
How cruel you are! :) Okay, i'll try to make it in own way and then put it on the desk for people's overview.
Regards, Gary.
-- Best regards, Igor Stasenko AKA sig.
Lol. Do a clean job from your perspective... the evil morphs will adapt and be assimilated. Resistance is futile! Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, November 19, 2008 5:17 PM Subject: Re: [Pharo-project] Host window events
2008/11/19 Gary Chambers <gazzaguru2@btinternet.com>:
It seems, for Morphic, a world is the best mapping to a host window (would subscribe to relevant events).
Sadly, a lot of Morphic relies on the "main" world, still, worth investigating. Certainly a *lot* more work to map a SystemWindow to a host window for a general case.
Yeah, just yesterday, i thought about things like #openInNewHostWindow instead of #openInWorld, but that's really will be tough task :) I'm currently focused on low-level things.
As far a Polymorph goes, I'd be happy to adapt to whatever scheme you decide :-)
How cruel you are! :) Okay, i'll try to make it in own way and then put it on the desk for people's overview.
Regards, Gary.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi all, I have just taken the last image of pharo-dev: "pharo0.1-10160dev08.11.5.zip" When I run it, I have a window opened: "Reading a stream", which use all my CPU and pharo is not usable. Can anyone help me? Jannik
On Thu, Nov 20, 2008 at 10:01 AM, jannik.laval.gmail <jannik.laval@gmail.com> wrote:
Hi all,
I have just taken the last image of pharo-dev: "pharo0.1-10160dev08.11.5.zip" When I run it, I have a window opened: "Reading a stream", which use all my CPU and pharo is not usable. Can anyone help me?
You are not alone :-). Please use version 08.11.3 which works well. -- Damien Cassou http://damiencassou.seasidehosting.st
Ok thanks Damien, jannik Le 20 nov. 08 à 11:10, Damien Cassou a écrit :
On Thu, Nov 20, 2008 at 10:01 AM, jannik.laval.gmail <jannik.laval@gmail.com> wrote:
Hi all,
I have just taken the last image of pharo-dev: "pharo0.1-10160dev08.11.5.zip" When I run it, I have a window opened: "Reading a stream", which use all my CPU and pharo is not usable. Can anyone help me?
You are not alone :-). Please use version 08.11.3 which works well.
-- Damien Cassou http://damiencassou.seasidehosting.st
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Nov 20, 2008 at 10:01 AM, jannik.laval.gmail <jannik.laval@gmail.com> wrote:
I have just taken the last image of pharo-dev: "pharo0.1-10160dev08.11.5.zip" When I run it, I have a window opened: "Reading a stream", which use all my CPU and pharo is not usable. Can anyone help me?
Download the latest version: http://gforge.inria.fr/frs/download.php/11507/pharo0.1-10166dev08.11.6.zip -- Damien Cassou http://damiencassou.seasidehosting.st
participants (4)
-
Damien Cassou -
Gary Chambers -
Igor Stasenko -
jannik.laval.gmail