November 2008 - Pharo-dev - lists.pharo.org

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

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

by Igor Stasenko

2008/11/19 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > >> If you filed it out/in rather than using MC to save/load then that's what >> I'd expect... > > Right, exactly. > 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. > 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.

Nov. 19, 2008

[Pharo-project] Host window events

by Igor Stasenko

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.

Nov. 19, 2008

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

by David RÃ¶thlisberger

> If you filed it out/in rather than using MC to save/load then that's > what I'd expect... Right, exactly. 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. Could you check if this is the case in your image? 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

Nov. 19, 2008