Please send it. May be publish it also on mantis.  I patched the global 
method that contains the balloon for halo :( But you know what it is.  
Again I do not know if people will be afraid that this is breaking 
their code (It will break mine). So is your solution keeping (via 
deprecation) the old way?

I think that the halospec code in Preference could be moved to 
haloMorph without impacting the system. But this is looking like 
another kind of changes.

So may be if you can send you code some Morphic/Etoy guy can have a 
look even if
I think that nobody will do it (but this is my pessimistic point of 
view, of course I will look at it
but I would like that people more concerned about less breaking stuff 
do it, if you see what I mean).

Stef


> Stephane;
>
> I have a small changeset where I have refactored the
> halos.  In the old way, halos are nothing more than
> EllipseMorphs, which rely on the Morphs to implement
> functionality.  What I did was create halo classes,
> and implement the functionality in them.  This allowed
> me to move some methods out of Morph.  Then I
> refactored the halospecs, so that each morph is
> responsible for the halos specs, rather than spreading
> the code out all over.  It also allows the halos to be
> more instance specific, so a programmer to allow a n
> instance of a morph to bring up different halos at
> different times.

I need that :)


>  If you'd like it, I can post it.
>
> Doug
>
>
>
>
> --- stéphane ducasse <ducasse at iam.unibe.ch> wrote:
>
>> hi
>>
>> I have been creating my own halos and I found quite
>> strange that a lot
>> of the code for halospec and haloMorph
>> is located in Preferences and not on the class side
>> of HaloMorph or
>> HaloSpec.
>> I could of course change that but are people
>> concerned by that or
>> prefer to keep a clunky system?
>>
>> Stef
>>
>>
>>
>
>