[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FR-devel] Problem with RUNNING state
From: |
Curt Hibbs |
Subject: |
RE: [FR-devel] Problem with RUNNING state |
Date: |
Tue, 25 Jun 2002 10:48:07 -0700 |
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?]
Curt
- [FR-devel] Problem with RUNNING state, Laurent Julliard, 2002/06/25
- RE: [FR-devel] Problem with RUNNING state,
Curt Hibbs <=
- RE: [FR-devel] Problem with RUNNING state, Rich Kilmer, 2002/06/25
- Re: [FR-devel] Problem with RUNNING state, Laurent Julliard, 2002/06/26
- RE: [FR-devel] Problem with RUNNING state, Rich Kilmer, 2002/06/26
- Re: [FR-devel] Problem with RUNNING state, Laurent Julliard, 2002/06/26
- RE: [FR-devel] Problem with RUNNING state, Rich Kilmer, 2002/06/26
- Re: [FR-devel] Problem with RUNNING state, Laurent Julliard, 2002/06/27
Re: [FR-devel] Problem with RUNNING state, Laurent Julliard, 2002/06/28