RE: [FR-devel] Problem with RUNNING state

[Rich Kilmer]

Response is at the bottom of this message.

> -----Original Message-----
> From: address@hidden [mailto:freeride-
> address@hidden On Behalf Of Curt Hibbs
> Sent: Tuesday, June 25, 2002 1:48 PM
> To: address@hidden
> Subject: RE: [FR-devel] Problem with RUNNING state
> 
> Laurent Julliard wrote:
> >
> 
> (NOTE TO RICH -- there's a question for you at the end)
> 
> > I have a question regarding the plugins states. I am in the process
of
> > writing an empty nutshell  Debugger plugin and I have troubles with
the
> > order in which plugins are actually started.
> >
> > The problem I have is that most "core" plugins like
> > System_GuiCore/MenuBars, MenuPanes, AppFrames goes to the RUNNING
state
> > when the start method is called. but the problem is that in most
cases
> > what the start method does is to start instantiate a listener that
will
> > react to :notify_data_set events in the future and then it simply
change
> > the state to RUNNING. However strictly speaking the plugin
environment
> > is not completely set up at that stage.
> >
> > This was not a problem in version 0.0.4 but now that I'm
experimenting
> > with the Debugger plugin (which is not a "core" plugin but an
add-on),
> > this add-on plug-in wants all the core to be running *AND* properly
> > setup. For instance for the Debugger to initiate OK, the UI must be
> > fully in place so that the debugger can insert a new item in the Run
> > menu, insert a new FOX widget in the DockPane,etc...
> >
> > The problem I have right now is that even when I put a dependency on
say
> >    GuiSetup in the plugin.xml of the Debugger it is not sufficient.
So
> > what shoudl I use to say FR to start the Debugger plugin only when
the
> > UI stuff is completely up and running?
> >
> > I have attached the freeride.log and note that the debugger is
attached
> > to the South DockPane too early in the process before the DockBar is
> > fully setup (which is indicated by the message "Dockbar UI
components
> > positioned OK!")
> >
> >
> > Laurent
> 
> GuiSetup was supposed to fulfill this need. When GuiSetup is started,
then
> the Gui system was supposed to be up and running. Obviously this is
not
> the
> case as I can see Gui Renderers starting even after GuiSetup has
finished.
> 
> I should point out that GuiSetup itself does not care whether or not
the
> gui
> renderers are up, is it merely does the configuration/layout of the
GUI on
> the databus, knowing that it *will* get rendered at some point.
> 
> What we want is for GuiSetup to be dependent on the gui renderer, but
we
> don't want GuiSetup to have to know what renderer is being used.
> 
> I think our pluging dependency stuff isn't sufficient for this, plus
I've
> been feeling that its a little too complicated and inflexible. But if
we
> can
> get by (temporarily) I'd rather not deal with it right now.
> 
> For now, why not make GuiSetup dependent on the subsystem
GuiRenderFox.
> This
> hard codes then renderer, but should work for now, until we have
something
> better.
> 
> [RICH -- we can make a plugin be dependent on a subsystems, right?]

Right now a subsystem is just a collection that has no manifestation in
the plugin architecture.  It literally is just a holder of many plugins
that each get loaded and was put in place to simplify grouping plugin
xml data.  Because of this you cannot be dependent on it.  

Thus (Curt) when you specify:

<subsystem name="GuiRenderFox">

the name is ignored.

So here is the idea.  Register the subsystem as a plugin using the
StandardPlugin module as its mixin (and REQUIRE a name be supplied).  It
would have no behavior except being dependent on all plugins specified
within it.  Then you name the GuiFoxRender subsystem GuiRender instead
like this:

BEGIN freeride\plugins\System_GuiRenderFox\plugin.xml

<subsystem name="GuiRender">

  <plugin name="AppFrameRenderFox" version="1.0" autoload="true">
    <require>plugins/System_GuiRenderFox/AppFrameRenderFox</require>
    <module>FreeRIDE::AppFrameRenderFox</module>
 
<properties>properties/GuiRenderFox/AppFrameRenderFox.xml</properties>
    <dependency state="LOADED" action="start">
      <when plugin="Logger" version="*" state="RUNNING"/>
    </dependency>
  </plugin>

  ...

END

The point here is that you should not have duplicate rendering
subsystems working at the same time in freeride, but we do want them
pluggable.  So the next framework that comes along to enable rendering
would also name its subsystem GuiRender (with its inner plugins still
named specific names like AppFrameRenderFox).  If someone writes a
plugin that requires the Fox GuiRender subsystem, they would set their
dependencies as GuiRender AND AppFrameRenderFox.  If they just need a
GuiRender subsystem, there is only the single (pluggable) dependency
that uses whatever renderer is installed.  I could also raise a fatal
error on startup if two plugins try and register under the same name
(such as if you installed two rendering subsystems at the same time).

This would be really straightforward to implement.

Thoughts?

> 
> Curt
> 
> 
> 
> 
> _______________________________________________
> Freeride-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/freeride-devel