BeginResetModel() not working
-
How do you know they are meaningless? They just don't do what you expected them to do. How do you know that the view may not have an optimization so that at the moment it receives the modelAboutToBeReset signal, is stops listening or does other clever stuff such as clearing a cache or whatever magic needs to be done? I don't. And I certainly don't know that of any custom view living out there in the wild. What is done with the signal in the default Qt views, you can find out by inspecting the source code of those views yourself.
Anyway: where is it documented that the beginResetModel blocks a return to the eventloop? How should that even work? Like I said: I imagined it would block further signals (and that would have been possible to do), but it does not. But returning to the eventloop is something that is very hard to prevent.
If I miss your whole point, then perhaps you should try to explain it again, but this time without complaints that your assumptions of how Qt model view works don't match with reality. Then, perhaps, we can help you search for a solution or a workaround for your specific scenario. We all know that Qt model view is not perfect and that some use cases are hard to implement with it.
-
[quote author="Andre" date="1348649547"]How do you know they are meaningless? They just don't do what you expected them to do. [/quote]
Because if you don’t get returned to eventloop views simply can't query data from the model (with or without beginResetModel/endResetModel) by themselves (unless directly asked to do so, indeed). But if you do (despite beginResetModel) they will, which means they are still listening. Rather simple logic, right?
[quote author="Andre" date="1348649547"]Anyway: where is it documented that the beginResetModel blocks a return to the eventloop? How should that even work? Like I said: I imagined it would block further signals (and that would have been possible to do), but it does not. But returning to the eventloop is something that is very hard to prevent[/quote]
It's written in the docs that beginResetModel/endResetModel are used for safe resetting of the model internal data structures, which these methods fail to do. That's all
[quote author="Andre" date="1348649547"]If I miss your whole point, then perhaps you should try to explain it again, but this time without complaints that your assumptions of how Qt model view works don't match with reality[/quote]
These are really not my assumptions. It's not me who started talking about event loops
[quote author="Andre" date="1348649547"]Then, perhaps, we can help you search for a solution or a workaround for your specific scenario. We all know that Qt model view is not perfect and that some use cases are hard to implement with it[/quote]
I have already found a workaround (see above)
-
[quote author="deisik" date="1348648089"][quote author="peppe" date="1348647631"]
- beginResetModel/endResetModel will simply cause the emission of the model's modelAboutToBeReset / modelReset signals, update bookeeping information (persistent indexes), etc.
- views are allowed to ask for data() at any time, therefore returning to the event loop with the model in a "inconsistent" state is wrong[/quote]
Your first proposition contradics the second one. Views being allowed to ask for data at any time means that model should always be in a consistent state. And what about resetting model in this case?
[/quote]I think you're missing an obvious assumption, my fault: from the point of view of your code, Qt is a single-threaded and event-driven. (You can start other threads but that's out the question here, we're in the GUI thread.)
Therefore, the view's code that fetches data cannot be running at the same time you're updating the model. The views might fetch in response to the signals you emit when you call begin*/end* methods, but this makes no sense to me (and in any case, WHEN you're calling those methods, the model IS ALREADY in a consistent state. Either it's BEFORE any modification happened, or it's AFTER all modifications have been made).
-
[quote author="peppe" date="1348647631"]In your testcase you're simply adding rows/columns with a progress, and therefore you should actually be using beginInsertRows / beginInsertColumns; or, complete the model reset in each iteration, before returning to the event loop.[/quote]
Yes, just to show that the program will crash. In the actual model the data is changed completely, rows/columns can be added, removed or their number can remain the same, but all data is changed in all rows/columns
-
[quote author="peppe" date="1348651164"]Therefore, the view's code that fetches data cannot be running at the same time you're updating the model. The views might fetch in response to the signals you emit when you call begin*/end* methods, but this makes no sense to me (and in any case, WHEN you're calling those methods, the model IS ALREADY in a consistent state. Either it's BEFORE any modification happened, or it's AFTER all modifications have been made).[/quote]
That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this (even if there're no signals WITHIN this block or any other which is explicitly being called)
-
[quote author="deisik" date="1348651720"]That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this
[/quote]
And it seems that you were (are still?) assuming that beginResetModel() would (should?) somehow enforce that, no matter what you did before calling endResetModel(). That assumption turns out to be wrong.
-
[quote author="deisik" date="1348651720"]
That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this
[/quote]The fact that your application is single threaded DOES guarantee this.
-
[quote author="Andre" date="1348651988"]And it seems that you were (are still?) assuming that beginResetModel() would (should?) somehow enforce that, no matter what you did before calling endResetModel(). That assumption turns out to be wrong.[/quote]
It strictly follows from the docs
-
[quote author="peppe" date="1348652004"]
[quote author="deisik" date="1348651720"]
That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this
[/quote]The fact that your application is single threaded DOES guarantee this.
[/quote]
Well, except if you return to the eventloop, spin a new one or otherwise start processing events somewhere between calling the beginResetModel() and endResetModel(), of course... Which seems to be exactly what happened here. -
[quote author="deisik" date="1348652087"][quote author="Andre" date="1348651988"]And it seems that you were (are still?) assuming that beginResetModel() would (should?) somehow enforce that, no matter what you did before calling endResetModel(). That assumption turns out to be wrong.[/quote]
It strictly follows from the docs
[/quote]
Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed. -
[quote author="peppe" date="1348652004"]The fact that your application is single threaded DOES guarantee this[/quote]
Data queries by the views happen within beginResetModel/endResetModel block. The fact that the application is single threaded guarantees that query won't happen simultaneously with a single command which makes some data change in this block but this query still happens inside this block (interrupts it)
-
[quote author="Andre" date="1348652298"]Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed.[/quote]
I told "follows", do you get the difference? It's written at the beginning of the thread (no pun intended)
-
[quote author="deisik" date="1348652600"][quote author="Andre" date="1348652298"]Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed.[/quote]
I told "follows", do you get the difference? It's written at the beginning of the post
[/quote]
Ok, so let met get that back into fresh memory here:
[quote author="deisik" date="1328354153"]As per documentation, "you must call this function before resetting any internal data structures in your model or proxy model" and regarding its counterpart, endResetModel(), "you must call this function after resetting any internal data structure in your model or proxy model". Rational reasoning tells me that by beginResetModel() you declare your data being no longer valid (read unavailable) and by endResetModel() being valid again while changing it somewhere in between so that any views getting data from the model should shrink from quering data which is not yet ready. Everything seems consistent and coherent in this simple logic, right?[/quote]
There are a lot of assumptions in your reasoning above, that just are not valid. Yes, sure, it would be nice if Qt would somehow enforce all the above automaticaly (patches welcome, I think), but it doesn't, and the docs don't tell you that it does protect you from that.
I will agree with you that the issues with spinning an eventloop are not clearly documented, nor is the real function of the beginResetModel() function itself. Also, it isn't immediately clear that a progress dialog even does spin an eventloop or how it otherwise processess events. It clearly does (otherwise, it would not be able to update itself), but again: there is no documentation to warn you against side effects of that. I too would have expected the beginResetModel() method to do more work than it does. However, nowhere there is a promise in the docs that you are protected against queries in the way you seem to be deducing from the docs.
[quote author="deisik" date="1348652495"][quote author="peppe" date="1348652004"]The fact that your application is single threaded DOES guarantee this[/quote]
Data queries by the views happen within beginResetModel/endResetModel block. The fact that the application is single threaded guarantees that query won't happen simultaneously with a single command which makes some data change in this block but this query still happens inside this block (interrupts it)[/quote]
Sorry, but no. There are no "interrups" happening in Qt. It must be caused by some call made by you between the begin/end calls that triggers processing events or something like that. My bet (again: not checked against sources or tested myself): your calls to update your progress dialog are the culprit. -
There is very SIMPLE reasoning behind my assumptions. Views should in NO case query invalidated data from the model being reset, not even because the data has changed but because this may easily crash the program (e.g. you already deleted some rows/columns, but have not yet updated the variables holding their number). And this is what is meant by docs when you read that “you must call this function before resetting any internal data structures in your model or proxy model”
I don't really see why you don't understand these things
-
[quote author="Andre" date="1348653224"]Sorry, but no. There are no "interrups" happening in Qt. It must be caused by some call made by you between the begin/end calls that triggers processing events or something like that. My bet (again: not checked against sources or tested myself): your calls to update your progress dialog are the culprit.[/quote]
This is no secret. The problem is that the views should be FORBIDDEN to query invalidated data in ANY case (unless explicitly called to do so, of course). And beginResetModel tells views just that (which views don't follow). If you don't understand this, it's beyond my power to explain you this
-
I tried my best to explain you how I see this, and how I diagnose the problem, and where the problem in your reasoning is. For naught, clearly. It seems we won't get to an understanding on this issue. Like I said: I guess patches are welcome, to the documentation and/or the views.
Edit:
Interesting quote from the [[doc:QProcessDialog]] docs:
[quote] warning If the progress dialog is modal (see QProgressDialog::QProgressDialog()), setValue() calls Application::processEvents(), so take care that this does not cause undesirable re-entrancy in your code. For example,don't use a QProgressDialog inside a paintEvent()![/quote] -
By beginResetModel we explicitly declare that data in our model is no longer valid. What you're trying to say boils down to saying that there is some sense in quering invalidated data. What sense?