Hi,
I want to build a morphic application (for algorithm animation) so I need to do something in the step method. I wanted to make it a subclass of SystemWindow (I'd actually prefer StandardWindow in Pharo but there doesn't appear to be an equivalent in Squeak). But when I do, the step method doesn't get called. (Nor does stepAt:) (And StandardWindow behaves the same.). But if I move it to MorphicModel step/stepAt: gets called, but I don't get any of that SystemWindow goodness. I've looked at the dispatch in Morph, and I don't see anything different in Worldstate>>runLocalStepMethodIn: but this stuff is very difficult to debug, because there's asynchronous stuff running behind the scenes. In particular, lastStepMessage value: now. lastStepMessage ifNotNil: [... is a little weird! Any pointers appreciated. Thanks ../Dave |
Hi.
You need to call #startStepping if you want #step to get called frequently according to #stepTime. Nevertheless, you may want to take a closer look at this project: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/animations Marcel |
Hi Marcel,
On 2012-Feb-5, at 2:04 , Marcel Taeumel wrote: > You need to call #startStepping if you want #step to get called frequently > according to #stepTime. Actually you don't with Squeak 4.2 and Pharo 1.3 (don't know about earlier versions), because Morph>>initialize does that. But just for completeness, I did that, and it made no difference. My class is just: MorphExp>>initialize super initialize. self startStepping. self color: Color red lighter MorphExp>>step self halt MorphExp>>stepAt: t self halt and it doesn't halt if it is a subclass of SystemWindow, but does if it's any higher up the hierarchy. > Nevertheless, you may want to take a closer look at this project: > https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/animations Thanks, but I don't want the issue about unloading, and I'm not worried about it being super-smooth animation. Also thanks for the link, because it looks like interesting things are happening at HPI! ../Dave |
Look at the methods #wantsSteps.
Cheers, Bob On 2/5/12 7:29 AM, Dave Mason wrote: Hi Marcel, On 2012-Feb-5, at 2:04 , Marcel Taeumel wrote:You need to call #startStepping if you want #step to get called frequently according to #stepTime.Actually you don't with Squeak 4.2 and Pharo 1.3 (don't know about earlier versions), because Morph>>initialize does that. But just for completeness, I did that, and it made no difference. My class is just: MorphExp>>initialize super initialize. self startStepping. self color: Color red lighter MorphExp>>step self halt MorphExp>>stepAt: t self halt and it doesn't halt if it is a subclass of SystemWindow, but does if it's any higher up the hierarchy.Nevertheless, you may want to take a closer look at this project: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/animationsThanks, but I don't want the issue about unloading, and I'm not worried about it being super-smooth animation. Also thanks for the link, because it looks like interesting things are happening at HPI! ../Dave |
On 2012-Feb-5, at 7:40 , Bob Arning wrote:
> Look at the methods #wantsSteps. Bingo! I assumed it was something stupid I was missing. On 2012-Feb-4, at 14:23 , Sean P. DeNigris wrote: > I don't know if it's any better, but when I create my own morph-in-a-window, > I usually don't subclass SystemWindow, but add my morph to a window using > openInWindowLabelled: or addMorph:fullFrame:. I feel like I have a little > more flexibility if I later want to use it not-in-a-window. After defining wantsSteos, I see that color: seems to work a bit strangely too in SystemWindow, so I'm going to try this. Thanks, Bob and Sean. |
One thing to consider is whether you really
want to subclass SystemWindow or if it might be better to
instantiate a vanilla SystemWindow and install your specialized
morph inside it.
Cheers, Bob On 2/5/12 9:57 AM, Dave Mason wrote: On 2012-Feb-5, at 7:40 , Bob Arning wrote:Look at the methods #wantsSteps.Bingo! I assumed it was something stupid I was missing. On 2012-Feb-4, at 14:23 , Sean P. DeNigris wrote:I don't know if it's any better, but when I create my own morph-in-a-window, I usually don't subclass SystemWindow, but add my morph to a window using openInWindowLabelled: or addMorph:fullFrame:. I feel like I have a little more flexibility if I later want to use it not-in-a-window.After defining wantsSteos, I see that color: seems to work a bit strangely too in SystemWindow, so I'm going to try this. Thanks, Bob and Sean. |
On 2012-Feb-5, at 10:11 , Bob Arning wrote:
> One thing to consider is whether you really want to subclass SystemWindow or if it might be better to instantiate a vanilla SystemWindow and install your specialized morph inside it. What are the considerations for one approach over the other? (In broad terms - not asking for a tutorial here! :-) Thanks ../Dave |
Fundamentally, the question is whether you are
trying to create a new kind of windowing behavior (if so,
subclassing may be the right approach) or if you just want your
new widget inside a window for ease of moving, collapsing,
expanding, etc (if so, adding your morph to a plain
SystemWindow is probably better).
Also ask yourself if you could ever want more than one of your widgets inside a single window. Or if you could ever want your widget naked in the World or inside some other graphical structure. Yes to any of these is a further indication to move away from subclassing and toward assembling components into larger components. Cheers, Bob On 2/5/12 10:16 AM, Dave Mason wrote: On 2012-Feb-5, at 10:11 , Bob Arning wrote:One thing to consider is whether you really want to subclass SystemWindow or if it might be better to instantiate a vanilla SystemWindow and install your specialized morph inside it.What are the considerations for one approach over the other? (In broad terms - not asking for a tutorial here! :-) Thanks ../Dave |
Free forum by Nabble | Edit this page |