On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: > That is one option, though it does seem to be burdensome on the announcement > consumers to (depending upon requirements) possibly have to track all > windows themselves. > > Regards, GaryI am not talking about Announcers, but where the Announcement is created. I'm not talking about letting the window be the announcer, but where the announcement is made. So you'd do openAsIsIn: aWorld "current implementation" someAnnouncer announce: (WindowOpened for: self in: self world) someAnnouncer could be a global announcer for all window events. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Gary Chambers-4
Gary,
If announcements are at all what I am expecting (perhaps a non-trivial assumption??), then I doubt it will be a problem. One would observe the world/window-manager for open events, and then express interest in events from individual windows. That might turn out to be easier on consumers than getting everything from one source. Cleanup should be trivial if the announcement framework uses weak references. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Chambers Sent: Thursday, January 07, 2010 8:10 AM To: [hidden email] Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus That is one option, though it does seem to be burdensome on the announcement consumers to (depending upon requirements) possibly have to track all windows themselves. Regards, Gary ----- Original Message ----- From: "Simon Denier" <[hidden email]> To: <[hidden email]> Sent: Thursday, January 07, 2010 12:47 PM Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus > > On 7 janv. 2010, at 12:49, Gary Chambers wrote: > >> I think the annnouncements should be sent by the World (being, >> effectively, >> the window manager). > > One problem is that World is an instance of PasteUpMorph. If we modify > this class, what happens to potential other instances? > By default in my Pharo image, it seems that World is the only instance of > PasteUpMorph. > >> Too many ways to open open a window exist and only the fact of being >> added >> to the World seems consistent. >> I suggest opened, closed, activated (becoming topmost-ish), deactivated, >> expanded, collapsed, restored and maybe repositioned/resized would be >> useful. > > > Do you mean that such announcements should be performed by World? Because > most are already done by windows themselves with the patch of Alex. > As I said, the only one really necessary in World is window opened, so > that listeners subscribed to World are notifited of windows opened in > World and can subscribe to them. > > By the way Alex, is there a squeaksource project with your extensions as > regular methods and classes (not in a changeset)? > > >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Henrik Sperre Johansen" <[hidden email]> >> To: <[hidden email]> >> Sent: Wednesday, January 06, 2010 9:53 PM >> Subject: Re: [Pharo-project] Notifications of windows >> opening/closing/focus >> >> >>> On 06.01.2010 22:36, Simon Denier wrote: >>>> On 6 janv. 2010, at 18:42, Gary Chambers wrote: >>>> >>>> >>>>> Indeed. Would be nicer if there was a proper announcement protocol for >>>>> such >>>>> things though. >>>>> >>>> I see, updateTasks is called everytime a change in layout happens then. >>>> Indeed, it looks like announcements will greatly simplified the trick. >>>> >>>> I am not sure where to do the announcement though. Does any top window >>>> uses openInWorld to add itself to World? >>>> >>>> >>> My guess would be that at the end of >>> SystemWindow>> openAsIsIn: >>> would be the the simplest place to put it. >>> >>> Cheers, >>> Henry >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Henrik Sperre Johansen
NVM this, I only read the top and thought it was in reply to my last mail, not Simons :)
On Jan 7, 2010, at 2:28 31PM, Henrik Johansen wrote: > > On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: > >> That is one option, though it does seem to be burdensome on the announcement >> consumers to (depending upon requirements) possibly have to track all >> windows themselves. >> >> Regards, GaryI am not talking about Announcers, but where the Announcement is created. > > I'm not talking about letting the window be the announcer, but where the announcement is made. > > So you'd do > openAsIsIn: aWorld > "current implementation" > someAnnouncer announce: (WindowOpened for: self in: self world) > > someAnnouncer could be a global announcer for all window events. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Henrik Sperre Johansen
Fair enough. Perhaps the "global" announcer could be accessed via the
class-side of SystemWindow. Lots of evil ways of manipulating morphs too. Just thought about hide/show etc. Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <[hidden email]> To: <[hidden email]> Sent: Thursday, January 07, 2010 1:28 PM Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus > > On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: > >> That is one option, though it does seem to be burdensome on the >> announcement >> consumers to (depending upon requirements) possibly have to track all >> windows themselves. >> >> Regards, GaryI am not talking about Announcers, but where the >> Announcement is created. > > I'm not talking about letting the window be the announcer, but where the > announcement is made. > > So you'd do > openAsIsIn: aWorld > "current implementation" > someAnnouncer announce: (WindowOpened for: self in: self world) > > someAnnouncer could be a global announcer for all window events. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Simon Denier-3
> By the way Alex, is there a squeaksource project with your
> extensions as regular methods and classes (not in a changeset)? Not yet. But a monticello package would be a bit ugly since: - it adds a variable to SystemWindow - it performs some overrides in ScrollPane and SystemWindow Creating a clean Monticello package is not easy. Cheers, Alexandre > > >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Henrik Sperre Johansen" <[hidden email]> >> To: <[hidden email]> >> Sent: Wednesday, January 06, 2010 9:53 PM >> Subject: Re: [Pharo-project] Notifications of windows opening/ >> closing/focus >> >> >>> On 06.01.2010 22:36, Simon Denier wrote: >>>> On 6 janv. 2010, at 18:42, Gary Chambers wrote: >>>> >>>> >>>>> Indeed. Would be nicer if there was a proper announcement >>>>> protocol for >>>>> such >>>>> things though. >>>>> >>>> I see, updateTasks is called everytime a change in layout happens >>>> then. >>>> Indeed, it looks like announcements will greatly simplified the >>>> trick. >>>> >>>> I am not sure where to do the announcement though. Does any top >>>> window >>>> uses openInWorld to add itself to World? >>>> >>>> >>> My guess would be that at the end of >>> SystemWindow>> openAsIsIn: >>> would be the the simplest place to put it. >>> >>> Cheers, >>> Henry >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Gary Chambers-4
Hi!
In the PharoTaskForces SqueakSource repository I committed a new version of Morphic (Morphic-Alexandre_Bergel.393). This version includes the window announcement I have been working on for few months already. Here is an example of a unit test. -=-=-=-=-=-=-=-=-=-=-=-= MorphicWindowNotificationTest>>testWindowCreationAndDeletion | t window newWindowCreated r | t := 0. World announcer on: MorphicCreationWindowAnnouncement do: [:ann | t := t + 1. newWindowCreated := ann window]. World announcer on: MorphicClosingWindowAnnouncement do: [:ann | t := t + 10. newWindowCreated := ann window]. window := SystemWindow labelled: 'foo'. window openInWorld. self assert: (t = 1). self assert: (window == newWindowCreated). window delete. self assert: (t = 11). self assert: (window == newWindowCreated). -=-=-=-=-=-=-=-=-=-=-=-= If everybody agrees on this, it would be cool to include it in Pharo soon. At each new version of Morphic, I will have to update this, and this is boring. The comment of the .mcz is -=-=-=-=-=-=-=-=-=-=-=-= This new version extends Morphic with a window event mechanism. It add a variables to SystemWindow (thus implies a recompilation of all subclasses of SystemWindow). It does some overrides in: - SystemWindow: for deletion, resize, ... - ScrollPane: notification for scrolling. This part is probably not nicely designed, but it works - PasteUpMorph: World can now emit event for window creation and deletion The method SystemWindow>>openAsIsIn: is overriden. The new version belongs to Morphic, before it belonged to Polymorph. Loading this version make Polymorph dirty therefore. 5 test methods are provided in MorphicWindowNotificationTest. All tests are green in a pharo1.0-10502-rc1dev09.12.2 -=-=-=-=-=-=-=-=-=-=-=-= Comments are welcome Cheers, Alexandre On 7 Jan 2010, at 10:58, Gary Chambers wrote: > Fair enough. Perhaps the "global" announcer could be accessed via the > class-side of SystemWindow. > > Lots of evil ways of manipulating morphs too. Just thought about > hide/show > etc. > > Regards, Gary > > ----- Original Message ----- > From: "Henrik Johansen" <[hidden email]> > To: <[hidden email]> > Sent: Thursday, January 07, 2010 1:28 PM > Subject: Re: [Pharo-project] Notifications of windows opening/ > closing/focus > > >> >> On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: >> >>> That is one option, though it does seem to be burdensome on the >>> announcement >>> consumers to (depending upon requirements) possibly have to track >>> all >>> windows themselves. >>> >>> Regards, GaryI am not talking about Announcers, but where the >>> Announcement is created. >> >> I'm not talking about letting the window be the announcer, but >> where the >> announcement is made. >> >> So you'd do >> openAsIsIn: aWorld >> "current implementation" >> someAnnouncer announce: (WindowOpened for: self in: self world) >> >> someAnnouncer could be a global announcer for all window events. >> >> Cheers, >> Henry >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
> Hi! > > In the PharoTaskForces SqueakSource repository I committed a new > version of Morphic (Morphic-Alexandre_Bergel.393). This version > includes the window announcement I have been working on for few months > already. > > Here is an example of a unit test. > -=-=-=-=-=-=-=-=-=-=-=-= > MorphicWindowNotificationTest>>testWindowCreationAndDeletion > > | t window newWindowCreated r | > t := 0. > World announcer on: MorphicCreationWindowAnnouncement do: [:ann | > t := t + 1. newWindowCreated := ann window]. > World announcer on: MorphicClosingWindowAnnouncement do: [:ann | t := > t + 10. newWindowCreated := ann window]. > window := SystemWindow labelled: 'foo'. > window openInWorld. > > self assert: (t = 1). > self assert: (window == newWindowCreated). > window delete. > > self assert: (t = 11). > self assert: (window == newWindowCreated). > -=-=-=-=-=-=-=-=-=-=-=-= > If everybody agrees on this, it would be cool to include it in Pharo > soon. At each new version of Morphic, I will have to update this, and > this is boring. Yes I would be happy. I did not want to push this change because I could not assess the impact in term of slowdown. Now if we get an ok from gary and/or others this is ok for me. > > The comment of the .mcz is > -=-=-=-=-=-=-=-=-=-=-=-= > This new version extends Morphic with a window event mechanism. > It add a variables to SystemWindow (thus implies a recompilation of > all subclasses of SystemWindow). > It does some overrides in: > - SystemWindow: for deletion, resize, ... > - ScrollPane: notification for scrolling. This part is probably not > nicely designed, but it works what is the increment of notification because it can geenrate a lot of events? > - PasteUpMorph: World can now emit event for window creation and > deletion > > The method SystemWindow>>openAsIsIn: is overriden. The new version > belongs to Morphic, before it belonged to Polymorph. Loading this > version make Polymorph dirty therefore. > > 5 test methods are provided in MorphicWindowNotificationTest. All > tests are green in a pharo1.0-10502-rc1dev09.12.2 > -=-=-=-=-=-=-=-=-=-=-=-= > > Comments are welcome > > Cheers, > Alexandre > > > On 7 Jan 2010, at 10:58, Gary Chambers wrote: > >> Fair enough. Perhaps the "global" announcer could be accessed via the >> class-side of SystemWindow. >> >> Lots of evil ways of manipulating morphs too. Just thought about >> hide/show >> etc. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Henrik Johansen" <[hidden email]> >> To: <[hidden email]> >> Sent: Thursday, January 07, 2010 1:28 PM >> Subject: Re: [Pharo-project] Notifications of windows opening/ >> closing/focus >> >> >>> >>> On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: >>> >>>> That is one option, though it does seem to be burdensome on the >>>> announcement >>>> consumers to (depending upon requirements) possibly have to track >>>> all >>>> windows themselves. >>>> >>>> Regards, GaryI am not talking about Announcers, but where the >>>> Announcement is created. >>> >>> I'm not talking about letting the window be the announcer, but >>> where the >>> announcement is made. >>> >>> So you'd do >>> openAsIsIn: aWorld >>> "current implementation" >>> someAnnouncer announce: (WindowOpened for: self in: self world) >>> >>> someAnnouncer could be a global announcer for all window events. >>> >>> Cheers, >>> Henry >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
>> If everybody agrees on this, it would be cool to include it in Pharo
>> soon. At each new version of Morphic, I will have to update this, and >> this is boring. > > Yes I would be happy. I did not want to push this change because I > could not assess > the impact in term of slowdown. Now if we get an ok from gary and/or > others > this is ok for me. I understand this. You're right on this. I simply did not have the time and pressure from users to push it. >> It does some overrides in: >> - SystemWindow: for deletion, resize, ... >> - ScrollPane: notification for scrolling. This part is probably not >> nicely designed, but it works > > what is the increment of notification because it can geenrate a lot > of events? there is no notification if there is no subscription. Alexandre > >> - PasteUpMorph: World can now emit event for window creation and >> deletion >> >> The method SystemWindow>>openAsIsIn: is overriden. The new version >> belongs to Morphic, before it belonged to Polymorph. Loading this >> version make Polymorph dirty therefore. >> >> 5 test methods are provided in MorphicWindowNotificationTest. All >> tests are green in a pharo1.0-10502-rc1dev09.12.2 >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Comments are welcome >> >> Cheers, >> Alexandre >> >> >> On 7 Jan 2010, at 10:58, Gary Chambers wrote: >> >>> Fair enough. Perhaps the "global" announcer could be accessed via >>> the >>> class-side of SystemWindow. >>> >>> Lots of evil ways of manipulating morphs too. Just thought about >>> hide/show >>> etc. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Henrik Johansen" <[hidden email]> >>> To: <[hidden email]> >>> Sent: Thursday, January 07, 2010 1:28 PM >>> Subject: Re: [Pharo-project] Notifications of windows opening/ >>> closing/focus >>> >>> >>>> >>>> On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: >>>> >>>>> That is one option, though it does seem to be burdensome on the >>>>> announcement >>>>> consumers to (depending upon requirements) possibly have to track >>>>> all >>>>> windows themselves. >>>>> >>>>> Regards, GaryI am not talking about Announcers, but where the >>>>> Announcement is created. >>>> >>>> I'm not talking about letting the window be the announcer, but >>>> where the >>>> announcement is made. >>>> >>>> So you'd do >>>> openAsIsIn: aWorld >>>> "current implementation" >>>> someAnnouncer announce: (WindowOpened for: self in: self world) >>>> >>>> someAnnouncer could be a global announcer for all window events. >>>> >>>> Cheers, >>>> Henry >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Schwab,Wilhelm K
On 07.01.2010 14:50, Schwab,Wilhelm K wrote:
> Gary, > > If announcements are at all what I am expecting (perhaps a non-trivial assumption??), then I doubt it will be a problem. One would observe the world/window-manager for open events, and then express interest in events from individual windows. That might turn out to be easier on consumers than getting everything from one source. Cleanup should be trivial if the announcement framework uses weak references. > > Bill > The Pharo implementation does not include weak announcement subscriptions, you have to manually unsubscribe if you need to. This can be solved in VisualWorks without keeping a list of whom you are subscribed to, by using the fact that the block in subscribe:do: can take 2 args instead of one, in which case the second argument is the announcer. If this were the case in the Pharo/Squeak implementation, the Global WindowOpened/Local InterestingWindowEvents could be written: (receiveAnnouncements to true in initialize, false in release) SystemWindow openAnnouncer subscribe: WindowOpened do: [:ann : | ann window satisfiesMyCriteria ifTrue: [ ann window subscribe: InterestingWindowEvent do: [:ann :announcer | receiveAnnouncements ifTrue: [self handleInterestingEvent: ann] ifFalse: [announcer unsubscribe: self]] Not very pretty, but still better than the alternative if you know the dynamic announcer is likely to outlive the consumer. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
One should always be *able* to unsubscribe, but it should not be required.
Squeak's weak collections do not measure up to the competition. Please take a look at my 1/2/2010 post "RE: [Pharo-project] Can't debug in 1.1". I doubt SharedLookupTable could be called efficient, but it solved some problems I was having due to the current implementation. I welcome concrete examples of how horrible it is, and offer it up as a starting point or simple inspiration for something more useful. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Sperre Johansen Sent: Thursday, January 07, 2010 6:57 PM To: [hidden email] Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus On 07.01.2010 14:50, Schwab,Wilhelm K wrote: > Gary, > > If announcements are at all what I am expecting (perhaps a non-trivial assumption??), then I doubt it will be a problem. One would observe the world/window-manager for open events, and then express interest in events from individual windows. That might turn out to be easier on consumers than getting everything from one source. Cleanup should be trivial if the announcement framework uses weak references. > > Bill > The Pharo implementation does not include weak announcement subscriptions, you have to manually unsubscribe if you need to. This can be solved in VisualWorks without keeping a list of whom you are subscribed to, by using the fact that the block in subscribe:do: can take 2 args instead of one, in which case the second argument is the announcer. If this were the case in the Pharo/Squeak implementation, the Global WindowOpened/Local InterestingWindowEvents could be written: (receiveAnnouncements to true in initialize, false in release) SystemWindow openAnnouncer subscribe: WindowOpened do: [:ann : | ann window satisfiesMyCriteria ifTrue: [ ann window subscribe: InterestingWindowEvent do: [:ann :announcer | receiveAnnouncements ifTrue: [self handleInterestingEvent: ann] ifFalse: [announcer unsubscribe: self]] Not very pretty, but still better than the alternative if you know the dynamic announcer is likely to outlive the consumer. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On 08.01.2010 01:32, Schwab,Wilhelm K wrote:
> One should always be *able* to unsubscribe, but it should not be required. > > Squeak's weak collections do not measure up to the competition. Please take a look at my 1/2/2010 post "RE: [Pharo-project] Can't debug in 1.1". I doubt SharedLookupTable could be called efficient, but it solved some problems I was having due to the current implementation. I welcome concrete examples of how horrible it is, and offer it up as a starting point or simple inspiration for something more useful. > > Bill > I guess I should have quoted Gary's question of whether the approach would be hard to unregister instead. Originally, I (like you) thought not. After actually looking at the implementation, I do. What I posted is one way to "solve" this, weak subscriptions is another. On a scale of "what's harder to get right", I'd bet there's a larger chance of having 2 arg blocks implemented first. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Henry,
No argument, your solution is simpler. However, we do not have announcements like this now, and it appears that the poor state of weak collections in Squeak/Pharo is standing in the way of a clean implementation. My vote is to tackle the weaklings, at least until they work well enough to support what we should have in this case. Otherwise, we kick the weak can down the road as has been done all along rather than fixing it, AND we end up with a sub-standard announcments-based framework. Let's do it right. We will then have an evolving/improving weak collection and something in the image that puts some stress on same. If I'm missing something, please enlighten me. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Sperre Johansen Sent: Thursday, January 07, 2010 7:45 PM To: [hidden email] Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus On 08.01.2010 01:32, Schwab,Wilhelm K wrote: > One should always be *able* to unsubscribe, but it should not be required. > > Squeak's weak collections do not measure up to the competition. Please take a look at my 1/2/2010 post "RE: [Pharo-project] Can't debug in 1.1". I doubt SharedLookupTable could be called efficient, but it solved some problems I was having due to the current implementation. I welcome concrete examples of how horrible it is, and offer it up as a starting point or simple inspiration for something more useful. > > Bill > I guess I should have quoted Gary's question of whether the approach would be hard to unregister instead. Originally, I (like you) thought not. After actually looking at the implementation, I do. What I posted is one way to "solve" this, weak subscriptions is another. On a scale of "what's harder to get right", I'd bet there's a larger chance of having 2 arg blocks implemented first. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Henrik Sperre Johansen
On Fri, 8 Jan 2010, Henrik Sperre Johansen wrote:
> On 08.01.2010 01:32, Schwab,Wilhelm K wrote: >> One should always be *able* to unsubscribe, but it should not be required. >> >> Squeak's weak collections do not measure up to the competition. Please take a look at my 1/2/2010 post "RE: [Pharo-project] Can't debug in 1.1". I doubt SharedLookupTable could be called efficient, but it solved some problems I was having due to the current implementation. I welcome concrete examples of how horrible it is, and offer it up as a starting point or simple inspiration for something more useful. >> >> Bill >> > I guess I should have quoted Gary's question of whether the approach > would be hard to unregister instead. > Originally, I (like you) thought not. > After actually looking at the implementation, I do. > > What I posted is one way to "solve" this, weak subscriptions is another. > On a scale of "what's harder to get right", I'd bet there's a larger > chance of having 2 arg blocks implemented first. I think there won't be 2 argument blocks, because that would make the current minimal implementation more complex or slower. (AXAnnouncements have this feature btw.) Levente > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Schwab,Wilhelm K
On 08.01.2010 02:07, Schwab,Wilhelm K wrote:
> Henry, > > No argument, your solution is simpler. However, we do not have announcements like this now, and it appears that the poor state of weak collections in Squeak/Pharo is standing in the way of a clean implementation. My vote is to tackle the weaklings, at least until they work well enough to support what we should have in this case. Otherwise, we kick the weak can down the road as has been done all along rather than fixing it, AND we end up with a sub-standard announcments-based framework. > > Let's do it right. We will then have an evolving/improving weak collection and something in the image that puts some stress on same. If I'm missing something, please enlighten me. > > Bill > Weak collections does not stand in the way of making the use case of unregistering dynamic registrations manually easier. They stand in the way of the use case of unregistrating registeration automatically. Here's what you're missing: No matter how you implement the automatic unregistering, it will be nondetermenistic, for the exact same reasons finalization is nondeterministic. Thus, if you require deterministic unregistration, you have to do it manually, and the use case of making that easier to do have value in its own right. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Henry,
Then we need to fix the weak collections. Dolphin (of the mid-90's) already had thread-safe weak collections and a high-priority process to detect and clean up "damage" to them; it's time to catch up. The more I think about it, your idea is sounding a lot like the dependency days of MVC - remember #release? I'm trying to forget. I am not trying to be confrontational, but we can and should do better than this. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Sperre Johansen Sent: Thursday, January 07, 2010 8:27 PM To: [hidden email] Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus On 08.01.2010 02:07, Schwab,Wilhelm K wrote: > Henry, > > No argument, your solution is simpler. However, we do not have announcements like this now, and it appears that the poor state of weak collections in Squeak/Pharo is standing in the way of a clean implementation. My vote is to tackle the weaklings, at least until they work well enough to support what we should have in this case. Otherwise, we kick the weak can down the road as has been done all along rather than fixing it, AND we end up with a sub-standard announcments-based framework. > > Let's do it right. We will then have an evolving/improving weak collection and something in the image that puts some stress on same. If I'm missing something, please enlighten me. > > Bill > Weak collections does not stand in the way of making the use case of unregistering dynamic registrations manually easier. They stand in the way of the use case of unregistrating registeration automatically. Here's what you're missing: No matter how you implement the automatic unregistering, it will be nondetermenistic, for the exact same reasons finalization is nondeterministic. Thus, if you require deterministic unregistration, you have to do it manually, and the use case of making that easier to do have value in its own right. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Build something and propose it.
Continue to discuss and get a group of people working on the solution. Good solution should emerge but code is important. Stef > Henry, > > Then we need to fix the weak collections. Dolphin (of the mid-90's) already had thread-safe weak collections and a high-priority process to detect and clean up "damage" to them; it's time to catch up. > > The more I think about it, your idea is sounding a lot like the dependency days of MVC - remember #release? I'm trying to forget. > > I am not trying to be confrontational, but we can and should do better than this. > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Henrik Sperre Johansen > Sent: Thursday, January 07, 2010 8:27 PM > To: [hidden email] > Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus > > On 08.01.2010 02:07, Schwab,Wilhelm K wrote: >> Henry, >> >> No argument, your solution is simpler. However, we do not have announcements like this now, and it appears that the poor state of weak collections in Squeak/Pharo is standing in the way of a clean implementation. My vote is to tackle the weaklings, at least until they work well enough to support what we should have in this case. Otherwise, we kick the weak can down the road as has been done all along rather than fixing it, AND we end up with a sub-standard announcments-based framework. >> >> Let's do it right. We will then have an evolving/improving weak collection and something in the image that puts some stress on same. If I'm missing something, please enlighten me. >> >> Bill >> > Weak collections does not stand in the way of making the use case of unregistering dynamic registrations manually easier. > They stand in the way of the use case of unregistrating registeration automatically. > > Here's what you're missing: > No matter how you implement the automatic unregistering, it will be nondetermenistic, for the exact same reasons finalization is nondeterministic. > Thus, if you require deterministic unregistration, you have to do it manually, and the use case of making that easier to do have value in its own right. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stéphane Ducasse
Looks ok to me.
Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <[hidden email]> To: <[hidden email]> Sent: Thursday, January 07, 2010 8:27 PM Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus > >> Hi! >> >> In the PharoTaskForces SqueakSource repository I committed a new >> version of Morphic (Morphic-Alexandre_Bergel.393). This version >> includes the window announcement I have been working on for few months >> already. >> >> Here is an example of a unit test. >> -=-=-=-=-=-=-=-=-=-=-=-= >> MorphicWindowNotificationTest>>testWindowCreationAndDeletion >> >> | t window newWindowCreated r | >> t := 0. >> World announcer on: MorphicCreationWindowAnnouncement do: [:ann | >> t := t + 1. newWindowCreated := ann window]. >> World announcer on: MorphicClosingWindowAnnouncement do: [:ann | t := >> t + 10. newWindowCreated := ann window]. >> window := SystemWindow labelled: 'foo'. >> window openInWorld. >> >> self assert: (t = 1). >> self assert: (window == newWindowCreated). >> window delete. >> >> self assert: (t = 11). >> self assert: (window == newWindowCreated). >> -=-=-=-=-=-=-=-=-=-=-=-= >> If everybody agrees on this, it would be cool to include it in Pharo >> soon. At each new version of Morphic, I will have to update this, and >> this is boring. > > Yes I would be happy. I did not want to push this change because I could > not assess > the impact in term of slowdown. Now if we get an ok from gary and/or > others > this is ok for me. > >> >> The comment of the .mcz is >> -=-=-=-=-=-=-=-=-=-=-=-= >> This new version extends Morphic with a window event mechanism. >> It add a variables to SystemWindow (thus implies a recompilation of >> all subclasses of SystemWindow). >> It does some overrides in: >> - SystemWindow: for deletion, resize, ... >> - ScrollPane: notification for scrolling. This part is probably not >> nicely designed, but it works > > what is the increment of notification because it can geenrate a lot of > events? > >> - PasteUpMorph: World can now emit event for window creation and >> deletion >> >> The method SystemWindow>>openAsIsIn: is overriden. The new version >> belongs to Morphic, before it belonged to Polymorph. Loading this >> version make Polymorph dirty therefore. >> >> 5 test methods are provided in MorphicWindowNotificationTest. All >> tests are green in a pharo1.0-10502-rc1dev09.12.2 >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Comments are welcome >> >> Cheers, >> Alexandre >> >> >> On 7 Jan 2010, at 10:58, Gary Chambers wrote: >> >>> Fair enough. Perhaps the "global" announcer could be accessed via the >>> class-side of SystemWindow. >>> >>> Lots of evil ways of manipulating morphs too. Just thought about >>> hide/show >>> etc. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Henrik Johansen" <[hidden email]> >>> To: <[hidden email]> >>> Sent: Thursday, January 07, 2010 1:28 PM >>> Subject: Re: [Pharo-project] Notifications of windows opening/ >>> closing/focus >>> >>> >>>> >>>> On Jan 7, 2010, at 2:10 04PM, Gary Chambers wrote: >>>> >>>>> That is one option, though it does seem to be burdensome on the >>>>> announcement >>>>> consumers to (depending upon requirements) possibly have to track >>>>> all >>>>> windows themselves. >>>>> >>>>> Regards, GaryI am not talking about Announcers, but where the >>>>> Announcement is created. >>>> >>>> I'm not talking about letting the window be the announcer, but >>>> where the >>>> announcement is made. >>>> >>>> So you'd do >>>> openAsIsIn: aWorld >>>> "current implementation" >>>> someAnnouncer announce: (WindowOpened for: self in: self world) >>>> >>>> someAnnouncer could be a global announcer for all window events. >>>> >>>> Cheers, >>>> Henry >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Jan 8, 2010, at 11:56 18AM, Gary Chambers wrote:
> Looks ok to me. > > Regards, Gary > > ----- Original Message ----- > From: "Stéphane Ducasse" <[hidden email]> > To: <[hidden email]> > Sent: Thursday, January 07, 2010 8:27 PM > Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus > > >> >>> Hi! >>> >>> In the PharoTaskForces SqueakSource repository I committed a new >>> version of Morphic (Morphic-Alexandre_Bergel.393). This version >>> includes the window announcement I have been working on for few months >>> already. >>> >>> Here is an example of a unit test. >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> MorphicWindowNotificationTest>>testWindowCreationAndDeletion >>> >>> | t window newWindowCreated r | >>> t := 0. >>> World announcer on: MorphicCreationWindowAnnouncement do: [:ann | >>> t := t + 1. newWindowCreated := ann window]. >>> World announcer on: MorphicClosingWindowAnnouncement do: [:ann | t := >>> t + 10. newWindowCreated := ann window]. - Why including Announcement at the end? - Why does one contain a verb, and the other a - When are they fired? Closing implies to me it's not been closed yet, but fired somewhere after the closing has started, while CreationWindow I have no idea what means. MorphicWindowOpen(ed/ing) MorphicWindowClos(ed/ing) are both easier to read for me, shorter, and more in line with the naming convention for Pragma announcements already in Pharo. Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Thanks for your comments.
I renamed the announcement accordingly to your comments. I attached a screenshot of the new hierarchy Better? Alexandre On 8 Jan 2010, at 08:57, Henrik Johansen wrote: > On Jan 8, 2010, at 11:56 18AM, Gary Chambers wrote: > >> Looks ok to me. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Stéphane Ducasse" <[hidden email]> >> To: <[hidden email]> >> Sent: Thursday, January 07, 2010 8:27 PM >> Subject: Re: [Pharo-project] Notifications of windows opening/ >> closing/focus >> >> >>> >>>> Hi! >>>> >>>> In the PharoTaskForces SqueakSource repository I committed a new >>>> version of Morphic (Morphic-Alexandre_Bergel.393). This version >>>> includes the window announcement I have been working on for few >>>> months >>>> already. >>>> >>>> Here is an example of a unit test. >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> MorphicWindowNotificationTest>>testWindowCreationAndDeletion >>>> >>>> | t window newWindowCreated r | >>>> t := 0. >>>> World announcer on: MorphicCreationWindowAnnouncement do: [:ann | >>>> t := t + 1. newWindowCreated := ann window]. >>>> World announcer on: MorphicClosingWindowAnnouncement do: [:ann | >>>> t := >>>> t + 10. newWindowCreated := ann window]. > I don't particularly like the naming. > > - Why including Announcement at the end? > - Why does one contain a verb, and the other a > - When are they fired? Closing implies to me it's not been closed > yet, but fired somewhere after the closing has started, while > CreationWindow I have no idea what means. > > MorphicWindowOpen(ed/ing) > MorphicWindowClos(ed/ing) > > are both easier to read for me, shorter, and more in line with the > naming convention for Pragma announcements already in Pharo. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Picture 3.png (16K) Download Attachment |
One other thing... when doing the SystemWindow lookup in ScrollPane... there
is (with Polymorph) a #window method implemented in Morph that might simplify the changes. Regards, Gary ----- Original Message ----- From: "Alexandre Bergel" <[hidden email]> To: <[hidden email]> Sent: Friday, January 08, 2010 1:17 PM Subject: Re: [Pharo-project] Notifications of windows opening/closing/focus > Thanks for your comments. > I renamed the announcement accordingly to your comments. I attached a > screenshot of the new hierarchy > > Better? > > Alexandre > > > -------------------------------------------------------------------------------- On 8 Jan 2010, at 08:57, Henrik Johansen wrote: > On Jan 8, 2010, at 11:56 18AM, Gary Chambers wrote: > >> Looks ok to me. >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Stéphane Ducasse" <[hidden email]> >> To: <[hidden email]> >> Sent: Thursday, January 07, 2010 8:27 PM >> Subject: Re: [Pharo-project] Notifications of windows opening/ >> closing/focus >> >> >>> >>>> Hi! >>>> >>>> In the PharoTaskForces SqueakSource repository I committed a new >>>> version of Morphic (Morphic-Alexandre_Bergel.393). This version >>>> includes the window announcement I have been working on for few >>>> months >>>> already. >>>> >>>> Here is an example of a unit test. >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> MorphicWindowNotificationTest>>testWindowCreationAndDeletion >>>> >>>> | t window newWindowCreated r | >>>> t := 0. >>>> World announcer on: MorphicCreationWindowAnnouncement do: [:ann | >>>> t := t + 1. newWindowCreated := ann window]. >>>> World announcer on: MorphicClosingWindowAnnouncement do: [:ann | >>>> t := >>>> t + 10. newWindowCreated := ann window]. > I don't particularly like the naming. > > - Why including Announcement at the end? > - Why does one contain a verb, and the other a > - When are they fired? Closing implies to me it's not been closed > yet, but fired somewhere after the closing has started, while > CreationWindow I have no idea what means. > > MorphicWindowOpen(ed/ing) > MorphicWindowClos(ed/ing) > > are both easier to read for me, shorter, and more in line with the > naming convention for Pragma announcements already in Pharo. > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -------------------------------------------------------------------------------- > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |