- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Host window events

by Igor Stasenko

2008/11/19 Gary Chambers <gazzaguru2(a)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.

Nov. 19, 2008

[Pharo-project] Re: [squeak-dev] Sparkle automatic update framework for Squeak OS-X

by Igor Stasenko

2008/11/19 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > With some funding help from Impara I built a plugin to enable the use of > Sparkle to receive update information about the macintosh carbon VM. > This lets you auto-update your Squeak based application by pushing update > notifications via rss to users. > Numerous one-click squeak based apps come to mind... > > Based on feedback and experience reports at some point I will consider if > this should be part of the mainstream Squeak Carbon VM. > > http://www.squeaksource.com/Sparkle.html > > Which contains the plugin source, the class based interface, and of course > SUnits. > > A 1.0.0 plugin can be found via the usual places in the experimental > directory as > SparklePlugin.1.0.0.bundle.zip > > http://www.smalltalkconsulting.com/squeak.html > That's very nice. Is there any analoguous frameworks for different platforms e.g. Windoze & Linux. I could help with making a windows port of it. There's a couple of things which regularily auto-update themselves on windoze: FireFox and Flash player. It would be nice to have it for squeak as well. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > -- Best regards, Igor Stasenko AKA sig.

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Gary Chambers

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(a)gmail.com> To: "Pharo Development" <pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Igor Stasenko

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.

Nov. 19, 2008

Re: [Pharo-project] OB package browser don't detects newpackages/updates a package list

by CÃ©drick BÃ©ler

>> You need to have your package defined as a Monticello package. Otherwise >> it's just a class cat, which is visible it the 'unpackaged' package of the >> package browser. Doesn't it depend on the composed category name ? For instance, with the package seaside if a class category of a new class is seaside-core then it goes to the seaside package ? >> Could you check if this is the case in your image? >> > > That's the problem, its not visible anywhere, even in 'unpackaged' package! > >> >> Cheers, >> David >> >>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Wednesday, November 19, 2008 2:56 PM >>> Subject: [Pharo-project] OB package browser don't detects >>> newpackages/updates a package list >>> >>> >>>> I filed out a package in one image, and then filed it in into a fresh >>>> one, which hasn't it before. >>>> I was little confused that brower can't see my package nor its sole >>>> class. >>>> Then i tried a system browser, to check what is going on , and found >>>> that my class is installed and sitting in image, while package browser >>>> pretends its not (it can't browse a class by its name, nor package). >>>> I forced it to appear only after adding package manually by issuing >>>> 'add package' in package pane menu. >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- CÃ©drick

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Gary Chambers

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(a)gmail.com> To: "Pharo Development" <pharo-project(a)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(a)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(a)gmail.com> >> To: "Pharo Development" <pharo-project(a)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(a)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(a)gmail.com> >>>> To: "Pharo Development" <pharo-project(a)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(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)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(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Igor Stasenko

2008/11/19 Gary Chambers <gazzaguru2(a)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(a)gmail.com> > To: "Pharo Development" <pharo-project(a)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(a)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(a)gmail.com> >>> To: "Pharo Development" <pharo-project(a)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(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Gary Chambers

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(a)gmail.com> To: "Pharo Development" <pharo-project(a)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(a)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(a)gmail.com> >> To: "Pharo Development" <pharo-project(a)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(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Igor Stasenko

2008/11/19 Gary Chambers <gazzaguru2(a)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(a)gmail.com> > To: "Pharo Development" <pharo-project(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 19, 2008

Re: [Pharo-project] Host window events

by Gary Chambers

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(a)gmail.com> To: "Pharo Development" <pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 19, 2008