Signal flag changes for QAbstractItemModel
-
Hi,
AFAIK, the flags are check "on use" so if you double click on an item which you just changed flags for not editable it should already take it into account.
wrote on 3 May 2023, 08:27 last edited by@SGaist
I come from looking at topic https://forum.qt.io/topic/144826/problem-using-an-integer-in-a-const-function-after-changing-its-value.I think your answer was "not good enough" :) , and @kshegunov's question is a good one. Let's say you do not "click an item", which doubtless would have caused that item to be re-evaluated/redrawn, but instead happen to do something in code which will cause
flags()on some item to now return a different value. What is going to cause that item/flags to be re-evaluated? Nothing, I think.Since there is no "flags changed" signal I can only guess you would have to use
dataChanged(), perhaps forDisplayRoleor all roles, just to get e.g. a table view to update from the model's new flags. -
@SGaist
I come from looking at topic https://forum.qt.io/topic/144826/problem-using-an-integer-in-a-const-function-after-changing-its-value.I think your answer was "not good enough" :) , and @kshegunov's question is a good one. Let's say you do not "click an item", which doubtless would have caused that item to be re-evaluated/redrawn, but instead happen to do something in code which will cause
flags()on some item to now return a different value. What is going to cause that item/flags to be re-evaluated? Nothing, I think.Since there is no "flags changed" signal I can only guess you would have to use
dataChanged(), perhaps forDisplayRoleor all roles, just to get e.g. a table view to update from the model's new flags.@JonB indeed, there's nothing to notify that specific change.
I am wondering whether dataChanged conveys that idea at all since it's there was in fact nothing changed data wise. -
@JonB indeed, there's nothing to notify that specific change.
I am wondering whether dataChanged conveys that idea at all since it's there was in fact nothing changed data wise.wrote on 3 May 2023, 20:51 last edited by JonB 5 Mar 2023, 20:53@SGaist
dataChanged()does not really convey that. But as @kshegunov said there isn't a role for "flags". I imagineDisplayRolewill have the desired effect of forcing it to re-evaluate theflag()s and see e.g. item enablement change, so you would get the desired behaviour for the wrong reason. -
@SGaist
dataChanged()does not really convey that. But as @kshegunov said there isn't a role for "flags". I imagineDisplayRolewill have the desired effect of forcing it to re-evaluate theflag()s and see e.g. item enablement change, so you would get the desired behaviour for the wrong reason.@JonB maybe coupled with
EditRolesince the flag change might also influence that part. -
I am sure there are some corner cases that will be fun
-
Well, I'd long forgotten about this topic, but I would think we actually need a
flagsChanged(QModelIndex, QModelIndex)signal, which would be "the right way"™. I didn't open a feature request at the time, but maybe one of you might feel strongly enough about it to do so. -
Well, I'd long forgotten about this topic, but I would think we actually need a
flagsChanged(QModelIndex, QModelIndex)signal, which would be "the right way"™. I didn't open a feature request at the time, but maybe one of you might feel strongly enough about it to do so.wrote on 6 May 2023, 08:21 last edited by@kshegunov
It would indeed! But then the issue is: who wants to go through all the code finding every occurrence whereflags()has changed to decide what needs to be done in response? And in practice would it be any more or less thandataChanged(index, index, {})does? :) -
@kshegunov
It would indeed! But then the issue is: who wants to go through all the code finding every occurrence whereflags()has changed to decide what needs to be done in response? And in practice would it be any more or less thandataChanged(index, index, {})does? :)@JonB said in Signal flag changes for QAbstractItemModel:
It would indeed! But then the issue is: who wants to go through all the code finding every occurrence where
flags()has changed to decide what needs to be done in response?It should be painless in the sense that it's a new signal, so nobody needs to actually do anything to keep old code working.
And in practice would it be any more or less than
dataChanged(index, index, {})does? :)Possibly, as you don't go around querying the data from the model, albeit I'm not sure if that's really relevant, as in the end you may need to.
-
@JonB said in Signal flag changes for QAbstractItemModel:
It would indeed! But then the issue is: who wants to go through all the code finding every occurrence where
flags()has changed to decide what needs to be done in response?It should be painless in the sense that it's a new signal, so nobody needs to actually do anything to keep old code working.
And in practice would it be any more or less than
dataChanged(index, index, {})does? :)Possibly, as you don't go around querying the data from the model, albeit I'm not sure if that's really relevant, as in the end you may need to.
wrote on 6 May 2023, 08:32 last edited by@kshegunov said in Signal flag changes for QAbstractItemModel:
Possibly, as you don't go around querying the data from the model, albeit I'm not sure if that's really relevant, as in the end you may need to.
Because of, say,
Qt::ItemIsEnabledflag, which shows item differently, won't it end up having to access item'sDisplayRolewhich has to query the model to get the text again to show it dimmed? -
@kshegunov said in Signal flag changes for QAbstractItemModel:
Possibly, as you don't go around querying the data from the model, albeit I'm not sure if that's really relevant, as in the end you may need to.
Because of, say,
Qt::ItemIsEnabledflag, which shows item differently, won't it end up having to access item'sDisplayRolewhich has to query the model to get the text again to show it dimmed?@JonB said in Signal flag changes for QAbstractItemModel:
Because of, say,
Qt::ItemIsEnabledflag, which shows item differently, won't it end up having to access item'sDisplayRolewhich has to query the model to get the text again to show it dimmed?It may, which was my original argument - it (the signal) could simply do nothing significant in the end.
-
@JonB said in Signal flag changes for QAbstractItemModel:
Because of, say,
Qt::ItemIsEnabledflag, which shows item differently, won't it end up having to access item'sDisplayRolewhich has to query the model to get the text again to show it dimmed?It may, which was my original argument - it (the signal) could simply do nothing significant in the end.
I wonder how often this use case happens.
-
@SGaist said in Signal flag changes for QAbstractItemModel:
I wonder how often this use case happens.
I'd imagine for any nontrivial use of the item model, this will happen. In the case of widgets it probably won't matter anyway, as you'd want to immediately redraw whatever it is you're showing; but with Qt quick it may actually be a malice on performance, since it would invalidate the scene graph node (which may or may not be a problem, I haven't actually looked at the implementation).
-
@SGaist said in Signal flag changes for QAbstractItemModel:
I wonder how often this use case happens.
I'd imagine for any nontrivial use of the item model, this will happen. In the case of widgets it probably won't matter anyway, as you'd want to immediately redraw whatever it is you're showing; but with Qt quick it may actually be a malice on performance, since it would invalidate the scene graph node (which may or may not be a problem, I haven't actually looked at the implementation).
wrote on 9 May 2023, 08:48 last edited by@kshegunov
One might actually need the signal to tell us which flags have changed. Only certain flag changes affect anything we are interested in, several seem not relevant.
14/18