freeride-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [FR-devel] Re: Debugger


From: Rich Kilmer
Subject: RE: [FR-devel] Re: Debugger
Date: Tue, 12 Nov 2002 22:26:59 -0500

comments below...

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On Behalf Of Laurent Julliard
> Sent: Tuesday, November 12, 2002 11:28 AM
> To: address@hidden
> Cc: 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
> 
> I looked at the Editpane.rb and EditPaneRenderer.rb file and I 
> understand the mechanics of commands. I just want to check my 
> understanding a little bit further:
> 
> - For now all your commands are defined in 
> EditPaneRenderer.rb because 
> they all more or less deal with renderer function at some point

The structure is this:

GuiCore component: EditPane

EditPane.cut -> calls proc > ["commands/cut"]

GuiRenderFox component: EditPaneRenderFox

mount proc: ["commands/cut"] to call .cut on the scintilla controller

The point is the abstract component (EditPane) just calls proc slots and
something sets a proc on that slot to do something with the call.  What
is does is not up to the abstract component.

> 
> - I guess all commands that deal with EditPane.rb level stuff only 
> could perfectly be defined in the EditPane.rb, right ?
> 
> - In the same vein, I think all the old class level method 
> (EditPane.open, close_all, current=, breakpoints, find) could also be 
> turned into commands but these commands should be attached to the top 
> level EditPane slot because it doesn't make any sense to 
> redefine them 
> again in all Edit pane instance slot, right ?

Actually, the class level methods are a bit evil I think.  Instead, use
Command objects (see AppCommands and EditCommands).  You will find that
CloseAll is a Command object now.  It iterates over all EditPane objects
and closes them.  Open is also there.  This is a complete restructuring
of what we had in there before...you need to study the Command object
architecture.

> 
> Which bring me to the last question? Are there guidelines to 
> follow to 
> decide which method should be invokde through a command and which one 
> should be called directly through the class.method classical 
> invocation?
> 

I would say that there are no class level methods...period.  The current
EditPane is accessed by going to the slot
["/system/ui/current/EditPane"] which is linked to the current EditPane
slot.  That is how you will access the breakpoints on the current
EditPane programatically.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]