Qt-interest Archive, February 2007
Re: model/view with undo
Message 1 in thread
Andreas Pakulat wrote:
> 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.
That unfortunately doesn't work for me.. the model is a tree with two
node types, containers and leafs. Containers may contain both node
types. So there is no way of telling what type an inserted row should
be, forcing me to provide a custom way for item creation, while there
are standard ways of item removing and editing. That's what I don't like
the (code) smell of.
>>>> 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.
I came to understand that the QAbstractItemModel classes in the Qt
model/view framework are rather adapters to domain models than the
actual models. That's why I don't like the idea of doing manipulation on
the domain model in there.
M
--
[ signature omitted ]
Message 2 in thread
On 01.02.07 08:58:03, Martin wrote:
> Andreas Pakulat wrote:
> > 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.
>
> That unfortunately doesn't work for me.. the model is a tree with two
> node types, containers and leafs. Containers may contain both node
> types. So there is no way of telling what type an inserted row should
> be, forcing me to provide a custom way for item creation, while there
> are standard ways of item removing and editing. That's what I don't like
> the (code) smell of.
Sorry, I don't get this. Why is it a problem to insert a new container
item into the tree as reaction to a button called "add Container" being
clicked? As I said above another way would be to just add a container by
default and let the user change it to a leaf node any time.
> >>>> 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.
>
> I came to understand that the QAbstractItemModel classes in the Qt
> model/view framework are rather adapters to domain models than the
> actual models. That's why I don't like the idea of doing manipulation on
> the domain model in there.
If you want to have the insert/remove/edit stuff in your domain model,
for whatever reasons, thats not a problem either. Of course your domain
model needs a way to communicate with the Qt model then, for example a
signal that is connected to the Qt models layoutchanged signal and
similar.
Still if your Qt model is a Qt wrapper around your domain model and you
don't expect your domain model to be modified via external apps than I
don't really see the problem in having the Qt model forward
model-changes to the underlying domain model. After all thats what a
wrapper is for.
Andreas
--
[ signature omitted ]
