|
From: | Laurent Julliard |
Subject: | Re: [FR-devel] Re: Debugger |
Date: | Thu, 14 Nov 2002 22:54:06 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 |
Rich Kilmer wrote:
-----Original Message-----From: address@hidden [mailto:address@hidden On Behalf Of Laurent JulliardSent: 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 misleadingWhat 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
[Prev in Thread] | Current Thread | [Next in Thread] |