Re: [FR-devel] Re: Debugger

[Laurent Julliard]

Rich Kilmer wrote:
> > -----Original Message-----
> > From: address@hidden 
> > [mailto:address@hidden On Behalf Of Laurent Julliard
> > Sent: Wednesday, November 13, 2002 1:33 AM
> > To: address@hidden
> > Subject: Re: [FR-devel] Re: Debugger
> >
> >
> > <SNIP>
> >
> > I'm still not convinced that having a big blob of flat code in 
> > attach_commands is the right approach for defining commands.  From a 
> > developer standpoint I think code readability suffers a lot. I think 
> > it would be better to have individual *private* methods and 
> > then build 
> > the commands from those methods. I know that we don't want people to 
> > use these methods (hence the private methods) but developers still 
> > need to read the code and maintain it. Plus it doesn't break the 
> > current architecture at all.
>
>
> OK...you convinced me...done!

Good, good!

> > I agree with you that we should call 'commands' something different 
> > (may be 'services' or 'interfaces') because commands is already used 
> > for menu commands which is sort of misleading
>
>
> What about "bindings" since you are creating a binding between the
> abstract component and some other behavior?

Why not... not very exciting though. What about 'outlets' in 
memory of the grandiose Interface Builder paradigm 
(NextStep/OpenStep where components interfaces were given the 
name of 'outlets'. I find the name smarter...

> > Another side remark: in the course of adapting the Debugger code 
> > (which you are going to do now) I found it difficult to listen to 
> > newly created EditPAne slots and only to those ones. In the former 
> > architecture all EditPanes slots were under a "pool' slot. With the 
> > current architecture if you create other slots under EditPane other 
> > than the EditPane instances (1,2,3....) it can be tricky to make the 
> > distinction when you receive a 'slot_add:' event. May be we should 
> > consider introducing a 'pool' level again in the ComponentManager so 
> > if other plugins wants to listen to newly created instances they just 
> > need to subscribe to the pool slot and be sure that the slot_add 
> > events they receive are EditPAne instances and not something else.
>
>
> Yeah, I understand the issue, but to limit our slot creation to a single
> level (for the EditPane itself) and not be able to leverage subslots
> like I do with "commands" seems like a waste.  The code snippet to
> determine the creation of a EditPane slot is:
>
> plugin["/system/ui/components/EditPane"].subscribe do |event, slot|
>
>  if (event == :notify_slot_add && slot.parent.name == 'EditPane')

This is what I used in the debugger originally it was sort of 
safe because I knew that only EditPanes slots were created under 
ui/components/EditPane/pool

But now that the pool level has gone this kind of test is no 
longer really safe because anyone may one day decide to create 
another slot under EditPane to store other kinds of information. 
This slot will still pass the test but does not contain an 
EditPane object. Hence the idea of introducing the pool sublevel 
again e.g ui/components/EditPane/pool/1, 
ui/components/EditPane/pool/2, etc...


>    #Do Something...this is an EditPane slot
>
>  end
>
> end
>
> It's a bit odd, but you get used to it.  The whole "notifications roll
> up the hierarchy" complicates things a bit, and you have to be aware of
> it, but at the same time it adds a lot of power.
>
> -Rich
>
>
>
>
> _______________________________________________
> Freeride-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/freeride-devel