|
|
Derive from QObject, and create your own ordering system using the
different existing signals and slots to know when a child has been added
or removed.
And only use your methods for the order, use the base QObject
functionality for everything else.
Scott
> -----Original Message-----
> From: Steven T. Hatton [mailto:hattons@xxxxxxxxxxxxxxxxxx]
> Sent: Sunday, March 05, 2006 8:51 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Re: Inserting a child QObject
>
> On Sunday 05 March 2006 23:12, Scott Aron Bloom wrote:
> > I think its clear, based on your needs, you should not use the
QObject,
> > parent<->child relationship..
> >
> > This does not limit the use of QObject, just that you will need to
> > create your own child relationship ordering mechanism.
>
> I'm not sure why you say that. QObject provides more than a simple
> recursive
> tree. There are many features such as delayed deletion, signaling,
event
> handling, properties, etc., which can still be beneficial to a project
> such
> as mine. All I need to do is provide my own comparison operators for
> sorting. I know that CodeModel in KDevelop doesn't use QObject, but
it
> supports a somewhat different realm of functionality than I am trying
to
> provide.
>
> One thing I don't like is that, AFAIK, the QObject base class must be
> public.
> I could be wrong about that , but I just tested making it protected,
and I
> got a build error.
>
>
> Steven
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/
|
|