Re: [paragui-users] Paragui redesign

[Alexander Pipelka]

Am Mon, 2002-05-06 um 20.46 schrieb Andrew Ford:
<snip>
> > Hmm,..
> > One point seem curious to me with that refcounting.
> > When do pointers get void (what would decrease the
> > refcount) ?
> > When deleting the pointer/object ?
> >
> 
> When you're reference counting, basically every
> reference is a small object that contains a pointer to
> the object (widget in this case).  When it is copied
> or to another reference, we now have two references,
> so we increase the ref-count.  When one of these
> objects are destroyed (either on the stack or
> dynamically), we now have one less reference, so we
> can decrement the ref-count.  Suppose the reference
> count gets to zero.  In this case, nobody can access
> the widget anymore so it can safely delete itself. 
> Since we always know that our pointed object is always
> a PG_Widget or derived, we're in good shape with this.
>  Basically, the widget takes care of itself so that
> the user doesn't have to worry about it.  As long as
> he holds a reference, it's around, and as soon as he
> (and paragui) doesn't, it goes away.  Something nasty
> will almost certainly happen here if the user is
> holding a dumb reference to the widget.  Of course, if
> the user still wants to do this, perhaps we can
> non-destructive references selectable via a policy
> when the user instantiates the reference type for
> paragui.  The user can decide he wants to be on his
> own (if anyone is wondering why I keep using he/his,
> we all know that girls can't program :) ).  We may be
> able to set it up so that the user can command that
> the widget be deleted right-now! invalidating any
> references held to it (this would require specific
> support both on the user and library side).

Ok. I see things clearer now :)

>   Anyway, I'm rambling, but I think we can make
> reference-counting at least as flexible as using local
> widgets or pointers to widgets.

Would be cool. I'm sure I'll get my in depth views when my book arrives.

>   I have a question for you.  What happens when we
> declare a local widget and make it a child of another
> widget, then the parent is deleted?  I ought to know
> this, I know, but I've forgotten at the moment.

By deleting a parent widget all child widget will also be deleted.

> 
> > >   Now that I'm thinking about it, isn't parsing
> > the
> > > XML attributes like sending events to the widgets,
> > and
> > > if treated like that, events not handled right now
> > are
> > > sent up to the super-class for handling until we
> > get
> > > to PG_Widget...
> > 
> > Kind of. But i think virtual functions fit perfectly
> > for that.
> 
> So how do we pass specific attributes (or sets of
> attributes that share some context) back to the
> super-class for processing?  We obviously don't want
> to do the full parsing in each widget (and users would
> then hate laying out custom widgets).

Hmm,..
There is no need for every widget to parse all possible attributes.
It should work like this:

PG_Widget::parseXMLAtts(...) {
        parse atts of PG_Widget
}

myclass::parseXMLAtts(...) {
        PG_Widget::parseXMLAtts(...)
        parse atts of myclass
}

mysubclass::parseXMLAtts(...) {
        myclass::parseXMLAtts(...)
        only parse atts of mysubclass
}

Alex