Re: [FR-devel] Re: Debugger

[Laurent Julliard]

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:

a) the code is much more readable with separate methods
b) with separate methods you can use rdoc and generate good looking 
developer documentation
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




--
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