PPS. There's a neat method called #on:send:to:, which would be perfect for the different actions in RPackage-SystemIntegration. I'm trying to understand how this on:send:to: would help us. Because Nautilus registered to system announcer Now I do not understand why RPackageOrganizer should not register to systemAnnouncer too. And even if we use on:send:to: who can garantee that the on:send:to: will notify first the RPackageOrganizer and not that an announcement will reach the browser before.
What was your idea?
Stef It has nothing to do with registration ordering, but using the proper API. If you look at the RPackageOrganizer registrations in RPackage-SystemIntegration, all they do in the action block is send self a message. Instead of: anAnnouncer when: SystemCategoryAddedAnnouncement do: [ :ann | self systemCategoryAddedActionFrom: ann ]; you write: announcer on: SystemCategoryAddedAnnouncement send: #systemCategoryAddedActionFrom: to: self
I do not get what is the difference. Can you explain how this would solve my problem? I was discussing with luc and noury yesterday and we thought about the following: The system should be layered in two layers system (Rename) should emit annoucement to system objects (like RPakcageOrganizer) UI tools should register not to system but to RPackageOrganizer. So this is probably the solution but I'm thinking that in the long turn may be pushing packages inside the system wiuthout annoucement would be better.
It also has the added benefit you can make them weak if you want :)
Cheers, Henry
And ugh, why the Announcement at the end of the Announcement names? :/
Who cares for now we have a system on its knees if one annoucnement breaks so to me this is totally useless. Stef