RE: [FR-devel] Re: Debugger

[Rich Kilmer]

comments below

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On Behalf Of Laurent Julliard
> Sent: Tuesday, November 12, 2002 12:21 PM
> To: address@hidden; rich Kilmer
> Subject: Re: [FR-devel] Re: Debugger
> 
> 
> Rich Kilmer wrote:
> > I'm sure you can figure this out but...
> > 
> > Notice that I created a deligation architecture through proc slots 
> > mounted under each editpane like:
> > 
> > plugin["command/cut"].call
> > 
> > These deligated proc slots are "fulfilled" by the renderer.  The 
> > editpane presents a regular object API with .cut, .copy, 
> etc that then 
> > calls these procs.
> > 
> > When it comes to having data stored on the editpane (for 
> markers) just 
> > analyze the interactions and create the appropriate proc deligation 
> > calls...then code the behavior on the editpane and renderer side.
> > 
> > Thanks Luarent,
> > 
> > Rich
> > 
> > 
> 
> Rich,
> 
> Another comment on the use of commands in the EditPane plugin. Beside 
> the discussion about where/when command should be declared (see 
> previous message) there is another point that I'd like to discuss:
> 
> All Edit Panes commands are declared in one single attach_commands 
> method. After thinking about it I think we should not do that 
> but keep 
> each method separate and then call the method from the command proc. 
> It add an extra methiod call but it has several advantages:

Actually, the edit pane itself (in GuiCore) does not do this.  The
EditPaneRenderFox does.  The EditPane is the API...the slots are
documented there.  The way in which a renderer fulfills them is up to
the renderer.  I don't think we need to break them out into separate
methods since all they are doing is mounting a proc (one to fulfill is
EditPane command).

> 
> a) the code is much more readable with separate methods

I don't think that adding all those methods would necessarily make the
code more readable, but that's in the eye of the coder ;-)

> b) with separate methods you can use rdoc and generate good looking 
> developer documentation

The developer documentation should be against the abstraction (EditPane)
not the renderer.

> c) it gives an additional flexibility in the sense that from inside 
> the plugin you can directly call the methods without the overhead of 
> the command mechanism.
> 
> Do you agree with this?
> 
> If so then I think I can rework the EditPane files a bit to make this 
> happen. Plus I think it gives an intuitive guideline wrt to when a 
> command must be created: use a command declaration whenever you want 
> to publish a command to the outside world for use by other plugins. 
> Does this sound ok?
> 
> Laurent

I don't think I am following you on this. The EditPane API is that
presented by the abstract component (in GuiCore).  The "commands" it
uses are fulfilled by something (actually right now most of the
"commands" are fulfilled by EditPaneRenderFox with the exception of
parse_code which is fulfilled by the SoureParser plugin).  The
"commands" you publish to the outside world are in the databus.  These
are not the same as the Commands that are bound to Keys, etc.  Maybe its
not a good idea to overload the command term.   Perhaps it should be
"behavior" or something.

Does this make sense?

-Rich