[cells-gtk-devel] setting parent

[Peter Denno]

On Tuesday 15 February 2005 18:38, ktilton at nyc.rr.com wrote:
> Peter,
>
> You asked about setting the parent directly. I think that will be a mess.
> First of all, there is an "adoption" sequence in cells intialization (part
> of to-be processing). Second, instance should then appear in the parents
> kids slot. ie, The Family class is kind of an API, and setting the
> fm-parent would be breaking the API.

Kenny, 

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

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

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....]

Vasilis's test code (test-menu.lisp) doesn't get an error because the menu 
items for the popup don't do anything. At least that's my theory. I hope you 
can disprove it, by showing me how to do the referencing.

* * *

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

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

>
> cheers, kenny

-- 
Best Regards,
 - Peter