On Tuesday 25 October 2005 20:02, Thomas Zander wrote:
> The listeners are the ones that also have to be QObjects.

Right.

> Everyone that has a 'current frame' is a potential listener.  This 
> includes the FrameSetEdit a.o.

There's only one instance of FrameSetEdit at a time (ok two in table cells),
so that's not a big problem either.

And actually I just had a bug where, if I could have printed myFrameSetEdit->className(),
I would have saved time :-)   (ok there's RTTI too but I always forget how to use that).

> > It simplifies the model because you don't have to create yet another
> > base class (interface) just to listen to signals from the viewmanager.
> 
> I never knew that creating more classes was a problem.  I tend to create 
> loads of classes

Creating loads of classes is certainly fine when it splits up the existing code.
But creating a class just to end up emulating what signal/slots offer, doesn't
seem necessary to me, it complexifies the reading of the code IMHO.

> I'll come back when I have a more finished list of listeners so we can see 
> then.

OK.

> As I said; I was under the impression that just making every class a 
> QObject was considered an incorrect way of working.

I know there there are both schools of thoughts, but I think most KDE developers
(except Marc Mutz :) ) are fine with using QObject in non-GUI code, as long
as it's not for objects of which we have 1000 instances.

Connecting a signal from A to slot in B is so much simpler and clearer than 
making B inherit an interface, making B register into A, making A remember 
all registered Bs, and making A interate over registered Bs to call a method there :)

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel