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

[Frank Goenninger]

Am 13.04.2006 um 21:04 schrieb 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.

Understood.

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

No. Control Panel is currently just the model. No View yet.

>            (darc-setup-panel))))

This is a View with an integrated model. No really pure OO just a  
quick hack.

I see I should do a widget hierarchy that looks like

window
       |
      +--- frame (= darc-setup-panel-frame)
      |          |
      |          |--- row
      |                    |--- ...
      |
      ----- frame (= control-panel-frame)
                |
                |---- row
                         |--- ....  Here the yet not coded control  
panel widgets should go in.

>
> 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. :)

Yep. As I admitted: Just a quick hack so far to test out several things.

> Let me send this off and stare at the code some more.
>
> kt

Now let me code some more to come up with a  clean Model/View  
separation  and with your inputs included.

THX!

Frank