Frank,
I see a few things. Deets next, but first my inclination is to leave the problems in place and work on the core to provide helpful error messages where possible (I will do anything to avoid writing documentation <g>). This will have the advantage over documentation in that it will catch careless veteran mistakes as well as newby mistakes.
Issues:
1. darc-setup-panel begins:
(defun darc-setup-panel () (mk-stack () <list of widgets>))
That is good in one respect, contrasted with control-panel, which begins
(defun control-panel () (list <list-of-widgets>))
That is not absolutely the end of the world, because the-kids here:
(defmodel psu-rc-app-view (window) ((selected-oper-pb :cell :ephemeral :accessor selected-oper-pb :initform (c-in nil) :initarg :selected-oper-pb) (selected-test-pb :cell :ephemeral :accessor selected-test-pb :initform (c-in nil) :initarg :selected-test-pb)) (:default-initargs :id :psu-rc-app-view :kids (c? (the-kids (app-menubar) (control-panel) (darc-setup-panel) ))))
Will flatten out the list returned by control-panel. In the end, every component listed by control-panel becomes a top-level widget of the window, meaning it needs packing instructions. And this brings us to the problem with the darc-setup-panel: it needs packing, too.
If you use stacks and rows, their kids get default packing. But the toplevel widget in a window does not get default packing. I tried that, but it gets in the way of the parent trying to do packing if the kids are doing packing. To do custom packing, one first must specify nil values for kid-packing values, then one has to pack each kid manually. I would explain that more, but let's just use stacks and rows.
I do not know how you visualize the outcome, but I see two big stacks coming, so:
control-panel now starts: (mk-stack () <widgets>)
and psu-rc-app-view kids becomes: (the-kids (app-menubar) (mk-row (:packing (c?pack-self)) ;; accept all TK packing defaults (control-panel) (darc-setup-panel))))
btw, if you check the lotsa-widgets demo you will see it starts that way. My policy when working with hairy libraries (like Celtk, I admit) is to take some sample code, make sure it works, and then rename it "kennys-new-app" and change things only as I need to. That let's me avoid /reading/ doc. (Notice a trend?) Eventually all the original code is gone and I understand what remains. Anyway...
With the above changes I now get a complaint about signal-lamp not having a path method, and I see that that is an "application-object", which suggests to me that you do not want it in the GUI at all, that all those are part of the model. I think we are on the verge of some deep OO design issues here. :) Let me send this off and stare at the code some more.
kt