[Top][All Lists]
[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.