[cells-gtk-devel] setting parent

[ktilton at nyc.rr.com]

> Thanks. Yes, that is the problem I am facing. The cells-gtk 
> application of the 
> cells defmodel (and thus the Family API) describes a decomposition 
> of 
> widgets. One widget contains others etc. It is a happy coincidence 
> that this 
> is the pattern that applies to most uses of the widgets, but...

First the good news: the pattern has been made to work for all sorts of hairy problems with widgets dynamically appearing and disappearing, so I think we will be OK. But I am taking a few minutes before heading out for a day of skiing so I might not be able to give you the full story until later today.

> 
> > Why do you need this? I wager answering that will avoid the need 
> to setf
> > the fm-parent.
> 
> Right. For those just tuning in the code was this, recently added 
> to 
> cells-gtk/widgets.lisp:
> 
> (def-c-output popup ((self event-box))
>   (when new-value
>     (setf (fm-parent new-value) self)))
> 
> The kid of the event-box is the widget that is going to respond to 
> with the 
> popup. ... Here's the whole thing:
> 
> (mk-event-box
> :popup 
> (mk-menu
>  :kids (list
>         (mk-menu-item :label "Test 1")
>         :on-activate 
>         (callback (w e d)
>           (setf (choice (upper self regexp-box)) "whatever"))))
> :kids
>   (list <thing that responds>...)))

Two possible tricks. First, always make kids a rule: (c? ....)

Then you can have code somewhat like:
    :responder (make-responder)
    :kids (c? (list <responder> (when <show-popup-p> <popup>)))

Or you can have a "socket" widget:

    :kids (c? (list <responder>
                    (make-socket :kids (c? (when <pop-up-wanted> <pop-up>))

Another trick is to have the pop-up always exist, but make it visible/invisible based on some condition. (Less desirable, to my taste.)

> 
> The problem is that the object made with mk-menu above isn't in 
> the hierarchy. 
> (If it were, I suppose it would show up as a menu, not be a popup 
> menu). But 
> it needs to refer to things in the hierarchy -- like it is doing 
> with (choice 
> (upper self regexp-box)).  I tried all sorts of things, closures 
> etc to get 
> it to reference outside of its own little hierarchy. I couldn't 
> find a way. 
> [ugh, now I've got to go back and prove that again....]

If you make the pop-up a c? rule, you always have "self" to link you into the hierarchy:

   :pop-up (c? (make-menu :owner self....))

Note that self would be the event-box in this context, and that I just invented the owner slot (tho I usually use "owner" in cases like this, which I have encountered before.

Mind you, a popup is in most guis its own window, so the conenction to the other visible widget is just by physical proximity (and by trapping self for the semantic connection.)

> I actually have another example where the strict 1-1 mapping 
> between widget 
> hierarchy and kids hierarchy doesn't work: user-specified stock 
> icons. But I 
> think I have a solution to that one. (clos object aren't really 
> needed here, 
> but getting the stock icons defined before the model build happens 
> has been a 
> challenge.). 

We can look at that, too, if you give me more specifics. Mind you, to a degree we have to blind-lead-blind since I do not know Gtk. But I reckon we can muddle thru.

> 
> > btw,as an aside, there has been one time when I made the parent 
> slot a
> > cell. Pretty scary (speaking as the author of the Family class) 
> but it
> > worked.
> 
> I don't understand cells well enough to know why that is scary. 
> There are ways 
> of adding and removing elements from the model, right? I suppose 
> it means 
> recalculating a lot of stuff though. 

No, there are a couple of tricks for that. One is the Family-values class, which is efficient about building/removing kids.

Another applies to any c? rule: their is a .cache symbol-macro which lets you preserve kids from a prior evaluation without recreating them (and in general with any rule work off the prior computed value (unless on the first evaluation).

gotta run, kenny