[cells-devel] Re: Celtk/cells: timing issue in initialization and No Widgets :-(

[Ken Tilton]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060413/b6e1edcd/attachment.vcf>