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