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: Wed, 13 Nov 2002 08:41:27 -0500

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

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

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

   #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






reply via email to

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