Qt-interest Archive, January 2007
model/view with undo
Message 1 in thread
Hi!
I have a design question about how to combine the model/view framework
and the undo framework of Qt.
Some changes to the domain model are performed directly through the Qt
model: e.g. you rename an item directly in the standard view which
invokes #setData, and there you'd have to create and execute a undoable
rename command.
On the other hand, for creating new items or deleting existing ones,
there's no standard user interface on the views and thus no standard API
between view and model. You'd have to let the user press a 'Delete'
button which invokes a slot executing the delete command. This slot
would probably be implemented in some controler class.
So there would be (at least) two locations in the code where the domain
model is manipulated; I don't like that idea, I think the manipulation
functionality should be in one place. Also, I don't really want to put
create/delete slots into the model class (actually, that's what I'm
currently doing... yuck).
So how would you guys design this?
Regards,
M
--
[ signature omitted ]
Message 2 in thread
On 31.01.07 11:23:09, Martin wrote:
> On the other hand, for creating new items or deleting existing ones,
> there's no standard user interface on the views and thus no standard API
> between view and model.
Then you missed a part of the model documentation. There is a well
defined API on how to remove items from a model, namely removeRows. The
same goes for adding rows, insertRows is the function that exists.
> You'd have to let the user press a 'Delete'
> button which invokes a slot executing the delete command. This slot
> would probably be implemented in some controler class.
Yes, but all you'd do in the slot is calculate the current selection and
tell the model to remove all indexes of the selection.
> So there would be (at least) two locations in the code where the domain
> model is manipulated; I don't like that idea, I think the manipulation
> functionality should be in one place.
It is already. And btw. nobody keeps you from writing your own
view-subclass that allows insertion and deletion of rows directly
without any extra buttons.
> Also, I don't really want to put
> create/delete slots into the model class (actually, that's what I'm
> currently doing... yuck).
Yikes, these really belong into the surrounding widget.
Andreas
--
[ signature omitted ]
Message 3 in thread
Andreas Pakulat wrote:
> On 31.01.07 11:23:09, Martin wrote:
>> On the other hand, for creating new items or deleting existing ones,
>> there's no standard user interface on the views and thus no standard API
>> between view and model.
>
> Then you missed a part of the model documentation. There is a well
> defined API on how to remove items from a model, namely removeRows. The
> same goes for adding rows, insertRows is the function that exists.
Sorry for not mentioning these methods, you are right. I do know
insertRows/removeRows, but I don't see how they can be used with a
somewhat complex domain model. If there are at least two different kinds
of items that can be inserted, how should the model know what to do in
#insertRows?
>> You'd have to let the user press a 'Delete'
>> button which invokes a slot executing the delete command. This slot
>> would probably be implemented in some controler class.
>
> Yes, but all you'd do in the slot is calculate the current selection and
> tell the model to remove all indexes of the selection.
Ok removing is rather trivial, but for creating new items you
essentially propose that the model provides the methods, right? That's
what I currently do and would like to get rid of :) But I think there's
no real alternative...
Thanks so far!
M
--
[ signature omitted ]
Message 4 in thread
On 31.01.07 14:23:15, Martin wrote:
> Andreas Pakulat wrote:
> > On 31.01.07 11:23:09, Martin wrote:
> >> On the other hand, for creating new items or deleting existing ones,
> >> there's no standard user interface on the views and thus no standard API
> >> between view and model.
> >
> > Then you missed a part of the model documentation. There is a well
> > defined API on how to remove items from a model, namely removeRows. The
> > same goes for adding rows, insertRows is the function that exists.
>
> Sorry for not mentioning these methods, you are right. I do know
> insertRows/removeRows, but I don't see how they can be used with a
> somewhat complex domain model. If there are at least two different kinds
> of items that can be inserted, how should the model know what to do in
> #insertRows?
Well, if the type of node inserted doesn't depend on the position in the
model you need to provide a way of telling your model. Alternatively you
may provide a way to change the type of node later on and thus create
the "most used" node when inserting a row.
> >> You'd have to let the user press a 'Delete'
> >> button which invokes a slot executing the delete command. This slot
> >> would probably be implemented in some controler class.
> >
> > Yes, but all you'd do in the slot is calculate the current selection and
> > tell the model to remove all indexes of the selection.
>
> Ok removing is rather trivial, but for creating new items you
> essentially propose that the model provides the methods, right? That's
> what I currently do and would like to get rid of :) But I think there's
> no real alternative...
Why do you want to get rid of that? It feels natural to me that a model
provides proper ways of creating new items in it, and if the existing
methods of the base class do not provide enough control over the
creation process you have to extend the base model.
Andreas
--
[ signature omitted ]
