Maric Michaud schrieb:
Le Tuesday 16 September 2008 14:47:02 Marco Bizzarri, vous avez écrit :
On Tue, Sep 16, 2008 at 1:26 PM, Georg Altmann <[EMAIL PROTECTED]> wrote:
Marco Bizzarri schrieb:
On Mon, Sep 15, 2008 at 9:37 PM, Georg Altmann <[EMAIL PROTECTED]>
wrote:
But this implies all the objects in the list have to be instances of
QObject. I wonder if this is isn't a weird design, because for example
all value type classes in Qt don't derive from QObject, e.g. QString. My
list objects are not that simple (in terms of the data structure). So is
it ok to make them QObjects?
Did you take a look at this?
http://www.potu.com/man/doc.trolltech.com/4.0/model-view-programming.html
It seems to imply that you should use QtAbstractItemModel as a base
class for all your models. But since I'm not an expert about Qt, I
cannot really say.
Yes, I did. But as I explained in my previous message, the whole Qt
model-view framework doesn't seem fit any data which can not be handled
as QVariant and thus as a value type.
It is not about QT, it is about MVC. In MVC, code which implement the model
should be completely ignorant of the libraries used for gui, and the gui part
of the application shouldn't acces directly to your model logic. This why
there is a third layer which abstract the logic of your datas and provide
standard operation for the gui code. This third layer (Controllers), should
be as few as possible coupled to the specificities of the gui library (but
must be).
The quoted papers explain rather well how to do this with QT (apart they call
controllers "delegates").
Except they always handle simple data. I don't see how to get around the
QVariant limitatation. Also the data should be displayed in a graphical
manner (maybe a QGraphicsScene/QGraphicsView or mabye custom
QScrollArea). This also doesn't seem to go well with the standard Qt
approach.
I could imagine to implement the model without using any Qt then use
proxy classes derived from QObject as controllers.
For medium to big project, don't be afraid to divide your program in three
packages, one for the model, in which you must not have any reference to QT
API of some sort, one for the controllers, where you provide events and
methods to manipulate your model, one for gui, where you just build windows,
subscribe to controller's events and use their functions as callbacks for
your widgets.
As this is a small project for now, I think the controller layer is too
much work. As the project gets bigger it should be possible to switch to
a full mvc implementation if necessary. For now I will try to work with
a model that provides some signals by itself.
Regards
Georg
--
http://mail.python.org/mailman/listinfo/python-list
