best way to model a non Qt classes without adding dependencies
-
I am familiar with working with qabstractitemmodel in the way it is shown in the examples
the model is usually a pointer inside the inherited object or the actual data inside it .my aim is to model non Qt related class without inherit it.
so far what i have done is building a non qt interface to the model and use it as a pointer in the
qabstractitemmodel inherited class.but this is good only for read only models.
when i want to create an editable model than i must inform Qt somehow about the changes i am going to make . (before and after signals)
but what if the changes didn't come from the Gui controller , say I have internally changed the model from somewhere else ? how can the Qt model know about it ?
all the examples that i saw in the help have a very tight Qt<-> model relation.
just inherit your model from the qabstractitemmodel and make all the changes through its interface.there must be an other way that would keep my domain seperated.
ps
i am working with widgets not qml
-
I am familiar with working with qabstractitemmodel in the way it is shown in the examples
the model is usually a pointer inside the inherited object or the actual data inside it .my aim is to model non Qt related class without inherit it.
so far what i have done is building a non qt interface to the model and use it as a pointer in the
qabstractitemmodel inherited class.but this is good only for read only models.
when i want to create an editable model than i must inform Qt somehow about the changes i am going to make . (before and after signals)
but what if the changes didn't come from the Gui controller , say I have internally changed the model from somewhere else ? how can the Qt model know about it ?
all the examples that i saw in the help have a very tight Qt<-> model relation.
just inherit your model from the qabstractitemmodel and make all the changes through its interface.there must be an other way that would keep my domain seperated.
ps
i am working with widgets not qml
@orio
It does not matter which way you look at it, if you want to update the data in the model you must ultimately callQAbstractItemModelmethods likebeginInsertRows()orsetData()or emit therowsInserted()ordataChanged()signals.If you don't want the outside world to know about this or Qt models/classes you can wrap your model as a member in non-Qt classes and provide your own methods for necessary functionality, which calls these as necessary internally.
-
@JonB said in best way to model a non Qt classes without adding dependencies:
know about this or Qt models/classe
what do you suggest to wrap? the qt model?
i dont want qt in my domain at all -
Hi,
One possible, and maybe a bit convoluted, way would be to add a callback API to your non-Qt model. Then your Qt model should register the usual suspects and your custom model would call them as expected.
-
maybe i am confused with data and qtmodel .
say i have an existing class , pure Cpp , all i want to do is model it , so i subclass the qabstractitemmodel ,thats the qtmodel , but then when i want to change data that is member inside my real class i must go through the qt model , otherwise it wont know what was changed .another question is if i need to model that business object class or to model a copy of its data
-
maybe i am confused with data and qtmodel .
say i have an existing class , pure Cpp , all i want to do is model it , so i subclass the qabstractitemmodel ,thats the qtmodel , but then when i want to change data that is member inside my real class i must go through the qt model , otherwise it wont know what was changed .another question is if i need to model that business object class or to model a copy of its data
@orio
If you "directly" change what is in your underlying data used by a Qt model you must emit the necessarydataChanged()/rowsInserted()etc. signals on theQAbstractItemModel. That is what Qt views etc. have slots attached to so that they know the model data has changed and adjust to redisplay. How you arrange to do that is up to you. At that level your internal data code will need to know something about there being a Qt model attached. You might even have your own data level have enough Qt knowledge to emit its own signals on data modification to which theQAbstractItemModelhas slots attached, which it uses to translate these internal signals into theQAbstractItemModelsignals needed, which would mean your level doesn't need to need to know about the Qt model internals. -
It does not need to know anything about Qt headers. You are asking to be able to modify your data structure from some esoteric place and the model on top of it should "just know" that it has changed. One way to do that would be to keep a copy of the data and poll for changes on a regular basis. That's not very efficient. I suggested you one possible way to do that using callbacks. With them you can notify interested parties that something has changed.
In any case, having a "pure data structure" and expecting the rest of the surrounding code to know when it has changed and what has changed without any additional logic is not something you will be able to achieve. However, there's no need to for your data structure to know anything about Qt in order to achieve update information propagation.