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
stéphane ducasse ha scritto in data 04/01/2005 9.03:
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?
Preferences is a bit clunky :) ... if you can fix it and rearrange it whould be great :))
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. If you'd like it, I can post it.
Doug
--- st�phane ducasse ducasse@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
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@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
Stephane;
I will post it here. It may take a couple of days, maybe this weekend.
Doug
--- st�phane ducasse ducasse@iam.unibe.ch wrote:
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@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
no problems it may take months to be used in the image :)
Stef On 7 janv. 05, at 5:23, Douglas Rollwitz wrote:
Stephane;
I will post it here. It may take a couple of days, maybe this weekend.
Doug
--- stéphane ducasse ducasse@iam.unibe.ch wrote:
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@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
squeak-dev@lists.squeakfoundation.org