RE: [FR-devel] Problem with RUNNING state

[Curt Hibbs]

See my response at the bottom...

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of Rich
> Kilmer
> Sent: Friday, June 28, 2002 9:03 AM
> To: address@hidden
> Subject: RE: [FR-devel] Problem with RUNNING state
>
>
>
>
> > <SNIP>
> >
> > The reason for that is because at that point and eventhough
> > AppFrameRenderFox has already started none of the FOX resources have
> > been properly initialized (there is no Main Window initialized)
> > so the MenuPaneRenderFox does its job thinking that is everything is
> > already running ok but what "RUNNING" says for now is only that we
> have
> > entered the start method note the initialization is finished.
> >
> > So I think there is something wrong in the design here. I see several
> > expelnations:
> >
> > a) the semantic of the "RUNNING" state is not good in the sense that
> > this is not because a plugin is in a running state that it is ready to
> > work. may be we should introduce another transient state like
> > "INITIALIZING" that woudl eventually become "RUNNING" once the
> > initialization has completed
> >
> > b) Another problem is that the RUNNING state is associated with the
> > **Class** method start and what we care about is the state of the
> > instances of that plugin.
> >
> > c) we could ask the plugin to the running state later in the process.
> > Instead of transitioning in the start method we could transition at
> the
> > end of the initialize method. But then it becomes an action that we do
> > in an instance method and I don;t know what are the implications of
> this.
> >
> > I'm open to discussion here because I really think that something is
> > flawed in the way we use the state transitions in the plugin but I
> don;t
> > yet see how to fix it in the proper way.
> >
> > laurent
> >
> > --
> > Laurent JULLIARD - Xerox R&T/SSTC/XPA - Open Source team
> >  >> Host your Xerox Software project on CodeX: http://codex.xerox.com
> >  >> address@hidden community: http://xww.linux.world.xerox.com
>
> Well, the point of transitions is to identify the state of a plugin to
> other plugins.  If you plugin in not in the RUNNING state after .start
> is called, then you SHOULD NOT say it is.  If it's after your class gets
> initialized, then that is when you should transition your plugin.
> Remember, the plugin is passed into the constructor to allow the class
> instance to do necessary things to the plugin instance.  The fact that
> we (normally) transition immediately does not mean this is the correct
> behavior for all plugins.
>
> So, I would say to move the transition code to the point where the
> actual state of the plugin IS in the state you are reporting (in this
> instance...RUNNING).

Laurent, you are correct that there is a design flaw, and Rich is correct
that the source of the design flaw is the plugins are entering the RUNNING
state when they are not really running. This problem is probably in all of
my plugins because each one was created (initially) as a clone of one of the
others (which started off as a clone of one of the test plugins).

I can provide some assistance and guidance in making the needed changes but,
unfortunately, I cannot make them myself because I cannot yet run the
current FreeRIDE  on Windows.

Fixing the fox renderer plugins should be pretty easy because they are all
structured pretty much the same. Looking at MenuPaneRenderFox.rb, you would
do this:

- from the method MenuPaneRenderFox.start, cut the second code line:
            plugin.transition(FreeBASE::RUNNING)

- paste the cut line of code as the very last line of the initialize method
in the Listener class.

Repeat this for each of the renderer plugins. I think that should do it for
the renderers. Then for the System_GuiCore plugins, they all look ok except
for GuiSetup.rb, which needs to have its
"plugin.transition(FreeBASE::RUNNING)" line moved to the very end of the
GuiSetup.start method.

Sorry to have to put this off on you. Please let me know how it goes.

Curt

-