[cells-gtk-devel] table with dynamic elements
Peter Denno
peter.denno at nist.gov
Sun Feb 6 17:59:00 UTC 2005
Hi kenny,
My use of ndisp was not very well thought out, it was there because the
example is based on code I was porting from CAPI. Here I don't have any need
for a slot that counts the number of elements. I wasn't able to get your
example to work because I am under a bit of pressure to go for a hike, it
being so nice out today. But if I eliminate all the ndisp junk I get a
pretty simple program that still doesn't work (same error). (one quick try is
all I had time for). Keep in mind that I am guessing a lot about how table
works, and putting the (c-in nil) in Vasilis's code was just a guess:
(def-widget table ()
((elements :accessor elements :initarg :elements :initform (c-in nil))
(defmodel example (gtk-app)
()
(:default-initargs
:expand t :fill t
:md-name :example :title "example"
:kids
(list
(mk-vbox
:kids
(list
(mk-hbox
:kids
(list
(mk-button :label "more"
:on-clicked
(callback (w e d)
(push (list (mk-entry :init "new"))
(elements (fm-other :table)))))
(mk-button :label "less"
:on-clicked
(callback (w e d)
(pop (elements (fm-other :table)))))))
(mk-table
:md-name :table
:height 200
:elements (c?
(list (list (mk-entry :init "Hello"))
(list (mk-entry :init "World"))))))))))
That pretty much eliminates my use of cells, leaving only my reliance on the
assumption that the elements slots uses them in a way that makes updates
possible.
On Saturday 05 February 2005 22:29, Kenny Tilton wrote:
> Peter, I had written quite a bit before realizing the problem. I think
> it is useful background, so I am leaving it in. The good stuff, tho, is
> towards the end.
>
> Peter Denno wrote:
> >Hi,
> >
> >I'm a bit lost about how to do this. I'd like to add elements to a table
> > and have them appear.
> >
> >What I am getting is this error:
> >(setf md-slot-value)> cellular slot ELEMENTS of #<TABLE 21B555A4> cannot
> > be setf unless initialized as inputp.
> >
> >I thought maybe it was because the elements slot of table is not a cell
> > slot, so I tried changing it by adding (c-in nil):
>
> If elements were not a cell slot, you would be allowed to setf it.
> Unless I have a bug in there, non-cell slots should work according to
> standard CLOS rules. And the default is to make a slot a cell.
>
> btw, I have gone back and forth on this so I would have to check, but I
> did have a validation check that warned me if I specified a cell (via c?
> or c-in) for a non-cell slot. I am a little fuzzy on that, tho.
>
> The error you show is for precisely the case where a cell slot has been
> initialized or defaulted to some maked literal value, including nil, and
> one attempts a setf on it. So your adding (c-in nil) should have worked.
> Lesseee.....
>
> >(def-widget table ()
> > ((elements :accessor elements :initarg :elements :initform (c-in nil))
> >
> >No difference.
>
> The (c? (list ...hello...world) initarg supplanted the (c-in nil), which
> is why this had no effect.
>
> To make your code work, at mk-table time you could have just specified
> (c-in (list ...hello...world)). But down below I offer a neater
> solution, avoiding the echo.
>
> >An example is below. If I stop and check the table, it has only 5 cell
> > slots, and none for elements. If I make a table at the command line with
> > (make-instance 'example) it has many more cell slots, including one for
> > elements. I suppose I am doing something obviously wrong. I don't have
> > much experience with this yet.
>
> How are you counting up the cell slots? There are two ways to count. One
> is to ask how many slots have been defined as being cells slots. This
> means they get special plumbing on their accessors. But I can then
> initialize such a slot to nil or 42 or anything else, as well (c?...) or
> (c-in ...). I think you are saying you only see a few cells (c?, c-in)
> for the many cell slots. And yes, that depends on what is suppliet at
> make-instance.
>
> Note also that c?-type cells can get optimized away if their rule does
> not access some other c? or c-in, and this cascades, so I can start off
> with all C?, some referencing each other, but if those get optimized
> away, then those depending on them may get optimized away. I have a
> second intenals slot in each instance for "optimized-away" or somesuch.
>
> Now if I am guessing right...oh, wait, I think i see the problem:
> >(in-package :test-gtk)
> >
> >(defmodel example (gtk-app)
> > ((ndisp :cell t :accessor ndisp :initform (c-in 2)))
> > (:default-initargs
> >
> > :expand t :fill t
> > :md-name :example :title "example"
> > :kids (list
> >
> > (mk-vbox
> >
> > :kids
> >
> > (list
> > (mk-hbox
> >
> > :kids
> >
> > (list
> > (mk-button :label "more"
> >
> > :on-clicked (callback (w e d)
> >
> > (incf (ndisp (upper self
> >example)))))
> > (mk-button :label "less"
> >
> > :on-clicked (callback (w e d)
> >
> > (decf (ndisp (upper self
> >example)))))))
> > (mk-table
> >
> > :md-name :my-table
> > :height 200
> > :elements (c?
> >
> > (list (list (mk-entry :init "Hello"))
> > (list (mk-entry :init "World"))))))))))
> >
> >(def-c-output ndisp ((self example) newval oldval)
> > (when (and newval oldval)
> > (let ((table (cells::fm-descendant-named self :my-table))) ; better
> > way? (cond ((< newval oldval)
> > (pop (elements table)))
> > ((> newval oldval)
> > (push (list (mk-entry :init (format nil "New ~a" newval)))
> > (elements table)))))))
> >
> >(defun doit ()
> > (cells-gtk-init)
> > (cells-gtk:start-app 'example))
>
> Here is a new rule for elements:
> :elements (c? (let ((ex (upper self example)))
>
> (bwhen (ndisp-delta (f-delta () (ndisp ex)))
> (cond
> ((eql delta 1 (cons (mk-entry :init (format nil "New
> ~a" (ndisp ex)))
> .cache)))
> ((eql delta -1 (cdr .cache)))
> (t (list <hello> <world>))))))
>
> That bit at the end is a little sketchy. I /think/ it will work to
> initialize the list.
>
> Caveat: I am actually working on the black hole right now so I have not
> time to test the above, but if it does not work i will take a few
> minutes to make sure I get you something that works. I hesitate because
> I changed synapses (such as f-delta above) recently and i am not sure
> the code I borrowed from is valid.
>
> Two tricks: f-delta, the synapse, returns the change in ndisp, not the
> value.
> Second: .cache is a symbol-macro which returns the current value of
> cell, so you can change it without re-consing the whole thing. Just amke
> sure a new cons cell gets returned (do not do delete on an item in the
> middle) or Cells will not see the change (the default test is EQL).
>
> All this said, I am concerned about having to hard-code the (c-in 2).
> What if we had the more/less buttons operate directly on the list and
> made ndisp simply (c? (length (elements (fm-other :table))?
>
> I am guessing you are just experimenting, but in this case you have a
> hybrid situation where elements starts as a specified list of hello and
> world but then becomes a function of changes to ndisp. And ndisp starts
> as a function of elements (the 2 matching the 2 elements) but then gets
> controlled by the user.
>
> So I think your experimenting (if I am right!) has led to a tough case
> for Cells, but only because of shisting relationships I would not expect
> in a real interface.
>
> cheers. kt
>
> ps. I am really rushing this and I am beat after a day on the slopes, so
> just come back with anything I screwed up and I will sort it out,
> perhaps tomorrow.
--
Best Regards,
- Peter
Peter Denno
National Institute of Standards and Technology,
Manufacturing System Integration Division,
100 Bureau Drive, Mail Stop 8264 Tel: +1 301-975-3595
Gaithersburg, MD, USA 20899-8264 FAX: +1 301-975-4694
More information about the cells-gtk-devel
mailing list