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